Как разделить проблему на более понятные части?

Question

Я не уверен, что можно дать общий совет по этой теме, но, пожалуйста, попробуйте. Трудно объяснить мой случай, потому что это слишком сложно объяснить. И это именно проблема.

Кажется, я постоянно сталкиваюсь с ситуацией, когда пытаюсь спроектировать какую-то часть своего проекта, но в ней так много вещей, которые нужно учитывать, что я не могу понять это.

Существуют ли какие-либо общие советы или рекомендации о том, как смотреть на мою систему за раз? Как найти меньшие порции, которые можно было бы разработать самостоятельно?

Answer 1

Создать глоссарий.

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

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

Поскольку вы не определили даже область вашей проблемы, я выберу случайный пример. В системе гражданского персонала у вас могут быть такие термины, как:

• заготовка : срок службы (от даты начала до даты окончания) для определенного класса и ступени
• сотрудник : серия заготовок, связанных с определенным номером SSN
• оценка и ступенька : строка и столбец в федеральном общем графике

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

Answer 2

Ваши ключевые цели:

• Высокая когезия : Код (методы, поля, классы) в пределах одного элемента / модуля / раздела должен интенсивно взаимодействовать; имеет смысл , чтобы эти элементы знали друг о друге. Если вы обнаружите, что некоторые из них не сильно взаимодействуют с остальными, они, вероятно, принадлежат кому-то еще или должны сформировать свой собственный раздел. Если вы обнаружите, что внешний код интенсивно взаимодействует с разделом и слишком много знает о его внутренней работе, он, вероятно, принадлежит ему. Типичный пример находится в ОО-коде, написанном в процедурном стиле, с «тупыми» объектами данных и «управляющим» кодом, который работает с ними, но на самом деле должен быть частью объектов данных.
• Слабая связь : Взаимодействие между частями / модулями / разделами должно происходить только через узкие, четко определенные, хорошо документированные API. Попробуйте определить такие API и посмотреть, какой код необходим для их реализации и какой код будет их использовать.

Answer 3

Полезно подходить к разложению проблемы как сверху вниз, так и снизу вверх.

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

Answer 4

Вот попытка, какая-то дикая догадка.

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

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

Answer 5

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

На самом деле, весь объектно-ориентированный подход - вот о чем все. Попытайтесь думать о своем приложении как о материальных вещах, которые делают вещи. Напишите псевдокод, описывающий, что это за вещи и что они делают. Я нахожу множество «перегородок» таким образом.