После разработки проекта может потребоваться слишком много настроек и изменений, чтобы он работал правильно ...
Что я могу сделать, чтобы предотвратить это?
После разработки проекта может потребоваться слишком много настроек и изменений, чтобы он работал правильно ...
Что я могу сделать, чтобы предотвратить это?
Ответы:
Есть простое правило, которое я применяю все время, потому что я тоже склонен быть перфекционистом. И перфекционизм ведет вас к посредственности.
Установить крайний срок. Корабль в этот срок.
Для того, чтобы предотвратить ваше программное обеспечение от наличия unfishined состояния отсутствует функцию , которая сделает его непригодным для использования, использовать это определение сделано для каждой функции вы производите. Не запускайте следующую функцию, пока ВСЕ шаги не будут выполнены:
Я предполагаю, что вы можете создать релиз одним щелчком мыши (используя сценарии сборки)
Прежде чем дать свой ответ (или, на самом деле, предложение ответа), я должен сказать, что у меня нет большого опыта работы с большими проектами, и я лишь изложу то, что я прочитал, и считаю, что это одна из причин. Я вполне могу ошибаться, но тогда, скорее всего, я кое-что узнал из всех полученных комментариев. ^^
Я считаю, что одним из важных факторов является не допустить ухудшения вашего кода в процессе реализации проекта. Это может быть предотвращено многими способами, из которых я знаю только несколько:
Не ждите слишком долго с рефакторингом: рефакторинг занимает некоторое время, но не стоит делать сложные вызовы функций только потому, что вас не побеспокоит переписать код, чтобы учесть этот дополнительный параметр. Более интуитивно понятный и менее дублированный код уменьшает количество ошибок.
Исправить разбитое окно. В Pragmatic Programmer я читал о явлении, известном как разбитое окно. Авторы утверждают, что код начнет ухудшаться так же, как ухудшается здание: оно начинается с разбитого окна. В коде это означает некрасивые исправления, именование переменных, функций; в общем просто плохой код. Я обнаружил, что это верно: я лучше пишу код и больше радуюсь кодированию, когда основа моего кода прочна. Если разбитых окон слишком много, мне часто не хочется писать хороший код. Поэтому, если вы видите разбитое окно, почините его как можно быстрее; рефакторинг, если вам нужно. Это приведет к уменьшению количества ошибок и ненужных настроек.
И не забудьте прочитать ответ Пьера 303 .
Что "слишком много" настроек и изменений? Обслуживание программного обеспечения может занять гораздо больше времени, чем первоначальная разработка программного обеспечения. В этом нет ничего плохого. Чтобы быть организованным, используйте систему отслеживания проблем .
В любом случае, вы, конечно, захотите сделать это как можно лучше. Для этого ничто не сравнится с тестированием .