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

Но на сколько там вообще всё адекватно и сходится с профессиональной разработкой?

Можно защититься, конечно: "Работает! Значит всё хорошо". Но не всё так просто.

Я понимаю, что это всё может звучать ооочень токсично, но не нужно мне верить на слово. Давайте я приведу вам 5 ошибок разных авторов с подробными объяснениями и вы сделаете свои выводы. Кстати в этом боте собрал для вас лучшие каналы с проверенными авторами которым можно доверять.

Меня зовут Роман Сакутин - я программист, разработчик игр с 10 летним опытом работы. Успел поработать в США в составе Dusk Games над проектом Frostfall, а сейчас владею своей студией - AGAVA, которая раньше делала мобильные и браузерные игры. А сейчас работает с крупными заказчиками на аутсорс разработке и копит деньги на игру мечты.

А ещё я веду блог про разработку игр на YouTube и у меня 270 000 подписчиков, которых я очень сильно люблю. Спасибо вам за вашу поддержку! Первые 100 000 подписчиков я набрал накидывая говна на рукожопиков, сейчас я снимаю подкасты про физику, науку и профессиональную разработку с докторами наук.

Но кажется, снова нужно взяться за старое.

В кругах разработчиков есть популярная фраза: "Проект не делается. Проект переделывается". Собственно, задача хорошего кода - иметь хороший maintenance. Чем медленней растёт стоимость (абстрактная) изменения проекта, тем лучше maintenance.

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

Когда код удобно и комфортно поддерживать, то он приближается к статусу "профессиональный". Помимо этого есть и другие метрики:

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

Это может показаться надумыванием, но проекты быстро из 10 строчек превращаются в десятки тысяч, а иногда и в миллионы. И отдельное искусство программистов - делать код, который при любом количестве строк понятный и ПРЕДСКАЗУЕМЫЙ.

Ещё Мартин Фаулер в своей книге "Рефакторинг" описывал эту распространённую ошибку. Но почему-то она всё ещё одна из самых излюбленных у "учителей", которые гордо называют себя профессионалами!

Вы можете заметить, что код в 45 и 50 строчке идентичен. Изменился только один знак.

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

Лечится такое очень просто. Например, выделением функции. Конкретно здесь 8 строчек можно заменить на 2. Если не считывать так по глупому направление движения. Но даже без этого можно просто сделать аккуратненько.

Все ошибки в видео я разбирал у себя на канале.

Давным давно, когда программирование только зарождалось, корпоративный мир задался вопросом: "Как оценить эффективность работы программиста?". И придумали считать строчки кода. Кто больше напишет тот и эффективней. Круто!

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

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

У нас с Гошей любовь, но судя по его комментария под моими видео - любовь не взаимная. Магическое число - это такая херомантия при виде которой вы думаете: "Что значит 42!?".

Можно сделать антитезис: "Ну как же не понятно?! -400 у Гоши - это верхняя точка окна... или нижняя... а окно всегда одного размера?"

Лечится это очень просто. Например, магическое число можно заменить на константу - Window.Bottom.

Согласитесь строки:
enemy.Top = Window.Bottom

Сильно понятней. А представляете если в одном файле с кодом десятки таких магических чисел? Например, почему -130? :)

Не весь работающий код имеет право на жизнь. Даже если у вас это запускается в тестовой сцене, то в боевом проекте это всё посыплется как карточный домик. Например, есть старая как мир уязвимость - SQL Injection.

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

Неопытный программист возьмёт строку с названием города. Грубо добавит это к строке SQL запрос и отправит в базу данных.

А базе данных всё равно. Она не ревнивая девушка и проверять ничего не будет. Она возьмёт и выполнит эту команду.

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

Мой путь разбора чужого кода хоть и невероятно токсичный, но дал свои плоды. За последние 5 лет разработчики в СНГ пересмотрели свой подход к программированию. Я уже не могу встретить у новых авторов, и даже начинающих программистов, тех глупых ошибок, которые были раньше.

Да, это было жестко, но зато мы все стали лучше.

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

Тут очень распространённая ошибка. Называется она "Власть Менеджеров". Когда вы не особо думаете о структуре программы и её слоях, то вы приходите к тому, что у вас появляется мега класс "GameManager", который делает вообще всё что можно.

Я однажды проводил ревью игре, в котором GameManager занимался 42 000 строк. Если хотя бы руководствоваться принципами SOLID, то такие мега структуры разбиваются на очень управляемую и понятную архитектуру. По-хорошему в вашем классе будет дай бог 50 строчек. И все они будут по мудрому связаны, и будут собираться в Composite Root, читая который будет очевидно что, куда и зачем.

Не стыдно писать плохо, стыдно это не признавать и не развиваться.

За 10 лет практики и многие годы обучения мы отточили свой материал до идеала. Я понял что самое главное в обучение - это не лекции а насыщенная практика и проверки профессиональных разработчиков.

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

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