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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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