React
- 1 ответ
- 0 вопросов
1
Вклад в тег
Фундаментальное практическое правило гласит: то, что изменяется одновременно, лучше хранить в одном месте.
Мы структурируем программы, чтобы облегчить внесение в них изменений;
Планируя изменение, мы хотим иметь возможность перейти в определенную точку программы и внести изменения именно в ней.
Когда я сталкиваюсь с кодом, который имеет дело с двумя разными задачами, я ищу способ разделить его на отдельные модули. Я стараюсь выполнить такое разделение, поскольку, если мне нужно будет вносить изменения в программу, мне придется иметь дело с каждой задачей в отдельности и не потребуется держать их обе в голове. Если мне повезет, то, возможно, будет достаточно внести изменения только в один модуль без необходимости запоминать детали другого.
модульность, которая обеспечивает возможность вносить множество изменений в программу, в то же время понимая лишь небольшую ее часть. Чтобы добиться этой модульности, я должен убедиться, что связанные программные элементы сгруппированы и связи между ними легко найти и понять.
Если у меня хороший набор структур данных, соответствующих поставленной задаче, то реализующий поведение код прост и понятен. Плохие структуры данных приводят к большому количеству кода, работа которого заключается просто в обработке плохих данных. И это не просто сложный код, который трудно понять; это также означает, что структуры данных скрывают то, что делает программа.
программная сущность (класс, модуль, метод) должна по возможности решать лишь одну задачу, но делать это хорошо.
Чем меньше у метода, класса или модуля вспомогательных задач, тем ниже вероятность случайных изменений.
не приведут ли меня принципы и паттерны в мир ненужной сложности (overengineering): стал ли мой дизайн после внесения изменений проще? Не решаю ли я проблему, которой на самом деле не существует?
Не попал ли я в сети преждевременного обобщения (premature generalization)?
Средний