Как не переборщить с желанием все спроектировать прежде чем писать код?
Я работаю в относительно небольшой компании (два человека на бэкэнде, два фронта, два разработчика мобильных приложений)
Но проект достаточно большой и сложный
И сейчас планируется разработка большого куска проекта (он чуть ли не сравним по объему с тем, что уже написано за три года - новая услуга на сервисе)
С коллегой разделились во мнениях Я говорю, что нужно все продумать
Он говорит: "Давай декомпозируем на задачи и начнем делать. По ходу реализации разберемся"
Я к проекту присоединился позже своего напарника и мне, честно говоря, (буду краток) не нравится как он написан. И мне не хочется усугублять, я хочу сделать качественно, чтобы не поддерживать говнокод следующие два года
Но я боюсь, что проектирование слишком затянется и не получится ли так, что это время потрачено впустую. Я даже хочу нарисовать UML-диаграмму для будущих классов (ну вообще надо бы, ситуация на проекте так себе)
Хотелось бы собрать плюсы и минусы обоих подходов и узнать не подхватил ли я "UML-головного-мозга" и не перегибаю ли я палку с желанием продумать все от и до перед началом написания кода
Делайте MVP и наращивайте проект. Измените задачу так, чтобы можно было отдавать клиентам кусками. Никому не надо, если вы будете большую фичу писать, а потом окажется что она не нужна.
Да, MVP хорошая штука и мы даже "выделили" его и выбросили пару пунктов, но на остальное ген. директор сказал: "Да если это не будем делать сразу, тогда вообще смысла нет. Делаем"
>не нравится как он написан
пффф а ты что думал, в сказку попал? тебе и не должно нравиться, это для бизнеса где-то на 25 месте находится.
-----
чесно говоря я вообще не слышал чтоб реально на практике УМЛ использовали, для проектирования (хотя тема когда-то и была на хайпе).
Ну да на черновиках набрасывают общие идеи, сам код также может быть тем черновиком для идей, но это всего-лишь черновик.
=======
>"Давай декомпозируем на задачи и начнем делать. По ходу реализации разберемся"
очень грамотный, взвешенный подход. Основная проблема не опытных людей, попытка сразу выдать идеальный результат в вакууме, люди которые поопытнее знают что это сделать не возможно, а попытка идеальной проектировки приведет только к переусложнению и ухудшит разработку и вместо того чтоб гибко подгонять решение под постепенные уточнения, вы будете стремится все подогнать под рамки какой-то первой "идеальной" идеи реализации, на основе первого восприятия задачи (которое часто ошибочно).
Проектирование полезно. Особенно больших модулей. Не жалейте на него времени, это ускорит в дальнейшем разработку, и внедрение новых фич, когда вы уже наглядно будете видеть могут быть с этой фичей какие-то проблемы или нет. Да и после проектирования уже видно что на какие куски разбить при разработке.
Проектирование даёт "карту самого быстрого наступления" к первому релизу.
А именно: возможность грамотно спланировать весь процесс разработки и своевременно его корректировать (дополнять, реструктурировать архитектуру и т.д.): какие блоки сделать сейчас, какие можно доделать потом; что можно выполнять параллельно, а что - только последовательно и т.д.
Здесь основные этапы проектирования, без которых сложные проекты не смогут долго существовать и поддерживаться.
Два часа мы только висели в скайпе и обсуждали детали ТЗ =)
У нас не самое большое ТЗ - 56 страниц (знакомый рассказывал про свои ТЗ в 130 страниц, поэтому не жалуюсь)
2 часа - это на осмысление, после ознакомления с ТЗ.
Так-то, конечно, ещё прибавляется время на прочтение ТЗ.
Просто нет смысла тратить больше. Если за это время не появилось общее видение того, что надо сделать и в каком порядке, то вряд ли через N дней внезапно во время душа придет гениальная идея. Конечно, в теории такое может быть, но ждать этого нет смысла, лучше действовать сразу.
И, как я сказал выше, большинство вопросов встаёт в процессе реализации. Просто в теории всё хорошо и красиво, а на практике сталкиваешься с реальными противоречиями и конфликтами. И вот тогда уже приходится придумывать, как их решать. В том числе озвучивать проблему начальству.
Не стоит углубляться сильно в планирование и проектирование. Очень важно спроектировать архитектуру, выделить какие-то основные модули, рассмотреть разные кейсы и возможные подводные камни. Можно схематично нарисовать структуру проекта с точки зрения кода. И не затягивать с написанием самого проекта, что-то переделывать и рефакторить придется в любом случае, нужно как можно скорее выкатить mvp. лучше разбить на возможный функционал, и постепенно выкатывать и смотреть, чего упустили, и приступать к следующему функционалу. а проблемы в любом коде найдутся, всегда есть, что улучшить
Простой
Простой
Средний
