Комментарии 7
Прекрасная иллюстрация важности места и времени. Надо было эту статью в Пятницу постить. И были бы плюсы вместо минусов.
Дорогое поколение снежинок, где каждый уникален и имее свое ценнейшее видение, как устроен мир и как правильно писать код. Я не хочу грубить, я просто оставлю это видео здесь. Это как раз об устаревших нормах.
https://youtu.be/Zh3Yz3PiXZw?si=HClL50yunLEdzyEq
Видео прикольное. Но по-моему это про разработку на JavaScript*)
Дорогое поколение снежинок
Сомневаюсь, что Дан Норт младше вас. Если вы посчитали, что преамбула к данному переводу крайне серьезный текст, несущий какие-то неверные трактаты - это не так. Это по большей части кликбейт для более интересного чтения.
Советую все же прочитать статью, а не только первые абзацы, чтиво, имхо, интересное.
Философия Unix: делает одно дело, но делает его хорошо
Это же Single Responsibility Principle из SOLID. Не говорю, что это также не философия Unix, но выходит, что вы ставите в противовес принципам SOLID один из их же принципов. Попытка сделать вид, что "это другое"?
Остальные принципы весьма субъективны:
Композиционность: внутренние компоненты хорошо сочетаются друг с другом.
"Хорошо" - понятие относительное. Да и почему подобное требование лишь к внутренним компонентам?
Предсказуемость: работает так, как вы ожидаете.
Это скорее относится к ожиданию с точки зрения высокоуровневого наблюдения за работой системы. К построению связей между компонентами системы это никак не относится
Идиомотичность: ощущается естественно.
Что означает "естественно" в данном контексте? Очередное красивое и весьма субъективное слово.
Вы не поверите, но, например, большая часть разработчиков видит устаревший синтаксис сишных циклов for как весьма идиоматичный и понятный, тоже самое у них с && вместо and и т.д. А от синтаксиса python, nim и rust они будут плеваться, говоря, что чёт какая-то шляпа и нифига не понятно
Как вы понимаете, это скорее дело привычки. Потому тот самый цикл for выглядит идентично и в c, и в java и в js, и во многих других языках. И не потому, что он какой-то идиоматичный, стильный, модный и молодежный, а потому что программистам так привычнее
Доменность: решение отражает предметную область в языке и структуре.
Наверное первый адекватный принцип из предложенных. Но опять же, больше уходит в стилистику кода нежели в конкретику
Вывод: автор не понял принципы SOLID, не осознал, что они говорят об объективных вещах, так ещё и в рамках конкретного уровня абстракции (интерфейсов) и поспешил выкинуть их в трубу ради пяти красиво звучащих и весьма субъективных принципов, потому что они "современные и интуитивно понятные".
Не секрет, что часто смысл SOLID часто эктраполируют далеко за пределы интерфейсов, но их смысл прекрасно ложится на достаточно многое, тот же Single Responsibility Principle - смысловая копия философии Unix
По сему, хочется предложить автору воспользоваться Open-Closed Principle и предложить коллекции авторских принципов не как замену существующим, а как дополнительную, и никак не относящуюся к уже существующим (потому что они действительно весьма разные, SOLID всё-таки про построение интерфейсов и их организацию, а ваши - про стилистику кода и ощущение элитизма из воздуха)
Классная ретроспектива вышесказанного. Очевидно, что вряд ли будет время, что когда-то (хотя бы) меньшая часть сообщества будет знать про данные принципы. С моей точки зрения, в первую очередь данные перевод - просто красивое чтиво. Но теперь по делу.
1. Быть юникс означает "стараться" делать одно, и делать что-то хорошо. Не зря автор приводит пример с пайпами и утилитами юникса. Можно рассмотреть пример, что тот же iptable. Делает что-то одно? ну, не одно. Так, что SRP - это конечная точка минимизации в рамках текущего свойства. В целом, вся статья про то, что мы можем решать СЛАУ под названием "программирование", а можем и вместо этого начать минимизировать приближенное решение. Такой подход просто выглядит удобнее и быстрее. Однако, как вы заметили, да, это все субъективщина и это главный недостаток данного подхода.
2. Композиционность - это больше про UI. В Java я сталкиваюсь с такой библиотекой как Vaadin, которая, на мой взгляд демонстрирует суть этого принципа. Опять же все та же субъективщина и минимизация. То есть по сути, ваш код просто должен смотреться одинаково монолитно будучи в любых формах композиции. Пример - у нас есть кнопка и текст филд. Будучи в форме или фильтре они как и с уровня Кода, так и с уровня интерфейса они должны выглядеть как единое целое, и далее новые компоненты которые мы написали - форма и фильтр также должны выглядеть как отдельные компоненты, которые также могут быть скомпанованы в единое целое, например, экран или страницу, итд.
3. Предсказуемость - это BLP в солид, который мы также минимизирует. Однако, тут - как раз двойственная ретроспектива код и софт - оба должны вести себя одинаково. Опять же, можно привести пример текст филда и кнопки, но пусть это будут только интерфейсы, допустим, какой то бизнес логики сложной обработки документов. Если мы обрабатываем хлмх и ворд - не важно что, в любом случае, не зависимо от реализации, на выходе мы будем получать одинаковый результат, а поведение не меняется координально лишь от того, что у нас другой тип документа. Имхо, все те же принципы солид, но в рамках свойств, а не догм.
4. Идиоматичность. Самый тривиальный пункт, пожалуй, который невозможно отнести к какому-то из принципов солид. Тут все просто - в первую очередь разработчик, приходящий в новый проект должен оперировать теми терминами которыми оперирует сообщество (и его команда). Например, на Java не писать открывающую фигурную скобку с новой строки, как это принято в дотнете. Имхо, самый очевидный и итак всеми соблюдаемый принцип(свойство).
Вы не поверите, но, например, большая часть разработчиков видит устаревший синтаксис сишных циклов
forкак весьма идиоматичный и понятный, тоже самое у них с&&вместоandи т.д. А от синтаксиса python, nim и rust они будут плеваться, говоря, что чёт какая-то шляпа и нифига не понятно
5. С доменностью полностью согласен, да как и со всем - это все вкусовщина. Да вся статья про то, что SOLID это объективно и, потому, не так "приятно". В то время как КУПИД - субъективно и приятно, но в глазах каждого из разработчика это будет трактоваться по разному.
6. Вывод
Вывод: автор не понял принципы SOLID, не осознал, что они говорят об объективных вещах, так ещё и в рамках конкретного уровня абстракции (интерфейсов) и поспешил выкинуть их в трубу ради пяти красиво звучащих и весьма субъективных принципов, потому что они "современные и интуитивно понятные".
Не знаю про какого из авторов вы тут говорите) Если про меня - тут как бы статья обрамлена в кликбайт, все остальное - сам перевод. Да, вы правильно заметили, Дан Норт именно это и хочет - чтобы разработчики думали своей головой и приявляли креатив(адекватный). А еще - КУПИД классно транслируется не только на код, но и на весь софт - то есть эти свойства могут оценивать не только "классы" и "связи/композации", но и конкретные высокоуровневые реализации и даже конечные продукты.
PS Солид никто выкидывать не собирается) все эти принципы, очевидно, будут применимы и в будущем.
Cпасибо за конкретезированный комментарий! Тоже было интересно почитать.
между требованиями иметь как можно меньше внешних зависимостей и выполнять только одну задачу и при том хорошо в реальной жизни восновном будет возникать противоречие, т.к. если вы, например, имеете потребность, но не используете XStream или его аналог как зависимость, значит вы решаете его задачу внутри своей разработки т.е. добавляете ее к перечню задач решаемых вашей единицей кода. Решение проблемы с логгерами лежало где-то как раз в сфере SOLID: 1) зависеть от интерфейсов, а не от реализаций, 2) не иметь дублирующих реализаций в рамках одной системы.
Бегство от реальности: как перестать подгонять свой код под устаревшие шаблоны