Когда я впервые начал программировать, я предполагал, что однажды достигну точки, где я начну проект, сяду и нарисую UML-диаграмму всех классов, а затем в значительной степени буду придерживаться этого. Я сейчас программирую пару лет, и это не так. Когда я прохожу проект, я часто говорю
- «Эй, мне нужен класс, чтобы делать _ _. Я не думал об этом раньше».
- «Подождите, эта функция действительно должна быть в этом классе, а не в этом. Я переверну его».
- «Это должно быть два класса вместо одного. Я разделю его».
- «Я должен сделать так, чтобы эти три автономных класса наследовали один абстрактный класс».
- И так далее, и так далее.
Это плохой признак того, что я часто меняю дизайн по мере продвижения? Значит ли это, что я плохой программист или это нормально?
источник
То, что вы делаете, обычно называют рефакторингом. Если вы когда-нибудь прекратите это делать, у вас будут проблемы.
Дело в том, что большая часть кода сложна, и люди, даже довольно умные, не могут понять все сразу.
источник
Нет, вы, похоже, следите за YAGNI и рефакторингом из приведенных примеров. Тебе не кажется, что лучше иметь это лучшее решение и быть способным сделать это, чем просто никогда больше не думать о чем-то?
Гибкая разработка программного обеспечения обычно имеет методы, чтобы приспособиться к этому, что весьма отличается от модели водопада.
источник
Это совершенно нормально (если только эти редизайны не будут капитально ремонтировать или перестраивать с нуля). Не беспокойся Было бы неплохо начать с UML-диаграммы в начале проекта, но не вырезайте ее из камня, так как вы почти всегда обнаруживаете, что все меняется по мере работы. Вы можете изучать новые методы, которые вы не знали в начале, вы можете захотеть усовершенствовать некоторые функции способами, которые вы не делали во время первоначального проектирования, меняются бизнес-требования, иногда во время первоначального проектирования возникают неизвестные, которые могут только быть учтены позже, и т.д ...
Что это важно , чтобы пойти и обновить эти первоначальные UML документы так , чтобы они отражали какие - либо существенные изменения в дизайне, иначе разработчики в будущем ( в том числе себя) может в конечном итоге очень смущены. Это может быть сложно, и часто требует хорошей дисциплины (и времени).
Очень-очень- очень редко начинать с дизайна и придерживаться его на 100% до реализации. Лично я никогда не видел, чтобы такое происходило, за исключением очень маленьких и тривиальных программ.
источник
То, что вы делаете, совершенно нормально (при условии, что вы не начинаете все сначала с нуля). Я занимаюсь этим более двадцати лет, и это все еще итеративный процесс.
Единственный раз, когда вы сможете разработать все заранее и придерживаться этого, - это если вы решаете точно такую же проблему, которую вы решили в прошлый раз, и даже тогда вы, вероятно, сможете найти место для улучшений.
источник
Я ни в коем случае не опытный разработчик, но я тоже так делаю. За последние несколько лет моя способность мысленно создавать необходимую архитектуру значительно улучшилась. Однако, когда я пишу часть программного обеспечения, независимо от того, сколько я занимаюсь планированием, всегда есть места, которые нужно немного переделать. Точки, которые я не осознавал, я буду повторяться, пока код на самом деле не будет написан.
Моя точка зрения в этом посте состоит в том, чтобы сказать, что я делаю все в вашем списке, и я не чувствую, что эти вещи обязательно плохие, если они не происходят постоянно и не оказывают реального негативного влияния на вашу производительность.
источник
Это называется итеративный процесс, и это основная концепция всех современных методов разработки программного обеспечения.
источник