Не нанимайте крутых программистов, если вы стартап и только начали делать продукт. Они вам все испортят
Один раз я написал статью о том, как увлечение новым языком программирования спасло меня от выгорания. Её прочитало много людей, и меня позвали работать в стартап. Предложение было заманчивым, ребята звали меня делать реальные вещи, а не абстрактное дерьмо. Я согласился.
Статья гарантированно напугает всех кто считает деньги,
поэтому думаю надо дать ряд пояснений для 'непричастных':
"Костыль"/быстрое решение/hotfix - с точки зрения последующих затрат это натурально множитель. Множество костылей и является тн. 'legacy code', по факту.
Каждая следущая добработка в проекте с костылями будет стоить не Х часов разработки а Х * коэффициент костылей.
Вот пример для иллюстрации:
Стоит задача реализовать загрузку файлов картинок через веб-форму, для генерации и отдачи preview. Задача в такой постановке банальна, посему отдается фрилансеру и делается за день.
Дальше нужно "доработать" загрузку больших картинок, скажем от 1Гб. Все, вы попали на пару месяцев работ, т.к. нужно делать асинхронную загрузку, с прогрессом, с паузой и отменой, с обработкой разрыва связи. Саму генерацию preview нужно тоже докручивать, тк ничего стокового при таких размерах работать не будет.
Дальше нужно добавить "всего лишь" генерацию превью PDF/DOCX какого-нибудь - и вы попали еще раз и сильно, потому что там внутри есть страницы, те на выходе вашего замечательного решения нужен не один сгенеренный preview а несколько. А вы уже например привязали биллинг к количеству сгенеренных пользователем превью.
Т.е всего лишь пара небольших доработок (с точки зрения бизнеса) и проекту на уровне MVP - кабздец, ну либо увеличение бюджета раза в три.
Что было бы если вместо быстрого решения было сделано продуманное?
Месяц-полтора тяжелой работы, зато все последующие доработки - с предсказуемыми сроками, без авралов и выхода за границы бюджета.
Так что не стоит так сразу кидать кирпичами в каждого предложившего рефакторинг - не каждый врач вам враг, даже если таблетки горькие :)
Идея хорошая, но в реальности будущее неопределенно.
Представьте, что дорабатывать ничего не нужно и бизнес всё устраивает, скажем год... А потом вообще вышла новая технология, которая это всё это из коробки умеет.
Или вообще бизнес решил отказаться от этого куска, или использовать сторонний сервис стоимостью 200 баксов в год.
Траты на рефакторинг это не просто -1 месяц работы команды, за этот месяц бизнес мог бы добавить новых фич (пусть и на костылях) и привлечь больше пользователей. т.е. стоимость рефакторинга умножайте на 2.
Сам рефакторинг тоже не 100% страховка от того, что не придется всё выкинуть нафиг и не рефакторить снова, если требования сильно поменяются.
Поэтому хороший разработчик не должен писать хороший код в вакууме.
Нужно задавать вопросы:
Зачем этот код нужен? Как он будет использоваться? Какая планируется нагрузка сейчас и через год? Какие планы у бизнеса? и т.п.
И исходя из ответов и собственного опыта (ведь бизнес сам часто не знает точно или обманывает сам себя) предлагать эффективное решение (цена=время/качество)
_______________________
Что бизнесу нужно знать так это то, что программисты обожают рефакторить и переписывать.
Мы готовы ради этого овертаймить, и сидеть ночами лишь бы код стал элегантным, расширяемым, поддерживаемым и т.п.
Вопрос нужен ли такой код бизнесу? нужен ли такой код бизнесу _сейчас_? Нужен ли такой код вместо уже работающего? Готов ли бизнес перетестировать все кейсы, которые затронул ваш рефакторинг?
В критических местах возможно да. В остальных под большим вопросом.
Лучший способ избежать говнокода и не потратить много времени - нанять человека, который уже решал подобную задачу в другом месте и кто-то другой заплатил за его опыт.
Месяц-полтора тяжелой работы, зато все последующие доработки - с предсказуемыми сроками, без авралов и выхода за границы бюджета.
Отлично, а зачем такое решение абстрактному сервису в вакууме, если такая задача может быть никогда и не возникнет? Это как если бы клиент подбирал машину для доставки продуктов по городу, а вы ему вместо условного VW Caddy предлагаете сразу БелАЗ, потому что вдруг какой-то клиент через 10 лет закажет сразу 100 тонн картошки.
Самый адекватный камент.
Каждая следущая добработка в проекте с костылями будет стоить не Х часов разработки а Х * коэффициент костылей.Вообще-то это далеко не всегда так. Имея уже работающий код намного понятнее как делать более общий вариант и этим рабочим решением уже пользуются.
Вот например:
Дальше нужно "доработать" загрузку больших картинок, скажем от 1Гб. Все, вы попали на пару месяцев работ, т.к. нужно делать асинхронную загрузку, с прогрессом, с паузой и отменой, с обработкой разрыва связи. Саму генерацию preview нужно тоже докручивать, тк ничего стокового при таких размерах работать не будет.Сделать поверх предыдущего загрузчика займет ровно столько же (а может и меньше), чем писать это "правильно" с самого начала.