Бессмысленно к этому апеллировать. Эта общемировая тенденция играет не в нашу пользу. Факт в том, что по ту сторону забора даже после всех деструктивных “общемировых тенденций” сегмент останется попросту шире, живей и насыщенней, чем у нас. На порядки шире. Вот и все.
У меня есть стойкое ощущение, что в описании к рейтингу сказано полправды, и на самом деле рейтинг отражает то, насколько доступны гражданам той или иной страны ресурсы, которые они хотят потреблять.
Иными словами, американцам от блокировки РТ - на порядки меньше удар по свободе ощущается, чем нам - от блокировки ютуба.
А я не понимаю, какой в 2026м еще остался смысл выстилать такие пространные пасты про какую то там ненависть... Это до СВО еще можно было капать на неокрепшие мозги подобным передергиванием, демагогией и игрой на эмоциях. А сейчас, лично я ненависти и презрения от бело-сине-белых релокантов в свой адрес насмотрелся на порядки больше, чем от сограждан и властей. Так что мозолька натерта.
Ничего с водителями не будет еще долго. Можно ИИ посадить за руль, но пресловутую ответственность за сбитых пешеходов или ДТП на него не возложишь. Сбойнет лидар там, или нейронку перемкнет в биас, и все... Кому тогда юридические претензии предьявлять? Нейронке?
Спор "ООП vs ФП vs ПП" бессмысленен и неконструктивен. Вообще, ИМХО, нет особого смысла выделять отдельные парадигмы, учитывая ту мультипарадигмальную солянку, которая используется по факту на местах. Гораздо интереснее история "императивная vs декларативная разработка".
Мерзотнее чтива давненько не видал. Вполне себе годная идея "будь проще" разбавлена абсолютно отвратительными тезисами, буквально вредными советами, которые могут быть поняты не так миллионом способов. По порядку:
Название переменных
Да, давайте прибьем все схемы обмена данными к идентичным структурам. Тот факт, что сервис обычно существует для того, чтобы данные преобразовывать, обрабатывать, работать с ними, а не просто оставаться тупым крудом, и то следствие, что преобразование данных легко влечет за собой изменение их структуры, вместе с именами и расположением полей - не, пошел я нахер, мы признаем только круды.
20 строк в методе, 200 строк в классе
Авторитетный источник занимается черепомерством в прямом эфире. Привести обоснования для приведенных цифр? Не, пошел я нахер, понятно.
Полиморфизм
Посмеялся от души над "обожаемым" примером. Автор и не знает, что еще в начале 2000х разрабы именно такой стиль кода классифицировали как "индусский".
Повторяемость кода
Очередной пучок черепомерства, которое никак не коррелирует с поддерживаемостью. Послушать таких, так выходит на джаве вообще нормальный код писать нельзя - джава же громозкая!
5.Слабая связанность
Я пойду дальше. После прочтения этого абзаца я пошлю нахер и автора, и людей, у которых весь код - это пары из interface Service -> class ServiceImpl. Эти люди совершенно некомпетентны в вопросах связности и декаплинга.
Юнит-тесты
А здесь идет пучок демагогии про юнит тесты. Как будто первый раз, мало TDD-шников до этого было. Целый абзац воды ниочем, зато звучит злободневно.
Системность
Очередная фиксация на крудах. Все есть круд. А что не круд, то под круд должно быть подогнанно, даже если это объективно не круд.
И напоследок.
Я полностью согласен с тем, что синьорность - это в первую очередь бизнесориентированность. Я отдаю себе отчет в том, что выеживаться в проектном коде неконструктивно. И скорее всего тот графовый алгос был действительно не к месту. Можно было бы в посте рассказать об этом всратом кейсе поподробнее. Собрать мотивацию тех людей кто принимал такие решения. Расписать последствия. И идея поста была бы донесена лучше, и чтиво было бы образовательнее. Но нет, какое еще "образовательное" начало - ведь заниматься дешевым поучательством с подменой всех понятий понятий так весело!
А чтобы за вредные советы сообщество не насадило на кол, влепим тэг "юмор". Кстати да - я душнила, юмор не понял.
Дело не в удобстве, дело в организации процесса. Польза от таких лонг ридов в первую очередь проявляется тогда, когда они ревьювятся вместе с кодом (иначе нет никакой гарантии что этому полотну текста вообще можно верить). Польза на ревью от этого двойная — во первых, ревьюерам не приходится гадать что означает та или иная ревью-дельта, вместо этого они сразу могут начать с чтения такой вот "документации", где оригинатор им все разъясняет, а потом сверять "что написано в доках" с тем "что написано в коде". Это резко увеличивает скорость и качество ревью. Во вторых, ревьюеры могут давать ремарки на "документацию", если им в ней что-то неясно. На выходе получается не просто проревьювленный код, а проревьювленный и полностью задокументированный солюшен.
Но если "документация" — в коммит мессагах, ревьюить ее становится резко сложнее. Мессаг не отредактировать без пересоздания коммита, а амендить коммиты на каждую ремарку от ревьюера — путь к косякам и ненависти.
ИМХО лучше такие лонг-риды писать в PR description чем в коммит мессаг, а в коммит мессаге оставлять просто краткое описание и обязательно ссылку на issue (по которой можно будет найти впоследствии PR). Коммит мессаг в разы тяжелее ревьювить и править ремарками чем PR description.
Ты так говоришь как будто эта ваша хваленая культура работает, ага. Если человек захочет переметнуться на темную сторону силы, он это сделает, и ничего вы, дельцы, ему не противопоставите. На каждом митинге он будет излучать энтузиазм, на каждом ассессменте он накатает себе 100500 достижений, на каждом код ревью он будет давать конструктивный фидбэк, на каждую ремарку у него будет контраргумент. Все тикеты он будет делать в срок, с тем уровнем качества, с которым будет возможно пройти код ревью. В общении он всегда будет позитивен, на пьянках — душой компании.
Любой косяк в процессе он повернет в свою пользу. Любую слабость он будет эксплуатировать, причем так, что никто не уличит его в токсичности ни в жизнь. Более того, он может даже не осознавать при этом что делает что-то плохое. А что — чего от него хотят, он делает вовремя и с надлежащим уровнем качества. В чем проблема?
ЗЫЖ я не оправдываю щас творцов если что. Я уже говорил что я не горжусь тем что являюсь оным. Но все же не надо все валить на одну сторону.
ИМХО пост был как раз по большей части именно о творце, который жалуется на себя же и себе подобных. Ведь признает же он в конце что:
это рай для инфантильных говнюков, которые не могут ничего, кроме дурацкого программирования.
и что
вчерашние парни из гаража не могут принять систему, в которой никому не нужно их творчество. Бизнесу нужен конвейер, превращающий айтемы из джиры в пулл реквесты, творчество тут только мешает.
Ну и в итоге "творцы" витают где то в облаках, называют требования клиентов "какими то странными хотелками", при этом для обычных людей странными выглядят именно они с их диалогами о том как запилить AbstractSingletonFactoryProvider поверх VisitorControllerObserverBean чтоб инжекции не поломались. А "дельцы", чтоб хоть как то держать "творцов" в узде под контролем и направить их усилия в конструктивное русло, придумывают всякую разную корпоративную культуру, только нихрена это не работает: молодые творцы стенают от HRов, которые их nullи проверять заставляют, а творцы, достигнувшие дзена, делают так:
Я стану самым отвратительным типом людей в индустрии. Скилл и гонор как у рок-звезды, при этом ни на секунду не верит в то, что делает. Выхлоп, как от пассажира. Влюблённый в технологии, но никогда не делает больше, чем просят. Самый крутой чувак в любой компании, папа ведущего разработчика, тот-кого-берут-на-совет-директоров. Почти Линус Торвальдс, только без линукса и вклада в прогресс. Мой скилл даст мне право распоряжаться жизнью и смертью, а довольное стадо поклонников будет говорить, что так и должно быть.
Не, ну вот зашибись стереотипы, да? А с чего бы код без паттернов и Спринга — сразу говнокод? А может я у себя в гараже придумал способ как дизайнить без вот этого всего? Что — на них мир сошелся? Да и не я один: скажи такое хаскелитам, например, так они на смех же подымут.
И я б с радостью посмотрел как рынок бы рассудил нас, пусть даже и не в мою пользу. Но вот сцуко незадача: угораздило меня заделаться творцом, а не дельцом. Рынок — не для творцов.
А, ну тогда самые дешевые гаражи — на гитхабе/гитлабе вообще. Правда остается вопрос — как поделки из такого гаража монетизировать, и тут основной посыл статьи прям в точку бьет:
им [творцам] больше ничего и не надо уметь — все проблемы в своей жизни они решат с помощью разработки.
И да — я такой же творец. И не горжусь этим. Период такой же хандры как у автора в посте я вроде уже прошел, а сейчас ловлю себя на мысли — с десяток лет вкладывался в какие то тупые паттерны, парадигмы, изучал языки и фреймворки, а толку? От этого что — проще кодить стало?
Вот выйдем мы на улицу — покажи мне BeanPostProсessor? Что оно такое? Нет его? И на кой ляд тогда оно в коде? Какие проблемы клиентов оно может решить? Да и кто — клиент? Не такой же "творец" ли часом? Так и приходишь к выводу — лучше бы я человечий язык учил. Чтоб с людьми на одном языке можно было разговаривать.
Ну так краснота как раз и иллюстрирует, что хотим, на самом деле.
Бессмысленно к этому апеллировать. Эта общемировая тенденция играет не в нашу пользу. Факт в том, что по ту сторону забора даже после всех деструктивных “общемировых тенденций” сегмент останется попросту шире, живей и насыщенней, чем у нас. На порядки шире. Вот и все.
У меня есть стойкое ощущение, что в описании к рейтингу сказано полправды, и на самом деле рейтинг отражает то, насколько доступны гражданам той или иной страны ресурсы, которые они хотят потреблять.
Иными словами, американцам от блокировки РТ - на порядки меньше удар по свободе ощущается, чем нам - от блокировки ютуба.
Было бы иронично стереть границы между кванмен и российским сегментом.
Пф. “Всех”.
Да че греха таить - говорите уж прямо. Мы подсели на эту иглу плотнее всех. И зажарка, получается, предназначена исключительно нам.
А я не понимаю, какой в 2026м еще остался смысл выстилать такие пространные пасты про какую то там ненависть... Это до СВО еще можно было капать на неокрепшие мозги подобным передергиванием, демагогией и игрой на эмоциях. А сейчас, лично я ненависти и презрения от бело-сине-белых релокантов в свой адрес насмотрелся на порядки больше, чем от сограждан и властей. Так что мозолька натерта.
Подзабытых? Как бы - средства контроля и манипулирования общественным мнением сейчас - сильны как никогда.
Статья - "верните мне мой 2018 год". Прям во весь рост ощущаются те самые всепропальщицкие вайбы того времени. Мммм...
Ушла эпоха.
Иронично выйдет, если текущий геополитический кризис дойдет до той точки эскалации, при которой начнет появляться практика интернирования.
Ничего с водителями не будет еще долго. Можно ИИ посадить за руль, но пресловутую ответственность за сбитых пешеходов или ДТП на него не возложишь. Сбойнет лидар там, или нейронку перемкнет в биас, и все... Кому тогда юридические претензии предьявлять? Нейронке?
Спор "ООП vs ФП vs ПП" бессмысленен и неконструктивен. Вообще, ИМХО, нет особого смысла выделять отдельные парадигмы, учитывая ту мультипарадигмальную солянку, которая используется по факту на местах. Гораздо интереснее история "императивная vs декларативная разработка".
Мерзотнее чтива давненько не видал. Вполне себе годная идея "будь проще" разбавлена абсолютно отвратительными тезисами, буквально вредными советами, которые могут быть поняты не так миллионом способов. По порядку:
Да, давайте прибьем все схемы обмена данными к идентичным структурам. Тот факт, что сервис обычно существует для того, чтобы данные преобразовывать, обрабатывать, работать с ними, а не просто оставаться тупым крудом, и то следствие, что преобразование данных легко влечет за собой изменение их структуры, вместе с именами и расположением полей - не, пошел я нахер, мы признаем только круды.
Авторитетный источник занимается черепомерством в прямом эфире. Привести обоснования для приведенных цифр? Не, пошел я нахер, понятно.
Посмеялся от души над "обожаемым" примером. Автор и не знает, что еще в начале 2000х разрабы именно такой стиль кода классифицировали как "индусский".
Очередной пучок черепомерства, которое никак не коррелирует с поддерживаемостью. Послушать таких, так выходит на джаве вообще нормальный код писать нельзя - джава же громозкая!
Я пойду дальше. После прочтения этого абзаца я пошлю нахер и автора, и людей, у которых весь код - это пары из interface Service -> class ServiceImpl. Эти люди совершенно некомпетентны в вопросах связности и декаплинга.
А здесь идет пучок демагогии про юнит тесты. Как будто первый раз, мало TDD-шников до этого было. Целый абзац воды ниочем, зато звучит злободневно.
Очередная фиксация на крудах. Все есть круд. А что не круд, то под круд должно быть подогнанно, даже если это объективно не круд.
И напоследок.
Я полностью согласен с тем, что синьорность - это в первую очередь бизнесориентированность. Я отдаю себе отчет в том, что выеживаться в проектном коде неконструктивно. И скорее всего тот графовый алгос был действительно не к месту. Можно было бы в посте рассказать об этом всратом кейсе поподробнее. Собрать мотивацию тех людей кто принимал такие решения. Расписать последствия. И идея поста была бы донесена лучше, и чтиво было бы образовательнее. Но нет, какое еще "образовательное" начало - ведь заниматься дешевым поучательством с подменой всех понятий понятий так весело!
А чтобы за вредные советы сообщество не насадило на кол, влепим тэг "юмор". Кстати да - я душнила, юмор не понял.
Действительно, дико.
Дело не в удобстве, дело в организации процесса. Польза от таких лонг ридов в первую очередь проявляется тогда, когда они ревьювятся вместе с кодом (иначе нет никакой гарантии что этому полотну текста вообще можно верить). Польза на ревью от этого двойная — во первых, ревьюерам не приходится гадать что означает та или иная ревью-дельта, вместо этого они сразу могут начать с чтения такой вот "документации", где оригинатор им все разъясняет, а потом сверять "что написано в доках" с тем "что написано в коде". Это резко увеличивает скорость и качество ревью. Во вторых, ревьюеры могут давать ремарки на "документацию", если им в ней что-то неясно. На выходе получается не просто проревьювленный код, а проревьювленный и полностью задокументированный солюшен.
Но если "документация" — в коммит мессагах, ревьюить ее становится резко сложнее. Мессаг не отредактировать без пересоздания коммита, а амендить коммиты на каждую ремарку от ревьюера — путь к косякам и ненависти.
Любой косяк в процессе он повернет в свою пользу. Любую слабость он будет эксплуатировать, причем так, что никто не уличит его в токсичности ни в жизнь. Более того, он может даже не осознавать при этом что делает что-то плохое. А что — чего от него хотят, он делает вовремя и с надлежащим уровнем качества. В чем проблема?
ЗЫЖ я не оправдываю щас творцов если что. Я уже говорил что я не горжусь тем что являюсь оным. Но все же не надо все валить на одну сторону.
ИМХО пост был как раз по большей части именно о творце, который жалуется на себя же и себе подобных. Ведь признает же он в конце что:
и что
Ну и в итоге "творцы" витают где то в облаках, называют требования клиентов "какими то странными хотелками", при этом для обычных людей странными выглядят именно они с их диалогами о том как запилить AbstractSingletonFactoryProvider поверх VisitorControllerObserverBean чтоб инжекции не поломались. А "дельцы", чтоб хоть как то держать "творцов"
в уздепод контролем и направить их усилия в конструктивное русло, придумывают всякую разную корпоративную культуру, только нихрена это не работает: молодые творцы стенают от HRов, которые их nullи проверять заставляют, а творцы, достигнувшие дзена, делают так:И я б с радостью посмотрел как рынок бы рассудил нас, пусть даже и не в мою пользу. Но вот сцуко незадача: угораздило меня заделаться творцом, а не дельцом. Рынок — не для творцов.
А, ну тогда самые дешевые гаражи — на гитхабе/гитлабе вообще. Правда остается вопрос — как поделки из такого гаража монетизировать, и тут основной посыл статьи прям в точку бьет:
И да — я такой же творец. И не горжусь этим. Период такой же хандры как у автора в посте я вроде уже прошел, а сейчас ловлю себя на мысли — с десяток лет вкладывался в какие то тупые паттерны, парадигмы, изучал языки и фреймворки, а толку? От этого что — проще кодить стало?
Вот выйдем мы на улицу — покажи мне BeanPostProсessor? Что оно такое? Нет его? И на кой ляд тогда оно в коде? Какие проблемы клиентов оно может решить? Да и кто — клиент? Не такой же "творец" ли часом? Так и приходишь к выводу — лучше бы я человечий язык учил. Чтоб с людьми на одном языке можно было разговаривать.