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

Я предсказываю, что потребуется системе в будущем, поэтому, когда будущее наступит, моя система будет готова к этим изменениям. Иногда, несмотря на то, что будущее для системы так и не наступает, она утилизируется или требования меняются так резко, что она уже не выглядит как та же самая система.

Мне посоветовали прочитать «4 правила простого дизайна». Первоначально это было выражено Кентом Беком в конце 1990-х годов в его популярной книге «Экстремальное программирование».

Четыре правила заключаются в следующем.

  • Проходит тесты
  • Раскрывает намерение
  • Нет дублирования
  • Наименьшее количество элементов

Эти правила в порядке приоритета, с которыми не согласен полностью. Будучи практиком TDD, я на 100% согласен с номером 1.

С номерами 2 и 3 у меня небольшие проблемы, дублирование — одна из моих неприятных проблем в программировании, я чувствую себя немного не в своей тарелке, когда вижу дублированный код, настолько, что чувствую необходимость изменить его. Поэтому я, вероятно, поместил бы его под номером 2.

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

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

Что приводит нас к «Наименьшему количеству элементов», это то, о чем я много думал в последнее время. Что представляет собой «наименьший» элемент? Каково наименьшее количество занятий? каково наименьшее количество методов? — это вопросы, над которыми я постоянно бьюсь, когда думаю о правильном подходе к дизайну.

Чтобы тем временем решить эту проблему, мне нравится думать о том, что сказал Боб Мартин о том, насколько маленькими должны быть функции, и вместо этого я применяю это к общему дизайну.

«Первое правило функций — они должны быть маленькими. Второе правило функций состоит в том, что они должны быть меньше этого размера».

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