[Перевод] Что разработчик никогда не должен делать
Я работал разработчиком более пяти лет. Это не делает меня экспертом, но я считаю, что сделал достаточно ошибок, чтобы поделиться с вами. Вот 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 вещей основаны на моём личном опыте, поэтому я не жду, что со мной все согласятся. Но я надеюсь, что это окажется вам полезным. Пишите в комментариях, если вам есть что добавить. Спасибо за чтение!
Habrahabr.ru прочитано 8359 раз
