тут проблема в том, что они знают 3 времени, но используют 12. Так же как в русском мы знаем 6 основных падежей, но используем 15 (6 основных + 4 дополительных + 5 частных).
НДФЛ это федеральный налог в России. В России местная власть не заинтересована в НДФЛ потому что это не ее деньги, а федеральная не заинтересована потому что гораздо больше получает средств из других источников и в первую очередь от бизнесов
Ты путаешь классификацию налога и распределение налога. То что он регулируется федералами, не значит что оно идет в федеральный бюджет.
НДФЛ: 85% - в региональные бюджеты, 15% - в местные бюджеты. Несмотря на то, что это – федеральный налог. Правда, НДФЛ по повышенной ставке 15% идет в федеральный бюджет как целевой налог – на дополнительное финансирование для лечения детей с редкими и опасными заболеваниями. (с) первая ссылка с Пульса от 23 года
Есть куча мест когда тесты, особенно в 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
Был слабый ИИ, стал слабый ИИ с деменцией...
тут проблема в том, что они знают 3 времени, но используют 12. Так же как в русском мы знаем 6 основных падежей, но используем 15 (6 основных + 4 дополительных + 5 частных).
и тянем useTimeout...
Ты путаешь классификацию налога и распределение налога. То что он регулируется федералами, не значит что оно идет в федеральный бюджет.
Есть куча мест когда тесты, особенно в 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