#вашивопросы

Есть мнение, что востребованность фронтэнд-разработчиков снижается, т.к. много новичков идут именно в эту область. Поэтому хотелось бы узнать Вашего мнения: у фронта-джуна есть риск в 2021 застрять на этапе поиска работы? Если "рынок" и правда перенасыщен, повлияет ли это на средний уровень зп?

Рынок фронтенд-разработки я не изучала, но про IT в среднем могу сказать так: многие компании постоянно находятся в состоянии кадрового голода. Найти хорошего специалиста (не обязательно опытного, можно и перспективного новичка) - это задача, которая может занять и полгода и год времени. Поэтому когда я слышу про снижение спроса на разработчиков, это всегда вызывает некоторый скепсис.

Ваша задача - сделать из себя именно хорошего специалиста - выкрутите на максимум свою любознательность и перфекционизм и относитесь к задачам добросовестно - и всё, вы будете выделяться из толпы. Найти пофигиста, который пишет говнокод и не планирует улучшать свои навыки («чик-чик и в продакшен»), необучаемого человека или эникейщика - гораздо проще, чем кого-то стоящего.

Перенасыщенный рынок я могу представить среди компаний, которые не сильно заморачиваются качеством разработчиков, а нанимают кого подешевле - как-нибудь склепал сайт, и нормально.

Что касается зарплат - если вы станете хорошим специалистом, вы сможете претендовать на уровень зарплаты выше средней и на работу в хорошей компании.

Анализом рынка я не занималась, так что это всё не более чем субъективное видение - но пока что сайты нужны всем, а значит, всем нужны разработчики сайтов.

И, наконец, если вас и правда беспокоят перспективы фронтендеров - изучайте и бэкенд тоже - учитесь сразу на фуллстек-разработчика - тогда при желании сможете переметнуться в любое из направлений и точно не пропадете.

Задать вопрос автору блога можно здесь: @hum_it_bot

#плохойкод

Как писать красивый код

Красивый код (как и хороший код) - это нечто мифическое: все о нём говорят, но никто не видел.
А вот с плохим кодом сталкивались все.

Если вы уже написали хотя бы 1000 строчек своего кода, советую обзавестись книгой Макконнелла Совершенный код (кстати, еле её нашла, на литресе и еще в двух местах она пропала). Тут есть всё, что нужно знать про код - от грамотных названий для переменных до правильного использования классов и функций. Для совсем начинающих она сложновата, но можете купить «на вырост» - это однозначно мастхэв.

А пока что наша с вами цель - писать нормальный код, хотя бы не плохой. Поэтому сегодня начинаем рубрику «что такое плохой код» и «как делать не надо».

Начинающие разработчики иногда гордятся тем, какой сложный код у них получается, но это ошибка новичка. Код должен быть настолько простым и легко читаемым, насколько это возможно. Ниже пример того, что делать не надо (циклы внутри циклов внутри циклов внутри циклов…) :

for (int i; ...) {
      
     
    for (int j;…) {

        // какой-то код

        for (int k;…)) {

           // код

            for (int l;…)) {

                // ещё код

                while (true) {
                    ...
                }
            }
        }
    }
}

То же касается и «многослойных» if-конструкций:

if (smth == true ) {

    // код
 
    if (smth_else == true) {

        if (smth_other == true) {

            // код 
        }
        else {

            // код 
        }
    }
    else if (smth) {

        // код 
    }
}
else {

     // код 
}

Проследить, в какой ветке if-else в этой «лестнице» ты находишься в разный момент исполнения и ни разу не запутаться - практически невозможно. Остаётся только гадать «что же хотел сказать автор?».

#вашивопросы

Добрый день, у меня возник вопрос по поводу "плохого кода", а именно (цитата) "циклы внутри циклов внутри циклов внутри циклов" (c), подскажите, пожалуйста, как тогда перебрать все элементы двумерного массива, без использования кмк очевидного цикла внутри цикла?

А я и не говорила, что никогда нельзя писать один цикл внутри другого. Бывают ситуации, когда это нужно или даже неизбежно.

Идея в том, что когда уровень вложенности становится очень большим - код становится сложным для восприятия и запутанным. То есть, если вы заметили, что пишете уже 3й(4й, 5й, 6й) вложенный цикл - и получается целая «матрёшка» или «слоёный пирог» из циклов - лучше остановиться и подумать, как переписать этот код (например, то, что происходит в циклах - вынести в отдельные функции).

То же касается бесконечных «ветвей» if-else. Если ваш код похож на лестницу (за счет отступов перед if-ами и for/while) - вероятно, его нужно упрощать.

Что касается двухмерных (трехмерных итд) массивов - чаще всего они встречаются в учебных задачах и довольно редко встречаются на практике (хотя зависит конечно от продукта, который вы разрабатываете).
Но если с ними всё же пришлось столкнуться в условиях боевой разработки, скорее всего, лучшим решением будет написать класс, в котором будут реализованы все операции с массивом, так чтобы в остальной части программы все задачи решались с помощью методов этого класса, а не с помощью прямого доступа к элементам массива.

