Оставить это простым сейчас или программировать с учетом будущего?

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

Мне дали задание запустить версию 1 к концу месяца. Я на полпути к разработке, и теперь я понял, что конец виден.

Вчера я потратил некоторое время на то, чтобы найти очень хорошее простое решение для одного из требований, и очень горжусь тем, как это получилось. Сегодня утром был разослан документ версии 2, и там есть требование, которое потребует, чтобы код, который я написал вчера, был либо потрошен, либо серьезно изменен. В будущем потребовалось бы много работы, если я оставлю все как есть. Теперь я могу потратить дополнительный день, чтобы сделать свое текущее решение более надежным, чтобы можно было добавить функцию v2 с гораздо меньшими усилиями, но это немного отстает от необходимости дополнительного кодирования, которое потребуется.

Я не знаю, буду ли я делать v2. Это может быть я или коллега, или даже стажер.

Если бы вы были на моем месте, потратили бы вы сейчас время, чтобы облегчить ситуацию в будущем, или вы бы оставили свое решение и занялись им, когда придет время?

Если крайний срок - «Вырезано в камне», просто закончите то, что вам нужно. Убедитесь, что вы завышаете оценки для v2, чтобы учесть изменения кода для нового требования. Также не забудьте кратко документировать, что, по вашему мнению, нужно будет изменить для новых функций v2, чтобы коллега мог подобрать его, если вы переназначены на что-то другое.

Если есть достаточная гибкость в крайнем сроке (1 день, судя по его звуку, поэтому стремитесь к продлению на 2,5 дня), тогда, конечно, продолжайте и пишите для известного будущего!

Избегайте падать добычей (рано) на второй системный эффект . Вот несколько хороших методов для применения:

1. Определенно избегайте демонтажа версии 1 только из-за того, что вы видите в версии 2. Планирование заранее хорошо, но создатель спецификаций v2 должен нести ответственность за сбой v2, а не v1.
2. (Если возможно) посмотрите, можете ли вы заставить создателя пересмотреть требования для версии 2, которые не потребуют больших изменений сейчас, а затем запланировать их позже, возможно, для v3.
3. Помните о YAGNI , но старайтесь программировать для расширяемости - избегайте магических чисел, жестко закодированных значений, пишите хорошие модульные тесты или контракты кода и т. Д. Применение хороших методов на раннем этапе сделает рефакторинг и изменения кода менее болезненными на этом пути.

Большинство программных проектов, которые растут как города , в конечном итоге успешны. Эволюционное планирование только в ограниченном будущем позволяет своевременно выпускать ваше программное обеспечение с функциональными возможностями, требуемыми при выпуске, и не более. Смотрите этот отрывок из Карла Сагана:

Организация [города] могла бы быть более эффективной, если бы все гражданские системы строились параллельно и периодически заменялись (именно поэтому катастрофические пожары - например, большие пожары в Лондоне и Чикаго - иногда помогают в планировании города). Но медленное нарастание новых функций позволяет городу работать более или менее непрерывно на протяжении веков.

• Карл Саган, Космос : http://www.eridanus.info/genesis.html

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

Оставь как есть.

Разработчики на самом деле ЦЕНУ унаследованного проекта, который делает то, что он должен делать, и не более.

То, что сегодня может показаться хорошей идеей для «постановки» кодовой базы для удовлетворения «будущих» требований, по всей вероятности, станет препятствием для понимания кода в будущем. Никто не любит иметь дело с частично реализованным функционалом и пережитками забытых фантомных требований. Я не говорю, что так и будет, но часто все складывается таким образом, несмотря на благие намерения.

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

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

Это зависит. Есть старое доброе правило: относись к другим людям так, как хочешь, чтобы относились к себе. Что бы вы сделали, если бы это был ваш собственный проект и вы знали все приоритеты?

Если v2 определенно требуется, а крайний срок - только желание, а не острая необходимость, тогда не создавайте технических долгов и исправляйте свои паруса, когда погода хорошая. Даже если кто-то еще сделает v2, они оценят дальновидность.

Если есть какие-либо сомнения относительно необходимости v2, тогда придерживайтесь YAGNI. Кроме того, если вы находитесь на другой стороне спектра и у вас есть один из тех клиентов, которые постоянно рассылают вам свои идеи до того, как они сформировались, то проверяйте свои электронные письма только 2 или 3 раза в день и не спешите с этим действием, вы будете удивлены сколько «проблем» и запросов становятся неактуальными еще до того, как вы их прочитаете.