#плохойкод

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

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

Скажем, в 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

Никаких лавров

Еще меня часто спрашивают: каково это - работать в IT с гуманитарным образованием? Как ко мне относятся коллеги? Нет ли пренебрежительного отношения?

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

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

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

Но, с другой стороны, это ведь и не такое уж большое дело - научиться чему-то новому. Все мы способны учиться, на то мы и Homo Sapience.

Баги мышления

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

Баг 1: Я ещё не готов. Думаю, эта «истина» закладывается нашей системой образования: возникает ощущение, что прежде, чем начать что-то делать, нужно долго-долго учиться, учиться и еще раз учиться. Сначала «отсиди» 5-6 лет в ВУЗе - и вот только тогда «начинай начинать». И поэтому у многих новичков появляется почти неистребимая установка: я ещё не готов. Написать свою небольшую програмку? - Ещё не готов. Вот закончу курсы, прочитаю еще 10 книг, позанимаюсь с репетитором - тогда и начну писать. Поучаствовать в опен-сорс проекте? - Нет, я еще не готов. Записаться на хакатон - я еще не готов. Устроиться на какую-нибудь стажировку? - Ну что вы, я еще совсем ничего не знаю. Сходить на собеседование? - Нет, я не готов.

Я сама долгое время так не могла написать резюме и начать искать работу, потому что «ну я же совсем ничего не знаю» - а как написала, взяли на работу с первого же собеседования.

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

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

Баг 2: Не умеешь - не берись. Как только вы сталкиваетесь с чем-то незнакомым, это вызывает страх, и вы стараетесь избежать новой темы. Тут срабатывает школьный шаблон «это мы не проходили, это нам не задавали». Например, вы работаете с Java, а тут вам (в процессе учебы или на работе) подворачивается код на Python. И реакция: «Нее, это незнакомый язык, я его не изучал, не буду даже на него смотреть». Срабатывает баг из предыдущего абзаца - мол прежде чем что-то делать, нужно это хорошенько изучить. «Нельзя просто взять Python и начать на нём кодить - сначала нужно книжку хотя бы прочитать.» Так вот ничего подобного - не только можно, но и нужно. Когда вы встречаете что-то незнакомое и непонятное, нужно не избегать этого, а считать, что это ОТЛИЧНЫЙ ШАНС ПОЗНАКОМИТЬСЯ С PYTHON. Гугл в помощь и вперёд.

Когда я устроилась на первую работу Python-разработчиком, мне почти сразу дали код на C# - так я начала кодить на C#. Когда я устроилась в другое место как бэкенд-разработчик на Python, одной из первых моих задач было - написать фронт на JavaScript. Не бойтесь вы нового - в Интернете есть информация обо всём, для всего есть документация в открытом доступе, а языки все плюс-минус похожи друг на друга. Если вы катались на коньках, значит сможете стать и на ролики.

Баг 3: Синдром самозванца. «Да я тут вообще ничего не понимаю, все коллеги умные и всё знают, а я тупой, и скоро они догадаются и уволят меня.» В результате стесняешься задавать вопросы, так как считаешь, что вопросы тупые и боишься опозориться. Не признаёшься, что не понял свою задачу - а то тебя так точно раскроют, Штирлиц ты наш. Молчишь на совещаниях и не участвуешь в обсуждениях - а что ты можешь сказать, ты же тупее здесь всех остальных? Если не согласен с чем-то - не высказываешься - другим-то виднее, наверно ты ошибся. В общем, детский сад, старайтесь не делать так. Даже если чего-то не понимаете, нужно вести себя как взрослый и общаться как взрослый, а не как школьник, который скрывает, что прогулял урок. Если вы узнали себя в этом описании, и вообще по натуре вы - скромный молчун - работайте над собой.

Не бойтесь начинать и не бойтесь ошибаться. Никто не рождается программистом.

Почему с новичками сложно работать

Устроиться впервые на работу стажером или джуном - это челлендж.

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

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

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

- Безответственность. Когда человек берёт задачу, мы ожидаем, что он а) до конца понимает, о чём она б) уложится в сроки, как обещает в) если возникают непредвиденные проблемы и в сроки нельзя уложиться - сразу об этом сообщит. Что же мы имеем на практике? Сотрудник клянётся, что понял задачу, и что никаких вопросов у него нет, когда он на самом деле ничего не понял. Обещает сделать задачу за неделю, в итоге через неделю там и 10% не сделано и заранее об этом он не предупреждает. Либо же в процессе работы появились неожиданные препятствия, и вместо того, чтобы об этом рассказать и обсудить с коллегами, как действовать дальше - он просто сидит и молчит.

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

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

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

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

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

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

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

Как найти работу джуниор разработчика если рабочего опыта в этой сфере нет, но я занимаюсь самостоятельным изучением? Училась на другом направлении в Германии, но поняла что это для меня скучно и неинтересно и я хочу в айти и постоянно учиться новому.

Сейчас я в России, в германии после провала на собеседовании упала мотивация.

Я слышала мнение от ребят, живущих в Европе, что в Германии найти работу новичку гораздо сложнее, чем в России.
Поэтому, раз вы сейчас находитесь в России - начните искать работу здесь. Заполните резюме, откликайтесь на всевозможные вакансии стажеров и джунов, ходите на собеседования.

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

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

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

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

Лучший способ приобрести опыт - это найти первое место работы.

