Spiiin's blogЧасто встречающиеся у программистов-новичков ошибки и часто встречающие у опытных программистов ошибки. С позиции “среднего” разработчика.
…
Ошибки новичков
1. Использование примитивов вместо высокоуровневых абстракций
Новички часто пишут код “с нуля”, забывая о возможностях используемых фреймворков или библиотек. Фактически это просто неумение работать со сложными типами и игнорирование возможностей системы типов используемого языка (точнее даже - возможностей выражать через типы ограничения и связи сущностей).
Каждый раз, когда необходимо завести переменную типа
int- подумайте, действительно ли нужен просто целочисленный тип, или же с помощью типа можно сказать ещё что-то полезное о переменной
2. Реализация всей логики в одной функции
Если какой-то кусок кода можно вынести в именованную функцию (даже если она не будет использоваться повторно), стоит так сделать. Функции проще объединять в классы или модули, чем “голый” код и разрастающиеся безымянные функции. Это нужно, чтобы уменьшить вероятность копи-пасты кода (точнее даже, уменьшения количества необходимых для изменения логики мест в коде).
Можно ли описать одним небольшим предложением, что делает функция? Что делает класс? Что описано в файле/namespace/модуле?
3. Игнорирование инкапсуляции
Инкапсуляция часто ошибочно трактуется новичками как необходимость делать все данные класса закрытыми. На практике лучше понимать и использовать её как средство сделать объект не ломаемым пользователем. Т.е. если изменение переменных не может привести к тому, что класс будет находиться в невалидном состоянии - то и не надо их прятать. Если же для корректной работы с объектом у него нужно вызвать 5 разных методов в строго определенном порядке (а в других случаях программа падает), значит, нет у него никакой инкапсуляции. Пользователь объекта не должен помнить о том, что нельзя делать с объектов, чтобы не сломать его внутреннюю логику - сам объект должен быть не ломаемым для пользователя.
Таким образом в некоторых языках отказываются “ломающихся” абстракций и возможностей (
goto, отказ от указателей, отказ от ручного освобождения памяти, отказ от мутабельности).
4. Персональный стиль
По большей части, все программы пишутся несколькими людьми, так что вместо того, что писать в строго выработанном правильном стиле, стоит учиться подстраиваться под стиль уже написанного кода. Код на некоторых языках имеет стандартные правила написания, но даже с учётом этого необходимо помнить, что программа могла писаться, когда в ходу были другие правила, или же по каким-либо другим причинам использовать другой подход. Стоит писать так, чтобы стиль всей программы был одинаковый - так у читающего код будет меньше вопросов, почему в разных местах программы используются разные варианты (и какой стиль выбрать при изменении кода).
Прежде чем писать код, прочитайте уже написанный
5. Неправильные вопросы опытным программистам
“Какой язык учить?” - неверно, опытные скорее могут рассказать, что уже учить не стоит. Новые знания можно копать самим, в больших количествах.
“Как быстро получить прибавку к зарплате” - неверно. Самый быстрый способ прокачки - менять работу каждые полгода-год, с повышением рангов. Но с определенного уровня начинают ценить лояльность, прыгающий между проектами профессионал стоит только того, чтобы выжать из него максимум и отпустить дальше. В компаниях с грамотным управлениям вашу работу и так отметят (если отметка соответствует ожиданиям - всё отлично, если нет - лучше уточнять, что не так). К счастью, обычно с определённого уровня программистам достаточно денег для того, чтобы хватало на жизнь (дойти до этого уровня можно за год-два-три - как повезёт).
Стоит максимально вникать в предметную область, опасно зависать на несколько лет в очень узкой нише.
Полезно раз в месяц-два изучать как минимум одну статью профессиональной тематики, раз в полгода-год читать книгу, раз в 2-3 месяца изучать библиотеки/фреймворки/движки, похожие на те, что используются в работе.
Ошибки опытных
1. Нежелание трогать плохой код
“Это надо разбираться с половиной программы” - нормальная с точки зрения опытного программиста отмазка, чтобы не выполнять рефакторинг кода. В запущенных случаях это даже перерастает в нежелание трогать свой плохой код.
Иногда таки надо разобраться с половиной программы, чтобы сделать код лучше. На костылях далеко не уёдешь, рано или поздно предстоит выбросить их и сделать нормальные колёса.
2. Нежелание отказываться от своих подходов
Иногда (редко но бывает), нужно сделать свой код хуже, чтобы он вписывался в проект. Иногда нужно выучить новую парадигму - очень сильно неприятно, когда ты 15-20 лет писал код и решал проблемы в одном стиле, а теперь их в проекте решают по другому, так как ты ещё не умеешь. Иногда нужно выучить новый язык, когда уже очень хорошо знаешь старый.
Грустно, но во многих компаниях уровни роста программиста - это скорее стаж, чем реальный опыт, а с учётом того, что в IT практически никогда не понижают при переходе между компаниями, оказывается также, что умение писать хороший код приходит (если вообще приходит) где-то на уровне “senior+”.
Время движется вперёд, и любые идеи могут устареть, даже те, которые ты считаешь основополагающими. Нужно не забывать их переоценивать
3. Игнорирование soft-skills
Рано или поздно в ходе роста программиста необходимо научиться нормально взаимодействовать с командой. На начальных этапах всё взаимодействие - это передача по конвейеру: получение задач от лидов/тм, передача выполненного к QA.
Но на более поздних необходимо взаимодействие со всеми вокруг - уточнение формулировки задач (и умение исправить или даже переделать постановку исходной задачи), корректировки сроков. Ещё позднее - формирование команды и умение улаживать конфликты в команде. Даже если ты собираешься расти в “техническую”, а не “управленческую” сторону, всё равно не избежать растущего количества взаимодействия, а умение взаимодействовать тоже нужно прокачивать.
В некоторых компаниях отрицательный отзыв по софт-скиллам блокирует твой карьерный рост.
В любой сфере достаточно людей, которые умеют программировать, но не хватает тех, которые умеют программировать, и при этом разбираются в предметной области.