Задать вопрос автору блога можно здесь: @hum_it_bot

7 дней

Эту неделю мне по работе нужно было заниматься фротэндом сайта (я бэкенд-разработчик), поэтому она прошла в режиме «кодить по 12 часов в день на React». Для тех, кто не в теме, React - это веб-фреймворк на JavaScript.

Так вот, могу заявить официально: чтобы разобраться с React-ом, разработчику с опытом нужно примерно 7 дней.

Вот какие стадии я прошла за неделю:

Первые дни: стадия отрицания. Вообще не понимаю, как работает React, просто копирую куски кода из другой части сайта с похожими страницами и меняю чуть-чуть под свои задачи, и так пока оно хоть как-то заработает. В документации написана какая-то муть, ничего не понятно. Столько всяких нюансов в этом вашем фронтенде, что в этом наверно полгода надо разбираться. Скучаю по бэкенду - там всё так просто и очевидно.

Середина недели: начинаю врубаться, что там как работает и какие компоненты для чего нужны. Появляется понимание, как нужно писать код. Прихожу в ужас от того, что накопипастила за предыдущие дни и понимаю, что это нужно переписать нормально. Переписываю весь свой код нормально и уже понимаю, как там что работает.

Конец недели: React - это довольно просто и удобно. В нём уже всё есть, и практически ничего не нужно придумывать и разрабатывать из головы - берешь готовые компоненты и из них складываешь как конструктор. И документацию в интернете очень легко искать - её много, написана понятным языком. Есть куча дополнительных модулей, в которых точно найдётся всё, что нужно для решения задач. Практически не нужно писать кода на чистом JavaScript. Задача закончена, сайт работает как нужно.

Конечно, настоящий хороший фронтэнд-разработчик в отличие от таких как я - знает все best practices - какие методы лучше подходят для каких ситуаций, как писать красивый и грамотный код, какое решение в какой ситуации будет более эффективным и потребует меньше оперативной памяти, будет меньше нагружать браузер (и компьютер пользователя). Я как человек, не работающий с фронтэндом, таких тонкостей не знаю - я просто пишу код методом проб и ошибок, и делаю так, чтобы он заработал.

Но в целом мой пример - это то, как происходит освоение новых технологий в процессе работы. Для опытного разработчика освоить любой другой язык программирования (или фреймворк, или технологию) - это не проблема. Мы часто делаем это без всяких книг или курсов - просто берём новый язык, и сразу начинаем на нём разрабатывать, а с непонятными нюансами разбираемся по ходу дела.

Конечно, супер-специалистом по новой технологии вот так за 1 неделю не станешь: решения поначалу будут очень сырыми, а код - говнокодом. Но что я хотела тут до вас донести: осваивать новое - это не так уж сложно и чтобы разобраться с азами и сделать небольшой проект - нужно не так уж много времени. И чем дольше вы работаете (пусть даже с другими технологиями), тем это будет даваться проще и быстрее. Так что не бойтесь IT, тут всё реально. 🙂

#вашивопросы

Расскажите, пожалуйста, как нашли первую работу программистом, сколько собеседований было до неё

1 собеседование было, после него сразу же устроилась работать. Параллельно собеседовалась во вторую компанию, но туда не попала. Подробнее я об этом писала в этом посте.

Узнала о программе для мам с маленькими детьми (а я как раз она) от центра занятости населения совместно с Синергией. Они предлагают переобучение, в тч на it-специальности. Например, фронтенд, тестирование, создание приложений. Отзывы об этой шляпе только от "наших студентов, которые прошли переподготовку", никаких объективных. Зато о самой Синергии отзывы как о шаражке с инфоцыганами. Это дело бесплатное, если тело одобрят, вроде даже стипендию обещают. Сказали, что мое гуманитарное образование - не помеха. Слышали ли вы о них? Для меня это был бы хороший вариант, бесплатно и дистанционно.

Программа бесплатная и у вас есть интерес - так о чём тут раздумывать? Не понравится - можно будет бросить её. Денег на этом вы не потеряете.

А отзывам я в последнее время не очень-то и доверяю: создаётся ощущение, что их часто пишут просто люди с дурным характером, которые не мотивированы обучаться, а только жалуются и ворчат. И в любом случае, инфоцыганство - это когда за деньги, а если бесплатно - то в чем вообще претензия?

Задать вопрос автору блога можно здесь: @hum_it_bot

#вашивопросы

Я хочу узнать, где учатся на тестеров. Мне вот больше нравится искать баги в чужой работе, чем писать код. Предполагаю, что основы программирования все равно нужны?

