Принципы, которые я усвоил за 24 года своей карьеры
Моя первая работа в области программирования была еще в 1996 году. Только что окончив колледж здесь, в Великобритании, я был принят на работу младшим программистом на COBOL. И вот мы сейчас, в 2020 году, а я все еще зарабатываю на жизнь написанием кода. И я люблю это.
За 24 года (на момент написания) моего опыта разработки коммерческого программного обеспечения - будь то программное обеспечение для управления складом для крупных распределительных центров или веб-приложения для малых, независимых предприятий - я кое-что узнал в процессе написания отличный код и создание отличного программного обеспечения.
Мое определение отличного - это программное обеспечение, в котором отсутствуют ошибки, проверено, обеспечивает высокую производительность, простое в обслуживании и понимании - с возможностью повторного использования везде, где это имеет смысл. И в этом мне помогают следующие принципы. Надеюсь, они вам пригодятся.
Код для людей
Вы пишете код только для людей. Даже если вы единственный разработчик, работающий над кодовой базой, вы должны придерживаться этого правила.
Существует так много способов написания кода - так много разных стилей - но, в конечном итоге, его цель - дать вам один и тот же конечный результат независимо от того, как он написан. Так что напишите свой код, чтобы другие (или вы, через шесть месяцев) могли его прочитать и понять.
Единственное предостережение к этому правилу: если то, что вы пишете, настолько критично для производительности, вы должны писать его таким образом, чтобы он был высокопроизводительным, но не столь очевидным в отношении того, что он делает и почему. Но если честно, как часто это происходит?
Обычно в вашей карьере наступает момент, когда вы постоянно пытаетесь написать умный код: что-то на несколько символов короче или всего пара строк, которые делают что-то очень сложное.
Это ваше эго на работе. Я знаю это, потому что я был там, и я часто вижу это у менее опытных разработчиков, которые начинают понимать требования к тому, чтобы быть отличным разработчиком ... хотя некоторые из них никогда не перерастают в это.
Держите свое эго под контролем. Сделайте свой код настолько простым, что разработчик любого уровня сможет его прочитать и понять, и, что особенно важно, разработчик любого уровня сможет поддерживать его.
Если вам нужны комментарии, это может быть слишком сложно
Если могу, я пишу действительно, очень простые функции, которые делают одно, поэтому их можно составить для совместной работы. Я стараюсь иметь только один вход, один выход и никаких побочных эффектов; поэтому в идеале они должны быть чистыми функциями. А те, которые не являются чистыми из-за побочных эффектов (вызов API, обновление DOM и т. Д.), Я стараюсь надлежащим образом сдерживать.
Если я это сделаю, то комментарии в моем коде станут редкостью, потому что здесь довольно ясно, что происходит. И если есть сложности или вопросительные знаки, то обычно мои тестовые примеры охватывают это и объясняют, почему.
Я не говорю, что вам не следует добавлять комментарии. Если они нужны, они нужны. Но как только я начинаю добавлять комментарий, я всегда останавливаюсь и думаю: добавляю ли я этот комментарий, потому что мой код слишком сложен?
У ваших модулей должны быть тесты - и, в идеале, они должны быть написаны в первую очередь
Мы говорим о модульных тестах. Если вы пишете действительно простые функции, вы можете писать действительно простые модульные тесты. Один вход, один выход и никаких побочных эффектов. А это означает, что нет никаких причин не писать сначала свои модульные тесты и не следовать практике разработки через тестирование (TDD).
Однако я менее строг к другим разработчикам в отношении написания тестов в первую очередь, когда речь идет о командах, с которыми я работаю. По моему опыту, большинство разработчиков с трудом следуют TDD. Они понимают концепцию и преимущества, которые она дает, но все же склонны сначала писать свой код.
Обычно я нахожу это потому, что они недостаточно подробно разбирают процесс и пытаются получить правильный конечный результат всего лишь с помощью горстки больших функций. Из-за этого они еще не знают, что правильно тестировать в своих подразделениях.
Дело в том, что если вы начинаете с тестов и сосредотачиваетесь на небольших, в основном чистых функциях с единственной ответственностью, то сначала писать тесты становится намного проще. И тогда вы обнаружите, что большую часть написанного вами кода можно использовать повторно… особенно когда вы начнете писать функции высшего порядка, которые можно использовать и составлять по-разному.
Но попадание в TDD требует изменения мышления, подхода и отказа от старых привычек. Это требует времени, терпения и практики. Следовательно, я не слишком строг в этом принципе с другими - хотя я всегда пытаюсь подтолкнуть их в этом направлении.
… И то, как ваши устройства работают вместе, тоже должны пройти тесты
Они также известны как интеграционные тесты.
Ваши функции покрываются модульными тестами, поэтому вы знаете, что при одном и том же вводе вы всегда будете получать один и тот же результат - возможно, в тех случаях, когда у вас есть побочные эффекты.
Затем вам обычно потребуется, чтобы эти функции работали вместе, чтобы получить общий конечный результат. Этот конечный результат - это то, что должны тестировать ваши интеграционные тесты.
Эти тесты являются основными тестами, которые вам следует писать. Они дают вам уверенность в том, что ваши подразделения работают вместе, как вы и планировали.
Когда ваш код будет покрыт модульными и интеграционными тестами, вы сможете с полной уверенностью провести рефакторинг кода. Внесите изменения, сохраните файл, посмотрите, как ваши тесты запускаются автоматически, и, если они пройдут, ваш код исправен.
Весь этот процесс иначе известен как красный, зеленый, рефакторинг: напишите свои тесты, которые не пройдут (красный). Напишите свой код, чтобы тесты прошли (зеленый). Измените код, чтобы он соответствовал вашим принципам и стандартам кодирования (рефакторинг).
Опять же, это требует изменения мышления. Но как только вы добьетесь этого через последовательную и целенаправленную практику, вы не будете оглядываться назад.
Ваши проекты должны пройти всеобщую проверку качества
Они должны стать частью ваших ожидаемых критериев, чтобы считать код пригодным для разработки. Такие вещи, как:
- Использование линтера для проверки вашего кода
- Использование prettifier для форматирования вашего кода
- Наличие согласованного минимального процента покрытия для тестов
- Успешное прохождение всех тестов до создания запроса на вытягивание
- Наличие некоторой формы проверки безопасности
… и так далее. Вам следует автоматизировать как можно больше этих проверок как можно раньше в вашем цикле разработки.
Иногда меня спрашивают, зачем вам приставка для проверки качества. Проще говоря, это означает, что все работают по одному и тому же плану, и это помогает избавиться от менталитета Я исправлю это позже, которое может закрасться. Это также означает, что ваши коллеги проверяют ваш код , на них меньше когнитивная нагрузка.
Что приводит нас к…
Сохраняйте когнитивную нагрузку на низком уровне
Чем больше вы пишете кода для людей, тем лучше будет проверка качества. И чем лучше тесты и чем проще код в целом, тем меньше когнитивной нагрузки требуется вашим коллегам, чтобы прочитать и понять ваш код и то, что он делает. Это также означает меньшую когнитивную нагрузку на ваше будущее, когда вы вернетесь к коду, который пишете сегодня. Ваше будущее и все, кто коснется кода в будущем, будут вам благодарны за это.
Возможно, вы не сможете реализовать все из этих принципов по ряду причин. Если это вы, потратьте некоторое время на то, чтобы выяснить, что вы можете реализовать, хотя бы для уменьшения когнитивной нагрузки.
Не запутайтесь, пытаясь сделать его идеальным
На протяжении всей своей карьеры я работал с отличными разработчиками. Я имею в виду, действительно здорово. Но некоторые из них выполняются вечно. Почему? Они хотят, чтобы все было идеально.
Они будут часами обдумывать имя переменной или функции, даже если текущие из них ясны и очевидны. Или они будут беспокоиться о вещах, которые им, вероятно, не понадобятся, или о сценариях, которые никогда не произойдут, или об оптимизациях, которые не имеют никакого значения в реальном мире.
Конечным результатом является то, что их скорость доставки ниже, чем могла бы быть, что потенциально может оказать давление на их коллег по производственной линии; внезапно они нуждаются в быстрой проверке кода, чтобы как можно скорее передать его инженерам по тестированию, которые должны работать быстро и, возможно, срезать углы. Этот эффект усиливается по мере продвижения работы по производственной линии.
Поздняя доставка - это факт жизни в разработке программного обеспечения, но не опаздывайте, потому что вы пытаетесь сделать свой код идеальным. Отлично - это достаточно хорошо.
Микрооптимизация редко того стоит
Это еще один убийца производительности: тратить часы или даже дни на рефакторинг кода, пробовать разные вещи, чтобы смыть все возможные приросты производительности ... и все это для экономии, которая ничего не значит в реальном мире.
Если программное обеспечение, над которым вы работаете, требует такого уровня оптимизации производительности, тогда все в порядке. Но это случается довольно редко, и его следует учитывать при оценке, чтобы ожидаемое и учесть затраченное время.
Так же, как попытки сделать ваш код идеальным, микрооптимизация редко того стоит. Они убивают время без заметной выгоды и оказывают давление на тех, кто находится дальше по производственной линии.
Примите, что будут ошибки
Принять это. Живи с этим. Не ругайте себя, когда кто-то находит их в написанном вами коде. Такова природа игры.
Оставьте лучше, чем вы нашли - или, по крайней мере, не хуже
Всякий раз, когда вам нужно изменить существующий код, всегда старайтесь оставить его лучше, чем вы его нашли. Улучшите тесты, улучшите имена переменных или функций и избавьтесь от этого цикла внутри цикла.
Это не всегда возможно по ряду причин, включая, конечно, отсутствие каких-либо улучшений. Поэтому убедитесь, как минимум, что вы не оставите его хуже, чем вы нашли.
Также при этом убедитесь, что вы не попали в ловушку попыток сделать его идеальным или сделать микрооптимизации, которые не имеют реальной ценности.
Стоимость технического долга в конечном итоге подорвет любой бизнес
Технический долг должен быть выплачен как можно скорее. Как и в случае с финансовым долгом, чем дольше он остается, тем хуже становится проблема и тем дороже стоит избавиться от нее.
В конце концов, это вас искалечит; вы будете постоянно писать код для решения проблемы и, следовательно, увеличивать объем долга, пока, наконец, не достигнете точки, в которой застряли и не нуждаетесь в полной переписывании. И многие компании не могут себе этого позволить.
Если можете, верните технический долг сразу после его обнаружения. Если это означает, что вы немного превысили свои оценки, объясните это всем, кто вам нужен (владельцу продукта, руководителю проекта и т. Д.), И объясните, почему это так важно. Если вы не можете вернуть его немедленно, запишите его, расставьте приоритеты и воспроизведите как можно скорее.
Люди ужасны в оценке
Один из моих бывших начальников говорил об оценках: Удвойте и добавьте 10%.
Честно говоря, это неплохая стратегия, потому что большинство людей довольно плохо оценивают время, необходимое для завершения рассказа, или сложность необходимой работы.
Чем меньше вы знаете о чем-либо, тем менее точной будет ваша оценка. Чем сложнее задача, тем менее точной будет ваша оценка. Чем крупнее задача, тем менее точной будет ваша оценка. А если вас просят оценить то, чего вы никогда раньше не делали… вы уже догадались, - тем менее точной будет ваша оценка. На самом деле, если вы никогда раньше этого не делали, ваша оценка, скорее всего, будет совершенно неточной.
Когда владелец продукта или менеджер проекта пытается спрогнозировать окончательную дату поставки на основе оценок, предоставленных им командами разработчиков, я всегда вздрагиваю; неточные оценки, умноженные на несколько историй и эпических произведений = в высшей степени неточные и фактически бессмысленные оценки.
Убедитесь, что вы это понимаете. И убедитесь, что человек, которому вы сообщаете, тоже это понимает.
Когда вы открываете запрос на включение, вы говорите: «Мой код готов к работе».
Если вы просите, чтобы ваш код прошел рецензирование, чтобы его можно было объединить с основной веткой разработки (которая зависит от вашего рабочего процесса), вы фактически говорите, что ваш код готов к производству.
Это означает, что он должен пройти все проверки качества, чтобы обеспечить достаточное покрытие тестами, все тесты прошли, код был добавлен и предварительно настроен, критерии приемки были соблюдены и т. Д.
По сути, вы говорите, что он готов продвигаться по производственной линии к следующему этапу. Так что проявите должную осмотрительность, прежде чем открывать пул реквест.
Не шифруйте чужой кодекс
Так легко стонать и жаловаться на чужой код. Так легко составить план их работы и рассказать своим коллегам, насколько она ужасна, и в то же время заставить себя выглядеть потрясающе, рассказывая им, как это должно было быть сделано.
Дело в том, что вы не знаете всей истории. Вы не знаете, какое давление они испытывали. Вы не знакомы с требованиями, критериями приемки или состоянием ума разработчика в то время.
Возможно, они переживали трудные времена в своей жизни, и код, который они писали, не был их главным приоритетом. Может быть, они все еще учились, и это было лучшее, что они могли сделать в то время. Возможно, старшие разработчики не выполнили свою работу должным образом, допустив проверку кода.
Если не до царапины, поправьте; не стоните об этом в стоячем зале или у кофемашины.
Иногда все выходит из окна
Бывают случаи, когда у вас нет выбора, кроме как сделать что-то быстрое и грязное - выбросить все свои руководящие принципы в окно и просто выполнить.
Такие случаи случаются со всеми разработчиками. По какой-то причине вам просто нужно стиснуть зубы и продолжать. Противодействие этому вызовет у вас только разочарование и гнев; оно того не стоит. Выражайте свою точку зрения, но не цепляйтесь за нее.
Когда это неизбежно произойдет, просто примите это, отпустите и двигайтесь дальше. Создайте задание по уборке, которое можно будет сыграть в самое ближайшее время; это означает, что вы можете все исправить, и регистрирует накладные расходы, которые принимают такие решения.
Заключение
Я стараюсь писать отличные программы. Конечно, иногда так бывает не всегда. Иногда я что-то упускаю или работаю над устаревшим кодом, который пока не могу переписать (или что-то еще). Я всего лишь человек. Так оно и есть, и это то, с чем, хотя мне и не нравится, я помирился очень давно.
Несмотря на это, я всегда стремлюсь к своему определению великого. Следование этим принципам позволяет мне это делать, и это принципы, которые я пытаюсь внушить другим разработчикам, с которыми я работаю.
Спасибо за прочтение!
