Нет, я говорю о гораздо более фундаментальных вещах.
Я работаю в ИТ на достаточно высоком, уже не исполнительском уровне, и когда мне говорят: “надо прикрутить вот такую штуку” - я первым делом спрашиваю заказчика и себя: “А зачем?”
Ваша статья фактически постулирует, что есть некая система ценностей, и вот если вы в неё не вписываетесь (а человек, который - фактически - не хочет заниматься тем, чем занимается, для него некая деятельность - не вызов, который он готов решать, а явная помеха, которую он стремиться неосознанно обойти всеми силами), то вам нужно таки в неё встроиться, пытаясь перестроить себя. Но вот вопрос: “А зачем?” : )
И если серьезно задуматься над этим - а это как раз дело для людей с высоким IQ - то ответ, внезапно, выходит за пределы очерченной системы, он ведет к осмыслению - а почему, собственно, я не хочу этим заниматься? Разве дело только в том, что у меня нет опыта? Ну так деятельного человека это никогда и не останавливает - он… учится, и это легко видеть у того же технаря, который отнюдь не с, например, двадцатилетним опытом рождается : ) Все эти годы он прекрасно справлялся с обучением в привлекающей его сфере, ему не требовались костыли. А тут, получается, у него отказывает его же навык обучения. Почему?
…Если завтра объявить, что ценны только те, кто умеет танцевать балет, то получится, что всем надо будет ему научиться - иначе у них возникнут проблемы с приобретением ценности. Этот пример взят намеренно - он достаточно абсурден. Но вот почему-то с предпринимательством и прочим таким - это уже возведено в аксиому. Но так ли это? И не является ли ваше состояние следствием того, что вам навязаны определенные ценности?
Если вы думаете, что это естественная ситуация, то могу вас огорчить - эта система ценностей не выбор, её активно продавливают заинтересованные лица. Продавливают через зачистку альтернатив, причем сейчас уже законодательно - делают невозможным, например, содержание собственного хозяйства, объявляя его общественно-опасным (якобы человек не в состоянии обеспечить требуемый уровень, изобретаются способы давления, всяческие инспекции и прочая. Хотя влияние человека тут минимально, в то время как корпорации наносят урон обществу массово), потихоньку запрещается самостоятельное вмешательство в механизмы - самостоятельный ремонт, и т.д. Система давно вовсе не естественный выбор, выбор стремительно сводится к безальтернативности.
Кроме того, если посмотреть на тот же бизнес - то это замкнутая система по сути лотерейного типа (что вы сами же и признаете - количество призов остается тем же, количество попыток - это количество лотерейных билетов, но выигравших в ней больше не станет : ) и вот еще один вопрос: а кто выигрывает от этого? Кроме казино? : ) Казино выгодно больше участников, его щедрые вознаграждения единичных счастливчиков не обанкротят его, а вот чем больше будет игроков и чем больше их вклад в лотерею - тем выше комиссионные держателей казино.
Еще не в накладе инфраструктурщики - ведь все попытки в любом случае стоят денег, фаундеры будут платить за инфраструктурные сервисы.
Ну и еще тут прекрасно могут чувствовать себя коучи, которые любезно объясняют - как “эффективнее” играть в лотерею, какие трудности возникают у потенциальных игроков с нежеланием вкладываться в эту чудесную систему - и как их порешать : )
А что - реально - получают игроки в своей массе, покупая больше билетов?
…Так собственно о чем я? Об осознании, о вопросе “Зачем?”, прежде чем что-либо делать. Несомненно, нужны люди с умением продавать и прочее такое, но это вовсе не значит, что это единственный вариант. Те, кто стремятся к этому - и так будут это делать, для них даже может быть ваша статья будет подспорьем. Но это не значит, что все должны этого хотеть : ) И вовсе не потому, что они не умеют : ) Они может статься - и не хотят этого уметь. И в этом порок только для системы, которая заинтересована именно в определенной системе ценностей и патологизирует альтернативы.
А в каком месте вы привели пример Композиции на Go?
Если вы про этот код:
type UserService struct{
cache Cache
}
type Cache interface{
Get(k string) (string, error)
Set(k, v string) error
}
type MapCache struct {/* ... */}
type MapCacheThreadSafe struct {/* ... */}
type RedisCache struct {/* ... */}
Так тут, пардон, — её нет, это Агрегация.
Но главный вопрос к "тоталитарности" интерфейсов в Go:
В чем преимущества "гадания" в Go — подходит ли структура под интерфейс, который нигде не задается явно при реализации, — перед явным объявлением в Python?
В Python я вижу, что класс наследуется от Cache и согласно LSP обязан следовать контракту родителя.
В Go же, чтобы понять, что, например, структура MapCache вообще имеет отношение к интерфейсу Cache, мне нужно откуда-то догадаться, что где-то объявлен такой интерфейс.
Где здесь та самая "тоталитарность", которая якобы упрощает жизнь и снимает вопросы? И как насчет последовательности дизайна языка? Куда вдруг пропала явная типизация - и всплыла "уточка типизации"? : )
И про мейнфреймы — это, мягко говоря, натяжка. Java создавалась как "write once, run anywhere" для разнородных систем, а не для мейнфреймов. Но это к делу не относится.
Суть в другом: и Java, и Python — языки широкого профиля, каждый со своей историей и компромиссами. Go — язык узкой специализации. И это не делает его "хуже" или "лучше". Просто разное назначение. А когда начинают сравнивать специализированный инструмент с универсальным и удивляться, почему у второго якобы "лишние" детали — это странно : )
Python и Java - в первую очередь языки для описания сложных доменов - для этого у них и есть соответствующие инструменты, которые позволяют без лишнего скрипа, а пожалуй что - и комфортно, описывать то, для чего они и были созданы. В инфраструктурных задачах они будут проигрывать языкам, заточенных под построение инфраструктуры, как те, в свою очередь, будут вынуждать писать логику какими-то нетривиальными подходами - потому что нет объектов, нет элементарных enum.
Я нигде и не утверждаю, что Python и Java - лучше во всём : ) потому что это элементарно не так, потому что область применения неизбежно диктует наиболее подходящий дизайн языка программирования, и чем более специфицируешься - и получаешь удобные плюшки для ниши, тем менее становишься универсальным. Всё имеет свою цену - и спецификация, и универсальность.
Rust - и вовсе выбор для системного программирования. Да, и на нём можно писать всё остальное - но это, утрируя, как забивать гвозди микроскопом. На каком-то уровне - сойдет; если нужна максимальная эффективность - будешь страдать.
Или вы будете утверждать, что таки Go - это и великолепный швец, и жнец, и на дуде игрец, ибо реализовал "тоталитарность"? : )
А зачем тогда сравнивать его с языками, явно другого поля применения, такими как - Java, Python, да и Rust?
Вы берете, условно говоря, трековую машину - с максимально обтекаемым силуэтом и прижатую к земле, у которой из салона выкинуто всё "лишнее" а вместо этого "лишнего" - установлен каркас безопасности... и сравниваете её с седаном, на котором ездят на работу каждый день, или с пикапом, в котором грузы возят - и говорите: во, зачем им этот салон, где усилители, почему такие высокие - их же раскачивать будет в поворотах!... : )))
И опять - речь не про то, что Go, условно - плох на "бездорожье" : ) ему туда по-сути и не надо, а о том, что если уж и имело смысл сравнивать - так это "машины" одного назначения.
А если делать "многоцелевую" машину - то вот тут и полезут компромиссы : )
Так и речь не о том, чтобы делать из Go язык на все случаи жизни, а о том, что автор сравнивает и "удивляется": и зачем в других языках все эти сложности, которых нет в Go? : ) Так это не потому, что Go нашёл программистский универсальный Грааль, а потому что это хороший инструмент для конкретной сферы. У других языков — другие сферы, отсюда и другой инструментарий.
Go — замечательный язык для своей ниши: инфраструктурные сервисы, CLI-утилиты, всё, что должно компилироваться в один бинарник и предсказуемо работать. Его ограниченность — это плата за попадание в эту нишу, а не философский идеал. Назвать это "тоталитарностью" и представить как главное преимущество — красиво, но по сути это эвфемизм для "узкой специализации". Как только язык попытается выйти за пределы этой ниши, его "тоталитарность" начнет трещать по швам, и он неизбежно начнет обрастать теми самыми сложными конструкциями, до которых у фанатов языка и дело ввиду их сферы разработки редко доходит.
Всё верно заметил автор, да еще и несколько наивен - проецирует свой опыт - насчет того, что многих людей интересует саморазвитие. Человеческий мозг - механизм адаптации: побыстрее достичь результата с минимальными затратами - и лежать себе и ничего не делать, развлекаться - вот что работает, и выискивать примеры не нужно - это повсеместно наблюдается. Мозг вовсе не осознает пользы и необходимости усилий, и вся наша цивилизация - это желание хлеба и зрелищ.
А с появлением и развитием ИИ это и ведет к тому, что самостоятельные усилия будут всё более обесцениваться и заменяться "быстрыми" достижениями ИИ; образовательная среда начнет загибаться еще сильнее и быстрее - кто и зачем будет в неё вкладываться? Дети, не получившие навыка учиться с детства посредством напряжения собственных извилин, в зрелом возрасте уже не смогут наверстать упущенное. И вот - добро пожаловать в человекопарк: человек станет "домашним питомцем" ИИ в лучшем случае.
Возьмите дитеныша дикого животного в зоопарк, кормите его, ухаживайте, обеспечивайте комфорт - а потом выпустите его "на волю" - и что получите?
А про то, что нам математика не нужна, ассемблер или знать как устроен компьютер и как он там вообще функционирует... это ведь не про то, что вы будете всё это применять ежедневно, а как раз о понимании - как это реально работает и как это развивать дальше. Да, можно и без этого прожить - но это жизнь в "зоопарке" с надеждой, что кто-то вместо тебя всё это знает и может и тебе обеспечит. А неведение - оно мультипликативный эффект имеет еще, и чем на большее вы забиваете, тем более быстрыми темпами растет ваша беспомощность.
Единственный выход тут - направить всю мощь ИИ в первую очередь на исследование и внедрение техник развития самого человека. А иначе - нас ждет конец человеческой линии развития.
Владимир, я понимаю, что невозможно научить всему сразу... но и учить неправильному поведению - это неправильно. Джун глядит на ваш код, и усваивает, что:
Можно совать всё в один метод
Можно смешивать уровни абстракций
Даже с самим именованием - проблема!
Это сводит на нет полезность вашей идеи - потому что её иллюстрация в таком виде не столько дала, сколько продемонстрировала антипаттернов : )
Ну, в целом да, к тому же эта история из разряда: Я познал ucoz/Wix/вписать_любимое - теперь я зохвотил мир web-разработки. Ниша своя есть у этого, но она где-то там, где говнокода и так хватало с избытком.
Тем не менее, всё же остается надежда на отчаянных парней-менеджеров и в суровом энтерпрайзе, которые проведут операцию Оптимизация, и дадут порулить LLM и в лиге повыше : ) где код не одноразовый.
Так пример-то демонстрирует не упрощение, а нарушения здравого смысла — что я и заметил: смешение ответственности в классе, причём даже при этом класс ничего не делает с Web; конвертация типов в бизнес-логике — это вообще оксюморон.
Ваша мысль про суть классификации — здравая, но подана с ошибками.
Я бы добавил к ней, что именование класса состоит из двух частей: предметной роли и инфраструктурной роли. Например, сервис вычислений логичнее назвать MathService — предметно он работает с математикой, инфраструктурно — это сервис. А то, что вы назвали MathWebService, скорее соответствует MathController: предметно — математика, структурно — контроллер (устоявшееся понятие в веб-фреймворках).
Либо структуру можно выразить через неймспейсы: services.Math, controllers.Math.
За критику извиняйте — писал не для того, чтобы задеть, а чтобы предложить улучшить материал, который, безусловно, не лишён пользы.
За всеми концепциями стоят банальные реальные потребности, в том числе и за Чистым кодом. Для человека, не разбирающегося в реальных движущих силах того или иного инструмента, естественно этот инструмент превращается в фетиш, а действия с ним - в карго-культ.
Смешно читать про противопоставление тестирования и чистого кода. Смешно читать, что чистый код не нужен, потому что он мешает писать программы быстро. Это непонимание чистого кода, его функций - портрет вайбкодера : ) Между тем - Чистый код просто форма борьбы со сложностью кода и закладка фундамента под то, чтобы код был структурирован и его можно было бы развивать. Это актуально для любого интеллекта - хоть человеческого, хоть искусственного: запутанный, плохо структурированный код будет приводить к деградации понимания что происходит и что код выражает экспоненциально с ростом количества кода.
При этом я ничего против LLM не имею. Они просто не справляются на больших проектах - и это факт из моего практического, постоянного и довольно обширного опыта применения LLM для кодинга. В последнее время я стал еще и натыкаться на то, что модели отстают от актуального знания - свежих библиотек - и генерят устаревший код, а зачастую и миксуя несовместимые версии. Плачевно обстоит дело и с рефакторингом крупных проектов - нужно либо продумать этот рефакторинг и описать от и до: где и что поменять конкретно и в полуручном режиме пройтись последовательно по изменяемым программным сущностям вместе с LLM, еще и попутно поправляя ее - но тогда в чем выигрыш?; либо получить взрыв на макаронной фабрике : )
Я не против, если бы LLM могла писать код за меня - и даже знания в прграммировании мне бы не мешали при этом : ) Но - это не работает так, как пишут нам восторженные вьюноши.
Ждем следующую статью: "Будут ли важна булева алгебра в ближайшем будущем" : )
А откуда в сервисах ...WebService слово Web взялось? Эти классы ничего про Web как раз и не знают и знать не должны: им побоку - откуда данные пришли, их дело - вычисления организовать.
Пример плохой ящитаю - он скорее оттолкнет, чем заставит задуматься, потому что конкретно в данном случае - оверинжиниринг с раздуванием кодовой базы на ровном месте, и для начинающего программиста это приведет либо к тому, что он воцерквится и начнет писать так всюду - и где надо, и где не надо - запаривая коллег в случаях, где "не надо"; либо же решит, что всё это вовсе - фигня, и не будет делать этого где как раз "надо".
Конвертация типов опять же внутри Вычислителя - плохо, Вычислитель работает с числами - и его требования к входящим данным как раз должны быть озвучены в сигнатуре, а вот уже тот, кто его вызывает - пусть и конвертит типы. Забавно ведь, если вы внутри программы в другом сценарии тот же вычислитель весов будете использовать, где у вас и так числовые значения веса - так теперь, чтоб воспользоваться вычислением веса вам придется конвертнуть числа в строки чтобы вызвать вычислитель, а тот будет обратно в числа конвертить, а потом еще и вернет вам строку, которую уже вам придется конвертить обратно в число : )
Ну и в целом - лучше всё таки писать проще сначала, если сразу задача не стоит объемная, где уже понятно, что надо выделять классы. Преждевременные архитектурные экзерцисы - это преждевременная архитектурная оптимизация, которая только раздувает код без практического выхлопа.
Само собой - есть задачи, где описанное в статье применимо и адекватно, но не надо превращать это в Золотой молоток.
Я согласен, что описанный мной подход - не универсален и не применим всюду. Опять же шаблонный код и решения - это в моей практике составляет инфраструктуру, а бизнес-логика - каждый раз разная, просто она в своем слое живет.
Ну, насчет "красиво" - это тоже субъективно сильно. Я под Правильным кодом подразумеваю больше шаблонный код - когда от проекта к проекту везде одни и те же структура проекта, архитектура, компоненты, библиотеки, одинаковый DI и т.д. Понятно, что такое, во-первых, даже при примерно одинаковой сфере проекта не совпадает на 100%, но тем не менее - всё же процент шаблонности достигает 70-80%, а во-вторых - можно иметь разные шаблоны на разные классы задач.
Всё это позволяет работать командам предсказуемо с предсказуемым качеством и временем разработки, хотя, понятно, и - гипотетически - можно было бы и "лучше", "красивее", "быстрее" : ) но обычно, из-за как раз таки возникающей непредсказуемости нестандартных подходов всё получается по факту как раз ровно наоборот: плохо, коряво и вдобавок долго : )
Для реально же "особых" случаев - да, придется нестандартные решения вкручивать, но во многих сферах разработки такое встречается очень нечасто, и большую часть проектов выгоднее писать просто правильно, стандартно - и не выеживаться : )
Я код делю на Работающий, Правильный и Эффективный : ) Причем это три разных вида кода.
Работающий - тот что работает. Не важно как - но делает именно то, что должен делать. Это код джуна, который всеми правдами и неправдами добивается, чтобы программа работала.
Правильный код - это код, который следует элементарным правилам: тому же SOLID, паттернам, где они собственно и возникают и т.д. - в целом я не согласен с хитропопыми заявлениями про "понимание, где надо следовать, а где не надо следовать правилам" - это банальный самообман самоуверенности - мол, я-то уж знаю че-почем : ) Это-то и приводит к тому, что пишут все кто в лес, кто по дрова и потом тратится время на разбирательства и проблемы на ровном месте из-за того, что кто-то внезапно решил, что он умнее. Не дано умничать, где без этого можно обойтись : ) KISS в частности и об этом : ) А вот Правильный код - он стандартный, особенно, если в компании есть четкие гайды, и - да, в некоторых местах можно было бы и "срезать путь" - но это будет вносить каждый раз новые неожиданные особенности в код и каждый раз в каждом проекте можно будет встретить что угодно, и разбираться с этим, и воротить дальше еще более непредсказуемые решения. Зачем? Ради чего?
Но, опять же, из-за своей природы, Правильный код хорош в понятности, но не оптимален из-за этого в плане производительности. А иногда производительность - это требование необходимое. И вот тогда и пишут уже Эффективный код - с хаками, с ручным управлением всего и вся, с экономией памяти и многая прочая, что может понадобиться, чтобы уложиться в требования. Тут ПРИДЕТСЯ отступить от правил, потому что по-правильному код работает медленно или в другом смысле недостаточно производительно. В любом случае важно, что Эффективный код пишут не от хорошей жизни, а вынужденно! И вот тут важно этот код постараться максимально изолировать от всего прочего, чтобы сложность не пустила метастазы по всему проекту, а второе - это тщательно задокументировать - что вы тут и для чего были вынуждены наворотить, а так же - как этим пользоваться : )
Нет, я говорю о гораздо более фундаментальных вещах.
Я работаю в ИТ на достаточно высоком, уже не исполнительском уровне, и когда мне говорят: “надо прикрутить вот такую штуку” - я первым делом спрашиваю заказчика и себя: “А зачем?”
Ваша статья фактически постулирует, что есть некая система ценностей, и вот если вы в неё не вписываетесь (а человек, который - фактически - не хочет заниматься тем, чем занимается, для него некая деятельность - не вызов, который он готов решать, а явная помеха, которую он стремиться неосознанно обойти всеми силами), то вам нужно таки в неё встроиться, пытаясь перестроить себя. Но вот вопрос: “А зачем?” : )
И если серьезно задуматься над этим - а это как раз дело для людей с высоким IQ - то ответ, внезапно, выходит за пределы очерченной системы, он ведет к осмыслению - а почему, собственно, я не хочу этим заниматься? Разве дело только в том, что у меня нет опыта? Ну так деятельного человека это никогда и не останавливает - он… учится, и это легко видеть у того же технаря, который отнюдь не с, например, двадцатилетним опытом рождается : ) Все эти годы он прекрасно справлялся с обучением в привлекающей его сфере, ему не требовались костыли. А тут, получается, у него отказывает его же навык обучения. Почему?
…Если завтра объявить, что ценны только те, кто умеет танцевать балет, то получится, что всем надо будет ему научиться - иначе у них возникнут проблемы с приобретением ценности. Этот пример взят намеренно - он достаточно абсурден. Но вот почему-то с предпринимательством и прочим таким - это уже возведено в аксиому. Но так ли это? И не является ли ваше состояние следствием того, что вам навязаны определенные ценности?
Если вы думаете, что это естественная ситуация, то могу вас огорчить - эта система ценностей не выбор, её активно продавливают заинтересованные лица. Продавливают через зачистку альтернатив, причем сейчас уже законодательно - делают невозможным, например, содержание собственного хозяйства, объявляя его общественно-опасным (якобы человек не в состоянии обеспечить требуемый уровень, изобретаются способы давления, всяческие инспекции и прочая. Хотя влияние человека тут минимально, в то время как корпорации наносят урон обществу массово), потихоньку запрещается самостоятельное вмешательство в механизмы - самостоятельный ремонт, и т.д. Система давно вовсе не естественный выбор, выбор стремительно сводится к безальтернативности.
Кроме того, если посмотреть на тот же бизнес - то это замкнутая система по сути лотерейного типа (что вы сами же и признаете - количество призов остается тем же, количество попыток - это количество лотерейных билетов, но выигравших в ней больше не станет : ) и вот еще один вопрос: а кто выигрывает от этого? Кроме казино? : ) Казино выгодно больше участников, его щедрые вознаграждения единичных счастливчиков не обанкротят его, а вот чем больше будет игроков и чем больше их вклад в лотерею - тем выше комиссионные держателей казино.
Еще не в накладе инфраструктурщики - ведь все попытки в любом случае стоят денег, фаундеры будут платить за инфраструктурные сервисы.
Ну и еще тут прекрасно могут чувствовать себя коучи, которые любезно объясняют - как “эффективнее” играть в лотерею, какие трудности возникают у потенциальных игроков с нежеланием вкладываться в эту чудесную систему - и как их порешать : )
А что - реально - получают игроки в своей массе, покупая больше билетов?
…Так собственно о чем я? Об осознании, о вопросе “Зачем?”, прежде чем что-либо делать. Несомненно, нужны люди с умением продавать и прочее такое, но это вовсе не значит, что это единственный вариант. Те, кто стремятся к этому - и так будут это делать, для них даже может быть ваша статья будет подспорьем. Но это не значит, что все должны этого хотеть : ) И вовсе не потому, что они не умеют : ) Они может статься - и не хотят этого уметь. И в этом порок только для системы, которая заинтересована именно в определенной системе ценностей и патологизирует альтернативы.
А что если цель - не в максимизации? А в балансе?
А в каком месте вы привели пример Композиции на Go?
Если вы про этот код:
Так тут, пардон, — её нет, это Агрегация.
Но главный вопрос к "тоталитарности" интерфейсов в Go:
В чем преимущества "гадания" в Go — подходит ли структура под интерфейс, который нигде не задается явно при реализации, — перед явным объявлением в Python?
В Python я вижу, что класс наследуется от
Cacheи согласно LSP обязан следовать контракту родителя.В Go же, чтобы понять, что, например, структура
MapCacheвообще имеет отношение к интерфейсуCache, мне нужно откуда-то догадаться, что где-то объявлен такой интерфейс.Где здесь та самая "тоталитарность", которая якобы упрощает жизнь и снимает вопросы? И как насчет последовательности дизайна языка? Куда вдруг пропала явная типизация - и всплыла "уточка типизации"? : )
Java моложе Python : )
И про мейнфреймы — это, мягко говоря, натяжка. Java создавалась как "write once, run anywhere" для разнородных систем, а не для мейнфреймов. Но это к делу не относится.
Суть в другом: и Java, и Python — языки широкого профиля, каждый со своей историей и компромиссами. Go — язык узкой специализации. И это не делает его "хуже" или "лучше". Просто разное назначение. А когда начинают сравнивать специализированный инструмент с универсальным и удивляться, почему у второго якобы "лишние" детали — это странно : )
Python и Java - в первую очередь языки для описания сложных доменов - для этого у них и есть соответствующие инструменты, которые позволяют без лишнего скрипа, а пожалуй что - и комфортно, описывать то, для чего они и были созданы. В инфраструктурных задачах они будут проигрывать языкам, заточенных под построение инфраструктуры, как те, в свою очередь, будут вынуждать писать логику какими-то нетривиальными подходами - потому что нет объектов, нет элементарных enum.
Я нигде и не утверждаю, что Python и Java - лучше во всём : ) потому что это элементарно не так, потому что область применения неизбежно диктует наиболее подходящий дизайн языка программирования, и чем более специфицируешься - и получаешь удобные плюшки для ниши, тем менее становишься универсальным. Всё имеет свою цену - и спецификация, и универсальность.
Rust - и вовсе выбор для системного программирования. Да, и на нём можно писать всё остальное - но это, утрируя, как забивать гвозди микроскопом. На каком-то уровне - сойдет; если нужна максимальная эффективность - будешь страдать.
Или вы будете утверждать, что таки Go - это и великолепный швец, и жнец, и на дуде игрец, ибо реализовал "тоталитарность"? : )
А зачем тогда сравнивать его с языками, явно другого поля применения, такими как - Java, Python, да и Rust?
Вы берете, условно говоря, трековую машину - с максимально обтекаемым силуэтом и прижатую к земле, у которой из салона выкинуто всё "лишнее" а вместо этого "лишнего" - установлен каркас безопасности... и сравниваете её с седаном, на котором ездят на работу каждый день, или с пикапом, в котором грузы возят - и говорите: во, зачем им этот салон, где усилители, почему такие высокие - их же раскачивать будет в поворотах!... : )))
И опять - речь не про то, что Go, условно - плох на "бездорожье" : ) ему туда по-сути и не надо, а о том, что если уж и имело смысл сравнивать - так это "машины" одного назначения.
А если делать "многоцелевую" машину - то вот тут и полезут компромиссы : )
Так и речь не о том, чтобы делать из Go язык на все случаи жизни, а о том, что автор сравнивает и "удивляется": и зачем в других языках все эти сложности, которых нет в Go? : ) Так это не потому, что Go нашёл программистский универсальный Грааль, а потому что это хороший инструмент для конкретной сферы. У других языков — другие сферы, отсюда и другой инструментарий.
Любить наследование необязательно, а вот уметь использовать, где оно есть - надо : )
Go — замечательный язык для своей ниши: инфраструктурные сервисы, CLI-утилиты, всё, что должно компилироваться в один бинарник и предсказуемо работать. Его ограниченность — это плата за попадание в эту нишу, а не философский идеал. Назвать это "тоталитарностью" и представить как главное преимущество — красиво, но по сути это эвфемизм для "узкой специализации". Как только язык попытается выйти за пределы этой ниши, его "тоталитарность" начнет трещать по швам, и он неизбежно начнет обрастать теми самыми сложными конструкциями, до которых у фанатов языка и дело ввиду их сферы разработки редко доходит.
Всё верно заметил автор, да еще и несколько наивен - проецирует свой опыт - насчет того, что многих людей интересует саморазвитие. Человеческий мозг - механизм адаптации: побыстрее достичь результата с минимальными затратами - и лежать себе и ничего не делать, развлекаться - вот что работает, и выискивать примеры не нужно - это повсеместно наблюдается. Мозг вовсе не осознает пользы и необходимости усилий, и вся наша цивилизация - это желание хлеба и зрелищ.
А с появлением и развитием ИИ это и ведет к тому, что самостоятельные усилия будут всё более обесцениваться и заменяться "быстрыми" достижениями ИИ; образовательная среда начнет загибаться еще сильнее и быстрее - кто и зачем будет в неё вкладываться? Дети, не получившие навыка учиться с детства посредством напряжения собственных извилин, в зрелом возрасте уже не смогут наверстать упущенное. И вот - добро пожаловать в человекопарк: человек станет "домашним питомцем" ИИ в лучшем случае.
Возьмите дитеныша дикого животного в зоопарк, кормите его, ухаживайте, обеспечивайте комфорт - а потом выпустите его "на волю" - и что получите?
А про то, что нам математика не нужна, ассемблер или знать как устроен компьютер и как он там вообще функционирует... это ведь не про то, что вы будете всё это применять ежедневно, а как раз о понимании - как это реально работает и как это развивать дальше. Да, можно и без этого прожить - но это жизнь в "зоопарке" с надеждой, что кто-то вместо тебя всё это знает и может и тебе обеспечит. А неведение - оно мультипликативный эффект имеет еще, и чем на большее вы забиваете, тем более быстрыми темпами растет ваша беспомощность.
Единственный выход тут - направить всю мощь ИИ в первую очередь на исследование и внедрение техник развития самого человека. А иначе - нас ждет конец человеческой линии развития.
Владимир, я понимаю, что невозможно научить всему сразу... но и учить неправильному поведению - это неправильно. Джун глядит на ваш код, и усваивает, что:
Можно совать всё в один метод
Можно смешивать уровни абстракций
Даже с самим именованием - проблема!
Это сводит на нет полезность вашей идеи - потому что её иллюстрация в таком виде не столько дала, сколько продемонстрировала антипаттернов : )
Вы сами бы такой код на ревью пропустили бы? : )
Ну, в целом да, к тому же эта история из разряда: Я познал ucoz/Wix/вписать_любимое - теперь я зохвотил мир web-разработки. Ниша своя есть у этого, но она где-то там, где говнокода и так хватало с избытком.
Тем не менее, всё же остается надежда на отчаянных парней-менеджеров и в суровом энтерпрайзе, которые проведут операцию Оптимизация, и дадут порулить LLM и в лиге повыше : ) где код не одноразовый.
Это, я считаю, на сегодняшний день заслуживает первого места в номинации «Лучший манифест говнокодинга» : ))
А по ситуации - это прекрасный задел для реальных программистов, когда после волны вайбоподелок придется разгребать последствия : )
Вайбте больше и быстрее, ребята! Больше будет работы в недалеком будущем для тех, кто разбирается в программировании : )
Так пример-то демонстрирует не упрощение, а нарушения здравого смысла — что я и заметил: смешение ответственности в классе, причём даже при этом класс ничего не делает с Web; конвертация типов в бизнес-логике — это вообще оксюморон.
Ваша мысль про суть классификации — здравая, но подана с ошибками.
Я бы добавил к ней, что именование класса состоит из двух частей: предметной роли и инфраструктурной роли. Например, сервис вычислений логичнее назвать
MathService— предметно он работает с математикой, инфраструктурно — это сервис. А то, что вы назвалиMathWebService, скорее соответствуетMathController: предметно — математика, структурно — контроллер (устоявшееся понятие в веб-фреймворках).Либо структуру можно выразить через неймспейсы:
services.Math,controllers.Math.За критику извиняйте — писал не для того, чтобы задеть, а чтобы предложить улучшить материал, который, безусловно, не лишён пользы.
За всеми концепциями стоят банальные реальные потребности, в том числе и за Чистым кодом. Для человека, не разбирающегося в реальных движущих силах того или иного инструмента, естественно этот инструмент превращается в фетиш, а действия с ним - в карго-культ.
Смешно читать про противопоставление тестирования и чистого кода. Смешно читать, что чистый код не нужен, потому что он мешает писать программы быстро. Это непонимание чистого кода, его функций - портрет вайбкодера : ) Между тем - Чистый код просто форма борьбы со сложностью кода и закладка фундамента под то, чтобы код был структурирован и его можно было бы развивать. Это актуально для любого интеллекта - хоть человеческого, хоть искусственного: запутанный, плохо структурированный код будет приводить к деградации понимания что происходит и что код выражает экспоненциально с ростом количества кода.
При этом я ничего против LLM не имею. Они просто не справляются на больших проектах - и это факт из моего практического, постоянного и довольно обширного опыта применения LLM для кодинга. В последнее время я стал еще и натыкаться на то, что модели отстают от актуального знания - свежих библиотек - и генерят устаревший код, а зачастую и миксуя несовместимые версии. Плачевно обстоит дело и с рефакторингом крупных проектов - нужно либо продумать этот рефакторинг и описать от и до: где и что поменять конкретно и в полуручном режиме пройтись последовательно по изменяемым программным сущностям вместе с LLM, еще и попутно поправляя ее - но тогда в чем выигрыш?; либо получить взрыв на макаронной фабрике : )
Я не против, если бы LLM могла писать код за меня - и даже знания в прграммировании мне бы не мешали при этом : ) Но - это не работает так, как пишут нам восторженные вьюноши.
Ждем следующую статью: "Будут ли важна булева алгебра в ближайшем будущем" : )
А откуда в сервисах ...
WebServiceслово Web взялось? Эти классы ничего про Web как раз и не знают и знать не должны: им побоку - откуда данные пришли, их дело - вычисления организовать.Пример плохой ящитаю - он скорее оттолкнет, чем заставит задуматься, потому что конкретно в данном случае - оверинжиниринг с раздуванием кодовой базы на ровном месте, и для начинающего программиста это приведет либо к тому, что он воцерквится и начнет писать так всюду - и где надо, и где не надо - запаривая коллег в случаях, где "не надо"; либо же решит, что всё это вовсе - фигня, и не будет делать этого где как раз "надо".
Конвертация типов опять же внутри Вычислителя - плохо, Вычислитель работает с числами - и его требования к входящим данным как раз должны быть озвучены в сигнатуре, а вот уже тот, кто его вызывает - пусть и конвертит типы. Забавно ведь, если вы внутри программы в другом сценарии тот же вычислитель весов будете использовать, где у вас и так числовые значения веса - так теперь, чтоб воспользоваться вычислением веса вам придется конвертнуть числа в строки чтобы вызвать вычислитель, а тот будет обратно в числа конвертить, а потом еще и вернет вам строку, которую уже вам придется конвертить обратно в число : )
Ну и в целом - лучше всё таки писать проще сначала, если сразу задача не стоит объемная, где уже понятно, что надо выделять классы. Преждевременные архитектурные экзерцисы - это преждевременная архитектурная оптимизация, которая только раздувает код без практического выхлопа.
Само собой - есть задачи, где описанное в статье применимо и адекватно, но не надо превращать это в Золотой молоток.
Я согласен, что описанный мной подход - не универсален и не применим всюду. Опять же шаблонный код и решения - это в моей практике составляет инфраструктуру, а бизнес-логика - каждый раз разная, просто она в своем слое живет.
Ну, насчет "красиво" - это тоже субъективно сильно. Я под Правильным кодом подразумеваю больше шаблонный код - когда от проекта к проекту везде одни и те же структура проекта, архитектура, компоненты, библиотеки, одинаковый DI и т.д. Понятно, что такое, во-первых, даже при примерно одинаковой сфере проекта не совпадает на 100%, но тем не менее - всё же процент шаблонности достигает 70-80%, а во-вторых - можно иметь разные шаблоны на разные классы задач.
Всё это позволяет работать командам предсказуемо с предсказуемым качеством и временем разработки, хотя, понятно, и - гипотетически - можно было бы и "лучше", "красивее", "быстрее" : ) но обычно, из-за как раз таки возникающей непредсказуемости нестандартных подходов всё получается по факту как раз ровно наоборот: плохо, коряво и вдобавок долго : )
Для реально же "особых" случаев - да, придется нестандартные решения вкручивать, но во многих сферах разработки такое встречается очень нечасто, и большую часть проектов выгоднее писать просто правильно, стандартно - и не выеживаться : )
Я код делю на Работающий, Правильный и Эффективный : ) Причем это три разных вида кода.
Работающий - тот что работает. Не важно как - но делает именно то, что должен делать. Это код джуна, который всеми правдами и неправдами добивается, чтобы программа работала.
Правильный код - это код, который следует элементарным правилам: тому же SOLID, паттернам, где они собственно и возникают и т.д. - в целом я не согласен с хитропопыми заявлениями про "понимание, где надо следовать, а где не надо следовать правилам" - это банальный самообман самоуверенности - мол, я-то уж знаю че-почем : ) Это-то и приводит к тому, что пишут все кто в лес, кто по дрова и потом тратится время на разбирательства и проблемы на ровном месте из-за того, что кто-то внезапно решил, что он умнее. Не дано умничать, где без этого можно обойтись : ) KISS в частности и об этом : ) А вот Правильный код - он стандартный, особенно, если в компании есть четкие гайды, и - да, в некоторых местах можно было бы и "срезать путь" - но это будет вносить каждый раз новые неожиданные особенности в код и каждый раз в каждом проекте можно будет встретить что угодно, и разбираться с этим, и воротить дальше еще более непредсказуемые решения. Зачем? Ради чего?
Но, опять же, из-за своей природы, Правильный код хорош в понятности, но не оптимален из-за этого в плане производительности. А иногда производительность - это требование необходимое. И вот тогда и пишут уже Эффективный код - с хаками, с ручным управлением всего и вся, с экономией памяти и многая прочая, что может понадобиться, чтобы уложиться в требования. Тут ПРИДЕТСЯ отступить от правил, потому что по-правильному код работает медленно или в другом смысле недостаточно производительно. В любом случае важно, что Эффективный код пишут не от хорошей жизни, а вынужденно! И вот тут важно этот код постараться максимально изолировать от всего прочего, чтобы сложность не пустила метастазы по всему проекту, а второе - это тщательно задокументировать - что вы тут и для чего были вынуждены наворотить, а так же - как этим пользоваться : )
hu yok hu yok - и в продакшн!