Сейчас мало пишу, но зато много просматриваю и принимаю. Иногда бывает трудно объяснить, чем плох тот или иной код. Мне кажется что люди не хотят быть понятными, и, как будто, специально усложняют свой код. Я же в свою очередь виду ущербность, но обосновать не могу.
Размышляя об этом осознал два важных момента. Можно сказать - ключевых:
Расположение кода на месте - понятие весьма растяжимое. Это может быть библиотека, отсутствие которой вынуждает принимать неоптимальные решения. Это может быть класс, нарушающий SRP и делающий больше чем должен, в результате чего определенное поведение невозможно расшарить и необходимо в том или ином виде дублировать.
Но дело не только в дублировании (а то так получится, что выброшенный третий ключевой момент каким-то образом стал важнее первого). Нарушение первого ключевого момента может проявляться в том, что код располагается не на том уровне абстракции. Что-то у меня вечером не придумывается подходящий пример, но это примерно как в один список поместить свечу зажигания и автомобиль.. Кто-то явно не на месте.
Еще это может проявляться когда мы вынуждены писать код там, где этого кода не должно быть. В проекте была ситуация, когда два приложения использовали библиотеку, которая вынуждала в одном из приложений писать заглушки для функций из доменной области другого приложения. Явно кто-то не на месте.
Перейду к необходимости кода. Как сказал Экзюпери: Il semble que la perfection soit atteinte non quand il n’y a plus rien à ajouter, mais quand il n’y a plus rien à retrancher (Совершенство достигается не тогда, когда уже нечего прибавить, но когда уже ничего нельзя отнять). Но не все так просто.
Иногда мы начинаем пилить объектную архитектуру. Иногда это доходит до крайностей. Недавно поймал себя на мысли - что это синтаксический, объектно ориентированный сахар, как и обычный сахар в больших количествах вреден. Что он там, кариес вызывает и диабет. И я подумал, что хотел бы убрать все объектные наслоения и для начала увидеть код, который собственно делает что-то полезное. Глядя на этот код я наверное смог бы сказать что в нем не так... Но глядя на большую иерархию классов, где содержательный код размазан и просматривался с трудом, я не мог сказать что в ней не так... Все? Нельзя ли убрать эти классы?
Нет, я не предлагаю все свалить в одну большую функцию. Но сам по себе алгоритм работы - хорошая отправная точка для того, чтобы понять где что должно быть.
Деля код на классы и методы мы уменьшаем неясность кода, значит приближаемся к совершенству. Но до определенного предела, преодолев который мы рискуем скатиться в макаронный хаос...
При итеративном подходе очень правильно писать лишь нужное. Не усложняя архитектуру для какой-то потенциальной пользы, которая может и не наступить.
Не пишите лишнего и неуместного. Вот такая мораль.
Размышляя об этом осознал два важных момента. Можно сказать - ключевых:
- Код должен располагаться на месте
- Код должен быть необходим
Расположение кода на месте - понятие весьма растяжимое. Это может быть библиотека, отсутствие которой вынуждает принимать неоптимальные решения. Это может быть класс, нарушающий SRP и делающий больше чем должен, в результате чего определенное поведение невозможно расшарить и необходимо в том или ином виде дублировать.
Но дело не только в дублировании (а то так получится, что выброшенный третий ключевой момент каким-то образом стал важнее первого). Нарушение первого ключевого момента может проявляться в том, что код располагается не на том уровне абстракции. Что-то у меня вечером не придумывается подходящий пример, но это примерно как в один список поместить свечу зажигания и автомобиль.. Кто-то явно не на месте.
Еще это может проявляться когда мы вынуждены писать код там, где этого кода не должно быть. В проекте была ситуация, когда два приложения использовали библиотеку, которая вынуждала в одном из приложений писать заглушки для функций из доменной области другого приложения. Явно кто-то не на месте.
Перейду к необходимости кода. Как сказал Экзюпери: Il semble que la perfection soit atteinte non quand il n’y a plus rien à ajouter, mais quand il n’y a plus rien à retrancher (Совершенство достигается не тогда, когда уже нечего прибавить, но когда уже ничего нельзя отнять). Но не все так просто.
Иногда мы начинаем пилить объектную архитектуру. Иногда это доходит до крайностей. Недавно поймал себя на мысли - что это синтаксический, объектно ориентированный сахар, как и обычный сахар в больших количествах вреден. Что он там, кариес вызывает и диабет. И я подумал, что хотел бы убрать все объектные наслоения и для начала увидеть код, который собственно делает что-то полезное. Глядя на этот код я наверное смог бы сказать что в нем не так... Но глядя на большую иерархию классов, где содержательный код размазан и просматривался с трудом, я не мог сказать что в ней не так... Все? Нельзя ли убрать эти классы?
Нет, я не предлагаю все свалить в одну большую функцию. Но сам по себе алгоритм работы - хорошая отправная точка для того, чтобы понять где что должно быть.
Деля код на классы и методы мы уменьшаем неясность кода, значит приближаемся к совершенству. Но до определенного предела, преодолев который мы рискуем скатиться в макаронный хаос...
При итеративном подходе очень правильно писать лишь нужное. Не усложняя архитектуру для какой-то потенциальной пользы, которая может и не наступить.
Не пишите лишнего и неуместного. Вот такая мораль.
0 коммент.:
Отправить комментарий