То что он разжёваны и то что их вообще нужно толковать - это и есть проблема, у нас вроде бы не теология а программирование.
Извините, но я не понял откуда взялось "толкования". Их не надо толковать, они правда хорошо описаны.
Если у принципа нет однозначной интерпретации то пойдут толкования, различные взгляды и направления.
Различные взгляды произрастают только из-за лени и недостатка хоть какого-то опыта. Вот будет какой-нибудь новоиспечённый джун убеждать вас в том, что 2+2 это 22. Вы правда после этого начнёте утверждать, что алгебра плоха, потому что кто-то неправильно её толкует? Ну да, будут такие люди, это неизбежно.
Когда строят здание то руководствуются не абстрактными общими принципами а конкретными обоснованными с точки зрения науки и практики нормами.
Принципы достаточно хорошо согласуются с практикой. Их ноги растут из практики.
В общем, я не очень понимаю, какую проблему вы нашли в SOLID-е. И чем предлагаете заменить. Да, я пока слышу вас так: всё это древнее и плохое, их кто-то не так воспринимает, надо выкинуть.
Ну выкинем. Дальше что? У вас есть другой свод правил? Или вообще не надо ничего использовать, а просто разрабатывать по принципам "делай хорошо" и "я художник, я так вижу"?
Альтернативы какие? Потому что все эти ваши претензии можно натянуть на что угодно вообще, умеючи можно и сову на глобус натянуть. Всё можно трактовать как угодно и неправильно.
Я сути проблемы не увидел. Потому что в моей практике, принципы работают хорошо, они действительно помогают писать хороший код и не тратить время на объяснение вещей, которые уже хорошо объяснили и описали. И люди уже приходят с этими знаниями, которые стыкуются со знаниями людей в командах. Это плохо? Ну видимо по-вашему да, надо каждый раз изобретать свой уникальный язык и систему правил в каждой команде. Так ведь интересней :)
Кстати да, я немного поработал с Claude и ChatGPT, для написания развесистой утилиты, меня результат удовлетворил. Правда только через чат. Но понял, что сначала надо поработать над самим заданием вместе с ИИ, прежде чем позволить нейронке срочно бросаться код генерить. Так получается меньше корректировок и меньше необходимости повторного ревью кода. С этой стороны открывается огромный простор для системных и бизнес-аналитиков :)
Понял, спасибо! К сожалению не каждый проект можно разрабатывать с открытым гитхабом, а в наших реалиях, и вообще с любым гитхабом. Отдельная благодарочка за пример с промптом :) Это был следующий вопрос, выгоднее ли разбивать разработку на маленькие итерации, как это делается в обычных командах, или большими постановками. Ещё интересно, может ли ИИ съесть постановки задач, как это делается для людей, например в Confluence-Jira, но это наверное тема для отдельных статей.
Т.е. Claude анализировал код на гитхабе, и вносил коммиты туда? Или комиты локальные? Т.е. вопрос скорее, обязателен ли гитхаб, можно было бы это проделать без него?
Я может проглядел, что использовали для взаимодействия исходного кода и Claude? Какие инструменты? Или копировали исходники из чата и обратно? Спасибо.
Пока опыт показывает, что чаще всего приходиться распиливать. Хотя это не отменяет банального принципа: не надо использовать технологии бездумно. Но это капитанство совершенно ни к чему.
Ага, настолько же тёплый, насколько мягкий. Самый убедительный аргумент сравнивать тёплое с мягким. Еще и выводы глубоко инженерные. Все, побежали сотни микросервисов, замечательно и успешно решающих свои задачи, слеплять в ламповый монолит.
Постоянные и непременные отсылки к дядюшке Бобу, или другим корифеям как-то странно звучат. Я не опираюсь на авторитет, никогда не апеллирую к нему в аргументах, мне он не важен. Это интересно как историческая справка, не более.
Благодаря популярности и широкому охвату аудитории среди специалистов, принципы на сегодняшний день очень хорошо разжёваны и расписаны, и достаточно раскритикованы. Смотрите на это, как на библиотеку, которую написали сообществом и можно использовать в работе, не затрачивая усилий на создание новых, узких и малоизвестных принципов или подходов.
Да, это не формула, высеченная в камне, не аксиома, не ответ на все вопросы, не решение всех задач, но это весьма конкретные указания, общие принципы, которым итак многие следуют вполне естественным образом. Оно и не удивительно, так как родились они также, из опыта, а не от теории.
Отдельные принципы могут иметь различия в деталях, на то они и принципы, а не конкретные методики, где написано до буквы: делай А, получишь Б. Но они и не абстрактные, позволяют быстрее установить общее понимание хорошего в рандомной команде. Т.е. суть в том, что они действуют не только между участниками одной команды, а между участниками всех команд в мире. Не удивительно, что будут разногласия. Вплоть до того: "да кому нужны эти ваши принципы, паттерны-шматерны, учебники, буквари! я буду писать как я хочу и точка!".
Негатив и отрицание ко всему наработанному опыту явление ожидаемое, и это часть эволюции. Надо выкидывать лишнее и бесполезное. Но я наблюдаю другой тренд: давайте вообще всё выкинем, под корень. Всё это туфта. Конечно, не забудем принизить значимость авторов: да это какой-то писака, вообще не шарит и далёк от реальных задач. Да ради бога, я на них не молюсь, и не жду этого от других :)
Бездумно чему-то следовать -- очень плохо. Надо применять с умом. Как и бездумно отрицать и нивелировать накопленный опыт.
Моё мнение, DDD это не про сущность в программном коде в виде какого-нибудь класса со 100500 полями. Это детали реализации. Но почему-то упорно бытует мнение, что DDD = рич объект. Вовсе нет.
Всё так, это не руководство к действию, которое применяется с оглядкой или шпаргалкой на какой-то свод принципов. Осмелюсь сказать, что многие их применяют даже не помня или не зная о них. Но для новичков это полезно, так как опыта ещё нет, в том числе может быть полезно на code review, чтобы не объяснять на пальцах и не тратить время на то, что уже обобщено и описано.
Понял. У меня другое мнение на этот счёт. Многие люди признают, что с опытом заявленные принципы становятся очевидными и применяются даже без явного знания или умышленного следования им. Эти принципы нужны для согласования работы, новичкам. Я понимаю, какому-нибудь сеньору всё итак понятно, и ему все эти лекала не нужны, он чувствует как надо, но зачем это экстраполировать на всех? Да, может они устарели местами, завирусились, это не делает консолидированный опыт плохим. Как минимум, это может быть полезно на code review, естественно без фанатизма. Отрицание это напоминает юношеский максимализм. Чего эти бородатые светила с олимпа нам тут напридумывали? Нам и без этого хорошо. Но это ИМХО. Тренд отрицания всего и вся тоже можно назвать завирусившимся.
Как-то это странно звучит. По началу мне нравился КиШ, а потом его стали крутить везде, опопсела группа, а я хочу андеграуд, попса это зло :) Хотя по факту ничего не поменялось.
Что значит "отказался" от YAGNI, KISS, SOLID? Делаем наперекор? Если не упарываться, то эти принципы выведены из практики, а не практика построена на этих принципах. Другое дело, когда их выпячивают и ожидают знания академических определений назубок зачем-то. Но это совсем другая проблема, из области дай дураку...
Не, ну так холивора не получится. Давай всё ж определяться, какие модели: анемичные или рич? Что таки должно быть в юз кейсах? Где заканчиваются бизнес-правила и начинается инфраструктура? Каждому сервису по интерфейсу? А сервис ли это? Вкидывать так вкидывать :)
Извините, но я не понял откуда взялось "толкования". Их не надо толковать, они правда хорошо описаны.
Различные взгляды произрастают только из-за лени и недостатка хоть какого-то опыта. Вот будет какой-нибудь новоиспечённый джун убеждать вас в том, что 2+2 это 22. Вы правда после этого начнёте утверждать, что алгебра плоха, потому что кто-то неправильно её толкует? Ну да, будут такие люди, это неизбежно.
Принципы достаточно хорошо согласуются с практикой. Их ноги растут из практики.
В общем, я не очень понимаю, какую проблему вы нашли в SOLID-е. И чем предлагаете заменить. Да, я пока слышу вас так: всё это древнее и плохое, их кто-то не так воспринимает, надо выкинуть.
Ну выкинем. Дальше что? У вас есть другой свод правил? Или вообще не надо ничего использовать, а просто разрабатывать по принципам "делай хорошо" и "я художник, я так вижу"?
Альтернативы какие? Потому что все эти ваши претензии можно натянуть на что угодно вообще, умеючи можно и сову на глобус натянуть. Всё можно трактовать как угодно и неправильно.
Я сути проблемы не увидел. Потому что в моей практике, принципы работают хорошо, они действительно помогают писать хороший код и не тратить время на объяснение вещей, которые уже хорошо объяснили и описали. И люди уже приходят с этими знаниями, которые стыкуются со знаниями людей в командах. Это плохо? Ну видимо по-вашему да, надо каждый раз изобретать свой уникальный язык и систему правил в каждой команде. Так ведь интересней :)
Отдельно плюс за требования к рейтлимитам :) Видимо на опыте.
Кстати да, я немного поработал с Claude и ChatGPT, для написания развесистой утилиты, меня результат удовлетворил. Правда только через чат. Но понял, что сначала надо поработать над самим заданием вместе с ИИ, прежде чем позволить нейронке срочно бросаться код генерить. Так получается меньше корректировок и меньше необходимости повторного ревью кода. С этой стороны открывается огромный простор для системных и бизнес-аналитиков :)
Понял, спасибо! К сожалению не каждый проект можно разрабатывать с открытым гитхабом, а в наших реалиях, и вообще с любым гитхабом. Отдельная благодарочка за пример с промптом :) Это был следующий вопрос, выгоднее ли разбивать разработку на маленькие итерации, как это делается в обычных командах, или большими постановками. Ещё интересно, может ли ИИ съесть постановки задач, как это делается для людей, например в Confluence-Jira, но это наверное тема для отдельных статей.
Т.е. Claude анализировал код на гитхабе, и вносил коммиты туда? Или комиты локальные? Т.е. вопрос скорее, обязателен ли гитхаб, можно было бы это проделать без него?
Я может проглядел, что использовали для взаимодействия исходного кода и Claude? Какие инструменты? Или копировали исходники из чата и обратно? Спасибо.
А какая разница? C++ как-то по-особенному умеет на одном ядре выполнять независимо две параллельные вычислительные задачи?
Именно так. Поддерживаю.
Пока опыт показывает, что чаще всего приходиться распиливать. Хотя это не отменяет банального принципа: не надо использовать технологии бездумно. Но это капитанство совершенно ни к чему.
Ага, настолько же тёплый, насколько мягкий. Самый убедительный аргумент сравнивать тёплое с мягким. Еще и выводы глубоко инженерные. Все, побежали сотни микросервисов, замечательно и успешно решающих свои задачи, слеплять в ламповый монолит.
Программисту нужно уметь писать код. Сантехник должен знать что такое гаечный ключ. Очень ценная и важная информация, безусловно.
Когда инструмент становится самоцелью, это превращается в проблему.
Постараюсь кратко ответить на это по существу:
Постоянные и непременные отсылки к дядюшке Бобу, или другим корифеям как-то странно звучат. Я не опираюсь на авторитет, никогда не апеллирую к нему в аргументах, мне он не важен. Это интересно как историческая справка, не более.
Благодаря популярности и широкому охвату аудитории среди специалистов, принципы на сегодняшний день очень хорошо разжёваны и расписаны, и достаточно раскритикованы. Смотрите на это, как на библиотеку, которую написали сообществом и можно использовать в работе, не затрачивая усилий на создание новых, узких и малоизвестных принципов или подходов.
Да, это не формула, высеченная в камне, не аксиома, не ответ на все вопросы, не решение всех задач, но это весьма конкретные указания, общие принципы, которым итак многие следуют вполне естественным образом. Оно и не удивительно, так как родились они также, из опыта, а не от теории.
Отдельные принципы могут иметь различия в деталях, на то они и принципы, а не конкретные методики, где написано до буквы: делай А, получишь Б. Но они и не абстрактные, позволяют быстрее установить общее понимание хорошего в рандомной команде. Т.е. суть в том, что они действуют не только между участниками одной команды, а между участниками всех команд в мире. Не удивительно, что будут разногласия. Вплоть до того: "да кому нужны эти ваши принципы, паттерны-шматерны, учебники, буквари! я буду писать как я хочу и точка!".
Негатив и отрицание ко всему наработанному опыту явление ожидаемое, и это часть эволюции. Надо выкидывать лишнее и бесполезное. Но я наблюдаю другой тренд: давайте вообще всё выкинем, под корень. Всё это туфта. Конечно, не забудем принизить значимость авторов: да это какой-то писака, вообще не шарит и далёк от реальных задач. Да ради бога, я на них не молюсь, и не жду этого от других :)
Бездумно чему-то следовать -- очень плохо. Надо применять с умом. Как и бездумно отрицать и нивелировать накопленный опыт.
Моё мнение, DDD это не про сущность в программном коде в виде какого-нибудь класса со 100500 полями. Это детали реализации. Но почему-то упорно бытует мнение, что DDD = рич объект. Вовсе нет.
Всё так, это не руководство к действию, которое применяется с оглядкой или шпаргалкой на какой-то свод принципов. Осмелюсь сказать, что многие их применяют даже не помня или не зная о них. Но для новичков это полезно, так как опыта ещё нет, в том числе может быть полезно на code review, чтобы не объяснять на пальцах и не тратить время на то, что уже обобщено и описано.
Понял. У меня другое мнение на этот счёт. Многие люди признают, что с опытом заявленные принципы становятся очевидными и применяются даже без явного знания или умышленного следования им. Эти принципы нужны для согласования работы, новичкам. Я понимаю, какому-нибудь сеньору всё итак понятно, и ему все эти лекала не нужны, он чувствует как надо, но зачем это экстраполировать на всех? Да, может они устарели местами, завирусились, это не делает консолидированный опыт плохим. Как минимум, это может быть полезно на code review, естественно без фанатизма. Отрицание это напоминает юношеский максимализм. Чего эти бородатые светила с олимпа нам тут напридумывали? Нам и без этого хорошо. Но это ИМХО. Тренд отрицания всего и вся тоже можно назвать завирусившимся.
Как-то это странно звучит. По началу мне нравился КиШ, а потом его стали крутить везде, опопсела группа, а я хочу андеграуд, попса это зло :) Хотя по факту ничего не поменялось.
Что значит "отказался" от YAGNI, KISS, SOLID? Делаем наперекор? Если не упарываться, то эти принципы выведены из практики, а не практика построена на этих принципах. Другое дело, когда их выпячивают и ожидают знания академических определений назубок зачем-то. Но это совсем другая проблема, из области дай дураку...
Не, ну так холивора не получится. Давай всё ж определяться, какие модели: анемичные или рич? Что таки должно быть в юз кейсах? Где заканчиваются бизнес-правила и начинается инфраструктура? Каждому сервису по интерфейсу? А сервис ли это? Вкидывать так вкидывать :)