На моей памяти на самые простые тестерские вакансии брали людей без опыта вообще - но речь шла о ручных тестах, где нужно было, условно говоря, «протыкать» кнопки в интерфейсе и убедиться, что всё ок.

Более квалифицированные (и следовательно высокооплачиваемые) тестировщики, как минимум, шарят в методике тестирования и владеют всеми необходимыми для этого инструментами - этому можно научиться либо на работе (если компания нацелена на ваше повышение квалификации) - в этом случае вырасти в хорошего профессионала можно из начинающего тестера, который пришел с нулевыми знаниями. Либо набраться знаний заранее самостоятельно, например, на курсах.

Что касается программирования - тут мнения разнятся. В некоторых компаниях исходят из того, что «писать код должны уметь все». Кто-то считает, что тестировщик должен понимать в общих чертах, как работает код и уметь при необходимости прочитать и понять отдельные его фрагменты. А некоторые считают, что тестировщики не должны быть программистами, им нужно владеть своим инструментарием, а не кодом заниматься.

А в некоторых компаниях тестировщики - это люди, которые пишут код автотестов, то есть это по факту уже программисты, а не тестировщики в привычном понимании.

Так что на счет необходимости программирования - всё зависит от подхода в конкретной компании, универсального ответа нет.

Что касается курсов по тестированию, вот небольшая подборка:

- Факультет тестирования ПО от Geekbrains с гарантией трудоустройства. Или более корткий курс Тестировщик ПО там же.

- Курс Тестировщик от Нетологии.

- Курс-симулятор Тестировщик программного обеспечения от Skillfactory.

- Если хотите варианты подешевле и готовы учиться в более самостоятельном режиме, посмотрите список курсов например от Udemy (UPD 2022 - cейчас из-за санкций оплатить курсы студентам из России там нельзя) - там много всего есть, в том числе дешевле тысячи рублей. Тут в отличие от предыдущих вариантов никто не обещает содействие в трудоустройстве, но главное ведь - скиллы, а не то, где вы их приобрели, и сколько за это заплатили.


Задать вопрос автору блога можно здесь: @hum_it_bot

#плохойкод

Сегодня продолжаем серию о том, как не надо писать код.

Смешение стилей

Скажем, в Python многие любят использовавть snake case, то есть соединять слова между собой нижним подчеркиванием, в результате получаются вот такие переменные: my_variable, my_other_variable. А где-то принято использовать camel case: myVariable, myOtherVariable. И тут важна последовательность - если в коде проекта уже принят один стиль, не надо туда добавлять переменные, использующие другой стиль, так чтобы my_variable соседствовали с myVariable.

Это же касается и, к примеру, переноса фигурных скобок (если они есть в языке) - переносить во всем проекте их надо одинаковым образом, а не где-то с новой строки, а где-то нет.

Названия для переменных

Худшее, что можно придумать - это называть переменные x, y, z, a, b, c, var1, var2, num1, num2 и так далее.
Имя переменной должно рассказывать о том, что в ней содержится (помните, что код должен быть читаемым и понятным для другого человека, не только для вас одного?).

Придумывайте информативные имена, например: average_salary, person_age, count_clicks - никаких переменных в одну букву.

Исключение: переменные итераторов (for int i; i++) - в таких циклах традиционно используют переменные i, j, k.

Не забывайте и про имена функций - они тоже должны быть «говорящими». Не называйте функции, например, do_everything() или do_calculations() - из такого имени непонятно, что именно функция делает или считает, нужно конкретнее: find_person_by_id() - например, ни у кого не вызовет недопонимания.

Магические цифры

Magic numbers - это когда вы используете в коде просто цифры.
Например: x = y * 100 / 2 + 365 - и читающему код непонятно, почему мы умножаем y именно на 100 и делим именно на 2, что это за 365, и так далее. Как это исправить? Использовать константы вместо чисел, например:

DAYS_IN_A_YEAR = 365
PERCENT_VALID = 100
DIVIDE_RATE = 2

x = y * PERCENT_VALID / DIVIDE_RATE + DAYS_IN_A_YEAR

Пример - вымышленный, и смысла в этом вычислении нет, он чисто для демонстрации того, как избегать магических чисел.
И да, как вы могли заметить, x и y - это плохие названия для переменных. 🙂

Напоминаю, что если вы хотите увидеть в канале ответ на свой вопрос, или хотите больше постов, посвященных какой-то конкретной теме, вы можете написать мне сюда: @hum_it_bot

#вашивопросы

Вот я и свитчнулся в 32 года в Андроид разработчика. Шёл с некоторыми знаниями по яве и несколько большими именно по Андроиду и инфраструктуре, а проект на Kotlin. "Он простой и не отличается почти". Ну да, как же. Работаю чуть больше месяца, а какие-то базовые вещи о котлине узнаю каждый день. В связи с чем в свободное время стараюсь изучать базу по Котлину. Но появляется такой вот момент: работать над своими проектами времени нет вообще. Пока пришёл к тому, что в один из вечеров выходных вместо отдыха время отдаю проектам. Так что скорость будет черепашья, но хоть что-то.

