Есть куча мест когда тесты, особенно в CI просто не нужны и даже вредны:
У тебя в проекте может не быть автоматических тестов для API. Напримр, в вашей команде уровень контрактных тестов находится на стороне аццептора, а на стороне инициатора только проверка на изменение сваггера. Сответственно, писать дополнительный код, который тебе нужен, который увеличит тест-таймы в процессе разработки, и удалить его после разработки, так как не пропускает QA, только для того чтобы понять полный пайплайн какого то процесса - ну так себе.
Ты разрабатываешь какую то часть пайплайна БП. Но, в этом пайплайне есть ещё куча апишек, которые тебе надо дернуть для того чтобы утилизировать артефакты тестирования. В CI это завязано на то что на регрессе просто создается база с нуля. Но в ручном тестировании каждый раз создавать тестовое окружение с 0 это ебудатьможно оверкилл
У тебя нет полной документации к апи, и код тебе не дают. Для исследований писать вечно зеленые тесты - ну, ой...
Всё нормально: не нравится цена - съезжай в более спокойный район. Так как при очень большом количестве чудаков, ты рано или поздно сам станешь водить машину как чудак. Иначе тебе машину разобьет очередной джигит
Если посмотреть на app/routes.py, то понятно, что такое мы поддерживать дальше не будем.Очень много дубликатов, нарушены кучи практик программирования.
Расширять тоже, проще переписать
Используются устаревшие технологии вроде бутстрапа и jq
три недели по паре часов, это 30 часов. Я бы уже напрягся если бы такое выдали дольше, чем через 8 часов от разработчика уровня джун+.
С другой стороны. Ну есть, предположим у "мойщика окон" лишние 200 баксов и желание упорядочить свои фотки, за одно и с тимлидством/менторством в минималках познакомится.
Очень часто когда я вижу статьи что SOLID не подходит, почти всегда то рассматривается с точки зрения Объектно‑Ориентированного Программирования. Хотя книга, где впервые использовались эти понятия, даже называется как Principles Of OO Design.
Ребят! Пока вы на SOLID смотрите как на паттерны программирования, а не принципы проектирования, у вас будет взрыв головного мозга. Не делайте так! Это не про код, это про квадратики (модули).
В начале 00х ООП был на первом уровне проектирования, когда 90% программных продуктов в реальности заключались в 5–6 классах, небольшом конфиге(программе) над RAPID и десятке DTO. Сейчас это уровень микросервиса. А проектирование заключается в умении состыковать несколько микросервисов. Поэтому, если в 00х принципы SOLID надо было применять к ОО, то сейчас эти принципы надо применять к схеме диаграммы микросервисов. Время поменялось. У нас сейчас нет времени заниматься чистотой внутри микросервисов — надо заниматься чистотой архитектуры.
tl;dr: они худые потому как двигаются много и не жрут, а двигаются и не жрут потому как худые. ну или больные и скоро сдохнут. а ты жирдяй потому как не двигаешься и жрешь и тоже сдохнешь но не скоро.
ну, в связи с тем, что положение об аттестации утратило силу, то чуть выше вон есть ссылка на письмо роструда:
Для работников, порядок проведения аттестации которых не установлен нормативными правовыми актами, он определяется локальным нормативным актом работодателя (например, положением), принимаемым с учетом мнения представительного органа работников (при его наличии).
получается, что работодатель сам создает приказ о виде аттестации и способах его прохождения.
Трудовой договор расторгнут в связи с несоответствием работника занимаемой должности вследствие недостаточной квалификации, подтвержденной результатами аттестации, пункт 3 части первой статьи 81 Трудового кодекса Российской Федерации
Результаты PR не являются значимыми с точки зрения трудового кодекса
Чисто для себя интересно: а почему? У нас есть 81 статья УК РФ (про аттестацию). Если до 20 года можно ещё было натянуть то, что любая аттестация не соответствует нормам аттестации, то с конца 20 года Положение о порядке проведения аттестации отменили и коммерческие фирмы могут самостоятельно натягивать тесты типа PR, 360 и прочие матрицы на понятие аттестации или, принимать решение о проведении аттестации, на основании этих процедур. Там конечно увольнение не по соглашению, но и не по сокращению, с очень интересной записью в трудовой.
Прям передернуло. Меня вот это всегда напрягает на МП когда товар будет в стекле: урбичи, сбитни, масла, ведь с высокой (для меня) вероятностью они не приедут в целостности. 3 из 10 последних заказов в стекле - битых. А ещё запачкает заказы других покупателей и на тебя как на врага народа смотрит владелец ПВЗ. Почему не поменять упаковку на пластик? Я конечно понимаю что микропластик вреден, хранится меньше, выглядит дешевле, но не так вреден как отбитое стекло или запачканные коробки.
Не хотите пластик, можно в жестянках, в алюминии тащить, но маркетплейсы и стекло это два несочетаемых слова
Ну во первых, не я путаюсь, а выше большая цитата из книги Чистая архитектура уже указанного автора. И если у вас есть возражения к автору, то у меня для вас плохие риторические новости.
Во вторых, мы не говорим класс в контексте SRP. Мы говорим о модуле. В модуле может быть несколько классов. А может быть и один. И если вам для реализации печати нужен какой то свой класс - то делайте его, но не называйте это следованию принципа SRP. Можете назвать это принципом разделения функционала, или принципом единообразия реализации, но не SRP. И да, если классу надо уметь себя распечатывать, то надо просто добавить в него метод print, а не создавать класс [ObjectType]Printer. За исключением, если ваш бухгалтерский отчет должен распечатывать, например, специалист по закупкам, в своем, закупочном, формате. Тогда, да, согласно SRP мы выделяем отдельный метод для формирования нового класса BookingReportPurchasing, из нового модуля, и отдельный метод print в этом классе (ну по вашему отдельный класс BookingReportPurchasingPrinter), а ответственность за аналитику модуля "возлагаем" на специалиста по закупкам.
Так что не надо чистый код путать с чистой архитектурой. Это 2 раздельных уровня. Архитектору, часто, не важно как ваш internal код реализован, это важно техлиду вашей группы, максимум. А вам, как чистокодмену не важна архитектура, пока к вам не спустится архитктор и не спросит: а какого нахрен черта.
В этом и есть смысл SOLID. Если у вас актор из Spring.Boot начнет влиять на реализацию в Spring.Security - это нарушение SRP. Но, если у вас у какого то класса оказалось 100500 методов внутри Spring.Boot, вопросы конечно возникнут в сфере разделения функционала, но вопросы в сфере разделения ответственности - не будет.
Хоть принцип действительно называется single-responsibility principle (через дефис), но отвечает он не за функционал, а за актора: A module should be responsible to one, and only one, actor
Ну, почитайте источники, блин, а не наколенное использование:
Из всех принципов SOLID наиболее трудно понимаемым является принцип единственной ответственности (Single Responsibility Principle, SRP). Это, вероятно, обусловлено выбором названия, недостаточно точно соответствующего сути. Услышав это название, многие программисты решают: оно означает, что каждый модуль должен отвечать за что-то одно.
Самое интересное, что такой принцип действительно существует. Он гласит: функция должна делать что-то одно и только одно. Этот принцип мы используем, когда делим большие функции на меньшие, то есть на более низком уровне. Но он не является одним из принципов SOLID — это не принцип единственной ответственности. Традиционно принцип единственной ответственности описывался так:
Модуль должен иметь одну и только одну причину для изменения.
Программное обеспечение изменяется для удовлетворения нужд пользователей и заинтересованных лиц. Пользователи и заинтересованные лица как раз и есть та самая «причина для изменения», о которой говорит принцип. Фактически принцип можно перефразировать так:
Модуль должен отвечать за одного и только за одного пользователя или заинтересованное лицо.
К сожалению, слова «пользователь» и «заинтересованное лицо» не совсем правильно использовать здесь, потому что одного и того же изменения системы могут желать несколько пользователей или заинтересованных лиц. Более правильным выглядит понятие группы, состоящей из одного или нескольких лиц, желающих данного изменения. Мы будем называть такие группы акторами (actor). Соответственно, окончательная версия принципа единственной ответственности выглядит так:
Модуль должен отвечать за одного и только за одного актора.
К SRP принцип единой ответственности не имеет отношение. Под SRP понимается принцип единого ответственного. Это хотя часто взаимозависимые понятия, но они в корне разные.
Вы реально при помощи No-Code два числа складываете и думаете, что это хреново получается? Это же не из пушки по воробьям, это крылатой ракетой по микробу. В реальном no-code решении вы не будете через интерфейс складывать 2 числа, скорее всего у вас будет блок который уже выдает сложенные числа. Вы не будете на no-code вычислять простые числа, у вас уже будет блок с ускоренным решетом или тестом Ферми в готовых блоках, иначе вы не тот инструмент используете.
No-code это не построитель универсальных велосипедов, это быстрый клей между велосипедами, и ему, в реальности, не нужно ставить задачи уровня сложить 2 числа. Его удел: взять блоки данных оттуда и отсюда, провести стандартную операцию над этими блоками и положить в третье место. Если ваша задача выше, чем стандартная задача этого инструмента, то вам нужен не этот инструмент. Может задача даже не этого уровня, а стоит посмотреть на low-code решения или расчехлить свой питон через ChatGPT.
Та же Tilda или Wix занимает очень жесткую нишу - сделать лендинг. И реально сделать на нем лендинг занимает 1-2 часа при нормальном контенте. Надо больше - есть готовые блоки: мини-магазин, платежки, формы опроса/подписок. Надо ещё более специфическое - вам нужно уходить в специализированные low-code системы: Ecwid, Umi, Bitrix, WordPress. За х10-х100 денег и времени. Нужно ещё более специфическое? Идти заказывать свой проект на аутсорсе. За х100-∞ денег и времени.
Для каждой задачи есть инструмент, а для каждого инструмента — задача
Есть куча мест когда тесты, особенно в CI просто не нужны и даже вредны:
У тебя в проекте может не быть автоматических тестов для API. Напримр, в вашей команде уровень контрактных тестов находится на стороне аццептора, а на стороне инициатора только проверка на изменение сваггера. Сответственно, писать дополнительный код, который тебе нужен, который увеличит тест-таймы в процессе разработки, и удалить его после разработки, так как не пропускает QA, только для того чтобы понять полный пайплайн какого то процесса - ну так себе.
Ты разрабатываешь какую то часть пайплайна БП. Но, в этом пайплайне есть ещё куча апишек, которые тебе надо дернуть для того чтобы утилизировать артефакты тестирования. В CI это завязано на то что на регрессе просто создается база с нуля. Но в ручном тестировании каждый раз создавать тестовое окружение с 0 это
ебудатьможнооверкиллУ тебя нет полной документации к апи, и код тебе не дают. Для исследований писать вечно зеленые тесты - ну, ой...
И ещё десяток
Всё нормально: не нравится цена - съезжай в более спокойный район. Так как при очень большом количестве чудаков, ты рано или поздно сам станешь водить машину как чудак. Иначе тебе машину разобьет очередной джигит
Походу, вайб-кодинг — это когда ты продукт-овнер, тимлид, аналитик и кюа в одном лице, а ИИ у тебя заменяет 2-х джунов под опиоидами в твоей команде.
Прикольно, конечно, но:
Если посмотреть на app/routes.py, то понятно, что такое мы поддерживать дальше не будем.Очень много дубликатов, нарушены кучи практик программирования.
Расширять тоже, проще переписать
Используются устаревшие технологии вроде бутстрапа и jq
три недели по паре часов, это 30 часов. Я бы уже напрягся если бы такое выдали дольше, чем через 8 часов от разработчика уровня джун+.
С другой стороны. Ну есть, предположим у "мойщика окон" лишние 200 баксов и желание упорядочить свои фотки, за одно и с тимлидством/менторством в минималках познакомится.
Очень часто когда я вижу статьи что SOLID не подходит, почти всегда то рассматривается с точки зрения Объектно‑Ориентированного Программирования. Хотя книга, где впервые использовались эти понятия, даже называется как Principles Of OO Design.
Ребят! Пока вы на SOLID смотрите как на паттерны программирования, а не принципы проектирования, у вас будет взрыв головного мозга. Не делайте так! Это не про код, это про квадратики (модули).
В начале 00х ООП был на первом уровне проектирования, когда 90% программных продуктов в реальности заключались в 5–6 классах, небольшом конфиге(программе) над RAPID и десятке DTO. Сейчас это уровень микросервиса. А проектирование заключается в умении состыковать несколько микросервисов. Поэтому, если в 00х принципы SOLID надо было применять к ОО, то сейчас эти принципы надо применять к схеме диаграммы микросервисов. Время поменялось. У нас сейчас нет времени заниматься чистотой внутри микросервисов — надо заниматься чистотой архитектуры.
обмазываться классами вовсе не обязательно. можно просто выставить этих 3х-летних сениоров на мороз )
Немного капитана: тот код который легко покрыть тестами скорее всего не эффективный )
tl;dr: они худые потому как двигаются много и не жрут, а двигаются и не жрут потому как худые. ну или больные и скоро сдохнут. а ты жирдяй потому как не двигаешься и жрешь и тоже сдохнешь но не скоро.
судя по импотенс фичей: с высокой вероятностью после смены исполнительной власти.
и смогли спасти только 9.5
ну, в связи с тем, что положение об аттестации утратило силу, то чуть выше вон есть ссылка на письмо роструда:
получается, что работодатель сам создает приказ о виде аттестации и способах его прохождения.
Трудовой договор расторгнут в связи с несоответствием работника занимаемой должности вследствие недостаточной квалификации, подтвержденной результатами аттестации, пункт 3 части первой статьи 81 Трудового кодекса Российской Федерации
Чисто для себя интересно: а почему? У нас есть 81 статья УК РФ (про аттестацию). Если до 20 года можно ещё было натянуть то, что любая аттестация не соответствует нормам аттестации, то с конца 20 года Положение о порядке проведения аттестации отменили и коммерческие фирмы могут самостоятельно натягивать тесты типа PR, 360 и прочие матрицы на понятие аттестации или, принимать решение о проведении аттестации, на основании этих процедур. Там конечно увольнение не по соглашению, но и не по сокращению, с очень интересной записью в трудовой.
Прям передернуло. Меня вот это всегда напрягает на МП когда товар будет в стекле: урбичи, сбитни, масла, ведь с высокой (для меня) вероятностью они не приедут в целостности. 3 из 10 последних заказов в стекле - битых. А ещё запачкает заказы других покупателей и на тебя как на врага народа смотрит владелец ПВЗ. Почему не поменять упаковку на пластик? Я конечно понимаю что микропластик вреден, хранится меньше, выглядит дешевле, но не так вреден как отбитое стекло или запачканные коробки.
Не хотите пластик, можно в жестянках, в алюминии тащить, но маркетплейсы и стекло это два несочетаемых слова
Ну во первых, не я путаюсь, а выше большая цитата из книги Чистая архитектура уже указанного автора. И если у вас есть возражения к автору, то у меня для вас плохие риторические новости.
Во вторых, мы не говорим класс в контексте SRP. Мы говорим о модуле. В модуле может быть несколько классов. А может быть и один. И если вам для реализации печати нужен какой то свой класс - то делайте его, но не называйте это следованию принципа SRP. Можете назвать это принципом разделения функционала, или принципом единообразия реализации, но не SRP. И да, если классу надо уметь себя распечатывать, то надо просто добавить в него метод print, а не создавать класс [ObjectType]Printer. За исключением, если ваш бухгалтерский отчет должен распечатывать, например, специалист по закупкам, в своем, закупочном, формате. Тогда, да, согласно SRP мы выделяем отдельный метод для формирования нового класса BookingReportPurchasing, из нового модуля, и отдельный метод print в этом классе (ну по вашему отдельный класс BookingReportPurchasingPrinter), а ответственность за аналитику модуля "возлагаем" на специалиста по закупкам.
Так что не надо чистый код путать с чистой архитектурой. Это 2 раздельных уровня. Архитектору, часто, не важно как ваш internal код реализован, это важно техлиду вашей группы, максимум. А вам, как чистокодмену не важна архитектура, пока к вам не спустится архитктор и не спросит: а какого нахрен черта.
В этом и есть смысл SOLID. Если у вас актор из Spring.Boot начнет влиять на реализацию в Spring.Security - это нарушение SRP. Но, если у вас у какого то класса оказалось 100500 методов внутри Spring.Boot, вопросы конечно возникнут в сфере разделения функционала, но вопросы в сфере разделения ответственности - не будет.
Хоть принцип действительно называется single-responsibility principle (через дефис), но отвечает он не за функционал, а за актора: A module should be responsible to one, and only one, actor
Ну, почитайте источники, блин, а не наколенное использование:
В той же английской вики написано всё верно
К SRP принцип единой ответственности не имеет отношение. Под SRP понимается принцип единого ответственного. Это хотя часто взаимозависимые понятия, но они в корне разные.
и запомните: хотя чай и коньяк одного цвета, но если вы "прихрюкните" после глотка и занюхаете кусочком шоколада, поверить что у вас чай - малореально
Вы реально при помощи No-Code два числа складываете и думаете, что это хреново получается? Это же не из пушки по воробьям, это крылатой ракетой по микробу. В реальном no-code решении вы не будете через интерфейс складывать 2 числа, скорее всего у вас будет блок который уже выдает сложенные числа. Вы не будете на no-code вычислять простые числа, у вас уже будет блок с ускоренным решетом или тестом Ферми в готовых блоках, иначе вы не тот инструмент используете.
No-code это не построитель универсальных велосипедов, это быстрый клей между велосипедами, и ему, в реальности, не нужно ставить задачи уровня сложить 2 числа. Его удел: взять блоки данных оттуда и отсюда, провести стандартную операцию над этими блоками и положить в третье место. Если ваша задача выше, чем стандартная задача этого инструмента, то вам нужен не этот инструмент. Может задача даже не этого уровня, а стоит посмотреть на low-code решения или расчехлить свой питон через ChatGPT.
Та же Tilda или Wix занимает очень жесткую нишу - сделать лендинг. И реально сделать на нем лендинг занимает 1-2 часа при нормальном контенте. Надо больше - есть готовые блоки: мини-магазин, платежки, формы опроса/подписок. Надо ещё более специфическое - вам нужно уходить в специализированные low-code системы: Ecwid, Umi, Bitrix, WordPress. За х10-х100 денег и времени. Нужно ещё более специфическое? Идти заказывать свой проект на аутсорсе. За х100-∞ денег и времени.
Для каждой задачи есть инструмент, а для каждого инструмента — задача