Как мне планировать свою базу кода? [закрыто]

В настоящее время я работаю над проектом, который должен охватить более 5000 строк кода, но я никогда не задумывался о дизайне. Какие методы я должен использовать для структурирования и организации моего кода? Бумага и ручка? UML диаграммы? Что-то другое?

Вы, вероятно, получите столько разных мнений, сколько будет ответов. Но вот моя точка зрения.

Для начала, 5000+ строк кода - очень очень маленький проект. Теперь, как вы идете о разработке проектов, которые растут. Во-первых, вы разрабатываете свою систему, а не код. Код на самом деле вторичен по отношению к архитектуре. Начните с поддержки минимальных текущих требований. Положите некоторые упрощенные рисунки участвующих компонентов. Мне лично нравится UML, но все визуальное будет хорошо. В идеале вы должны придерживаться хороших методов проектирования (интерфейсы, разделение задач и т. Д.).

Если вы поддерживаете минимальные требования в своем дизайне, закодируйте его. Снова, попытайтесь придерживаться хороших методов кодирования.

После этого итеративно добавляйте больше функциональности по мере появления новых требований. В идеале вы хотите обновить свой дизайн.

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

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

Я предлагаю вам купить доску и несколько разноцветных магнитов и Post-It. Это поможет вам определить ваши задачи.

PS 5000+ строк кода не являются "большими", хотя. Программное обеспечение CMS / Forum имеет более 5000 строк кода.

Я хотел бы создать пакет и диаграммы классов. В диаграмме пакета мне было бы интересно сгруппировать классы и интерфейсы в логической форме. Я также хотел бы создавать внутренние пакеты и т.д ...

Но сначала нужно подумать, что должна делать программа. Вы можете создавать диаграммы использования или делать это вручную. Я делаю это вручную с диаграммой классов, потому что я предпочитаю получать код сразу, и позже проще поменять местами диаграммы классов. Использование диаграммы классов дает мне мой Java. Если мне не нравится это, я вручную изменяю это. Новый код автоматически обновляется в моих диаграммах. У меня визуально обновленное представление моего кода на высоком уровне. Это действительно полезно, потому что даже если я пишу код, я всегда могу потратить несколько минут, чтобы посмотреть, как мой проект идет графически. Я просто перетаскиваю объекты в нужном пакете вручную, чтобы организовать его. Я думаю, что мой код лучше использовать пакет абстракции и диаграммы классов.

_{(источник: ejb3.org )}

некоторые из моих коллег сказали, что мой способ работы - это дерьмо .... но мне это нравится :-)

Определенно. У меня есть небольшая «таблеточная» доска для сухого стирания, но я использую все, что вам удобно. Важно то, что вы можете легко изложить свои мысли и увидеть общую картину того, как все сходится.

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

РЕДАКТИРОВАТЬ: Вы также можете быть заинтересованы в грамотном программировании . Идея в том, что вы можете все это спланировать и постепенно становиться более конкретным. Например, вы можете сказать, что ваша программа состоит из:

1. Получение текста от пользователя
2. Преобразование текста в изображение
3. Сохранение полученного изображения на диск

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

1. Определите количество строк, которые должен занять текст
2. Выберите случайные цвета для текста и фона
3. Обработайте его в подходящем формате

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

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

Для меня разница между архитектурой и дизайном минимальна, и это просто разные итерации процесса, который я описал выше. Граница между ними размыта и различна для разных людей.

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

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

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