Хороший тимлид — не обязательно лучший инженер. Иногда это тот, кто даёт инженерам спокойно работать. Банально звучит, на практике — редкость.
Это называется не тимлид а менеджер. А если он менеджер, то все-равно должен быть старший от разработки, можно называть как угодно, хоть ведущий разраб хоть техлид, иначе однажды команда просто разосрется из за природы разных мнений и опыта.
По моим данным — команда без кодящего тимлида выдаёт на 41% больше. Может, мой случай — исключение, и мне просто повезло с Серёгой. Но мне кажется, мы неправильно понимаем, что такое лидерство в разработке.
Два сеньора с противоположными точками зрения и тимлид который 3 года не кодит...
С 2020-го пошло по-другому. Бизнес стал лучше понимать, за что он платит.
Спасибо, поржал. Как раз таки года с двадцатого, произошел бум найма разработчиков когда бизнес окончательно перестал понимать кого он вообще нанимает, главное было закрывать вакансии. Именно тогда пошел массовый найм выпускников инфо-цыганских курсов, найм старших помощников младших конюхов и прочих мега важных ролей. Дада, бизнес стал очень сильно лучше разбираться.
Сегодня senior — это уже не титул и не количество лет в профессии.
Хотите совет? Когда пишете статью про senior сегодня, удостойте читателей чести дать определение тому что такое хотя бы вообще senior, не говоря уже о том что это есть сейчас. Иначе получается что Вы сами придумали - сами разоблачили.
PS спойлер, senior - это название сетки зп в определенной компании, не более
Статья на тему: Фантастические факты и места где они обитают или как притянуть за уши все что угодно.
Например, API метаинформации можно сделать на Java Spring за месяц, хотя на Python FastAPI разработка займёт неделю.
Удобно, сами придумали факт, сами же на его основе него сделали выводы. Мне прям любопытно стало, я понимаю если бы Вы написали что на Python на 10% ну 15% быстрее чем на Java, но писать что на Python приложение будет написано x4 это прям сильно. У меня прям фантазии не хватает что будет делать Java разраб еще 3 недели.
Оверинжинирингом: преждевременно заложите или оптимизируете то, что пока еще не нужно, то, что ещё не болит.
Если в рамках стратегии - "когда у проекта настанут проблемы то я уже буду работать в другом месте и это будет не моя проблема", то норм.
Python 30–45 дней.
Java 40–55 дней.
Go 60–90 дней.
Время разработки фичей на Python возьмем за 1, на Go — чуть побольше, на Java — больше всего.
Сами придумали - сами доказали.
Чем больше объём кода, тем выше когнитивная нагрузка
Каждая строка кода — потенциальное место для ошибки
Меньше кода — меньше багов
Меньше кода – быстрее изменения
Удивительно, как же все просто в этой жизни. Зачем в Python тогда добавили типизацию? Сколько лишнего текста. Выходит что язык стал только хуже?
Видно, что Python-разработчики получают меньше всех, Go-разработчики — больше всех, разработчики на Java тоже неплохо живут.
Выглядит так, как будто бы Python еще и дешевле, но на деле - то что там ниже зп показатель что там больше всего разработчиков и следовательно качество по больнице ниже а следовательно и производительность. Странно это не учитывать.
Кстати, Go так популярен только в России — может быть, потому, что у нас экосистем очень много.
Go стал популярен по двум основным причинам. Во-первых, это палочка выручалочка для time-to-market приложений на Python/PHP/Ruby которые превратились в проблему когда компания выросла. Во-вторых, это палочка-выручалочка для HR так как в этот язык можно быстро перевербовать из любого другого.
Исследование Рэя Байшахи
Исследование Биссьянде
2014 и 2013 годы, актуальность зашкаливает. Но это не проблема когда хочется факты подтянуть за уши.
Мы должны не топить за свой любимый язык, а выбирать наиболее рациональный.
При этом в статье все подогнано под Python.
Рынок труда требует от нас, чтобы мы развивались в сторону T-shaped, владели несколькими языками и компетенциями, тесты писали, выступали, как системные аналитики, особенно техлиды.
Нет, это не рынок, это эффективные менеджеры придумывают очередные инновационные решения несуществующих проблем, сложности от которых будет решать бизнес потом, когда инноваторы будут работать уже на другом месте.
А теперь к реальности. Неожиданно, разработчики - это не стенографистки и разработка проекта это не набор теста на скорость.
По большей части что Python что Java что Go - это языки со сборкой мусора и рантаймом и как следствие, в реальности, по способу использования и скорости разработки на них не так чтобы сильно отличаются, учитывая что в Python последнее время популярна типизация с одной стороны и даже языки типа Java стали довольно сахарными то и темболее. Не нужно рассказывать сказки про x3-x4.
Язык это просто инструмент. Разработчик большую часть времени думает как решать задачу, читает код, документацию, общается а не лупит по клавишам. В реальности на скорость разработки больше всего влияют процессы, хорошая аналитика и опыт разработчика. На выбор языка в первую очередь будет влиять текущая экосистема компании, состояние рынка а не мифические показатели скорости разработки.
Поискав в дикой природе, чтобы посмотреть на реальные размеры, особо то и не нашёл самостоятельные CLI написанные на Шарпе.
Ну я не о том что C# подходящий инструмент для написания полноценного целевого CLI, а в контексте того что автор утверждал что Java экосистема восхитительна по сравнению с "ничтожной экосистемой" C#, на что я и предложил попробовать реализовать банальный автономный CLI на Java и на CLI и потом поделиться опытом насколько такая базовая задача как CLI на Java будет просто сделано и посмотреть насколько эти утверждения хоть как то бьются с реальностью.
Внезапно в Шарпе с этим не лучше. Или не кроссплатформенный net4 или многомегабайтный монстр
Ну я не про то что в шарпе или в Go или еще в каком то языке который не Си/С++/Rust большой бинарник. Я про то что в C# очень просто создать консольное приложение которое собирается в автономный бинарник, сделать это можно секунд за 5, и есть библиотеки разные удобные, в отличии от Java где такая тривиальная история как консольное приложение превращается в муку.
Не очень понимаю что значит как язык хуже? Ну вот к примеру то что Go вышел в 2009 году и в нем уже были горутины, а в Java мире виртуальные потоки появились только в 2023 году (спустя 14 лет), это видимо показатель того что Java лучше как язык?
хотя они пытаются пройти по её пути
По какому ее пути? Добавить дженерики со стиранием типов? Да вроде бы нормальные добавили а не те о которых джава последние 10 лет избавиться не может. По какому ее пути тогда? Сейчас больше похоже на обратное - в Java добавили виртуальные потоки напоминающие горутины, потихоньку отходят от ООП, плюс больше двигаются в сторону AOT. Больше похоже что Java в сторону Go идет.
А приводит это к тому, что экосистема C# — с гулькин нос. У тебя есть несколько крутых фреймворков имени Microsoft, несколько известных опенсорсных проектов... и всё. Нет такого, что как в Java или JS/Node ты сидишь и час выбираешь, какую бы библиотеку из сотен использовать, чтобы сложить два числа.
Дада, знаменитые сотни библиотек по разработке игр, десктопов фронтендов и прочего. Куда там "никчемной" экосистеме C# с Unity, Godot, Avalonia, всякими Blazor и кучей десктопной и прочей обвязкой, куда этому всему до могучей экосистемы Java состоящей по большей части из библиотек на тему Spring и все что с ним связано. Еще было бы не плохо в подтверждение своих слов показать насколько весело в Java обстоят дела с разработкой обычного автономного CLI приложения. Ну так, для иллюстрации как все "хорошо" в Java мире.
Прежде чем поливать говном другие языки и экосистемы, неплохо было бы в них для начала подразобраться, так для галочки хотя бы.
У многих компаний есть свои карты компетенций, где расписано на какой грейд какие технологии нужны. К сожалению, эти карты от компании к компании сильно отличаются, как и предлагаемая зп.
Потому что все это субъективщина.
Так или иначе нужен инструмент, который бы усреднял требования и давал представление о ситуации.
Вопрос в том кому нужен? Работодателям очевидно не нужен так как никто в этом направлении как не чесался так и не чешется особо.
Ну окей, нужен инструмент, как будем строить систему грейдов? По "стандартной лестнице: Junior, Middle, Senior" ? Ну ок, джун - тот кто еще не самостоятельный а мид тот кто уже самостоятельный а сеньор это вообще кто? Абстрактный опытный разработчик? Ну ок. А мид который еще не сеньор но уже не простой рядовой разработчик это кто? Сеньор с 5 годами опыта и с 10 годами это одни и тот же грейд или нужно делить еще на 3-5 подгрейдов? Итого получим 6-10 грейдов. Дальше выясняется что обычно с уровня условного сеньора идет специализация, когда одни хорошо разбирается в БД, другой в DevOps, третий в многопоточности, четвертый проектирует неплохо а пятый просто решала. Как эти критерии рассчитывать, делать сетку навыков под каждую возможную специализацию? А как оценивать пересечение специализаций когда человек несколько специальностей знает? А как оценить специалиста с хорошей базой и гибким мышлением, который по новой технологии доки за вечер прочитает и на коленке сделает? Ну и наконец, будут ли оцениваться навыки вызывающие споры? Ну например, у кого-то есть навыки в продвинутом ООП, DDD SOLID, чистых архитектурах и прочем а кто-то считает это бесполезным и даже вредным. Есть еще функциональное программирования. Как такое оценивать, чтобы привести всех к общему знаменателю? Кто-то гордится что он чистый код пишет а кто-то пишет эффективный. Как быть?
Вердикт: Грейд — это ваша способность управлять сложностью, а не стаж в трудовой книжке.
Грейд - это ваша способность зарабатывать деньги.
Можно долго пытаться убеждать себя что в грейдах есть какой то смысл, корреляция с опытом, управлением какой-то сложностью и прочее. Но на деле грейд - это не более чем навык подстраиваться под хотелки конкретной компании, такие как: умение хорошо собеседоваться, умение дружить с руководством и иметь своих людей на правильных позициях, умение подстраиваться под внутренние требования, какими бы абсурдными они не были, для того чтобы получать больше денег.
Да хотелось бы чтобы корреляция с опытом была но нет в современных компаниях этого нет уже давно.
А как только начинаем смотреть МКД, нифига ж себе, оказываются есть архитектурные нормы и требования.
Нюанс в том что SOLID это не нормы и не требования. Это частное мнение Роберта Мартина, изложенное в его книгах и которое, по воле случая, завирусилось. Никакого отношения к доказанной эффективности, доказуемости и уже тем более какие то стандартам разработки по факту это не имеет.
А если у вас более сложная архитектура?
Например стандартная библиотека какого-нибудь популярного языка программирования. Где в среднем нарушение SOLID во всех позах поставлено на поток. Интересно почему? Вроде бы не глупые люди должны таким заниматься.
Классный ответ, правда и ошибки С++, это тоже "проблемы разработчика, а не языка".
Проблема Rust в том, что он в принципе не может реализовать некоторые алгоритмы без вставок unsafe кода.
У Вас такое развлечение, носиться из статьи в статью с одними и теми же заезженными до дыр тезисами, о том что если язык не гарантирует вам абсолютную безопасность во всем то он ничем не лучше языка который при любом неловком движении отстреливает вам конечности?
Проблема такого подхода в том что если в Rust все это появится то Вы начнете жаловаться на то что на льду поскользнулись при этом пишете на Rust а он плохой такой вроде бы вам безопасность гарантировал.
И таких людей не переубедишь. Приводи им примеры или нет - свой опыт им не передашь. Да и слушать у нас как-то стало не модно".
Чисто для интереса. Вот Вы так сокрушаетесь что людей не переубедить. А Вам никогда не приходила мысль, хотя бы на долю секунды, что чисто гипотетически Вы можете быть не правы?
Поэтому я решил попробовать доказать вам, что принципы разработки (почти как законы физики)
А если ли у этих принципов явные и понятные всем а главное однозначные формулировки? Ну например что такое ответственность а как ее рассчитать для конкретного случая? Есть ли доказательства эффективности применимости данных принципов отличные от субъективного восприятия? Или основной показатель эффективности - это "я считаю оно работает у меня а значит работает у всех"?
Для дрели: кнопка под указательным пальцем должна управлять только оборотами. Нельзя на неё вешать переключение на перфорацию.
Не скажу за дрель, но в схожих условиях в оружии, спусковой крючок часто используют и для стрельбы и для переключения ведения режимов огня и как предохранитель и ничего.
L - Liskov Substitution Principle (Принцип подстановки Барбары Лисков). Классы-наследники не должны противоречить базовому классу.
Советую изучать лучше данный принцип. Там нет ничего про классы.
А теперь вопрос - сколько ещё будут держаться эти принципы? Через сколько лет вы захотите чтобы производители дрелей перестали этого придерживаться?
И очень хорошо, что инженеры когда проектируют различные решения, не забивают себе голову такими глупостями и догмами а проектируют реализацию исходя из требований и собственной смекалки.
Яркий пример из Второй мировой - зенитная артиллерия. Эта та которая по самолетам стреляет. Вместо того чтобы всякие единственные ответственности соблюдать, инженеры сделали орудие которое может стрелять и по земле а более того были сделаны противотанковые снаряды. И более того, впоследствии оказалось что зенитное орудие едва ли не лучшее противотанковое средство. После чего в Германии и СССР стали ставить слегка модифицированные зенитные орудия на танки. А вот если бы знали про SOLID не страдали бы видиом фигней и делали зенитные орудия которые могут стрелять только по самолетам.
Имхо, гораздо легче воспринимать и читать код, когда разработчик позаботился о том, чтобы завернуть его в класс.
Гораздо проще читать код, когда в нем нет ничего лишнего, например класса, который используется не по прямому назначению а только для того чтобы в него что-то завернуть.
кстати, эту же идею Вы можете обнаружить в книге "Чистый Код" от Роберта Мартина
Лучше, вместо того чтобы читать старые книги сомнительного содержания, почитать свежий блог автора этой книги. Откроете для себя много нового, например что у него сейчас любимый язык на котором он пишет это Clojure, и что он за минималистичность простоту и про прочее за все хорошего против всего плохого.
У Вас одна публичная функция а значит для любого пользователя класса - у Вас только одна функция. То что Вы написали внутри 10-20 приватных для своего удобства это никак не меняет семантики - можете все скомпоновать в одну или разбирать на 1000, для пользователя класса ничего не измениться. Более того, если Вы перепишите класс на обычную функцию которая будет вызывать вспомогательные функции, по большей части ничего не измениться, потому что никакие особые свойства объектов не используете.
Единственный публичный метод. Вся работа с сервисом ведётся через метод call. Избавляемся от проблемы когда разработчики начинают придумывать run-ы, execute-ы, process-ы и т.д.
Спасибо за комментарий! Возможно, тут возникло недопонимание - в классе может быть несколько методов, просто публичный - только один - и это метод call.
Вы можете сделать хоть тысячу маленьких функций, а можете собрать все воедино и результат у вас будет один и тот же и изменится не может, потому что функция на самом деле одна а так как все остальные функции приватные то для пользователя Вашего класса их нет и быть не может.
Объект - это история про некое состояние, про применение методов к этому состоянию для его изменения или создания новых. У Вас, класс(объект) - это просто банка с одной функцией. Если Вы вытащите функцию из банки - ничего не поменяется но станет чуть чуть проще так как останеться разделение на простые функции и простые данные. Подход - в функцию передается и возвращается DTO сильно проще чем Ваш, не нужно объяснять кому-то что это вроде бы сервис но на самом деле команда с состоянием, а еще там может быть только одна функция и она должна быть такой то, не нужно объяснять не нужно следить за таким стилем чтобы никто не начал еще функции публичные писать, не нужно никого учить и объяснять почему класс должен имитировать функцию. Будьте проще - просто используйте функции и не нужно будет ничего объяснять и проверять.
Единая ответственность. Каждый сервис реализует законченный кусок бизнес-логики — от простого создания объекта до комплексных операций с вызовами других сервисов или внешних API.
Единственный публичный метод. Вся работа с сервисом ведётся через метод call. Избавляемся от проблемы когда разработчики начинают придумывать run-ы, execute-ы, process-ы и т.д.
Вы определенно двигаетесь в правильном направлении. Позвольте, сэкономлю Вам немного времени. У Вас не сервис а команда и она Вам не нужна. Если Вам нужен класс с одной функцией - это значит что класс здесь в принципе не нужен. Выкиньте ненужное, оставьте старую добрую функцию и все еще упроститься.
Это называется не тимлид а менеджер. А если он менеджер, то все-равно должен быть старший от разработки, можно называть как угодно, хоть ведущий разраб хоть техлид, иначе однажды команда просто разосрется из за природы разных мнений и опыта.
Два сеньора с противоположными точками зрения и тимлид который 3 года не кодит...
Спасибо, поржал. Как раз таки года с двадцатого, произошел бум найма разработчиков когда бизнес окончательно перестал понимать кого он вообще нанимает, главное было закрывать вакансии. Именно тогда пошел массовый найм выпускников инфо-цыганских курсов, найм старших помощников младших конюхов и прочих мега важных ролей. Дада, бизнес стал очень сильно лучше разбираться.
Хотите совет? Когда пишете статью про senior сегодня, удостойте читателей чести дать определение тому что такое хотя бы вообще senior, не говоря уже о том что это есть сейчас.
Иначе получается что Вы сами придумали - сами разоблачили.
PS спойлер, senior - это название сетки зп в определенной компании, не более
Статья на тему: Фантастические факты и места где они обитают или как притянуть за уши все что угодно.
Удобно, сами придумали факт, сами же на его основе него сделали выводы. Мне прям любопытно стало, я понимаю если бы Вы написали что на Python на 10% ну 15% быстрее чем на Java, но писать что на Python приложение будет написано x4 это прям сильно. У меня прям фантазии не хватает что будет делать Java разраб еще 3 недели.
Если в рамках стратегии - "когда у проекта настанут проблемы то я уже буду работать в другом месте и это будет не моя проблема", то норм.
Сами придумали - сами доказали.
Удивительно, как же все просто в этой жизни. Зачем в Python тогда добавили типизацию? Сколько лишнего текста. Выходит что язык стал только хуже?
Выглядит так, как будто бы Python еще и дешевле, но на деле - то что там ниже зп показатель что там больше всего разработчиков и следовательно качество по больнице ниже а следовательно и производительность. Странно это не учитывать.
Go стал популярен по двум основным причинам. Во-первых, это палочка выручалочка для time-to-market приложений на Python/PHP/Ruby которые превратились в проблему когда компания выросла. Во-вторых, это палочка-выручалочка для HR так как в этот язык можно быстро перевербовать из любого другого.
2014 и 2013 годы, актуальность зашкаливает. Но это не проблема когда хочется факты подтянуть за уши.
При этом в статье все подогнано под Python.
Нет, это не рынок, это эффективные менеджеры придумывают очередные инновационные решения несуществующих проблем, сложности от которых будет решать бизнес потом, когда инноваторы будут работать уже на другом месте.
А теперь к реальности. Неожиданно, разработчики - это не стенографистки и разработка проекта это не набор теста на скорость.
По большей части что Python что Java что Go - это языки со сборкой мусора и рантаймом и как следствие, в реальности, по способу использования и скорости разработки на них не так чтобы сильно отличаются, учитывая что в Python последнее время популярна типизация с одной стороны и даже языки типа Java стали довольно сахарными то и темболее. Не нужно рассказывать сказки про x3-x4.
Язык это просто инструмент. Разработчик большую часть времени думает как решать задачу, читает код, документацию, общается а не лупит по клавишам. В реальности на скорость разработки больше всего влияют процессы, хорошая аналитика и опыт разработчика. На выбор языка в первую очередь будет влиять текущая экосистема компании, состояние рынка а не мифические показатели скорости разработки.
Совет на будущее - если пользуетесь гугл-транслейтом или нейронкой, чисто для интереса, перепроверяйте полученный результат.
И да, делать выводы по
Thread.sleepтакое себе, можно не полениться и все-таки хотя бы побросать запросы на какой никакой сервер.Ну я не о том что C# подходящий инструмент для написания полноценного целевого CLI, а в контексте того что автор утверждал что Java экосистема восхитительна по сравнению с "ничтожной экосистемой" C#, на что я и предложил попробовать реализовать банальный автономный CLI на Java и на CLI и потом поделиться опытом насколько такая базовая задача как CLI на Java будет просто сделано и посмотреть насколько эти утверждения хоть как то бьются с реальностью.
Минимальный консольный Hello world для win-64:
go 1.25.0
1 559 КБ
c# native aot net10.0
905 КБ
Ну я не про то что в шарпе или в Go или еще в каком то языке который не Си/С++/Rust большой бинарник. Я про то что в C# очень просто создать консольное приложение которое собирается в автономный бинарник, сделать это можно секунд за 5, и есть библиотеки разные удобные, в отличии от Java где такая тривиальная история как консольное приложение превращается в муку.
Да не. В C# там более менее норм, бинарник примерно как у Go
Не очень понимаю что значит как язык хуже? Ну вот к примеру то что Go вышел в 2009 году и в нем уже были горутины, а в Java мире виртуальные потоки появились только в 2023 году (спустя 14 лет), это видимо показатель того что Java лучше как язык?
По какому ее пути? Добавить дженерики со стиранием типов? Да вроде бы нормальные добавили а не те о которых джава последние 10 лет избавиться не может. По какому ее пути тогда? Сейчас больше похоже на обратное - в Java добавили виртуальные потоки напоминающие горутины, потихоньку отходят от ООП, плюс больше двигаются в сторону AOT. Больше похоже что Java в сторону Go идет.
Дада, знаменитые сотни библиотек по разработке игр, десктопов фронтендов и прочего. Куда там "никчемной" экосистеме C# с Unity, Godot, Avalonia, всякими Blazor и кучей десктопной и прочей обвязкой, куда этому всему до могучей экосистемы Java состоящей по большей части из библиотек на тему Spring и все что с ним связано. Еще было бы не плохо в подтверждение своих слов показать насколько весело в Java обстоят дела с разработкой обычного автономного CLI приложения. Ну так, для иллюстрации как все "хорошо" в Java мире.
Прежде чем поливать говном другие языки и экосистемы, неплохо было бы в них для начала подразобраться, так для галочки хотя бы.
Потому что все это субъективщина.
Вопрос в том кому нужен? Работодателям очевидно не нужен так как никто в этом направлении как не чесался так и не чешется особо.
Ну окей, нужен инструмент, как будем строить систему грейдов? По "стандартной лестнице: Junior, Middle, Senior" ? Ну ок, джун - тот кто еще не самостоятельный а мид тот кто уже самостоятельный а сеньор это вообще кто? Абстрактный опытный разработчик? Ну ок. А мид который еще не сеньор но уже не простой рядовой разработчик это кто? Сеньор с 5 годами опыта и с 10 годами это одни и тот же грейд или нужно делить еще на 3-5 подгрейдов? Итого получим 6-10 грейдов. Дальше выясняется что обычно с уровня условного сеньора идет специализация, когда одни хорошо разбирается в БД, другой в DevOps, третий в многопоточности, четвертый проектирует неплохо а пятый просто решала. Как эти критерии рассчитывать, делать сетку навыков под каждую возможную специализацию? А как оценивать пересечение специализаций когда человек несколько специальностей знает? А как оценить специалиста с хорошей базой и гибким мышлением, который по новой технологии доки за вечер прочитает и на коленке сделает? Ну и наконец, будут ли оцениваться навыки вызывающие споры? Ну например, у кого-то есть навыки в продвинутом ООП, DDD SOLID, чистых архитектурах и прочем а кто-то считает это бесполезным и даже вредным. Есть еще функциональное программирования. Как такое оценивать, чтобы привести всех к общему знаменателю? Кто-то гордится что он чистый код пишет а кто-то пишет эффективный. Как быть?
Грейд - это ваша способность зарабатывать деньги.
Можно долго пытаться убеждать себя что в грейдах есть какой то смысл, корреляция с опытом, управлением какой-то сложностью и прочее. Но на деле грейд - это не более чем навык подстраиваться под хотелки конкретной компании, такие как: умение хорошо собеседоваться, умение дружить с руководством и иметь своих людей на правильных позициях, умение подстраиваться под внутренние требования, какими бы абсурдными они не были, для того чтобы получать больше денег.
Да хотелось бы чтобы корреляция с опытом была но нет в современных компаниях этого нет уже давно.
Надеюсь в резюме у себя Вы такое не указываете
Нюанс в том что SOLID это не нормы и не требования. Это частное мнение Роберта Мартина, изложенное в его книгах и которое, по воле случая, завирусилось.
Никакого отношения к доказанной эффективности, доказуемости и уже тем более какие то стандартам разработки по факту это не имеет.
Например стандартная библиотека какого-нибудь популярного языка программирования. Где в среднем нарушение SOLID во всех позах поставлено на поток. Интересно почему? Вроде бы не глупые люди должны таким заниматься.
У Вас такое развлечение, носиться из статьи в статью с одними и теми же заезженными до дыр тезисами, о том что если язык не гарантирует вам абсолютную безопасность во всем то он ничем не лучше языка который при любом неловком движении отстреливает вам конечности?
Проблема такого подхода в том что если в Rust все это появится то Вы начнете жаловаться на то что на льду поскользнулись при этом пишете на Rust а он плохой такой вроде бы вам безопасность гарантировал.
Чисто для интереса. Вот Вы так сокрушаетесь что людей не переубедить. А Вам никогда не приходила мысль, хотя бы на долю секунды, что чисто гипотетически Вы можете быть не правы?
А если ли у этих принципов явные и понятные всем а главное однозначные формулировки? Ну например что такое ответственность а как ее рассчитать для конкретного случая? Есть ли доказательства эффективности применимости данных принципов отличные от субъективного восприятия? Или основной показатель эффективности - это "я считаю оно работает у меня а значит работает у всех"?
Не скажу за дрель, но в схожих условиях в оружии, спусковой крючок часто используют и для стрельбы и для переключения ведения режимов огня и как предохранитель и ничего.
Советую изучать лучше данный принцип. Там нет ничего про классы.
И очень хорошо, что инженеры когда проектируют различные решения, не забивают себе голову такими глупостями и догмами а проектируют реализацию исходя из требований и собственной смекалки.
Яркий пример из Второй мировой - зенитная артиллерия. Эта та которая по самолетам стреляет. Вместо того чтобы всякие единственные ответственности соблюдать, инженеры сделали орудие которое может стрелять и по земле а более того были сделаны противотанковые снаряды. И более того, впоследствии оказалось что зенитное орудие едва ли не лучшее противотанковое средство. После чего в Германии и СССР стали ставить слегка модифицированные зенитные орудия на танки. А вот если бы знали про SOLID не страдали бы видиом фигней и делали зенитные орудия которые могут стрелять только по самолетам.
Гораздо проще читать код, когда в нем нет ничего лишнего, например класса, который используется не по прямому назначению а только для того чтобы в него что-то завернуть.
Лучше, вместо того чтобы читать старые книги сомнительного содержания, почитать свежий блог автора этой книги. Откроете для себя много нового, например что у него сейчас любимый язык на котором он пишет это Clojure, и что он за минималистичность простоту и про прочее за все хорошего против всего плохого.
У Вас одна публичная функция а значит для любого пользователя класса - у Вас только одна функция. То что Вы написали внутри 10-20 приватных для своего удобства это никак не меняет семантики - можете все скомпоновать в одну или разбирать на 1000, для пользователя класса ничего не измениться. Более того, если Вы перепишите класс на обычную функцию которая будет вызывать вспомогательные функции, по большей части ничего не измениться, потому что никакие особые свойства объектов не используете.
Вы можете сделать хоть тысячу маленьких функций, а можете собрать все воедино и результат у вас будет один и тот же и изменится не может, потому что функция на самом деле одна а так как все остальные функции приватные то для пользователя Вашего класса их нет и быть не может.
Объект - это история про некое состояние, про применение методов к этому состоянию для его изменения или создания новых. У Вас, класс(объект) - это просто банка с одной функцией. Если Вы вытащите функцию из банки - ничего не поменяется но станет чуть чуть проще так как останеться разделение на простые функции и простые данные. Подход - в функцию передается и возвращается DTO сильно проще чем Ваш, не нужно объяснять кому-то что это вроде бы сервис но на самом деле команда с состоянием, а еще там может быть только одна функция и она должна быть такой то, не нужно объяснять не нужно следить за таким стилем чтобы никто не начал еще функции публичные писать, не нужно никого учить и объяснять почему класс должен имитировать функцию. Будьте проще - просто используйте функции и не нужно будет ничего объяснять и проверять.
Вы определенно двигаетесь в правильном направлении. Позвольте, сэкономлю Вам немного времени.
У Вас не сервис а команда и она Вам не нужна. Если Вам нужен класс с одной функцией
- это значит что класс здесь в принципе не нужен. Выкиньте ненужное, оставьте старую добрую функцию и все еще упроститься.