Мерзотнее чтива давненько не видал. Вполне себе годная идея "будь проще" разбавлена абсолютно отвратительными тезисами, буквально вредными советами, которые могут быть поняты не так миллионом способов. По порядку:
Название переменных
Да, давайте прибьем все схемы обмена данными к идентичным структурам. Тот факт, что сервис обычно существует для того, чтобы данные преобразовывать, обрабатывать, работать с ними, а не просто оставаться тупым крудом, и то следствие, что преобразование данных легко влечет за собой изменение их структуры, вместе с именами и расположением полей - не, пошел я нахер, мы признаем только круды.
20 строк в методе, 200 строк в классе
Авторитетный источник занимается черепомерством в прямом эфире. Привести обоснования для приведенных цифр? Не, пошел я нахер, понятно.
Полиморфизм
Посмеялся от души над "обожаемым" примером. Автор и не знает, что еще в начале 2000х разрабы именно такой стиль кода классифицировали как "индусский".
Повторяемость кода
Очередной пучок черепомерства, которое никак не коррелирует с поддерживаемостью. Послушать таких, так выходит на джаве вообще нормальный код писать нельзя - джава же громозкая!
5.Слабая связанность
Я пойду дальше. После прочтения этого абзаца я пошлю нахер и автора, и людей, у которых весь код - это пары из interface Service -> class ServiceImpl. Эти люди совершенно некомпетентны в вопросах связности и декаплинга.
Юнит-тесты
А здесь идет пучок демагогии про юнит тесты. Как будто первый раз, мало TDD-шников до этого было. Целый абзац воды ниочем, зато звучит злободневно.
Системность
Очередная фиксация на крудах. Все есть круд. А что не круд, то под круд должно быть подогнанно, даже если это объективно не круд.
И напоследок.
Я полностью согласен с тем, что синьорность - это в первую очередь бизнесориентированность. Я отдаю себе отчет в том, что выеживаться в проектном коде неконструктивно. И скорее всего тот графовый алгос был действительно не к месту. Можно было бы в посте рассказать об этом всратом кейсе поподробнее. Собрать мотивацию тех людей кто принимал такие решения. Расписать последствия. И идея поста была бы донесена лучше, и чтиво было бы образовательнее. Но нет, какое еще "образовательное" начало - ведь заниматься дешевым поучательством с подменой всех понятий понятий так весело!
А чтобы за вредные советы сообщество не насадило на кол, влепим тэг "юмор". Кстати да - я душнила, юмор не понял.
Дело не в удобстве, дело в организации процесса. Польза от таких лонг ридов в первую очередь проявляется тогда, когда они ревьювятся вместе с кодом (иначе нет никакой гарантии что этому полотну текста вообще можно верить). Польза на ревью от этого двойная — во первых, ревьюерам не приходится гадать что означает та или иная ревью-дельта, вместо этого они сразу могут начать с чтения такой вот "документации", где оригинатор им все разъясняет, а потом сверять "что написано в доках" с тем "что написано в коде". Это резко увеличивает скорость и качество ревью. Во вторых, ревьюеры могут давать ремарки на "документацию", если им в ней что-то неясно. На выходе получается не просто проревьювленный код, а проревьювленный и полностью задокументированный солюшен.
Но если "документация" — в коммит мессагах, ревьюить ее становится резко сложнее. Мессаг не отредактировать без пересоздания коммита, а амендить коммиты на каждую ремарку от ревьюера — путь к косякам и ненависти.
ИМХО лучше такие лонг-риды писать в PR description чем в коммит мессаг, а в коммит мессаге оставлять просто краткое описание и обязательно ссылку на issue (по которой можно будет найти впоследствии PR). Коммит мессаг в разы тяжелее ревьювить и править ремарками чем PR description.
Ты так говоришь как будто эта ваша хваленая культура работает, ага. Если человек захочет переметнуться на темную сторону силы, он это сделает, и ничего вы, дельцы, ему не противопоставите. На каждом митинге он будет излучать энтузиазм, на каждом ассессменте он накатает себе 100500 достижений, на каждом код ревью он будет давать конструктивный фидбэк, на каждую ремарку у него будет контраргумент. Все тикеты он будет делать в срок, с тем уровнем качества, с которым будет возможно пройти код ревью. В общении он всегда будет позитивен, на пьянках — душой компании.
Любой косяк в процессе он повернет в свою пользу. Любую слабость он будет эксплуатировать, причем так, что никто не уличит его в токсичности ни в жизнь. Более того, он может даже не осознавать при этом что делает что-то плохое. А что — чего от него хотят, он делает вовремя и с надлежащим уровнем качества. В чем проблема?
ЗЫЖ я не оправдываю щас творцов если что. Я уже говорил что я не горжусь тем что являюсь оным. Но все же не надо все валить на одну сторону.
ИМХО пост был как раз по большей части именно о творце, который жалуется на себя же и себе подобных. Ведь признает же он в конце что:
это рай для инфантильных говнюков, которые не могут ничего, кроме дурацкого программирования.
и что
вчерашние парни из гаража не могут принять систему, в которой никому не нужно их творчество. Бизнесу нужен конвейер, превращающий айтемы из джиры в пулл реквесты, творчество тут только мешает.
Ну и в итоге "творцы" витают где то в облаках, называют требования клиентов "какими то странными хотелками", при этом для обычных людей странными выглядят именно они с их диалогами о том как запилить AbstractSingletonFactoryProvider поверх VisitorControllerObserverBean чтоб инжекции не поломались. А "дельцы", чтоб хоть как то держать "творцов" в узде под контролем и направить их усилия в конструктивное русло, придумывают всякую разную корпоративную культуру, только нихрена это не работает: молодые творцы стенают от HRов, которые их nullи проверять заставляют, а творцы, достигнувшие дзена, делают так:
Я стану самым отвратительным типом людей в индустрии. Скилл и гонор как у рок-звезды, при этом ни на секунду не верит в то, что делает. Выхлоп, как от пассажира. Влюблённый в технологии, но никогда не делает больше, чем просят. Самый крутой чувак в любой компании, папа ведущего разработчика, тот-кого-берут-на-совет-директоров. Почти Линус Торвальдс, только без линукса и вклада в прогресс. Мой скилл даст мне право распоряжаться жизнью и смертью, а довольное стадо поклонников будет говорить, что так и должно быть.
Не, ну вот зашибись стереотипы, да? А с чего бы код без паттернов и Спринга — сразу говнокод? А может я у себя в гараже придумал способ как дизайнить без вот этого всего? Что — на них мир сошелся? Да и не я один: скажи такое хаскелитам, например, так они на смех же подымут.
И я б с радостью посмотрел как рынок бы рассудил нас, пусть даже и не в мою пользу. Но вот сцуко незадача: угораздило меня заделаться творцом, а не дельцом. Рынок — не для творцов.
А, ну тогда самые дешевые гаражи — на гитхабе/гитлабе вообще. Правда остается вопрос — как поделки из такого гаража монетизировать, и тут основной посыл статьи прям в точку бьет:
им [творцам] больше ничего и не надо уметь — все проблемы в своей жизни они решат с помощью разработки.
И да — я такой же творец. И не горжусь этим. Период такой же хандры как у автора в посте я вроде уже прошел, а сейчас ловлю себя на мысли — с десяток лет вкладывался в какие то тупые паттерны, парадигмы, изучал языки и фреймворки, а толку? От этого что — проще кодить стало?
Вот выйдем мы на улицу — покажи мне BeanPostProсessor? Что оно такое? Нет его? И на кой ляд тогда оно в коде? Какие проблемы клиентов оно может решить? Да и кто — клиент? Не такой же "творец" ли часом? Так и приходишь к выводу — лучше бы я человечий язык учил. Чтоб с людьми на одном языке можно было разговаривать.
А по мне так ну их всех вообще — и эффективных манагеров, с их дурацкими потугами нас оптимизировать, сложить, поделить и подвести под одну гребенку «чтоб не пикали тут и не разводили токсичность», и творцов с их дурацкими монадами, BeanPostProcessor'ами, глубоким внутренним миром и неудовлетворенной потребностью к фреймворкостроительству.
А я таким не стал. Я только научился притворяться, что бы меня не выгоняли. И я не верю, что смогу кого-нибудь переубедить. Поэтому я стану ещё хуже, чем эти корпоративные программисты. С меня хватит. Мой измождённый мозг больше не будет инкубатором для бойлерплейта. Если очень высокий скилл позволяет работать меньше — я это использую.
> И то, и другое есть средство организации программ. Из модулей
Ну вот это я бы как раз поостерегся утверждать. По крайней мере в вводном посту к OSGi такие сравнения точно ни к чему. Эдак все подходы и парадигмы в истории на модульность можно натянуть — мол, мы класс придумали чтоб бить приложение на такие вот реюзабельные модули… А потом приходят люди и говорят «зачем мне это в 2019, когда я на микросервисах слабать тожсамое могу». А потому что нифига это не тожсамое :)
> энтерпрайз (конкретно сейчас, в лице спрингсорса) от неё отвернулся. есть повод задуматься…
Задумался в свое время. И пришел для себя к выводу, что произошло это потому — что всеми так разлюбимый спринг — один большой пучок рантайм-магии с кодогенерацией и рефлексией, а OSGi такие выкрутасы не любит. И вот ИМХО это — спринговый слив, а не OSGiшный.
По большому счету OSGI это средство для создания Java-приложений из модулей. Близким аналогом можно считать, например JavaEE, и в какой-то степени OSGI контейнеры могут выполнять JavaEE модули (скажем, web-приложения в виде War), а с другой стороны, многие JavaEE контейнеры содержат OSGI внутри, как средство реализации модульности «для себя». То есть, JavaEE и OSGI — это вещи похожие до совместимости, и удачно взаимодополняющие.
Я б поостерегся проводить такие жирные аналогии между OSGi и JavaEE. Две совершенно разные вещи что по принципам работы, что по решаемым задачам. Karaf/ServiceMix еще куда ни шло. И то они один пень они не сертифицированные EE контейнеры, никогда ими не были, и никогда оными не планировались, что тоже к проведению аналогий не располагает.
OSGi лежит в основе кучи EEшных контейнеров — да. Некоторый набор EEшных спек-имплементаций упакован в бандлы и доступен как фичи в Карафе — да. Но не более того.
Ну например взять какой нибудь интерфейс SortedSet, сымплементировать от него класс, и допустить в имплементации какой нибудь косяк с сортировкой. В итоге, все программы, принимающие на вход SortedSet и справедливо делающие предположение о том что итерация по коллекции будет идти по определенному порядку, перестанут быть корректными после подстановки класса с косяком. Прямое нарушение LSP. Но языкам пофиг — пока синтаксически все верно, они все сбилдят и запустят.
LSP вообще просто нарушить, даже если тупо интерфейс имплементировать. И ничто не проверит за девелопера корректность LSP — ни компилятор, ни статический анализатор, ни даже система типов. Единственный реальный недостаток наследования по отношению к остальным инструментам sybtypingа только в том, что с ним нарушить LSP проще всего.
Мерзотнее чтива давненько не видал. Вполне себе годная идея "будь проще" разбавлена абсолютно отвратительными тезисами, буквально вредными советами, которые могут быть поняты не так миллионом способов. По порядку:
Да, давайте прибьем все схемы обмена данными к идентичным структурам. Тот факт, что сервис обычно существует для того, чтобы данные преобразовывать, обрабатывать, работать с ними, а не просто оставаться тупым крудом, и то следствие, что преобразование данных легко влечет за собой изменение их структуры, вместе с именами и расположением полей - не, пошел я нахер, мы признаем только круды.
Авторитетный источник занимается черепомерством в прямом эфире. Привести обоснования для приведенных цифр? Не, пошел я нахер, понятно.
Посмеялся от души над "обожаемым" примером. Автор и не знает, что еще в начале 2000х разрабы именно такой стиль кода классифицировали как "индусский".
Очередной пучок черепомерства, которое никак не коррелирует с поддерживаемостью. Послушать таких, так выходит на джаве вообще нормальный код писать нельзя - джава же громозкая!
Я пойду дальше. После прочтения этого абзаца я пошлю нахер и автора, и людей, у которых весь код - это пары из interface Service -> class ServiceImpl. Эти люди совершенно некомпетентны в вопросах связности и декаплинга.
А здесь идет пучок демагогии про юнит тесты. Как будто первый раз, мало TDD-шников до этого было. Целый абзац воды ниочем, зато звучит злободневно.
Очередная фиксация на крудах. Все есть круд. А что не круд, то под круд должно быть подогнанно, даже если это объективно не круд.
И напоследок.
Я полностью согласен с тем, что синьорность - это в первую очередь бизнесориентированность. Я отдаю себе отчет в том, что выеживаться в проектном коде неконструктивно. И скорее всего тот графовый алгос был действительно не к месту. Можно было бы в посте рассказать об этом всратом кейсе поподробнее. Собрать мотивацию тех людей кто принимал такие решения. Расписать последствия. И идея поста была бы донесена лучше, и чтиво было бы образовательнее. Но нет, какое еще "образовательное" начало - ведь заниматься дешевым поучательством с подменой всех понятий понятий так весело!
А чтобы за вредные советы сообщество не насадило на кол, влепим тэг "юмор". Кстати да - я душнила, юмор не понял.
Действительно, дико.
Дело не в удобстве, дело в организации процесса. Польза от таких лонг ридов в первую очередь проявляется тогда, когда они ревьювятся вместе с кодом (иначе нет никакой гарантии что этому полотну текста вообще можно верить). Польза на ревью от этого двойная — во первых, ревьюерам не приходится гадать что означает та или иная ревью-дельта, вместо этого они сразу могут начать с чтения такой вот "документации", где оригинатор им все разъясняет, а потом сверять "что написано в доках" с тем "что написано в коде". Это резко увеличивает скорость и качество ревью. Во вторых, ревьюеры могут давать ремарки на "документацию", если им в ней что-то неясно. На выходе получается не просто проревьювленный код, а проревьювленный и полностью задокументированный солюшен.
Но если "документация" — в коммит мессагах, ревьюить ее становится резко сложнее. Мессаг не отредактировать без пересоздания коммита, а амендить коммиты на каждую ремарку от ревьюера — путь к косякам и ненависти.
Любой косяк в процессе он повернет в свою пользу. Любую слабость он будет эксплуатировать, причем так, что никто не уличит его в токсичности ни в жизнь. Более того, он может даже не осознавать при этом что делает что-то плохое. А что — чего от него хотят, он делает вовремя и с надлежащим уровнем качества. В чем проблема?
ЗЫЖ я не оправдываю щас творцов если что. Я уже говорил что я не горжусь тем что являюсь оным. Но все же не надо все валить на одну сторону.
ИМХО пост был как раз по большей части именно о творце, который жалуется на себя же и себе подобных. Ведь признает же он в конце что:
и что
Ну и в итоге "творцы" витают где то в облаках, называют требования клиентов "какими то странными хотелками", при этом для обычных людей странными выглядят именно они с их диалогами о том как запилить AbstractSingletonFactoryProvider поверх VisitorControllerObserverBean чтоб инжекции не поломались. А "дельцы", чтоб хоть как то держать "творцов"
в уздепод контролем и направить их усилия в конструктивное русло, придумывают всякую разную корпоративную культуру, только нихрена это не работает: молодые творцы стенают от HRов, которые их nullи проверять заставляют, а творцы, достигнувшие дзена, делают так:И я б с радостью посмотрел как рынок бы рассудил нас, пусть даже и не в мою пользу. Но вот сцуко незадача: угораздило меня заделаться творцом, а не дельцом. Рынок — не для творцов.
А, ну тогда самые дешевые гаражи — на гитхабе/гитлабе вообще. Правда остается вопрос — как поделки из такого гаража монетизировать, и тут основной посыл статьи прям в точку бьет:
И да — я такой же творец. И не горжусь этим. Период такой же хандры как у автора в посте я вроде уже прошел, а сейчас ловлю себя на мысли — с десяток лет вкладывался в какие то тупые паттерны, парадигмы, изучал языки и фреймворки, а толку? От этого что — проще кодить стало?
Вот выйдем мы на улицу — покажи мне BeanPostProсessor? Что оно такое? Нет его? И на кой ляд тогда оно в коде? Какие проблемы клиентов оно может решить? Да и кто — клиент? Не такой же "творец" ли часом? Так и приходишь к выводу — лучше бы я человечий язык учил. Чтоб с людьми на одном языке можно было разговаривать.
В сумме один пень какой то сюрреализм получается.
Вспомнилось: https://www.yegor256.com/2017/08/01/how-to-manage-a-manager.html
Ну вот это я бы как раз поостерегся утверждать. По крайней мере в вводном посту к OSGi такие сравнения точно ни к чему. Эдак все подходы и парадигмы в истории на модульность можно натянуть — мол, мы класс придумали чтоб бить приложение на такие вот реюзабельные модули… А потом приходят люди и говорят «зачем мне это в 2019, когда я на микросервисах слабать тожсамое могу». А потому что нифига это не тожсамое :)
Задумался в свое время. И пришел для себя к выводу, что произошло это потому — что всеми так разлюбимый спринг — один большой пучок рантайм-магии с кодогенерацией и рефлексией, а OSGi такие выкрутасы не любит. И вот ИМХО это — спринговый слив, а не OSGiшный.
Я б поостерегся проводить такие жирные аналогии между OSGi и JavaEE. Две совершенно разные вещи что по принципам работы, что по решаемым задачам. Karaf/ServiceMix еще куда ни шло. И то они один пень они не сертифицированные EE контейнеры, никогда ими не были, и никогда оными не планировались, что тоже к проведению аналогий не располагает.
OSGi лежит в основе кучи EEшных контейнеров — да. Некоторый набор EEшных спек-имплементаций упакован в бандлы и доступен как фичи в Карафе — да. Но не более того.
А вообще, спасибо за пост. Люблю OSGi.