Еще вашу привлекательность в глазах работодателей можно поднять, выполняя какие-то проекты для себя (напишите сайт, игру, приложение, телеграм-бота итд) - чтобы потом рассказать о них на собеседовании. И еще можно включиться в какой-нибудь open source проект в качестве разработчика.

Но для начала поищите работу.

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

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

Гуманитарные науки (как и программирование) тоже используют абстрактное мышление - поверьте, термины из философии, психологии или лингвистики «на кофемашинах» никто не объясняет.

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

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

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

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

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

Привет! После обучения на курсах при компании и стажировки наконец-то стала Junior Software Developer (спасибо вам за вдохновение и личный пример успеха). Вопрос такой: есть ли у вас полезные советы для джунов основанные на личном опыте?

Во-первых, поздравляем нашу читательницу, приятно слышать.

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

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

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

3. Задавайте вопросы: когда что-то непонятно - не молчите и не стесняйтесь. Задавайте даже самые тупые (на ваш взгляд) вопросы - главное чтобы в голове всё прояснилось.

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

5. Грамотно просите о помощи: тут нужен баланс - с одной стороны, вам нужно получить всю необходимую информацию, с другой стороны - ценить время ваших коллег.

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

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

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

7. Отвечайте за результаты своей работы: не обещайте того, чего не сможете сделать. Если не удалось верно оценить сроки работы или возникли непредвиденные препятствия - сразу сообщайте об этом старшим коллегам. Если где-то накосячили - что-то сломали, что-то случайно удалили - расскажите об этом коллегам, не скрывайте - скорее всего, они что-то придумают.

8. Будьте осторожны: используя, скажем, git, убедитесь, что понимаете, что за команду вы собираетесь выполнить - не затрите нужный код в репозитории. Если у вас есть доступ к продовой базе данных - помните - 7 раз SELECT - 1 раз UPDATE. Если делаете что-то в базе данных руками, перед каждым UPDATE или DELETE открывайте транзакцию (например, командой BEGIN;) - потом убедитесь, что не удалили и не изменили ничего лишнего - и если произошло что-то нежелательное - откатите изменения командой ROLLBACK;

9. Оценивайте ресурсы: если вы написали программу, которая должна обработать много-много данных - прежде, чем её запускать, оцените, сколько времени занимает её работа на небольшом кусочке этих данных - возможно, для того, чтобы обработать все нужные данные, ей понадобитс 10 миллионов лет - и значит нужно переделывать. Оценивайте, сколько памяти и CPU нужно вашим программам - не факт, что их столько есть в наличии.

10. Пишите тесты. Даже если этого от вас не требуют. Когда пишете код
- сразу думайте, как вы будете его тестировать.

11. Осваивайте незнакомые технологии.

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

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

Подскажите пожалуйста какие бесплатные онлайн курсы можно послушать сейчас? И для начального понимания программирования и для изучения английского языка?

Я бы не рекомендовала смешивать изучение программирования и английского языка - лучше выделять отдельные часы для каждого предмета, мозгу проще фокусироваться на 1 задаче, а не сразу на 2х. Вот если вы уже хорошо понимаете аудио на слух, тогда другое дело. (С другой стороны, технический английский не такой уж сложный, и терминов там не много, так что бояться его и избегать любых видео на английском тоже не стоит).

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

А рекомендую всем я традиционно бесплатный гарвардский курс CS50 по введению в Computer Science и программирование. В этом посте все ссылки.

Задать вопрос автору блога можно будет здесь (когда телеграм починят): @hum_it_bot

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

Хочу войти в it сфера с абсолютного нуля. По началу заинтересовала тема геймдева, работа с движками, с ландшафтом или разработкой игр или фильмов (анимаций то, что можно делать использую игровые движки) Читал что это довольно перспективная сфера, в том числе работа с Led павильонами по типу тех где снимался сериал Мандалорец. Понятия не имею с чего начать и какие вопросы задавать. Очень много информацию и выбрать актуальную в данную момент сложно, был бы рад ответу на данный вопрос.

Итак, если я верно понимаю вопрос - вы хотите с чего-то начать, и не хотите самостоятельно искать информацию.

Тогда есть такие варианты:

1) Обеспечить себя общей айтишной базой, пройти бесплатный курс по введению в Computer Science - про CS50 я столько раз уже тут писала, что уже даже самой надоело. Так вы создадите себе бэкграунд, и уже не будете начинать с абсолютного нуля. Потом уже идти на узкоспециализированные курсы - скажем, по геймдеву

2) Cразу пойти на платные курсы по геймдеву - желательно на длительные (год-полтора), чтобы не искать информацию самостоятельно и не тонуть в её обилии.
- Разработка игр на Unity от Geekbrains (длительность около года)
- Разработка игр на Unreal Engine Geekbrains
- Профессия разработчик игр на Unity от Skillfactory (12 месяцев)

Есть и более ускоренные варианты - на несколько месяцев. Тут, очевидно, будут давать меньше материала и практики, но и по цене они обычно дешевле:
- Разработчик игр на Unity от Нетологии (7 месяцев)
- Разработчик игр на Unity за 6 месяцев от Geekbrains

3) Вариант для более самостоятельных: просто берёте любые понравившиеся курсы по разработке игр на недорогих платформах - и проходите любые из них, в любом порядке - главное начать, а потом уже сориентируетесь. На Udemy можно найти целый список курсов по теме, цена вопроса - 1000 рублей за курс (UPD 2022 - cейчас из-за санкций оплатить курсы студентам из России там нельзя).

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

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