Можно ли сделать мвп при этом не наговнокодив?

Question

[ishlambad]

Можно ли найти этот "идеальный баланс" / усидеть на двух стульях? Так чтобы написать быстро основной функционал, как любят говорить те, кто стоял у истоков проекта, "на коленке" при этом, "подложить" зачатки архитектуры, DI, тестов итп. Для того чтобы, когда проект выйдет в "люди", не было (овер)сложностей внедрения фичей и можно было потихоньку допиливать "хрупкие" места, при этом не сломав ничего.

Большая ли разница во времени - если я буду писать, балансируя 50/50 на solid, dry, kiss, yagni итп, сколько я времени сэкономлю, чем, если бы я писал, как Рахул из Индии, "грубо" говоря в файл на 100000 строк. Более чем в 2 раза или нет?

Comments

[Максим Федоров]

можно, зависит от ваших навыков, скорости работы и вашей "нейроночки"

[ishlambad]

Максим Федоров, спасибо) а как думаете по времени, ощутимая ли экономия?) и вопрос, под что пилите?)

[Максим Федоров]

ishlambad, не знаю просто как делать "не экономно" :) шутка
обычно, пишем как умеем, умеем так — не заумно/модно, но и стараемся изолировано писать, чтобы тесты писались хорошо и быстро, кода много просто

пишем бекенд большой системы

Answer 1

[Владимир Солнцев]

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

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

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

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

Comments

[ishlambad]

Согласен с вами) параллельно с этим вопросом нагуглил эту статью. В комментариях нашел ответ на свой.))

Answer 2

[Андрей]

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