Какие советы будут? Отказаться от отдыха вообще считаю неправильным, выгорание знакомо и так. Жертвовать учёбой ради проектов тоже не уверен, что стоит, но и проекты хочется развивать 😷

Первые несколько месяцев на работе, особенно если это первый подобный опыт - самые тяжелые. Но даже и разработчикам с опытом, когда они меняют работу, первое время приходится вникать, как там что устроено на новом месте и осваивать новые технологии.

В этот период сложно находить время и ресурсы на что-либо другое в жизни - у меня, например, не хватало времени ни на какие хобби или развлечения, да и банально на то, чтобы книжку почитать - тоже.

Так что мой совет - не старайтесь запихнуть сейчас в свой график много дел (в том числе ваши проекты). Вам нужно время на адаптацию, на усвоение недостающих знаний (на kotlin), на то, чтобы всё это улеглось в голове. Через полгода должно стать полегче, и уже будет проще успевать что-то ещё.

Задать вопрос автору блога можно здесь: @hum_it_bot

​Поиск работы

Мне часто задают вопрос, где и как я искала работу - а мне, признаюсь, и ответить-то нечего: такое, что я прям сама искала работу, а не она - меня, было только 1 раз в самом начале моей айтишной карьеры. Тогда я опубликовала резюме Python-разработчика на hh, на следующий день мне позвонил рекрутер, и после собеседования я устроилась на работу в это первое место.

С тех пор я ни разу не искала работу, она сама ищет меня. Каким образом? Однажды, еще в мои доайтишные времена я прочитала в фейсбуке одной знакомой такой совет: «вот вы жалуетесь, что не можете найти работу, а сколько раз можно повторять - заведите уже профиль на linkedin». И хоть мне особо нечем было похвастаться в своем профиле, и хотя я и не искала работу, я всё же его завела и с тех пор периодически вношу туда изменения - записи о новом месте работы, новые скиллы, которые я освоила и так далее.

Так вот, уже когда я работала на первом месте программистом, ко мне в linkedin стали периодически заглядывать рекрутеры и предлагать другую работу. Один раз я после общения с таким рекрутером чуть не сбежала на другую работу, где обещали зарплату в 2 раза больше, потом, правда спохватилась, что зарплату-то там предлагали чёрную, а я может и ипотеку хочу, нужна белая зарплата. Но после этого случая в голове поселилась мысль, что я вполне могу найти себе работу и за гораздо большую зарплату, чем получала на тот момент.

Рекрутеры продолжали периодически заглядывать, минимум несколько раз в год, и в итоге я всё-таки ушла работать в одну очень известную компанию.

После того, как в моём linkedin вместо одной не очень известной компании появилось название этой известной компании, произошел какой-то фурор: рекрутёры стали приходить толпами. Практически каждый день там кто-то предлагает работу. Заходить туда регулярно мне лень, тем более, что для этого нужен VPN, так как доблестный роскомнадзор закрыл доступ на linkedin в России (если что, в браузере Opera есть встроенный vpn). Поэтому я захожу раз в месяц, добавляю в контакты всех рекрутеров, кто прислал приглашение (их уже у меня там наверно штук 500), и на каждое сообщение вежливо отвечаю, мол спасибо за предложение, но я сейчас работу не ищу. Пишут там не только из российских компаний, были предложения из Нидерландов, Германии, с Кипра и США.

Конечно, письмо от рекрутера - это еще не гарантия трудоустройства, но тем не менее пока у меня нет ощущения, что мне угрожает безработица.:)

Что я сделаю, если захочу поменять работу? Можно пойти пассивным путем и ответить кому-нибудь из рекрутеров, что я готова принять участие в собеседовании. А можно сделать и более дерзко, опубликовать пост в духе: «Всем привет! А я тут работу ищу…» - но правда во втором случае, боюсь, рекрутеры налетят как птицы в фильме Хитчкока.

Ваша покорная слуга дала интервью учителю информатики для её проекта, и вот что из этого получилось:
🔽🔽🔽

​​Продолжаем знакомиться с IT профессиями😊

Взяла интервью у Елены, автора канала Программирование для гуманитариев: @it_human


❓ Как называется ваша профессия?

Разработчик ПО

❓Каков график вашей работы?

Графика как такового нет, особенно в условиях удалённой работы в связи с пандемией.
Работаю днём ориентировочно 6-8 часов в день, иногда больше.

❓Есть ли перерывы во время работы?

Да, когда я не забываю их себе устраивать.

❓ В чём заключаются основные принципы вашей работы, чем вы занимаетесь?

Есть 2 основных направления:

