Как обрабатывать мелкие ошибки, которые представляют собой недостатки дизайна?

Question

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

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

Answer 1

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

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

Answer 2

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

Answer 3

Руководство всегда хочет увидеть возврат своих инвестиций в свое время. Таким образом, менеджмент хочет видеть своевременный выпуск, и они также хотят видеть, что вы исправили x количество ошибок в y часы. Но это не значит, что вам нужно игнорировать дизайн. Когда вы исправляете ошибки, приготовьтесь к редизайну той части, в которой вы видите недостатки. После выпуска, будьте готовы представить свои аргументы в пользу того, почему его нужно перепроектировать и как долго вам понадобится его исправить. Запишите это, пока он свежий, и пока вы исправляете эти ошибки.

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