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

21

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

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

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

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

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

Tyanna
источник
Следующая ссылка была полезна для меня: Elegantcode.com/2012/01/16/marines-vs-boy-scouts
QuanhD

Ответы:

18

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

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

FrustratedWithFormsDesigner
источник
1
+1 за предложение документировать более надежное решение. Эта функция может быть реализована или не реализована точно так, как вы запланировали, но, безусловно, хорошая идея - сообщить будущему исполнителю о ваших мыслях об изменениях.
Майк Партридж
2
Я фактически начал писать окурки метода для ожидания версии 2 сегодня утром после прочтения документа. Я думаю, что я оставлю это на этом и некоторые комментарии, чтобы сказать, как они будут играть в будущем. Спасибо :)
Tyanna
1
Следите за мячом ... мой опыт - это плохая вещь, чтобы беспокоиться о том, что делать с V2, когда у вас есть крайний срок V1, который может ударить вас между глазами, если он гибкий, это не крайний срок. Если разработка не попадает в сроки, это вина разработчиков.
Mattnz
13

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

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

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

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

Кевин Маккормик
источник
Мне нравится идея поговорить с дизайнером и менеджментом, чтобы узнать, состоят ли они в браке с этой функцией. Я вижу это больше как бесполезный звонок, который вызовет больше работы, чем стоит ... но тогда я напряженный разработчик. :)
Тианна
2
+1: избегайте попыток предсказать будущее. Когда это прибудет, это будет удивительно.
S.Lott
7

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

Кевин Клайн
источник
Это правда, но это верно только в том случае, если у вас есть время заранее спланировать это очень тщательно и у вас есть необходимые знания бизнеса, чтобы предвидеть природу различных изменений. Учитывая большинство деловых ситуаций, хотя (сейчас дешевле, меньше), я полностью согласен с вашими заявлениями. У меня есть несколько примеров, если вы настоящий неверующий :)
Джоэл Этертон
@JoelEtherton: Даже если у вас есть бизнес-знания, предвидеть изменения очень сложно, до такой степени, что часто не стоит пытаться ... только мой опыт.
Слёске
@Sleske: Иногда возможно, но мой опыт был в обоих направлениях. В моей нынешней работе хорошее планирование и предусмотрительность избавили меня от лишних головных болей.
Джоэл Этертон
6

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

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

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

Angelo
источник
+1 за "нет полу-реализованной функциональности". Хотелось бы, чтобы я проголосовал больше.
Слёске
1

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

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

Майк Данлавей
источник
Хорошая идея о хранении изменений отдельно. Вместо diff, ветка, вероятно, является лучшей идеей (видимой, легче объединить и т. Д.). Вы всегда можете удалить его позже.
Слёске
1

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

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

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

Кола
источник