Писать код программ согласно заданию (процесс включает так же написание тестов к коду, и проверку корректности его работы в тестовой среде).
А также читать код, который пишут коллеги - мы проверяем код друг друга и советуем, как его улучшить - это называется code review.

И второе направление работы - запускать программы уже для пользователей, и следить, чтобы всё работало - чинить в случае, если возникают поломки.

❓Мог бы школьник, выпускник, работать по вашей специальности при минимальной подготовке?

Минимальной подготовки не хватит, нужно хорошее знание инструментов и технологий, которые мы используем в работе, а научиться им можно только с опытом.

❓Какие предметы в школе стоит изучать более внимательно для вашей профессии?

Информатику, очевидно, и, думаю, английский язык. Математику тоже не стоит игнорировать, но средних знаний должно хватить.

❓В каком программном обеспечении необходимо разбираться?

Нужно уметь работать с Linux, и желательно с Docker. Для работы с кодом нужен git.
Также нужно разбираться в базах данных (например, с PostgreSQL).
Для настройки серверов пригодится Ansible.
Хорошо уметь работать с Grafana (на ней мы смотрим графики, по которым понимаем, что всё работает правильно, или наоборот - сломалось).


❓Приходится ли вам проходить дополнительные обучающие курсы для повышения качества вашей работы?

Я изначально училась только на курсах, поэтому слово "дополнительные" ко мне не очень применимо. 🙂

❓Как часто вы ищете информацию в интернете по работе?

Примерно 90% рабочего времени

❓ Насколько важны компьютер, телефон и другие гаджеты в вашей работе?

Компьютер - это основной инструмент, без него работа невозможна. Телефон может пригодиться если нужно что-то тестировать - например, отправку СМС-уведомлений или автоматические звонки.
Я не занимаюсь разработкой мобильных приложений, поэтому телефон - не мой основной инструмент.

❓Как вы думаете, сможет ли робот или искусственный интеллект заменить вас, если да, то через какое время?

Сомневаюсь. И каждому роботу нужен программист, который будет его разрабатывать, улучшать и чинить.

❓ В каком диапазоне находится ваша зарплата?

150-200 тыс рублей

💻⌨🖥⌨💻⌨🖥⌨💻⌨🖥

Разработка программного обеспечения — это проектирование, написание, тестирование и поддержка компьютерных программ с целью решения задач для множества пользователей; это создание надежных защищенных решений, которые выдержат испытание временем и справятся с некоторыми не известными заранее задачами, лежащими в области, близкой к очевидным исходным задачам.

Подробно о том, в чём разница между программистом и разработчиком ПО читала тут

Зарплата по России

от 40 до 200 тыс. руб

#вашивопросы

А почему тогда в гайдах переменные называют var1, z/y/x?

Это был вопрос к моему посту о том, что переменные в 1 букву - это плохой стиль.
Почему в гайдах встречается такое? Потому что там приведены небольшие учебные примеры, для разъяснения материала.
А в коде настоящих проектов так не стоит делать.

#плохойкод

Магические строки

Продолжаем разбираться с тем, какой код писать НЕ стоит.

В предыдущем посте я рассказывала про магические числа в коде, которых в идеале быть не должно.

Сегодня поговорим о магических строках или строковых литералах в коде.

Пример:
if (name == "alligator")

Вот эта строка "alligator" - и есть магическая.

Что с ней не так, спросите вы? Если это единственное место в коде программы, где она встречается, то, в принципе ничего особо страшного в ней нет.

Но представьте, что вот таких if (name == "alligator") в коде много, и эта строка повторяется в разных местах, скажем, раз 10.
Что тогда может пойти не так? Например, в одном месте вы напишете по ошибке aligator, в другом aligater, в третьем alligator - и синтаксически код будет верным, но он будет давать неправильные результаты в ряде случаев, где вы опечатались. И придется проверять в 10 местах, правильно ли там написана строка.

Или, к примеру, вы используете ctrl + C, ctrl + V - копируете и вставляете этого аллигатора в разные места в коде. В итоге если вы ошибетесь в начале, то 10 раз вставите в код неправильные значения, и потом придется 10 же раз заменять на верные (да, современные текстовые редакторы позволяют это сделать достаточно легко, но зачем, если этого вообще можно избежать?).

Как сделать по-другому? Как и с магическими числами - заведите константы для таких строк. 1 раз в коде программы объявите константу:
ALLIGATOR = "alligator"

Используйте везде в коде эту константу:
if (name == ALLIGATOR)

Если вы ошиблись в строке «alligator», и её надо на что-то исправить - её придётся исправлять ровно 1 раз, в 1 месте - там, где вы объявляли константу, и всё.

В других местах кода незамеченных ошибок не возникнет. Если по ошибке написать, например,
if (name == LIAGITATOR)
- код не запустится, и интерпретатор (или компилятор) выведет ошибку о том, что переменная LIAGITATOR не существует. И так баг будет исправлен на самой ранней стадии, и не проскользнёт незаметно в продакшен.

