Перевод статьи «Learn the fundamentals of a good developer mindset in 15 minutes».
Продолжаем разбирать, что отличает образ мышления хорошего разработчика. Первую часть читайте здесь.
11. Предсказания
«Предсказание это лишь прогноз того, что может случиться в будущем. Оно может основываться на каких-то объективных данных или же на предположениях».
Сталкиваясь с тем фактом, что код в будущем может быть изменен, некоторые разработчики предпринимают попытки сразу решить эту проблему. Для этого они проектируют решение настолько общее, что оно должно, по их мнению, подходить для любой ситуации, какая только может возникнуть в будущем.
Чрезмерная обобщенность решения связана с большим количеством лишнего кода.
Вы не можете предугадать, что случится в будущем. Поэтому, каким бы общим ни было ваше решение, оно не может быть достаточно общим, чтобы удовлетворить все возможные будущие требования. Велика вероятность, что весь код, написанный вами для решения будущих проблем, так никогда и не пригодится. Зато он повысит сложность вашей системы, затруднит внесение изменений и в конечном итоге станет тяжким бременем, которое раздавит вашу программу.
Не нужно заниматься предсказаниями. Ваш код должен быть обобщенным лишь в той степени, которая требуется сейчас.
12. Предположения
Что такое предположение?
«Предположение это утверждение, принимаемое за истину, или утверждение, которое может быть истиной, несмотря на отсутствие убедительных доказательств».
Предположения это вещи, которые вполне способны уничтожить проект разработки ПО. Рассмотрим пример.
Разработчики знают, что им нужно создать систему, делающую Х. Затем у них возникает идея, что в будущем этой системе нужно будет делать Y, поэтому они реализуют и Y тоже. Для создания Y пишутся тысячи строк кода.
В будущем разработчики понимают, что текущие требования полностью отличаются от предполагаемых. Но теперь в их программе есть ненужный код, который тяжело выбросить, потому что все в системе взаимосвязано. На рефакторинг уходят месяцы работы, и в итоге разработчики приходят к выводу, что лучше переписать все заново – и из-за этого теряются еще месяцы.
Чтобы избежать подобного, следуйте простому правилу:
Код должен основываться на том, что вам известно сейчас, а не на том, что, как вы предполагаете, случится в будущем.
13. Прекратите изобретать велосипед
Если вы, например, изобретаете собственный сборщик мусора, хотя уже существует отличный его образец, вы зря потратите кучу времени. Это время вы могли бы употребить на работу над собственной программой.
Есть лишь несколько обстоятельств, при которых имеет смысл изобретать велосипед:
- Вам нужно нечто, чего пока не существует.
- Все существующие «велосипеды» плохие или не могут удовлетворить ваши нужды.
- Существующие «велосипеды» не поддерживаются на должном уровне.
Простое правило:
Не изобретайте велосипед заново.
14. Сопротивляемость
Первой реакцией разработчика на предложение внести изменения должно быть «НЕТ».
Всегда сопротивляйтесь добавлению большего количества кода и дополнительного функционала, пока не убедитесь в их необходимости. Потому что ненужные изменения увеличивают количество дефектов в вашей системе.
Как определить, действительно ли изменения нужны?
Возвращаемся к первой части нашей статьи и вспоминаем о назначении своего ПО. А затем вспоминаем раздел, касающийся расстановки приоритетов.
«На что будет похож завтрашний Unix? Я уверен, что завтрашний Unix будет похож на сегодняшний, только он будет более захламленный», – Расс Кокс.
15. Автоматизация
Не тратьте время на повторяющиеся задачи. Настройте их автоматическое выполнение и забудьте о них. Они могут работать, пока вы спите. Если вы понимаете, что делаете что-то снова и снова, просто вспомните правило:
Если можешь автоматизировать что-то – автоматизируй.
16. Измерение кода
«Измерять прогресс в программировании путем подсчета строк кода это все равно что судить о прогрессе в строительстве самолета по возрастанию его веса», – Билл Гейтс.
Я часто вижу разработчиков, определяющих качество своего кода, основываясь на количестве строк. Они думают, что чем больше кода, тем лучше они работают. Их программы содержат сотни, тысячи строк кода, и для этих разработчиков это показатель того, что они работают над чем-то значительным.
Но встает вопрос: действительно ли это что-то значительное, или просто с этими программами что-то не так?
Скорее всего, эти программы неправильно спроектированы. Большинство простых решений не требуют много кода. Вполне можно достичь простоты, решив проблему при помощи меньшего количества строк.
Я не говорю, что чем меньше кода, тем лучше. Стараясь написать как можно меньше кода, вы легко можете попасть в ловушку и начать писать более хитроумный, тяжелый для понимания код. Здесь нужен баланс.
Оптимальный вариант – небольшое количество понятного, хорошо читаемого кода.
17. Продуктивность
Как вы измеряете продуктивность своего труда? Если подсчетом строк кода, то когда вы более продуктивны: когда пишете побольше или когда выбрасываете сотни лишних строк?
Ваша главная цель – сохранять размер кодовой базы небольшим. Вы не должны задаваться вопросом, как суметь написать больше кода. Скорее нужно спрашивать себя, как бы удалить побольше строк.
«Одним из моих самых продуктивных дней был тот, когда я удалил 1000 строк кода», – Кен Томпсон.
18. Тестирование
Когда нужно добавлять в свой проект ведение логов и обработку ошибок? Это стоит делать как можно раньше. Таким образом вам будет проще находить источники проблем, а благодаря этому вы сэкономите много времени.
Когда дело касается тестирования кода, я вижу много ошибок. Приведу пример. Было два условия, простой блок if-else. Разработчик передал input, который попал внутрь if-блока. Тест пройден, коммит отправился в систему управления версиями. Готово! Но как насчет блока else? Когда эта программа была поставлена в продакшен, это послужило причиной множества ошибок.
Тестируя код, нужно как минимум единожды выполнить все новые строки, причем сначала нужно тестировать отдельные части, а потом код в целом.
Если у вас замечен баг, для начала нужно его воспроизвести. Не нужно угадывать, в чем причина появления бага, и вносить исправления, основываясь на предположениях. При таком подходе вы скорее всего ошибетесь. Прежде, чем делать какие-то изменения, нужно увидеть баг своими глазами.
Вы должны быть разработчиком, которому можно доверять. Когда ваши коллеги видят, что вы сделали коммит, все они должны быть уверены, что вы протестировали свой код и убедились, что он рабочий.
Непротестированный код это нерабочий код.
19. (Недо)оценка
Приблизительные оценки, сделанные разработчиками, это большая проблема.
Обычно разработчики больше склонны недооценивать, чем переоценивать количество времени и сил, необходимых для разработки функционала. А в результате все эти просчеты приводят к пропущенным дедлайнам.
Решение: разбивайте большие вещи на составные части. Чем меньше задача, тем проще делать оценку. Вы, скорее всего, все равно ошибетесь, но гораздо меньше, чем если будете оценивать проект в целом.
Помните:
Выполнение любой задачи занимает больше времени, чем вы предполагаете.
20. Избегаем переписывания
Я думаю, что если вы будете применять в своей работе все уже описанные фундаментальные принципы создания программ, то до переписывания всего кода с нуля у вас дело не дойдет. Тем не менее, если каким-то образом вы совершите ошибки, которые приведут вас к идее начать все заново, вам нужно знать следующее:
Переписывание кода часто является манией разработчика, а не решением проблемы.
Почему так? Потому что читать код тяжелее, чем писать его. Вот почему так сложно использовать код повторно. Вот почему, когда мы читаем чужой код, наше подсознание шепчет нам: «Вытри все и начни сначала».
Во многих случаях переписывание кода все же необходимо. Однако нужно помнить следующее:
Первым вариантом решения проблемы должен быть рефакторинг.
21. Документация и комментирование
Один из ошибочных подходов к комментированию – добавление комментариев, сообщающих, что код делает. Это неправильно. То, что код делает, должно быть очевидно, исходя из самого кода. Если же это не очевидно, значит, код нечитаемый и его нужно упрощать.
Когда вы не можете упростить код, следует добавить комментарий, поясняющий эту сложность.
Настоящее назначение комментариев – сообщать о том, почему вы сделали что-то, а не о том, что делает код. Если вы не поясняете своих резонов, другие программисты могут запутаться и удалить важные части вашего кода при внесении в него изменений.
Пишите комментарии, поясняющие, «почему», а не «что».
Что касается документации, важно, чтобы она поясняла архитектуру вашей программы, а также каждый ее модуль и компонент. Это дает читателю возможность увидеть ваше ПО на высоком уровне. Когда к вашей команде присоединяется новый разработчик, благодаря такой документации ему будет легче понять вашу программу в целом.
Разработчики, занимающиеся своими частями программы, могут не иметь ни малейшего преставления о других ее частях. В результате они могут допустить ошибку в своей работе, которая повлияет и на другие части программного обеспечения. Поэтому важно, чтобы документация описывала все модули и компоненты.
22 Выбор технологий (инструментов, библиотек и т. п.)
Начнем с главного:
Не полагайтесь на внешние технологии или уменьшайте свою зависимость от них, насколько это возможно.
Почему? Потому что это еще один распространенный источник сложности. Зависимости могут убить вашу активную разработку и только еще больше затруднить работу. Когда вы слишком зависите от внешних технологий, вы не свободны. Что, если в одной из этих технологий обнаружится серьезный баг? Вам нужно будет ждать, пока разработчики его пофиксят. А если эта технология заложена в основу вашего проекта, вы застрянете и не сможете двигаться дальше. Поэтому важно очень внимательно подбирать технологии для вашего проекта.
Есть несколько вещей, которые стоит учесть, прежде чем начать использовать какую-то технологию:
- Активно ли она разрабатывается?
- Будет ли продолжаться ее поддержка?
- Насколько легко будет ее отключить?
- Что о ней говорит сообщество?
Ответив на эти вопросы, вы сможете снизить риск выбора неподходящей технологии.
23. Саморазвитие
Продолжайте учиться. Испытывайте новые языки программирования и инструменты, читайте книги о разработке программ. Это позволит вам взглянуть на разработку под другим углом. Ежедневные маленькие улучшения играют большую роль в обогащении знаниями и навыками.
Будьте открыты для нового. Избегайте одержимости чем-то одним. Нужно стараться использовать те технологии, которые необходимы для решения конкретных задач, а не те, которые вам просто больше нравятся. Не встревайте в ненужные дискуссии вроде Microsoft vs Linux:)
Знайте, что каждая отдельная проблема имеет собственное специфическое решение.
24. Не геройствуйте
Скажем, вы уверены, что с какой-то задачей можно справиться за пару часов. Но вот проходит четыре часа, а вы пока сделали только четверть необходимого. Инстинкт вам подсказывает, что сдаться сейчас уже совершенно невозможно, ведь вы потратили на эту работу столько времени! И вы включаете режим героя. Вы намерены заставить эту штуку работать (и слегка раздосадованы тем, что она все еще не работает). Вы хватаете свой плащ героя и отгораживаетесь от окружающего мира.
Не будьте одержимы. Нужно понимать, когда пора сдаться. Не медлите с обращением за помощью.
25. Не задавайте вопросов… Просите о помощи
Когда вам нужно что-то реализовать, но вы не уверены относительно решений, не спрашивайте окружающих, как это сделать… по крайней мере, не сразу. Вместо этого сначала испытайте все, до чего можете додуматься сами. И чем менее вы знакомы с концепцией или языком, тем важнее поступать именно таким образом.
Когда не можете ничего придумать самостоятельно, поищите варианты решения в интернете. Найдите ответы и испытайте их. Модифицируйте эти ответы, посмотрите, можете ли вы понять, почему они работают, а затем адаптируйте их для своего кода.
Но всегда обращайтесь за советом.
Когда вы уже испытали все варианты и (желательно) нашли рабочее решение, наступает лучший момент попросить совета. Попросите товарищей и старших разработчиков просмотреть ваш код.
Спасибо за внимание! Надеюсь, это руководство вам пригодится!
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]
