Как разработчику-одиночке эффективнее начать писать сложный проект?
На этот вопрос наверное сложно ответить объективно, но он очень актуален для меня, постараюсь как можно лучше конкретизировать, дочитайте до конца.
Я занимаюсь и веб-разработкой (фронтенд) и десктоп-разработкой (.NET). Опыт работы с очень большими проектами у меня есть, в основном как у овнера продукта/заказчика.
Большой проект начинается с написания основополагающей документации по примерно таким этапам:
- Бизнес-видение - зачем и что мы хотим в итоге получить?
- Высокоуровневые требования - пучок больших фичей
- Минимальный жизнеспособный продукт - выбор из списка фичей того, без чего продукт нельзя запустить в релиз
- Проект архитектуры приложения и выбор технологического стека
- Общий дизайн-концепт интерфейса и брендирование
- Спецификации выбранных фичей - декомпозиция, фунциональная логика фичей, детальное описание каждой фичи с учетом удобства для пользователя
- Постановка задач разработчикам, начало разработки, прототипирование
Итого, чтобы начать вообще что-либо писать, требуется огромная куча работы, в идеале команды из человек десяти, минимум недели на 2.
Обычно у одиночек это происходит так - "давай слепим какой-нибудь интерфейс, пропишем в коде поведение для каждого его элемента, и готово". Процесс понимания того, что ты должен сделать и того что пишешь в коде происходит одновременно, или даже код бежит вперёд понимания, в результате получается "разработка методом тыка", а потом либо большие удивлённые глаза заказчика "будь осторожен в своих желаниях", либо понимание, что "надо всё переписывать".
То есть вижу 2 крайности: полный цикл разработки и тяп-ляп-в-продакшн. Где золотая середина для разработчика-одиночки, которому надо провести проект от заказа до публикации? Проблема всегда одна: лучший КПД разработчика в кратчайшие сроки.
Вопрос следующий: вот к примеру, я один, есть например конкретная словесная задача "написать еще один Телеграм-клиент" и есть понимание о стеке, например ".NET WPF + MVVM", хотя это не важно в контексте данного вопроса. А дальше то что? Как это делают профессионалы?
Ответы (2 шт):
Дисклеймер: тут нет "правильного" ответа. У каждого он будет свой.
Однако, "хренак-хренак и в продакшн" более перспективный метод, т.к. "практика — главный критерий истины". Пока теоретик будет проектировать свои ажурные замки в облаках, практик набьет шишек и уже встретиться с реальностью и она будет его направлять.
Второй аспект - написание кода не так сильно отличается по сути от написания документации. И то и то - проектирование. И там и там возможны переделки по ходу. Если вы будете писать код от общего к частному, то вполне сможете минимизировать "большие удивлённые глаза" и понимание, что "надо всё переписывать".
Третий аспект - вы же не будете писать проект в одиночку от начала и до конца? У вас появятся пользователи, спонсоры, инвесторы и коллеги, сообщество, и т.п. Чем раньше вы сможете завлечь их и поддерживать интерес, тем больше они смогут вам помочь в дальнейшем. Детальное ТЗ может привлечь инвестора, а приятный MVP - пользователя.
Касательно работы одному, тут тоже индивидуально, но главная проблема, обычно - мотивация. Написание документации для самого себя вещь неплохая (помогает разложить все по полочкам, перепроверить себя, по сути как rubber duck debugging), но быстро надоедает, а следование ей превращается в изнурительный труд на галерах. Продуктивнее может быть последовательное установление и достижение MVP целей, когда у вас максимально рано появляется что-то чем можно пользоваться, хвастаться и предъявлять как "достижение". А каждая достигнутая мини-цель - буст мотивации продолжать.
Надо начать делать, в вашем случае - писать.
Обычно, я боюсь начинать сложные и большие проекты из-за их... сложности. Поэтому я сначала смотрю примерные проекты у остальных, смотрю как они реализованы, и после этого начинаю писать архитектуру, основываясь на том, что я увидел. После этого, смотря на размер того, что я написал, я разбиваю это на маленькие задачи. Поверьте, это действительно помогает и так проще делать большой проект, разбив его на пункты или задачи. Потом, при возникновении какой-то проблемы, я начинаю разбирать этот пункт тщательнее.
Разумеется, разобраться с технологиями (как вы написали в вопросе) это нужно, причем на старте, но не нужно хвататься за первую технологию, которую вы знаете. Возможно, она не очень подходит для этой задачи и могут получиться сплошные костыли да палки.
Поэтому, обобщая весь мой ответ, я советую посравнивать, почитать, посмотреть как это имплементировано у других, разбить на маленькие задачи, и начать выполнять большой проект по задачам. Вот увидите, это будет несложно :)
Это был пример из моего опыта, надеюсь, он вам пригодиться ;)