Что такое классы

Мне несколько раз подписчики жаловались на то, что не понимают ООП. Причем выведать, на чём конкретно они застопорились, и что именно оказалось непонятным - почему-то ни разу не удалось, на уточняющие вопросы молчат как партизаны, и как рыба об лёд. Поэтому предлагаю начать с азов, и разобраться с тем, что такое классы, и для чего они нужны.

Предположим вы пишете код, где нужно как-то использовать данные пользователя: возраст, телефон, имя итд. Для этого нужны такие переменные:
user_age, user_phone, user_name

А если пользователей 2 или более, переменных стновится в 2 раза больше:
user1_age, user2_age, user1_phone, user2_phone…

В общем, код превращается в какую-то кашу.

Для удобства нам тут не хватает отдельного типа данных для всех юзеров - User.
И для этой цели была придумана такая сущность как struct, структура - она есть в C, Go и некоторых других языках.
struct позволяет хранить вместе те переменные, которые связаны (например, относятся к одному и тому же юзеру).

Ниже - пример на каком-нибудь условном си-подобном языке (это псевдокод, не настоящий код)

struct User {
string name;
int age;
string phone;
}

Так мы будем все данные для одного юзера группировать вместе. Например, создадим два пользователя с разными данными:
struct User user1 = {"Маша", 15, "+79161234567"};

struct User user2 = {"Пётр", 23, "+79167654321"};

В итоге у нас в коде не 6 переменных, а 2 - user1 и user2. А «внутри» каждого такого объекта хранятся все нужные данные, и мы можем их получить вот так: user1.name, user2.name.

А что же такое класс? Класс - это тоже тип данных, примерно как struct, только более расширенная версия. В классах хранятся не только сами данные (как в структурках), но и - методы (функции) для работы с этими данными.

Например:

