Это плохой признак того, что я часто меняю дизайн при разработке проекта?

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

• «Эй, мне нужен класс, чтобы делать _ _. Я не думал об этом раньше».
• «Подождите, эта функция действительно должна быть в этом классе, а не в этом. Я переверну его».
• «Это должно быть два класса вместо одного. Я разделю его».
• «Я должен сделать так, чтобы эти три автономных класса наследовали один абстрактный класс».
• И так далее, и так далее.

Это плохой признак того, что я часто меняю дизайн по мере продвижения? Значит ли это, что я плохой программист или это нормально?

Это нормальная часть развития. Два основных принципа Continuous Design :

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

Мой личный взгляд на этот вопрос заключается в том, что вы должны иметь хорошее представление о макродизайне , но позволить микродизайну развиваться. Другой способ выразить это заключается в том, что высокоуровневое проектирование (насколько я понимаю, используя UML / инструменты моделирования), скорее всего, будет оставаться довольно статичным в течение всего жизненного цикла проекта. Детальный дизайн того, какие методы делают, и иерархия классов должны быть свободными, чтобы быть гибкими.

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

То, что вы делаете, обычно называют рефакторингом. Если вы когда-нибудь прекратите это делать, у вас будут проблемы.

Дело в том, что большая часть кода сложна, и люди, даже довольно умные, не могут понять все сразу.

Нет, вы, похоже, следите за YAGNI и рефакторингом из приведенных примеров. Тебе не кажется, что лучше иметь это лучшее решение и быть способным сделать это, чем просто никогда больше не думать о чем-то?

Гибкая разработка программного обеспечения обычно имеет методы, чтобы приспособиться к этому, что весьма отличается от модели водопада.

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

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

Очень-очень- очень редко начинать с дизайна и придерживаться его на 100% до реализации. Лично я никогда не видел, чтобы такое происходило, за исключением очень маленьких и тривиальных программ.

То, что вы делаете, совершенно нормально (при условии, что вы не начинаете все сначала с нуля). Я занимаюсь этим более двадцати лет, и это все еще итеративный процесс.

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

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

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

Это называется итеративный процесс, и это основная концепция всех современных методов разработки программного обеспечения.