Я перфекционист. Я всегда хочу, чтобы мой код был безупречным и без ошибок. Сразу от выбора имени переменной до сообщения о фиксации в Git я буду стремиться к совершенству. Иногда я тратил несколько минут на выбор имени ветки в Git. Вот и все, я сказал это, я принял это.

Но одна из вещей, которую я так далеко извлек из своего пути разработчика, - это то, что попытки стать перфекционистом мешают стать хорошим разработчиком. Да, каждый разработчик хочет, чтобы его код был идеальным. Но мало ли они знают, что ни один код не идеален, он всегда достаточно хорош.

Вы хотите, чтобы ваш код был идеальным, как безупречный бриллиант. Но я говорю вам, что почти каждый алмаз на земле имеет какой-то изъян. Этот недостаток показывает уникальность алмаза, а также идентичность алмаза.

Лучше алмаз с изъяном, чем камешек без него.
- Конфуций

Нет кода лучше, чем «без кода»

Совершенный код (не) существует. И единственный способ достичь совершенства - не писать никакого кода. Если взять операционную систему Linux, которая работает на 99% серверов Интернета по всему миру, то даже сегодня у нее так много проблем.

Если бы разработчики Linux ждали подходящего момента для отправки своего кода, я уверен, что они бы не зашли так далеко. Кроме того, это не означает, что они пишут плохой код. Они пишут код, который достаточно хорош для отправки.

Если вы можете сделать сегодняшнюю работу сегодня, но делаете это таким образом, что вы не можете сделать завтрашнюю работу завтра, тогда вы проиграете.
- Кент Бек

Процесс не должен тормозить прогресс

Я люблю следовать лучшим практикам во всей своей работе. Первое, что я делаю после изучения синтаксиса и семантики языка программирования, - это знаю, как разрабатывать код с использованием передовых практик для конкретного языка. Но позвольте мне сыграть здесь адвоката дьявола.

Заставьте это работать, сделайте это правильно, сделайте это быстро.
- Кент Бек

Да, мы все знаем, что каждый разработчик должен следовать лучшим инженерным практикам. Так вы в конечном итоге станете хорошим разработчиком. Но в то же время нельзя допускать, чтобы процесс и практика мешали выпуску программного обеспечения.

Возьмем пример. Вы создаете веб-приложение, чтобы отображать последние новости о программном обеспечении. Конечный продукт должен уметь извлекать новости из разных источников и отображать их на красивой веб-странице. Вы начнете проект с учетом начальной версии, это будет простое веб-приложение, которое извлекает новости, связанные с программным обеспечением, из одного источника, такого как TechCrunch.

Первое, что вам нужно сделать, это заставить его работать. Первоначальная версия должна получать новости из TechCrunch. Теперь вам нужно написать шаблонный код для установления соединений с конечной точкой API TC, посмотреть, как разработан их API, и как реализовать поисковые запросы с помощью этого API.

Затем вы можете просто отобразить результаты на веб-странице. Теперь вам есть что показать для вашей первоначальной версии. Затем вам нужно исправить это. Теперь вы немного очистите код. Удалите все жестко запрограммированные значения, структурируйте свой проект, абстрагируйте модули и напишите несколько тестов.

Допустим, вы реализовали OAuth для связи с API TechCrunch. Вы будете абстрагироваться как отдельный модуль, чтобы вы могли повторно использовать его при добавлении API для другого источника новостей.

Теперь последняя часть, вы можете сделать это быстро. Поскольку вы уже внедрили рабочую версию и очистили код. Вы можете легко определить, какая часть кода занимает больше времени, и исправить их, выполнив простой сравнительный анализ.

Помните, хорошие разработчики, следуйте лучшим практикам. Хорошие разработчики тоже показывают прогресс. Если вы заметили, что вы уже начали показывать прогресс на самом первом шаге.

Технические долги - это нормально

Согласно Википедии, технический долг - это то, что отражает подразумеваемую стоимость дополнительных доработок, вызванных выбором простого решения сейчас, а не использованием лучшего подхода, который потребовал бы больше времени.

Технические долги такие же, как и любые другие долги. Когда у вас чего-то не хватает, вы одалживаете это и возвращаете, когда можете. Когда вы решите залезть в долги, следует помнить о двух вещах.

Во-первых, окупаемость повлечет за собой некоторые проценты, а это компромисс, на который вы готовы пойти позже, чтобы сделать что-то сегодня. Во-вторых, невыплата долга в нужное время вызовет у вас проблемы.

Помните, как и любые другие долги, технические долги со временем накапливают проценты, и невыплата их доставит вам неприятности.

Но технические долги - это не плохо. Если вам нужно разработать MVP, вы должны смириться с возникшими долгами, чтобы доказать свою гипотезу. Кроме того, при выпуске версии программного обеспечения вы должны отказаться от того, чтобы иметь то, что не соответствует текущему плану выпуска.

Опять же, вы должны построить свою базу кода таким образом, чтобы вы могли выплатить долг в будущем. Код с техническими долгами - неплохой код. Код, который не позволит вам выплатить технические долги, - это плохой код.

Конструирование - это компромисс между полезными функциями и необходимыми функциями

Так что не ждите подходящего момента, чтобы начать проект. Не ждите, пока ваш код станет безупречным, чтобы отправить релиз.

Идеальный момент сейчас, идеальный код - это рабочая версия, которая у вас есть прямо сейчас.

Прекратите совершенствовать и начните отгрузку.