class User {

string name;
int age;
string phone;

function say_hello() {
print(«Hello! My name is {name}»);
}

Таким образом, мы можем не только хранить в классе информацию об имени, возрасте и телефоне юзера, но и использовать метод класса say_hello:
user1.say_hello()
>> Hello! My name is Маша

user2.say_hello()
>> Hello! My name is Пётр

В следующих постах поговорим о том, что такое экземпляры классов и конструкторы.

https://news.1rj.ru/str/rosfemnadzor/2576

Моё мнение: когда читаете статьи вот по таким хайповым темам, лучше делить прочитанное на 2, а то и на 4. На мой взгляд, инфосреда сейчас перенасыщена текстами с подобной окраской, и это искажает восприятие реальности.

Сначала люди начитаются про якобы существующий патриархальный ад в IT, а потом мне в бота прилетают вопросы в духе «а как вы справляетесь с сексизмом в IT», «а вы страдаете от токсичной маскулинности мужского коллектива в IT»?

Еще раз повторюсь: с сексизмом в IT лицом к лицу я не сталкивалась, и лично от него не страдала. (Не берусь утверждать, что никто другой с ним не сталкивался, я говорю только о своем опыте).

Что такое «токсичная маскулинность» в IT - я без понятия. «Токсичность» на работе, если уж на то пошло - зависит от конкретных людей в конкретном коллективе. Конфликтные, склочные люди везде создадут «токсичную атмосферу», независимо от их пола (что за сексизм, право). А с адекватными спокойными людьми приятно работать, опять-таки, независимо от их пола. А по моему опыту, конфликтности и агрессии в IT куда меньше, чем в других областях (уж точно меньше, чем в продажах или в работе с клиентами).

Что касается статьи - совсем не собираюсь её оспаривать, она написана по данным, которые собирали в США, и всё, что там написано - касается американской корпоративной культуры. Я в США не была, и что там происходит - не знаю. Но брать выводы, полученные для США, и судить по ним о том, что происходит на другом континенте - некорректно. Я не говорю, что корпоративная культура в России лучше или хуже, чем в США (я не знаю ничего про это). Но почти уверена, что корпорации там и у нас - заметно отличаются.

Зато я могу тут привести слова одной знакомой девушки-айтишницы, которая успела поработать и в США, и в России. По её опыту, сексизм и предвзятось в отношении к женщинам в корпоративной культуре США выражена гораздо сильнее, чем у нас, в России. И связать это можно в частности с тем, что в США есть общественные силы, которые давят на работодателей и обязывают их брать на работу женщин - вот эти все квоты, позитивная дискриминация и так далее. А когда людей заставляют что-то делать - это всегда вызывает раздражение и протест. Это раздражение и протест уже в свою подогревают сексистские настроения, только в скрытом виде. И в результате если у работодателей есть возможность безнаказанно и незаметно проявить дискриминацию в адрес женщин (скажем, отказать ей в работе) - для них это соблазн, своего рода запретный плод. Вот такой вот парадокс.

Но мы-то не в США живем. По крайней мере, пока. Так что не бойтесь «токсичной среды», выдумки это всё. Другое дело, что не всем нравится гиковатая интроверсивная атмосфера в айтишных офисах, и не все готовы сидеть целый день у компа - но это уже дело вкуса.

Вернёмся к нашим классам.

Что такое классы я рассказывала в этом посте. Если у кого-то остались вопросы по тому посту, присылайте их в бота.

Итак, на этом этапе будем считать, что класс - это описание типа данных
(пример на псевдокоде):

class User {

string name;
int age;
string phone;

function say_hello() {
print(«Hello! My name is {name}»);
}
}

Для нас этот значит, что существует такой тип данных как User, у него есть такие атрибуты как имя (name), возраст (age) и номер телефона (phone). А еще у каждого объекта User можно вызвать метод say_hello, тогда на экране высветится приветствие и имя этого юзера.

Класс - это некий шаблон, трафарет, с помощью которого мы создаём объекты нужного нам типа (объекты = экземпляры класса). Так как же создать объект с помощью класса?

В некоторых языках, например в Java и C++, объекты класса создаются с помощью ключевого слова new.
Создадим двух юзеров:

user1 = new User()
user2 = new User()

В Python мы просто используем имя класса и скобки:

user1 = User()

Мы создали объекты, но эти объекты - пустые, мы не записали в них никаких данных - ни имя, ни возраст, ни телефон, поэтому пользы от них в таком виде мало. Чтобы создавать объекты сразу с нужными данными, нам нужен специальный метод (функция), который в момент создания объекта запишет в него все нужные данные. Такой метод называется конструктор.

В C++ и Java метод-коструктор называется так же как сам класс, например (это всё еще псевдокод):

class User {

string name;
int age;
string phone;

// метод-конструктор
function User(user_name, full_age, phone_number) {
name = user_name
age = full_age
phone = phone_number
}
}

И теперь мы можем с помощью этого конструктора создавать объекты класса уже с данными:

user1 = new User("Катя", 19, "9169989999")
user2 = new User("Петя", 8, "9161234567")

А в Python в качестве аналога конструктору мы используем метод init:

class User:

def __init__(self, user_name, full_age, phone_number):
self.name = user_name
self.phone = phone_number
self.age = full_age

user = User("Anna", 42, "9161234567")

Первый аргумент self в Python обозначает сам объект (то есть новый юзер, которого мы создаем при вызове функции).
Например, self.name = user_name - значит присвоить объекту поле name со значением user_name.

В некоторых других языках с похожим смыслом используется ключевое слово this. Например, в Java конструктор может выглядеть так:


public class User {

string name;
string number;
int age;

public User(String user_name, int full_age, String phone_number) {
this.name = user_name; // this здесь не обязательно использовать, привожу для аналогии с self
this.age = full_age;
this.number = phone_number
}

}

И напоследок: вернемся к самым первым примерам, где мы создавали объекты классов, но в самих классах не написали метод-конструктор, вот эти user = new User(). В таких случаях при создании объектов всё равно вызывается неявно метод-конструктор - он называется конструктором по умолчанию и в нём не используются аргументы. И если мы не определили его в коде сами, его за нас создаёт компилятор, сам.

Как стать программистом

Иногда мне кажется, что от IT у людей примерно такие ожидания: однажды за тобой прилетает волшебник на голубом вертолете, забирает в Хогвартс, там тебя заботливо принимают, обучают всему, вокруг тебя начинает происходить всякая магия, ты не успеваешь опомниться, как оказываешься на пуфике в гугле, где играешь в пинг-понг и видеоигры, а в перерывах взмахом волшебной палочки сотворяешь чудеса. И всё это без особых усилий, чистый кайф.

Думаю, у кого-то примерно так и происходит, но давайте смотреть правде в глаза: такие ожидания вряд ли помогут вашему успеху.

Я придумала другую метафору, которая скорее укажет вам путь в IT. Метафора грустная, и, возможно, не совсем этичная. Она про заключенных в российских колониях, которые шьют одежду. Тебя подводят к швейной машинке и говорят: шей. А ты, возможно, эту швейную машинку видишь впервые. Возможно, ты никогда в жизни и иголку с ниткой в руке не держал. Ты вообще не представляешь, как это работает, ты не умеешь шить. Но деваться некуда - ты шьёшь. И в итоге шьют все - в том числе те, у кого вначале совсем не получалось.

Вот так же и с написанием программ. Ты уже начал изучать какой-то язык программирования? Отлично - садись и пиши программы. Да, знаю - сложно, непонятно, я не умею, не знаю, у меня лапки. Тем не менее, надо довести дело до конца - написать программу. У меня, думаете, нет лапок? У всех лапки. Но айтишник - это такой человек, который, несмотря на лапки, доводит дело до конца.

А что именно писать? Да всё подряд. Напишите простенькую игру (поначалу можно консольные) - виселицу, крестики-нолики, морской бой, пинг-понг. Напишите небольшой сайт для себя. Напишите календарь с уведомлениями, напишите программу со списком дел. Напишите телеграм-бота, который будет вам присылать каждый день мотивирующую фразу, или курс валют, или прогноз погоды. Пишите, всё, что угодно - любую фигню, которая вам приходит в голову.

Поначалу программы будут простенькие, сайты - кривоватые, код плохим и вымученным - ну и что. Зато это сделано своими руками, и оно работает! Это самый приятный момент в работе программиста - когда твой код работает - пусть даже это всего-лишь какие-то крестики-нолики в консоли.

Вот так становятся айтишниками, а не в бесконечной прокрастинации и ожидании прозрения.

#плохойкод

Сложные булевы выражения

Сегодня в рубрике про плохой код рассмотрим вот такие булевы выражения:

// си-подобный синтаксис
if (person.age > 27 || person.age < 18 && month >= 9 && month != 12 && money > 0)

# Python
if (person_age > 27 or person_age < 18 and month >= 9 and month != 12 and money > 0)

В коде иной раз встречаются образцы ещё длиннее и сложнее этого вымышленного примера.
Недостатков в подобном коде как минимум 2:

1. У операторов И и ИЛИ (как и у всех остальных) - есть приоритет - то есть, порядок, в котором они будут выполняться. И он может оказаться не таким, как вы ожидаете (погуглите «таблица приоритетов операций» для вашего языка). Поэтому если уж мудрите с длинными вычилениями, лучше заключайте выражения в скобки, чтобы однозначно определить порядок выполнения операций.

2. Сложно, запутанно, нечитаемо. Это значит, что а) вы с высокой вероятностью сами уже запутались, пока писали этот код, и в нём уже есть баги и ошибки. и б) его сложно прочитать другому человеку. Вы же помните, что код должен быть понятным?

