«Мы можем провести рефакторинг позже» - это гребаная ложь.
Прежде чем я начну разглагольствовать, я хочу прояснить, что я действительно сочувствую сценариям, в которых у вас недостаточно ресурсов и мало времени на критически важные для бизнеса функции, требующие активного времени на разработку, чтобы выжить. Я работал в одном таком месте. Это не обязательно порождает хороший код, часто просто код, который работает.
Моя тирада здесь не о таких ситуациях. Это примерно 99,999% всех остальных случаев, когда у вас есть шанс сделать это правильно в первый раз, когда вы разрабатываете его, просто правильно обосновывая ожидания своих клиентов. Если вы знаете, что вам понадобится четыре дня, чтобы что-то заработало и заработало, скажите им, что это займет восемь дней, и потратите последние четыре дня на доработку, улучшение обработки ошибок, повышение доступности и т. Д.
Потому что, как только коды будут развернуты, когда они будут запущены в производство и «работают» - удачи, и у вас будет свободное время, чтобы вернуться к ним. Если вам повезло, что у вас есть менеджер с сильным техническим образованием (а ему повезло, что он имеет то же самое на всем протяжении цепочки), вы можете просто получить его.
Но факт в том, что большинство людей, не являющихся разработчиками, даже не понимают скрытых издержек технического долга.
К черту, многие разработчики этого даже не понимают!
Каждая строчка кода - это ответственность, насквозь.
Каждая строчка кода подвержена ошибкам, учитывая взаимосвязанный контекст, в котором эта строка существует.
Каждая строчка кода - это еще одна строчка кода. вы должны задокументировать.
Каждая строчка кода инерционна для дальнейшего развития функции.
Когда ваша система заработает, вы абсолютно должны тратить свое время на выполнение этих трех вещей.
Во-первых, уменьшите размер - сделайте свой код максимально СУХИМ. Но никогда не жертвуйте удобочитаемостью и не используйте уловки. На это всегда нужно гораздо меньше, чем вы думаете. Я разработал API с 5+ полнофункциональными конечными точками CRUD и обширной документацией, которая может занимать 12 запросов в секунду (включая накладные расходы базы данных) на крошечном сервере с менее чем 180 строками кода. Не потому, что я какой-то волшебник, а потому, что когда вы очень внимательно изучаете, что делают ваши коды, вы почти всегда обнаруживаете, что часто повторяете себя.
Во-вторых, добавьте больше журналов. Обычно это происходит за счет увеличения размера, поэтому здесь необходимо уравновесить; но, боже мой, поблагодаришь ли ты себя позже. Журнал, журнал, журнал, журнал, журнал, журнал… .. особенно если вы используете распределенную систему.
В-третьих, проводите больше тестов на сбой. Целенаправленно попытайтесь ввести в свою программу как можно больше глупостей. На самом деле, действительно потеет из-за того, что он разбился. Не просто проверяйте успешные пути при создании приложения; убедитесь, что вы тестируете и все плохие. Иногда это может занять очень много времени, но оно того стоит. Больше обработки ошибок - всегда хорошо.
Регистрируйте больше, обрабатывайте больше ошибок и делайте все с меньшим количеством SLOC. Создавайте внутренние программные API (каждый класс / модуль - это API!) С учетом расширяемости и производительности разработчика. Добавляйте много комментариев (раньше я думал, что вам не нужно было, и я счастлив сказать, что был для этого долбаным идиотом). Напишите документацию по готовым модулям.
Делайте все это клише, повторяйте чушь, потому что на самом деле это не чушь.
И не говорите себе, что сделаете это «позже».
