Я работал разработчиком более пяти лет. Это не делает меня экспертом, но я считаю, что сделал достаточно ошибок, чтобы поделиться с вами. Вот 10 вещей, которые никогда не стоит делать разработчику.
1) Быть перфекционистом
Ничто не идеально, и я уверен, что «идеального кода» не существует тоже.
Разработка это итеративный процесс. Ты пишешь код, тестируешь, получаешь обратную связь, делаешь рефакторинг и повторяешь. То, что работает сегодня, может не работать завтра. Поэтому программы должны быть гибкими и легко изменяемыми (вот почему они называются софтом).
Я не говорю, что нужно отказаться от стремления к совершенству. Просто нужно помнить о написании слишком сложного и связного кода.
Быть профессионалом не то же самое, что и быть перфекционистом. Это скорее когда ты оптимально хорош большую часть времени.
2) Просить время на рефакторинг
Рефакторинг кода это процесс реструктуризации существующего кода без изменения его внешнего поведения. Код без рефакторинга начинает «дурно пахнуть», что означает его сложно понимать и использовать другими разработчиками.
Мы, разработчики, знаем, что рефакторинг всегда стоит проводить после реализации функциональности. Проблема в том, что нетехническим членам команды плевать на такие вещи. Они часто говорят тебе: «Мы быстрорастущая компания, нужно сначала сфокусироваться на добавлении функциональности». Но спустя время код становится неподдерживаемым и ты начинаешь выпрашивать время на рефакторинг.
Не нужно просить отдельное время на рефакторинг. Делайте его в рамках реализации функциональности.
3) Не понимать, что такое «легаси-код»
Экосистема веб-разработки известна своими быстрыми изменениями. Я помню один свой прошлый проект, который использовал Next.js 10. К тому времени, как я начал над ним работать, вышла версия 11 с новыми функциями и улучшениями. Внезапно, мой проект с версией 10 стал выглядеть устаревшим.
Многие неправильно думают, что «легаси-код» значит старый код, но это не так. Согласно Майклу Физерсу, автору книги «Эффективная работа с унаследованным кодом», «легаси-код» это код без тестов. Если ты не можешь протестировать код, ты не можешь сделать его рефакторинг. Если ты не можешь делать рефакторинг, ты не можешь его поддерживать.
«Старый» Next.js-проект имел приличное покрытие тестами и нормально работал. Это был «хорошо поддерживаемый код», а не «легаси-код». Пожалуйста, не гонитесь за новыми инструментами только потому, что они новые и блестящие. Помните, что Github продолжает работать на Ruby on Rails, которому 17 лет.
4) Считать функциональное программирование лучшим
Да, функциональное программирование это новая штука, все крутые ребята им занимаются, но это не значит, что его нужно использовать везде.
Например, в работе над Flutter-проектом, возможно, его не стоит использовать на уровне интерфейса пользователя. Частое использование полностью функционального кода на уровне интерфейса может вызывать проблемы с производительностью из-за не нужных повторных отрисовок. Flutter предназначен для использования в стиле объектно-ориентированного программирования, стоит его использовать именно так.
Но это и не значит, что нужно совсем избегать функционального программирования или любой другой крутой штуки. В том же примере можно использовать функциональное программирование на уровне бизнес-логики, где оно подходит лучше. Просто учитывайте контекст, в котором вы работаете, и выбирайте соответствующий инструмент.
5) Слепо следовать «лучшим практикам»
Чистая архитектура, принципы SOLID, DRY, KISS, YAGNI, TDD, BDD, CI/CD и т. д.
Существует много лучших практик в разработке программного обеспечения. Они придуманы с благими намерениями, но не следует им слепо следовать.
Например, TDD (Test-Driven Development) это отличная практика, позволяющая убедиться, что код работает так, как ожидается. Но если вы работаете с языками, поддерживающими REPL, такими как Clojure или Python, вам, возможно, не понадобится использовать TDD для всего подряд.
Единственная цель TDD — как можно быстрее получить обратную связь. Если можно получить обратную связь, без написания тестов, то TDD не нужен (хотя тесты писать надо!).
6) Справляться с трудностями в одиночку
Я видел много младших разработчиков, которые стремились продемонстрировать свои так называемые «навыки решения проблем». Они часто изо всех сил пытаются решить проблему, которая уже решена другими. Пожалуйста, не будь таким. Не изобретай велосипед.
Величайшие умы мира — это те, кто стоит на плечах гигантов.
Когда ты начинаешь работать в команде, то понимаешь, что можешь многому научиться у своих товарищей, у которых больше опыта, чем у тебя.
Они твои «гиганты». Запрыгивай им на плечи и не трать время, спрыгивая на землю. Теперь твоя цель — стремиться к более высоким гигантам.
7) Впадать в неконтролируемый «поток»
Вы когда-нибудь испытывали состояние «потока»? Это состояние ума, при котором ты полностью погружен в задачу, чувствуешь прилив энергии и сосредоточенность. Попадание в состояние «потока» программистом может ощущаться как будто код пишет сам себя, а ты всего лишь посредник.
Но будьте осторожны — в конечном итоге можно написать «слишком много» кода. Я часто ловлю себя на том, что переусердствую с проектированием, когда нахожусь в «потоке». Не только я, но и Роберт Мартин, автор «Чистого кода», также столкнулся с контрпродуктивностью, находясь в потоке.
Для умышленного прерывания состояния потока, я рекомендую «метод помидора», когда ты работаешь 25 минут, а затем берешь пятиминутный перерыв. Это помогает тебе оставаться в фокусе и избегать выгорания.
8) Не двигать своим телом
Работать инженером-программистом непросто. Ты будешь часами сидеть перед компьютером, печатать на клавиатуре и смотреть в экран. Легко забыть о своем здоровье, когда находишься в «потоке». Но помни, твоё здоровье – это самое главное. Мозг бесполезен, если тело не работает как нужно.
Пробуй двигаться каждые 30 минут (или 25, если используешь метод помидора). Встань, потянись, пройдись и выпей воды.
9) Забывать, как круто быть программистом
Когда я начинал программировать, меня это так заводило. Я создавал всякие штуки, решал проблемы и учился новому каждый день.
Но со временем я начал забывать, как весело программировать. Я был слишком сосредоточен на написании «чистого кода», следовании «лучшим практикам» и решении «сложных проблем». Чаще всего я не мог толком написать собственный код, потому что занимался чужим кодом и кодом компании. Куда делась моя креативность?
Всегда нужно помнить, как весело быть программистом. Я знаю, что это сложно, но постарайся найти время для работы над собственными проектами, изучения нового и создания чего-то классного. На своем рабочем месте попробуй поговорить с товарищами по команде о новых интересных технологиях, даже если вы не используете их в своем проекте. Это поможет оставаться мотивированным и вдохновленным.
10) Быть «кодером», а не инженером
Есть разница между «кодером» и «инженером-программистом». Кодер — это тот, кто пишет код, а программист — это тот, кто решает проблемы с помощью кода. У меня есть две серьёзные причины, почему тебе не следует быть кодером:
Так называемые «кодеры» в будущем будут заменены ИИ (фактически они уже заменяются). Я знаю, что это спорно, но, к сожалению, это правда
-
Людей не волнует ваш код, их волнует, насколько хорошо вы решаете их проблемы.
Будьте «решателем проблем», использующим код как инструмент. Поймите проблему, найдите лучшее решение и реализуйте его с помощью кода. Это то, что делает инженер-программист.
Заключение
Эти 10 вещей основаны на моём личном опыте, поэтому я не жду, что со мной все согласятся. Но я надеюсь, что это окажется вам полезным. Пишите в комментариях, если вам есть что добавить. Спасибо за чтение!
Комментарии (58)
BugM
22.05.2024 16:02+23Да, функциональное программирование это новая штука
Ахаха
0xC0CAC01A
22.05.2024 16:02+1Кстати, а что это за видео?
Guid0Fawkes
22.05.2024 16:02+3Вы сейчас не пошутили?
Если вдруг нет, это Хуан Хойя Борха, ищется по словам Хохотун (есть даже статья в Википедии), Испанец-хохотун, Ризитас. А пародиям и мемам на его знаменитое видео-интервью несть числа.
lrdprdx
22.05.2024 16:02+1Видел несколько "фэйковых переводов" этого видео. Один из лучших вот этот: https://youtu.be/AaESGrylj7k?si=vWsw690LZUCWstIM
Потом оригинал посмотрел --- ничем не хуже)
Batalmv
22.05.2024 16:02+2Не нужно просить отдельное время на рефакторинг. Делайте его в рамках реализации функциональности.
Зависит от объема рефакторинга. Еслти его много - сложно утаить
Это был «хорошо поддерживаемый код», а не «легаси-код». Пожалуйста, не гонитесь за новыми инструментами только потому, что они новые и блестящие
Есть очень простой и в тоже время важный фактор - наличие deprecated компонент. Если они есть - код уже legacy. И по фиг, если он прекрасен, покрыт тестами и может быть легко изменен. Хотя ... где-то в мире маленьких денег возможно это не так
Слепо следовать «лучшим практикам»
Я думаю, проблема в слове "слепо", а не 2следовать". Чаще всего, люди просто не понимают, в чем именно лучшая практика заключается
LifeKILLED
22.05.2024 16:02+1Чаще всего, люди просто не понимают, в чем именно лучшая практика заключается
Недавний хайп вокруг критики "чистого кода" заключался в том, что критик применил его к бутылочному горлышку, требующему оптимизации. Странно, что эта очевидная манипуляция так расфорсилась.
Seenkao
22.05.2024 16:02не хочешь узнать какие компьютеры используются в Европе для управления ЖД-транспортом? )))
Kuch
22.05.2024 16:02+8Не нужно просить отдельное время на рефакторинг. Делайте его в рамках реализации функциональности.
Ужасно если в PR помимо задачи въехал ещё и рефакторинг. Ревьюить его будет одно удовольствие
Gwilwo
22.05.2024 16:02А в чем сложность? Если рефакторинг делается отдельным комитом, перед или после основной задачи
Kuch
22.05.2024 16:02+1Но все равно это поедет в один PR. И ревьеру это придется смотреть все одной портянкой, пытаясь разделить бизнес логику и изменение функциональности с обычным рефакторингом
Gwilwo
22.05.2024 16:02Ага, зато если его не делать, разработчик будет наслаждаться каждый день, пытаясь понять что вообще происходит в проекте. Один час времени проверяющего на десятки часов других разработчиков.
ManGegenMann
22.05.2024 16:02Вы не умеете смотреть отдельные коммиты? Обычно рефакторинг делают до бизнес кода 1 коммитом.
Kuch
22.05.2024 16:02+3Обычно рефакторинг делают в отдельном PR.
Я не делаю ревью по коммитам. Это какая-то бессмыслица смотреть 10 коммитов в которых несколько раз одно и то же место могло меняться. Время слишком дорого стоит, чтобы заниматься ерундой.
ednersky
22.05.2024 16:02если одно и то же место меняется 10 раз - повод сразу режектнуть PR
BugM
22.05.2024 16:02Почему? Человек думает, пишет и ему нравится комитить свои изменения. Итог получился хорошим. Вроде все нормально. Подделывать историю коммитов мало кто любит, это какое-то бесполезное занятие.
ednersky
22.05.2024 16:02+1Подделывать историю коммитов мало кто любит, это какое-то бесполезное занятие.
это бесполезное занятие для тех, кто никогда не использовал систему контроля версий... по назначению.
кстати, для чего по Вашему нужна система контроля версий?
BugM
22.05.2024 16:02В начале расскажите когда и зачем вы смотрели коммиты из смердженных веток? И как часто вы этим занимаетесь?
ednersky
22.05.2024 16:02занимаюсь нечасто, но когда этим приходится заниматься, то этот аспект становится безумно важным
а вопрос "зачем" это и есть вопрос, что я задал Вам.
итак, зачем по Вашему нужна система контроля версий?
BugM
22.05.2024 16:02+1Нечасто. А подделывать коммиты и тратить на это время по вашему мнению должен любой разработчик каждый день. Нормальные люди таким заниматься откажутся. Грубо откажутся.
Сурсконтрол конечно же нужен чтобы в блейме найти автора говнокода и хорошенько посмеяться нам ним у кулера.
Flyingmark
22.05.2024 16:02Только в случае, если совершенно не понимаешь почему тут сделано именно так, и ищешь кто, когда и в рамках какой задачи написал именно так. Иногда просто отсутствие правки там, где надо, а иногда там есть хитрая бизнес логика.
BugM
22.05.2024 16:02Почитать тикеты, которые должны быть прилинкованы к любой строчке кода, полезнее.
ManGegenMann
22.05.2024 16:02А зачем он это пушит? Берешь коммитишь локально дальше делаешь, потом сделал возврат подлил изменения.
Любой коммит вашей системы должен быть рабочим, я беру тыкаю Любой и жму старт, проект запускается и полноценно накатил все нужные миграции на чистой БД и начал работать.
BugM
22.05.2024 16:02Чтобы код оказался более чем на одном компьютере. Или чтобы прогнать CI/CD поверх кода. В современном мире микросервисов там интересное бывает.
Откуда у вас такое требование? Мастер должен переходить из одного рабочего состояния в другое. Что там в фича ветке вообще все равно. Это касается только того кто ее делает.
konstunn
22.05.2024 16:02+2Согласен. Нужно как минимум разносить в разные коммиты рефакторинг и фичу. А может даже и отдельными PR.
6afia9oftware
22.05.2024 16:02+1Спасибо! Отличные советы. Особенно понравился совет про кодера и программиста, тк сейчас только понимаю, что это абсолютная правда - можно написать гениальное ПО, но если оно никому не нужно, твой "гений" меркнет перед этим. Свои знания необходимо сочетать с нашим миром, тогда ты сможешь максимально удачно существовать, применяя знания и умения на практике, а просто совершенствование в чем-либо, и в кодировании в т.ч., никому кроме тебя не нужно, программист или инженер - это, в первую очередь, помощник народа, а не бодибилдер (колабилдер). Ещё раз спасибо!
Bigata
22.05.2024 16:02Более-менее правдоподобно, за исключением:
1) пункт наверное разработчики банковских интерфейсов на вооружение взяли. Ну ладно календарь в экран не лезет, можно масштабом спастись, в консоли куча нотисов и ошибок, так ещё и выкладывают токен.
4) не понял - там где уместно использовать ООП, так и с функциональным, иногда не имеет смысла лишние объекты создавать, если функция используется редко и в одном сегменте; в чём то перекликается с п 5)
ednersky
22.05.2024 16:02+1Немного статей из тех что я лайкаю, лайкаю с удовольствием. Но это прям-прям хорошая.
Единственная ошибка:
Да, функциональное программирование это новая штука
вообще, с функционального проггинга как бы не всё начиналось. man LISP. Хювеньен, Сапеньян и прочие...
Kenya-West
22.05.2024 16:02+1Все такие умные, прям...
10) Быть «кодером», а не инженером
Будьте «решателем проблем», использующим код как инструмент.
Если бы я был решателем проблем, то я бы использовал тебя, а не код. Вся правда жизни заключается именно в моей фразе.
mr_lionovsky
22.05.2024 16:02Не понимать, что такое «легаси-код»
На работе уже 20 лет работает сервер на Win2003. Никто операционку не трогает, обслуживание сводится с редкой замене выпадающих дисков RAID и минимальной читски в случае стучания кулеров.
А так же сервер с Debian 6, PHP 5.2, которому вроде как 10 лет. На старых версиях PHP не все понимают как писать код - всё же многая логика сильно изменилась.
А всё почему - производство, остановка и апгрейд всего этого выльется в нехилый простой и убыток компании. Работает, пусть и легаси - не трогай.
AlexMih
22.05.2024 16:02Интересная логика. А когда у этого сервера сгорит материнка, (подчеркну - не "если", а "когда". То есть это произойдет непременно, вопрос только во времени):
Придется купить новое железо.
Win2003 на него не станет. Станет только современная Windows.
Половина того системного софта, что стояло на Win2003, не станет на современную Винду. Придется ставить современные версии.
Половина прикладного софта откажется работать с обновленным системным софтом, потребовав допиливания или переписывания с нуля.
...То в какой простой и убыток выльется это компании?
Причем, скажу еще раз - событие это произойдет обязательно и непременно. Похоже, у ответственного за это человека удивительно крепкие нервы.
xxxDef
22.05.2024 16:02+1Одно из важных особенностей обновлений - решение вопросов с найденными дырами в безопасности
AlexunKo
22.05.2024 16:02+1На бессознательном уровне ваши всегда-никогда поставят вас раком рано или поздно. Это детская логика.
StPadre
22.05.2024 16:02После утверждения, что "функциональное программирование это что-то новое", смысл в заголовке вообще теряется, не рановато ли говорить о том, чего не стоит делать другим?
memba
22.05.2024 16:02Я работал разработчиком более двадцати лет. Это не делает меня экспертом, но я считаю, что начинающим стоит обратить внимание на пункт 8. А все остальное очень спорно и индивидуально.
kozlov_de
Не просить время на рефакторинг...
Спорно.
Надо спросить. Получить отказ. Решить что руководитель идиот и зря получает деньги. А вот потом уже тратить на реф свои собственные ресурсы
CrazyElf
Бывают разные проекты, разные команды, разные задачи. Наша команда получила легаси код в ужасном состоянии и начальство вполне понимая ситуацию дало нам достаточно времени на приведение кода в порядок, написание документации, рефакторинг и всё остальное, что было нужно. Это не мешает пилить попутно бизнес-фичи, а наоборот помогает. Если бы нужно было пилить бизнес-фичи поверх легаси, ничего не меняя, то просто бы все уволились в очередной раз и всё. А так работают, всё хорошо, всем интересно.
LaRN
Свое время тратить не нужно. Нужно заложить время на рефакторинг при планировании следующей доработки.
Просто накидывать процентов 5 на риски их использовать потом.
Yuriy_75
Ну вот доработка типа "добавить еще один алгоритм расчета чего-нибудь". Вы понимаете, что уже реализованные алгоритмы - это дикая мешанина, без документации и тестов. Разобраться в этом болоте - работы на пару недель. Как вы убедите заказчика, что реализация простенького алгоритма из пары арифметических действий требует две недели?
LaRN
Так я же пишу 5%, а не две недели. Тут просто много небольших попутных изменений, которые делают код чище.
Yuriy_75
То что чисто надо писать код нового алгоритма - ок. Со старыми алгоритмами из моего примера - что делать? Один новый алгоритм добавить - ну максимум 4 часа. Это с кодированием и тестированием.
5% от 4 часов это 12 минут. Что там за 12 минут можно в старых алгоритмах вычистить?
В общем, я пока сторонник мнения, что время на рефакторинг надо выделять отдельно.
LaRN
Ну вот для примера мой сегодняшний кейс. У нас каждый день дейлик на 30 мин. Скрам - все дела. Вот пока тема меня не касается сижу и рефакторю код.
Вроде 20 мин не много, но оно каждый день. Главное иметь план рефакторинга. Это один из вариантов как найти время.
Ну или если доработка не 4 часа, а 20, тут тоже уже можно немного заложить на рефакторинг.
kozlov_de
а потом тебя спросят почему ты не занимаешься основной задачей
LaRN
Так это часть основной задачи. Только нужно делать не буквально то, что написано. А старать делать код немного чище, чем было до доработки.
Опять же это все будет проверно тестами при ввпуске доработки, т.е. риск регресса минимальный
Dmitry_604
5% на рефакторинг легаси? даже не смешно. Обычно если лезешь в рефакторинг, то тратишь половину если не больше общего времени на задачу, по моему опыту.
ednersky
так потому и тратите половину времени, что выделяете именно под рефакторинг время.
Если же проводить рефакторинг именно тех мест, что вы правите, то и рефакторинга будет немного (столько же, но сильно размазан по коммитам) и он будет проходить вместе с коммитами, а то, что правкам не подвергается, получается - не важно хорошо или плохо написано: итак работает.
Dmitry_604
Так обычно рефакторинг в рамках одной двух функций не получается, если заменять по уму.
Если потихоньку чистить локально по методу бой-скаута, тогда да, по сути это просто часть задачи на которую итак заложено копание в легаси и нахождение нужного места встройки. Но по опыту глобально проект это не выправляет.
По хорошему рефакторинг это отдельные задачи с покрытием тестами старого кода и переделывания в новый. Но за такое не заплатят да.
ednersky
Вообще, если любой принцип довести до абсолюта, то будет получаться абсурд (об этом собственно в стате и спич, насколько я понимаю).
Соответственно можно говорить о принципе "в среднем придерживаемся такого подхода, но если что-то удобнее - не боимся выйти за границы".
Понятное дело, что если вы накопили сумасшедшее количество кода который НЕОБХОДИМО рефакторить и без этого не продвинуться - то вы просите время у начальства. Это нормально.
Но, если вы просто развиваете проект, как обычно, то можно рефакторить "по месту".
И здесь, кстати, вполне будут возможности обоснования "почему для добавления поля 2+2 надо 2 недели времени". Вы просто отвечаете: "потому что до этого наша система не была заточена на сложение чисел и эта задача - новая для неё".
Как-то так.
Ошибкой будет, как раз, добавить "2+2" быстро и костылём, а потом клянчить время у начальства на "поправить правильно".
Yuriy_75
Ну то есть, сначала пообещали начальству мощную и гибкую систему в рекордные сроки, а после внедрения рассказываем, что она не умеет складывать числа?
kozlov_de
Рефакторинг по мелочи вообще не эффективен
Иногда нужно поднять старые пласты говна. Вы будете делать это в своё время и на энтузиазме?
ef_end_y
Мой вариант решения проблемы: правило бойскаута «оставь место стоянки чище, чем оно было до твоего прихода». В рамках любой задачи немного рефакторишь старый код. Бывают запущенные случаи и это длится годами
ostapkob
Да был у меня опыт получения премии раз в квартал, но за новые проекты. И написать для директора, что то вроде переписывания уже работающего процесса было не уместно.
duke_alba
А просто заложить время на рефакторинг, когда оцениваешь сроки?
Не надо, как менеджеры, умножать сроки на 3.14, но есть же ещё 2.71?! :-)
Yuriy_75
С оценкой сроков и раньше было непросто. А ныне в аджайл подходе - это еще и вообще не модно. MVP за спринт сделать, а дальше к нему приделывать фичи.