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

10

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

Райан
источник
какой язык ?
Не ручка и бумага. Клавиатура и монитор.
Тулаинс Кордова

Ответы:

6

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

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

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

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

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

Алекс Гительман
источник
Я полагаю, что вы имеете в виду «перспектива», а не «перспектива». (Я не могу редактировать, потому что в нем меньше шести символов.)
Maxpm
4

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

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

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

Raptor
источник
Серьезный вопрос: какая польза от диаграммы вариантов использования? Те, что я видел, были болезненно тривиальными рисунками в виде фигурок и шариков, которые не говорили мне ничего, чего я еще не знал.
Йорис Тиммерманс
1
MadKeithV - как и любой инструмент, он хорош только тем, кто их использует. Старайтесь избегать болезненно тривиальных случаев и концентрируйтесь на более сложных ситуациях. Однако то, что вы находите тривиальным, другие в команде не могут. Вариант использования или любая другая диаграмма поможет убедиться, что все поют с одного листа гимна.
Гэвин Коутс
@Gavin Coates - я понимаю, что вы говорите, но знаете ли вы какие-либо онлайн-примеры, на которые я мог бы взглянуть, чтобы действительно повлиять на мое мнение об этих диаграммах?
Йорис Тиммерманс
3

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

альтернативный текст

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

альтернативный текст
(источник: ejb3.org )

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

UML_GURU
источник
2

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

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


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

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

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

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

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

Maxpm
источник
2

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

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

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

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

RationalGeek
источник
2

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

Кевин Клайн
источник