В настоящее время я работаю над проектом, который должен охватить более 5000 строк кода, но я никогда не задумывался о дизайне. Какие методы я должен использовать для структурирования и организации моего кода? Бумага и ручка? UML диаграммы? Что-то другое?
architecture
uml
Райан
источник
источник
Ответы:
Вы, вероятно, получите столько разных мнений, сколько будет ответов. Но вот моя точка зрения.
Для начала, 5000+ строк кода - очень очень маленький проект. Теперь, как вы идете о разработке проектов, которые растут. Во-первых, вы разрабатываете свою систему, а не код. Код на самом деле вторичен по отношению к архитектуре. Начните с поддержки минимальных текущих требований. Положите некоторые упрощенные рисунки участвующих компонентов. Мне лично нравится UML, но все визуальное будет хорошо. В идеале вы должны придерживаться хороших методов проектирования (интерфейсы, разделение задач и т. Д.).
Если вы поддерживаете минимальные требования в своем дизайне, закодируйте его. Снова, попытайтесь придерживаться хороших методов кодирования.
После этого итеративно добавляйте больше функциональности по мере появления новых требований. В идеале вы хотите обновить свой дизайн.
Основываясь на моем опыте, важно не проектировать вашу систему в ожидании несуществующих требований. В противном случае ваш проект будет расти очень быстро и станет очень сложным за короткое время. Опять же - придерживайтесь передового опыта и начинайте с конкретных текущих требований.
источник
Блок-схема, диаграмма классов, диаграмма вариантов использования - обязательные диаграммы для больших проектов. Найдите и выберите, какие внешние библиотеки вам нужны, и найдите любые подобные открытые исходные коды, которые вы можете использовать (чтобы узнать и сократить время разработки).
Я предлагаю вам купить доску и несколько разноцветных магнитов и Post-It. Это поможет вам определить ваши задачи.
PS 5000+ строк кода не являются "большими", хотя. Программное обеспечение CMS / Forum имеет более 5000 строк кода.
источник
Я хотел бы создать пакет и диаграммы классов. В диаграмме пакета мне было бы интересно сгруппировать классы и интерфейсы в логической форме. Я также хотел бы создавать внутренние пакеты и т.д ...
Но сначала нужно подумать, что должна делать программа. Вы можете создавать диаграммы использования или делать это вручную. Я делаю это вручную с диаграммой классов, потому что я предпочитаю получать код сразу, и позже проще поменять местами диаграммы классов. Использование диаграммы классов дает мне мой Java. Если мне не нравится это, я вручную изменяю это. Новый код автоматически обновляется в моих диаграммах. У меня визуально обновленное представление моего кода на высоком уровне. Это действительно полезно, потому что даже если я пишу код, я всегда могу потратить несколько минут, чтобы посмотреть, как мой проект идет графически. Я просто перетаскиваю объекты в нужном пакете вручную, чтобы организовать его. Я думаю, что мой код лучше использовать пакет абстракции и диаграммы классов.
(источник: ejb3.org )
некоторые из моих коллег сказали, что мой способ работы - это дерьмо .... но мне это нравится :-)
источник
Определенно. У меня есть небольшая «таблеточная» доска для сухого стирания, но я использую все, что вам удобно. Важно то, что вы можете легко изложить свои мысли и увидеть общую картину того, как все сходится.
Некоторые люди предпочитают более формальные планы, такие как UML-диаграммы, но я чувствую, что слишком легко освоить микроуправление тем, как должен выглядеть каждый метод. Еще раз, однако, используйте то, что вам удобно.
РЕДАКТИРОВАТЬ: Вы также можете быть заинтересованы в грамотном программировании . Идея в том, что вы можете все это спланировать и постепенно становиться более конкретным. Например, вы можете сказать, что ваша программа состоит из:
Тогда вы можете уточнить вашу идею преобразования текста в изображение. Так что это может выглядеть так:
Тогда вы можете уточнить идею выбора случайных цветов, и вскоре вы просто пишете обычный код.
источник
Для меня деятельность по разработке программного обеспечения представляет собой серию прогрессивно более тонких проектов для решения конкретной проблемы. Когда у вас есть общее представление о том, что вы создаете, ваш дизайн может быть чем-то очень высокого уровня, например, «будет веб-приложение, которое взаимодействует с базой данных SQL и несколькими веб-службами» или что-то в этом роде. Затем, когда вы углубляетесь в детали каждого элемента, вы получаете более детальный дизайн. В зависимости от сложности решения будет больше или меньше итераций в процессе проектирования. Заключительная итерация включает создание фактического кода, который реализует более высокие уровни дизайна.
Для меня разница между архитектурой и дизайном минимальна, и это просто разные итерации процесса, который я описал выше. Граница между ними размыта и различна для разных людей.
Существует умение решить, на какой уровень детализации дизайна перейти, для каких частей приложения и в какие моменты жизненного цикла проекта. Для проектов с высоким уровнем риска и высокой сложности вам может потребоваться очень детальный дизайн, прежде чем вы начнете писать строку кода. Для небольших проектов вы можете с легкостью выполнить предварительный дизайн, просто набросать немного кода, а затем посмотреть, что не работает, и изменить дизайн этих областей. Здесь не только один ответ. Обычно это где-то между этими двумя крайностями.
У меня есть пост в блоге, в котором говорится о некоторых принципах, которые я использую при приближении к архитектуре. Это может быть полезно для вас, думая в этом направлении. Часть статьи относится к .NET, но большая часть - нет.
источник
Я задавал себе тот же вопрос. Сейчас я просто занимаюсь разработкой на основе тестов и не беспокоюсь об этом. Я не «планирую» код вообще, кроме как следовать стандартам для выбранной архитектуры. Когда я начинаю проект, у меня есть некоторое представление о том, что будет необходимо, но по мере развития я стараюсь быть открытым. Следуя тестовой разработке и непрерывному рефакторингу кода, мне не нужно «планировать» код. Я просто удовлетворяю один контрольный пример за другим, и дизайн вытекает из рефакторинга. Это всегда лучший дизайн, чем любые планы, которые я мог сделать до написания кода.
источник