-
Сначала проблемы, потом решения
Иногда бизнес предлагает сразу готовое решение. Бывает при этом, что проблема, ради которой предложено решение, успешно решается иначе и гораздо проще. Проблема — это несоответствие между тем, что есть сейчас, и тем, что необходимо иметь. Бизнес должен рассказать, к чему необходимо прийти (каков конечный результат для бизнеса), программист должен придумать, как к этому прийти. Всегда допытывайся у бизнеса, в чём…
-
Паттерн Input-Do-Output
Уточнение Single Responsibility Principle Мне нравится принцип единственной ответственности. Чувствуется в нём что-то глобальное, основательное. Что мне не нравится — так это отсутствие понимания, что же он, чёрт возьми, конкретно означает. Ну вот что конкретно мне нужно сделать, чтобы его соблюсти? Как на пальцах мне понять, что вот тут ответственность одна, а там несколько? Чёткого…
-
Название функции
Любой код не является хаотичным набором знаков, а производит вполне конкретные операции над вполне конкретными величинами, у которых есть естественный человеческий смысл и соответствующие названия. И смысл, и названия происходят из предметной области, с которой работает программист, даже если эта предметная область не находится в физическом или воображаемом мире. При написании кода автор превращает элементы…
-
Длина функций
Обычно принято измерять функции количеством строк, я же делаю это с помощью количества переменных. Был такой умный чел, психолог Джордж Миллер. Он экспериментально доказал, что мозг человека может успешно справляться одновременно максимум с 7±2 отдельных объектов, причём только ценой сильного напряжения. Комфортное же значение находится в районе 3-4. Поэтому я стараюсь, чтобы в каждой моей…
-
Извлечение функции
Управление сложностью Согласно закону Миллера, человеческий мозг легко управляется одновременно примерно с тремя отдельными объектами, а предел находится в районе семи (известное эмпирическое правило 7±2, закон Миллера). Таким образом, условные 18 переменных (для мозга — 18 отдельных объектов), вкупе с непосчитанным количеством промежуточных значений и операций над ними, для мозга представляют абсолютный перегруз. Что делать?…
-
От простого к сложному
Сначала сделай работающий простой вариант, потом усложняй. Принцип скрама в миниатюре: небольшие итерации, после каждой — работающий продукт с инкрементом. Только итерация занимает не две недели, а условно два часа. Не стоит кодить так, чтобы часть приложения оставлась сломанной продолжительное время. В идеале приложение всегда должен быть рабочим, а новые участки кода должны «подключаться» по…
-
Не повторяйся
Don’t repeat yourself здорово звучит, особенно в виде аббревиатуры DRY, но не особо точно отражает свою суть, что чревато неправильным истолкованием. Иногда этот принцип начинают понимать в том смысле, что код вообще не должен дублироваться, что не соответствует первоисточнику. На самом деле так: Каждая часть знания должна иметь единственное, непротиворечивое и авторитетное представление в рамках…
-
Изменяемость кода
Следующий по важности критерий хорошего кода после читаемости — его готовность к изменениям. Собственно, читаемость тоже обеспечивает лёгкость изменений. В современных реалиях быстро изменяющихся условий программный продукт не может быть стабильным, иначе он моментально устареет. Конкурентное преимущество может сохранять только постоянно развивающийся продукт. Для бизнеса жизненно важно, чтобы его хотелки оказывались на проде максимально быстро.…