Комментарии 6
Интересная методика.
В целом она пересекается с другими рекомендациями по созданию кода — многие рекомендуют сосредоточиться в первую очередь на читаемости. Тут и именование, и корректное использование терминов, и декомпозиция ради понятности.
Принцип похож на создание «языка предметной области», на основе которого создаются программные сущности.
В ходе обсуждения и создания как можно более понятных терминов естественным образом структура программы и взаимодействия приходят к более понятному виду.
В целом она пересекается с другими рекомендациями по созданию кода — многие рекомендуют сосредоточиться в первую очередь на читаемости. Тут и именование, и корректное использование терминов, и декомпозиция ради понятности.
Принцип похож на создание «языка предметной области», на основе которого создаются программные сущности.
В ходе обсуждения и создания как можно более понятных терминов естественным образом структура программы и взаимодействия приходят к более понятному виду.
Если честно, мне лично понятнее не стало от этих «перестановок». Мне кажется проблема в определении «високосный», а вовсе не в коде. И чтобы сделать проще, упрощать надо «бизнес процессы и определения» а не код. Конечно, в случае с високосными годами шансы поменять определение практически нулевые, но вот в «кастомной» бизнес логике всегда есть баланс между простотой и объемом покрываемых юз-кейсов. И про этот баланс надо помнить, иначе придётся делать системы которые обрабатывают «millions of records in fractions of seconds»
НЛО прилетело и опубликовало эту надпись здесь
Думаю есть более общая проблема — неконтролируемая когнитивная сложность того, что мы создаём. Это и код, и инженерные устройства, и законы, и даже сам язык, на котором мы говорим. Это естественный процесс, когда тот кто разобрался создаёт сложную штуку, а другой тратит время не только, чтобы понять сам принцип, но и особенности реализации, и иногда историю, почему именно так и нет ли там подводных камней. Нужно бы как-то научиться эту сложность отслеживать и стимулировать не добавлять сверху. Как — никто не знает, но хоть у вас есть решение для частного случая, это радует.
Если сделать еще один шаг по этому пути, то можно переизобрести literate programming
«Если год делится на 400, то он високосный. Если же он делится на 100, то это обычный год, но при делении на 4, это високосный год".
Куда делись otherwise из оригинала? Без них смысл не тот, что в англоязычной версии.
В любом случае на ровном месте развели «пост». Ведь изначальный код можно было прочитать как:
год является високосным в 2х случаях:
— если он делится на 400
— если он делится на 4 и не делится на 100
Но его прочитали специально невнятно чтобы потом показать каким клевым является развесистый if.
«Если год делится на 400, то он високосный. Иначе если он делится на 100, то это обычный год. Иначе если он делится на 4, это високосный год. Иначе это обычный год".
В обновленной версии кода приходится держать в уме все предыдущие проверки.
ИМХО: пример в статье получился неудачный.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как написать легко описываемый код