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

39

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

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

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

сочная люси
источник

Ответы:

41

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

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

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

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

Берин Лорич
источник
3
+1, вот почему я всегда недоволен, когда люди говорят о сериализации объектов в базу данных -> и что если завтра ваш класс будет разбит на несколько частей, как вы десериализуетесь, не оставляя старый код? Я очень предпочитаю альтернативу Protobuf (выделенные классы для хранения / обмена сообщениями), где ваши основные классы могут свободно развиваться, и вам просто нужно адаптировать уровень сериализации / десериализации.
Матье М.
@Matthieu - вы пишете миграцию базы данных. Это редко занимает больше часа, чтобы написать и проверить. В Ruby on Rails есть отличное средство для миграции баз данных.
Кевин Клайн
1
@kevin: я думаю, что у нас нет одинаковых баз данных, в моей - несколько сотен миллионов строк. Миграция не вариант.
Матье М.
+1 - быть слишком гордым / упрямым, чтобы признать, что совершил ошибку, - не очень хорошая вещь. Некоторые люди считают, что признавать ваши ошибки признаком недальновидности, но большинство, вероятно, будут уважать вас за это, и, безусловно, если ваша стратегия борьбы с серьезной ошибкой состоит в том, чтобы отрицать, что это ошибка, то вторая ошибка, скорее всего, будет фатальной.
Steve314
12

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

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

ElGringoGrande
источник
10

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

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

JB King
источник
5

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

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

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

FrustratedWithFormsDesigner
источник
6
Шаг 1: Создать диаграмму UML. Шаг 2: Написать код. Шаг 3. Выбросьте UML-диаграмму, чтобы никто ее не увидел, и не запутаетесь в том, как на самом деле работает код.
Куби
4

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

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

Джон Боде
источник
2

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

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

Пайпер Мерриам
источник
0

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

Vartec
источник