Рекомендуемые способы разделения некоторой функциональности на функции, модули и пакеты?

Question

Наступает момент, когда в относительно крупном проекте нужно подумать о разделении функциональности на различные функции, затем на различные модули, а затем на различные пакеты.Иногда в разных исходных дистрибутивах (например:извлечение общей утилиты, такой как optparser, в отдельный проект).

Вопрос - как решить, какие детали поместить в один модуль, а какие - в отдельный модуль?Тот же вопрос для пакетов.

Answer 1

Видишь Сколько классов Python я должен поместить в один файл?

Нарисуйте свой общий набор определений классов.

Разделите эти определения классов на "модули".

Внедряйте и тестируйте модули отдельно друг от друга.

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

Примечание.Практически невозможно разложить работающее приложение, которое развивалось органично.Так что не делай этого.

Разбирайте свой дизайн как можно раньше и чаще.Создавайте отдельные модули.Интегрируйтесь для создания приложения.

Answer 2

Есть классическая статья Дэвида Парнаса под названием "О критериях, которые следует использовать при разбиении систем на модули".Это классика (и имеет определенный возраст, поэтому может немного устареть).

Может быть, вы сможете начать оттуда, PDF-файл доступен здесь

http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf

Answer 3

Достаньте ручку и лист бумаги.Попробуйте нарисовать, как ваше программное обеспечение взаимодействует на высоком уровне.Нарисуйте различные слои программного обеспечения и т.д.Группируйте предметы по функциональности и назначению, возможно, даже по тому, какую технологию они используют.Если ваше программное обеспечение имеет несколько уровней абстракции, я бы посоветовал сгруппировать их по этому признаку.На высоком уровне все элементы определенного уровня имеют одно и то же общее назначение.Теперь, когда ваше программное обеспечение разделено на слои, вы можете разделить эти слои на различные проекты на основе определенной функциональности или специализации.

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

Надеюсь, это даст вам то, с чем можно работать.

Answer 4

ИМХО, вероятно, это должно быть одной из вещей, которые вы делаете ранее в процессе разработки.Я никогда не работал над крупномасштабным проектом, но было бы разумно, если бы вы составили дорожную карту того, что будет сделано и где.(Не пытаюсь подколоть тебя за то , что ты спрашиваешь об этом , как будто ты совершил ошибку : D )

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

Answer 5

Я сочувствую вам.Вы страдаете от неуверенности в себе.Не волнуйся.Если вы можете говорить на любом языке, включая ваш родной, вы имеете право выполнять модульность самостоятельно.В качестве доказательства вы можете прочитать "Языковой инстинкт" или "Математический инстинкт".

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

1. Некоторые проекты / фреймворки получают много шума.Тем не менее, некоторые из их функциональных группировок, даже названия, данные модулям, вводят в заблуждение.Они не "раскрывают намерения" программистов.Они не проходят тест на "высокую когезивность".

2. Книги ничуть не лучше.Пожалуйста, применяйте правило 80/20 при выборе книги.Даже хорошая, очень полная, хорошо проработанная книга, такая как "Лучшие практики разработки программного обеспечения" Кейперса Джонса 2010 года, невежественна.В нем говорится, что команде Agile / XP из 10 человек потребуется 12 лет, чтобы создать Windows Vista, или 25 лет, чтобы создать пакет ERP!В нем говорится, что до 2009 года не существовало метода сегментации, его термин означает модульность.Я не думаю, что это тебе поможет.

Моя точка зрения такова:Вы должны очень тщательно выбирать свою модель / ссылку / источник примеров.Не переоценивайте известные имена и недооценивайте себя.

Вот моя помощь, проверенная на моем опыте.

1. Это очень похоже на решение о том, какие атрибуты относятся к какой таблице БД, какие свойства / методы относятся к какому классу / объекту и т.д.?На более глубоком уровне это очень похоже на расстановку мебели дома или книг на полке.Вы уже делали такие вещи.Программное обеспечение то же самое, ничего особенного!

2. Сначала побеспокойтесь о "сплоченности".например ,Книги (Лев Толстой, Джеймс Джойс, ДЕ Лоуренс) - это выбор.(HTML, CSS, Джон Китс.jQuery, tinymce) - нет.И есть много способов все устроить.Даже систематики все еще находятся в серьезной вражде по этому поводу.

3. Тогда побеспокойся о "совокуплении". Будь "застенчивым"."Не разговаривай с незнакомцами". Не будь чрезмерно дружелюбным.Постарайтесь сделать ваш пакет / таблицу БД / класс / объект / модуль / книжную полку как можно более самодостаточными, независимыми.Джоэл говорил о своем восхищении командой Excel, которая ненавидит все внешние зависимости и которая даже создала свой собственный компилятор.

Answer 6

На самом деле это зависит от каждого создаваемого вами проекта, но вот пример:

1. core пакет содержит модули, без которых ваш проект не может жить.это может содержать основную функциональность вашего приложения.
2. ui пакет содержит модули, которые имеют дело с пользовательским интерфейсом.это если вы отделите пользовательский интерфейс от своей консоли.

Это всего лишь пример.и это действительно были бы вы, которые решали бы, что и куда делать.