А чтобы переписать такое выражение, можно создать несколько (булевых) переменных с понятными именами и записать в них результат промежуточных вычислений:

is_person_young_adult = person_age > 18 and person_age < 27

is_autumn = month >= 9 and month < 12

person_has_money = money > 0

И теперь используем в исходном выражении эти переменные:

if (person_has_money and (not is_person_young_adult) and is_autumn)

Видите, насколько более понятным стал код по сравнению с примером вверху поста? А всего-то - несколько новых переменных ввели.

Теперь из кода видно, что, если у клиента на счету есть деньги, и он не входит в возрастную группу «молодой взрослый» и сейчас осень - что-то должно произойти (например, ему можно показать на сайте баннер с какими-нибудь скидками).

И да, вы верно заметили - в примере есть магические числа, это для упрощения понимания. А в настоящем коде их по возможности нужно избегать, как мы помним.

ООП

Для тех, кто присоединился недавно, ввожу в курс дела: многие подписчики жаловались мне, что начали изучать программирование, но не смогли разобраться с такой темой как ООП (объектно-ориентированное программирование).

Поэтому я начала серию постов про ООП, где разбираем на пальцах и максимально простыми словами основные понятия.

Кто не читал предыдущие посты из этой серии, рекомендую начать с них:

- Что такое классы
- Что такое экземпляры классов, и как их создавать

Сегодня же разберёмся с самим понятием «объектно-ориентированное программирование».

Собственно ООП - это подход к программированию, основанный на использовании классов и экземпляров этих классов. У этого подхода есть ряд принципов, о которых я расскажу подробнее в дальнейшем (абстракция, инкапсуляция, наследование, полиморфизм).

В языках программирования, которые поддерживают ООП всегда присутствуют классы. Например, в Java обойтись без классов вообще невозможно. C++ также придуман специально для ООП, но в нём при желании можно и не пользоваться классами. Но помните, что это своего рода моветон - по-хорошему, если вы не используете классы и ООП, значит нужно писать на языке Си, а не C++.

А есть языки, которые поддерживают ООП, но позволяют обходиться и без него. Например, такой язык - Python. Причем, ООП в Python специфический: там есть классы, но принципы ООП там можно не соблюдать (синтаксис языка это никак не ограничивает). Так что по сути это ООП, основанное на джентельменских соглашениях, то есть на надежде, что программисты сами добровольно не будут их нарушать.

Есть языки, в которых вообще нет ни классов, ни ООП. Например, языки C и Go.

А есть и вовсе функциональные языки - в них, если несколько упрощать, никакие промежуточные объекты не используются, а результаты вычислений передаются из одной функции в другую по цепочке, пока не будет получен нужный результат - это Lisp, Haskell и другие.

Подробнее принципы ООП (абстракция, инкапсуляция, наследование, полиморфизм) - разберем в следующих постах.

Задать вопрос автору блога можно здесь: @hum_it_bot