В начале не понятно зачем это нужно, затем кажется что ты шаришь и все очень удобно, а после ты ловишь себя на мысли, что понятно абсолютно нихуя и кажется, что вокруг все ебанулись. Именно так выглядят стадии изучения gradle. 

На всех проектах рано или поздно нужно сделать какой-то скрипт, который бы автоматизировал какую-то рутину. Что-то вроде генерации отчета, отправки сообщения в рабочий чат, отправки apk куда-либо. Как чаще всего такие задачи делаются на мобильных проектах? Правильно, фиганем сейчас gradle plugin и все будет работать. Код вот тут рядом и язык один и тот же,  все смогут это поддерживать. Поддерживать как сам плагин, так и морально тех кто с ним работает.

Сейчас, работая уже почти год в инфре, я понял это крайне шаткая дорожка. Как только проект вырастет, а он вырастет, вы сильно пожалеете о том, что не захотели потратить время на тот же python. Представьте, у вас простая задача, но каждый раз на CI, вам нужно сначала подождать пока gradle придет в себя, затем сконфигурируется, и только потом запустится. Помимо этого еще и при следующем обновлении окажется, что вы как-то не так эту таску вызываете и у вас начнет все падать. Желая сократить время, вы начали зависеть от системы, которую не контролируете, не говоря уже о ресурсах.

Как тут быть? Все очень просто, если для вашей задачи не нужно знать о графе зависимостей, забейте и делайте CLI. Просто берете python и тупо располагаете скрипты рядом с вашим кодом. Все в одном месте, как и с gradle. Но теперь вы не зависимы от системы сборки, не тратите время на инициализацию графа и разговоры с психологом. Все очень легко дебажить, и вам плевать на обновления gradle и т.д 

Ну а если у вас есть уже какая-то инфра внутри компании, и есть возможность запуливать докер образы или какой-нибудь s3 чтобы туда складывать бинари, то у вас еще и появляется возможность использовать другие языки типа go или тот же kotlin.  

Можно даже пойти дальше и упарится как это сделали разработчики detekt. Вы заглядывали в их репу? Это высший пилотаж как по мне. Возможно я вас удивлю, но detekt можно запускать без gradle как обычную CLI программу. Я вообще планирую на рабочем проекте это внедрить, чтобы порезать время на конфигурацию и вены себе в случае, если gradle не уйдет с рынка.

Короче, что делают разрабы detekt. Они сделали CLI, который можно легко тестировать, дебажить и вносить изменения. Затем они просто делают gradle plugin, в котором есть зависимость на CLI и при запуске gradle task тупо запускает CLI под капотом. Ну не круто ли а? 

В итоге они используют плюсы и того и того подхода. Ну разумеется чтобы такое сделать, нужно желание в этом разобраться и компетенции. Теперь вы знаете что есть еще один способ решить эту проблему.

В догонку к предыдущему посту. Не смог не поделится с вами годнотой

Ну что дамы и господа, это знаменательный момент, нас теперь больше 2000. Представляете, 2000 крутых людей, которые собрались в одном канале.

На фоне этого, умопомрачительного успеха я решил, что стоит рассказать о себе по подробнее, чтобы вы лучше понимали кого вы читаете.
Усаживайтесь по удобнее, заваривайте чаек, и погнали...

продолжение в комментах 👇

Мне кажется крайне крутой идея выпустить пост прям 31 декабря, посреди новогодней суеты когда его вероятнее всего прочитает никто. Но если вы читали предыдущий пост, сами знаете с кем, имеете дело)

Один из самых крутых сериалов которые я смотрел за этот год, это сериал "Разочарование" от нетфликса. В целом, название сериала полностью совпадает с моим мнением про этот уходящий год. Не то чтобы этот год был прям ужасным, но под конец года я знатно выгорел. Выгорел не от работы, а скорее от всего в совокупности: от проблем в отношениях, от вынужденного поиска квартиры, от того, что работа не драйвит так как раньше, и что я хотел бы, чтоб мои посты выходили почаще (представьте: настал рассвет, пока вы ходили по чаще) Да же сейчас, пока пишу этот пост слова даются крайне тяжко(

Последние два года я каждый раз думаю, сесть, собраться с мыслями и сделать уже итоги года. С одной стороны прикольно читать про чужой опыт, это я вообще обожаю делать и сам двигаю свой контент в эту стороны, с другой стороны, а нахер оно кому нужно. Все эти открытки со статистикой канала, ничего полезного не дают, разве что позволяют потешить эго автора.

Поэтому я не буду раздувать и выпытывать из себя каких-то крутых наставлений на этот год. Просто хотел бы сказать всем спасибо кто подписывается, кто ставит реакции, кто комментирует, всех обнял, приподнял. Благодаря вам я все еще продолжаю вести этот канал. В следующем году постараюсь выпускать посты стабильно хотя бы раз в неделю)

Всех с Новым Годом 🥂

Ну что как первая рабочая неделя, вспомнили профессию? Я вообще планировал сразу начать выпускать посты на первой же неделе нового года, начать новую жизнь так сказать. Правда я не учел, что размер моего мозга после праздников успешно конкурирует с орехом, поэтому накатать чего-то годного пока не получилось. Однако не волнуйтесь, технические посты скоро будут)

Начало года часто связано с планированием и постановкой целей. Поэтому я решил начать этот год с вопроса к вам. А вы ставите себе какие-то карьере цели на год? Я не про OKR сейчас спрашиваю, а вот конкретно личные. Что-то вроде сменить эту галеру на другую галеру по моднее, или вырасти из сеньора в сеньора+?

Личные цели это парадоксальная штука. Они одновременно нахер не нужны и бывают дико полезны. Существует две основные стратегии. 

В первой мы говорим, что нахер эти цели, будем делать по кайфу как получится. Все равно мы не умеем ничего планировать, всех черных лебедей не предскажешь да и нужно просто кайф ловить от процесса. Маршрут на несколько шагов неизвестно куда - не получится планировать, будущее непредсказуемо ни для человека, ни для компьютера.

Вторая стратегия, наоборот поставить какие-то цели, чтобы понять куда вообще идти. Желательно чуть выше чем мы привыкли делать, чтобы поразить всех результатами. Целимся в солнце в луну попадем – блевать тянет от этой фразы, но на всяких планированиях слушать приходится. 

Парадокс вот в чем. С одной стороны без целей мы будем заниматься херней, я этом профи уж поверьте. Без четких целей нет фокуса, а без фокуса мы отвлекаемся на дичь вроде – срочно переписать весь проект на compose. С другой мы не можем обладать всегда полной информацией и в процессе может выясниться, что мы вообще идем не туда. Но цель у нас как бы поставлена, а поэтому идти к ней все равно нужно. Да и тот же SMART это очень хорошо, только в случае когда известно, как цель достигать. Короче сложно и каждый выбирает стратегию для себя.

И тут, я как блогер должен был вам раскидать как же все таки нужно поступать, но не буду, потому что вспоминайте шутку про орех. И напишите в комментах, ставите ли вы себе на цели на год?

Меня все таки очень забавляют разрабы которые сильно защищают gradle. Да нужно пройти пару курсов и прочитать 200 статьей, чтобы хоть что-то понимать, да он жрет неадекватно много ресурсов, да после обновления на новую версию все может сломаться к херам: НО КТО ЕСЛИ НЕ gradle?

Причем я не понимаю зачем они это делают? Ведь не ты же его делал, я не до твоего продукта добываюсь, у тебя же жизнь станет лучше если мы будем вместе эту критику доносить до разрабов gradle. Помимо этого, от критики рождаются новые решения, чем сильнее индустрия будет ныть про то, что gradle кусок говна, тем быстрее появится другое решение. Я готов поставить на кон гетеросексуальность разработчиков gradle, что при появлении конкуренции среди систем сборки, они начнут улучшаться более быстрыми тэмпами, перенимая друг у друга хорошие концепции. 

Как мне кажется работает это следующим образом. Какой-то разработчик посвятил этой ненужной возне с заведомо ублюдской системой кучу своего времени. Разумеется никому не охото признавать то, что ты потратил время впустую и теперь твои знания ничего не стоят. И в такой ситуации ты будешь всеми силами защищать эту технологию. 

Пугает еще то, что чем дольше мы все сидим на gradle, тем дольше с него не слезем. То же самое получилось с linux. У последнего есть куча проблем, но вы в современном мире можете себе представить чтобы кто-то накидал новое ядро операционки с новыми концепциями? Это уже нереально, там написано уже так много кода, что никто не сможет сделать что-то хотя бы частично конкурирующее с linux. Такая же ситуация и с chomium и android.

Ну и что же с этим делать спросите вы? Ну как мне кажется если все хотя бы попробуют собрать проект на других системах сборки типа bazel уже может что-то сдвинуться. Или станет хуже, хрен знает я плохо будущее предсказываю)))

Я как вчера помню свой первый МР (мерж реквест) на проекте с командой больше 1-го разработчика. То что сделали с моим МРом можно смело выкладывать в оранжевый ютуб. Мне тогда накидали 40 комментариев за 5 минут. На проекте работали крайне педантичные разработчики, которые докапывались до каждой строчки кода. Разумеется работая в такой компании, ты рано или поздно сам становишься таким же педантичным фанатиком. Я мог докопаться до чего угодно, до форматирования, до названия переменных, до прически автора. 

Продолжалось это до тех пор, пока на очередном ревью не задал себе вопрос: “а не херней ли я страдаю?”. В ответ на вопрос мне явилось ведение в виде Линуса Торвальдса который сказал мне, что даже для него это слишком. И после этого я понял две вещи: что стоит завязывать работать под грибами, а также нужно пересмотреть свое отношение к ревью кода. 

Докапываясь до мелочей, ты просто-напросто сжираешь время и нервы, как свои так и другого человека. Время, которое могло быть потрачено более эффективным способом. 

И я сформулировал для себя несколько основных правил, как правильно делать код ревью. В основе этих правил простой принцип: “Не доебывайся до мелочей”.  Все крайне просто, комментирую я код только в 3-х случаях. 

1️⃣ Когда вижу что разработчик делает откровенную херню. Не просто, что решение “не самое лучше”, или что “можно сделать красивее”, а вот прям нельзя. Ебанет если так сделать, и я могу четко с пруфами объяснить почему. 

2️⃣ Когда вижу что разработчик начал пилить велосипед, когда уже есть готовый компонент в проекте. Или когда кто-то начал для простой задачи выдумывать супер крутую архитектуру, которая закладывает фундамент для будущего. В некотором смысле это можно отнести к предыдущему пункту.

3️⃣ Четкое нарушение конвенций, которые приняла вся команда. При возникновении спорного момента или если такого нет в конвенциях, то сначала выносим на обсуждение и только потом можем докапываться в МР. Если же у вас нет принятых конвенций в команде, тогда на основе чего вы решили доебаться? На основе своих ощущений прекрасного?

Все вот эти вещи вроде: “можно сделать короче“, “в будущем возможно понадобится X, давай переделам”, “так нельзя писать код” идут лесом. Туда же идут всякие идеи по микрооптимизации некритичного кода. 

Мне рассказывали забавные истории про тимлида который оставлял комментарии типа: “Ыыы исправь!” и это блять не шутка. Не можешь четко сформулировать что не так – сиди, блять, помалкивай или иди учиться формулировать свои мысли.

В дополнение к предыдущему, сильная педантичность к проверке изменений приводит к другой проблеме. Большие изменения ревьются крайне долго или вообще забивается на ревью. Это конечно отчасти проблема автора МР, но порой никак без больших изменений. Так устроена наша психика, когда привыкаете докапываться до каждой строчки. Потом смотришь на изменения в 1к строчек и твоей мозг думает, ууу это на долго, давай сначала с мелочью разберемся чтобы ничего не отвлекало. Ну а дальше сами понимаете. У нас в команде вообще есть рофл для таких МРв, если он висит несколько дней и без комментариев, мы считаем что МР достаточно "настоялся" и в нем точно нет косяков.

Ну и еще момент, для всех правил есть исключение. Правила которые я описал выше применимы когда у вас зонеркоманд из сеньоров и крепких мидлов. Когда проводим ревью джунов, можно добавить чуть больше духоты, но аккуратно и с объяснением почему нужно делать так, и так.

До чего же я все-таки ненавижу собесы. Каждый раз нервничаешь как перед первым свиданием. Готовишься, вспоминаешь скорости работы всех стандартных структур данных. Вспоминаешь задачки, которые недавно решил на leetcode. В туалет бегаешь несколько раз из-за стресса. Проверяешь что оборудование работает нормально. Справляешься с заплетанием языка в начале собеседования.

Так еще и после фидбэк оставлять, ведь это все со стороны собеседующего...

Итак, после того как я рассказал о себе, наверняка у кого-то мог возникнуть вопрос. Что делать, если я долбаеб и не собираюсь меняться?

Да, не такие посты вы ожидали от канала про разработку, но не делайте вид, будто в пятницу вы собрались чему-то продуктивно учится. Поэтому присаживайтесь по удобнее, сейчас я поведаю вам, как стать самым конченым долбоебом в команде. Погнали:

Не выполняй свои обязательства. Например обещал ты сделать доклад для команды про технологию X через неделю – все должны понимать, что возможно будет готово в течении полугода или вообще не будет готово. Если хоть раз выполнишь свое обещание, все будут ждать от тебя этого всегда.

Обесценивай опыт других людей. На собесе вообще не обращай внимания на то, чем занимался разработчик и в чем он крут. Чем более крутую штуку он сделал на прошлой работе, тем больше ты должен доказать ему, что все это гнилая, никому не нужная херня. Спрашивай то, что вообще не влияет на работу (вроде флагов Activity) и которую можно посмотреть в справочнике. Если разработчик не ответил, то сразу ставь ему грейд сильно ниже того, на который он тянет. Путь вообще спасибо скажет, что ты посвятил ему свое время.

Не учись на своих ошибках. Твой успех это всегда закономерность, потому что ты гений от природы. Если же тебя постигла неудача, то вина исключительно внешних факторов. Не нужно рефлексировать над провалами и неудачными решениями, это путь лузеров. Победители всегда ходят по граблям!

Успехи других это нелепая случайность или сбой в матрице. Поэтому важно не забывать всем это доказывать. В следующий раз, когда какая-то команда будет рассказывать о своих успехах, начни максимально доебываться до них. Скажи что по твоим личным метрикам их успехи полная хуйня. Пусть сукины дети знают свое место!

Никакой предсказуемости. Каждый твой поступок должен вызывать дикое удивление у окружающих. Все ждут от тебя взвешенных решений в выборе технологий и адекватности в общении? Удиви их!

Работай по выходным!

Стремись всегда продемонстрировать всем свою власть. Если ты тимлид, бери к себе в команду заведомо слабых стажеров, а потом увольняй их по окончанию стажировки. Не нужно быть избирательным и вкладываться в развитие, зачем, ведь на улице всегда очередь из стажеров. Нахер это все, главное доказать всем что ты можешь испортить человеку карьеру одним решением.

Выебывайся. Всегда и везде, и всем чем только можно, любым даже самым незначительным достижением. Поправил незначительный баг, сделал статью с 2-мя просмотрами, купил BMW. Исключительно важно, донести это всем, до кого можешь дотянутся.

В этом вся суть, все что делается вокруг исключительно для тебя. Забудь слова “уважение” и “здравый смысл”, это для всяких мудил которые не понимают твоего величия.

⚖️ Когда нужно использовать статику

Недавно ко мне прилетел вопрос, касательно того как правильно делать логирование. Нужно ли делать логер статичным или же инжектить его везде через DI?

Вообще этот вопрос часто может возникнуть у начинающих разрабов, которые только изучили концепцию DI. Я по себе помню, что как только знакомишься с этим паттерном, в твоих руках он превращается в молоток, а ты везде начинаешь видеть гвозди. DI далеко не панацея и есть много мест в коде, где этот паттерн не приносит пользы, а наоборот делает код сложнее в поддержке. 

И вот топ 3 вещей которые обязаны делаться через статику:

📜Логирование/Аналитика. Мне досталось одна либа, в которой логирование было сделано именно через DI. Каждый раз когда мне нужно было писать лог, приходись прикидывать логер через конструктор, это максимальное неудобное убожество. 

Суть логера в том, что он должен быть доступен в любой части программы, независимо от слоя UI/Presenter/Domain. Может возникнуть вопрос, а как тогда быть, если логер нужно подменить, например заменить в релизной сборке. Идем и смотрим как это сделано в Timber. Либа предоставляет возможность подменить реализацию во время инициализации приложения через статические методы. Устанавливаете нужный логер вначале и потом не парите голову. 

С аналитикой ровно тоже самое. Аналитика также должна быть доступна из любой части программы без возни с DI. Как быть если у нас несколько систем или нужно будет заменять их в будущем? Во-первых, мы фигово предсказываем будущее, а во-вторых делайте также как Timber.  

🖼 Загрузка картинок. Вот это вообще такая вещь на грани, вот почему. Очевидно что смешивать View и DI затея не самая удачная. Потому как у вас View становятся зависимы от вашего DI, помимо этого важно с самим DI не закосячить в плане скоупов и ЖЦ View, так еще это и максимально неудобно в коде. 

При этом с другой стороны тут у нас network слой, что означает что его по-хорошему контролировать. Подсовывать нужные там proxy, или отслеживать куда трафик идет, возможно как-то хитро подменять url или добавлять заголовки к запросам на картинки. Должна быть возможность это все конфигурировать и подменять это все для разных фичей.

Тут на самом деле, даже и думать не придется, потому как все либы для работы с картинками работают по одному и тому же принципу. Для примера можно взять coil. По умолчанию используется один и тот же экземпляр загрузчика, который можно сконфигурировать при старте приложения. Если же нужен другой загрузчик, можно прям на месте загрузки сконфигурировать свой и подсунуть в туже же самую функцию.

⛓Dispatchers/Schedulers. Раньше почти на каждом проекте был следующий подход. Мы не используем библиотечные шедулеры (вроде Schedulers.io(), Schedulers.computation()) а сделаем интерфейс:

interface Schedulers{
  fun io():Schedulers

  fun computation():Schedulers
}

Затем как вы уже поняли инжектим этот интерфейс везде где у нас есть асинхронные вызовы. Нужно это для тестирования, ведь теперь максимально удобно взять и подменить шедулеры на тестовые. 

Идея дурацкая по двум причинам: первое как я уже писал в посте про тестирование, лучше ничего не подменять и тестировать в условиях реальной работы. Иначе в тестах на одном потоке все прекрасно, а в проде гонка и плавающие баги, второе это просто бесячее дублирование в каждом классе с асинхронщиной, что по сути везде кроме UI.

Ну а что делать если подменять все таки нужно? Если RX, то ничего делать не нужно, он из коробки позволяет подменять стандартные шедулеры. Корутины к сожалению такого не умеют, однако  это можно сделать через статику. Делаем класс, который по умолчанию возвращает библиотечные реализации диспетчеров, а в тестах эту статику меняем. Единственный минус, что важно теперь следить чтобы все использовали этот самый класс для получения диспетчеров, который мы договорились использовать.

Итак немного графомании на канале. Все же слышали историю паренька который автоматизировал знакомство с девушками? Если вы вдруг так же как и я давно не заходили в твиттер, то история примерно следующая. Один паренек решил, что общаться с девушками в сети довольно энергозатратное действие и сделал систему, которая сама знакомится и общается с девушками в сети. 

Вроде как по его рассказу у него там оркестр из нескольких нейронок, одна листает профили и отбирает по фоткам, вторая пишет в личку, третья дает советы по общению и коммуникативным стратегиям, четвертая смотрит в календарь и договаривается о встрече и т.д. Инженерный подход я уважаю 😄

Разумеется сама новость произвела эффект разорвавшейся бомбы и все разделились на два лагеря. 

Одни говорят что такое в принципе невозможно сделать в одиночку и что история в целом сомнительная. Вызывает подозрение как количество мэтчей в примерно 5к штук, так и тот факт, что чувак начинающий разработчик, а система весьма сложная даже для крепкого сеньора. Некоторые даже начали фигачить свои треды разоблачения. 

Вторые наоборот говорят “а че такова, система делается за пару часов ленивого кодинга“, эти судя по всему не признанные гении. 

Я крайне не люблю эту фразу, но скорее всего "всей правды мы не узнаем", и вероятнее всего она где-то посередине. Хоть я и крайне редко обсуждаю здесь какие-то инфоповоды, но этот интересен как минимум по двум причинам. 

Во-первых, у меня была точно такая же идея. Это может быть этически не совсем хорошо, но если кто-то из вас знакомился в сети, то знает, что это как искать кусочек сена в стогу иголок. Ты уколешься 500 раз, прежде чем, что-то из этого выйдет. Однако я хотел автоматизировать процесс только знакомства. Этот же нейроказанова пошел дальше и нейронка общалась с одной из девушек целый год. Практически реализация фильма “Она”.

Во-вторых, мне хотелось бы, чтобы это было правдой. Хотелось бы верить, что в целом уровень технологий у нас достиг того, что простой джун за пару вечеров, соединив пару нейронок и парочку API, может сделать такой проект. Кажется именно для этого мы и создавали компьютеры. Ну не конкретно для пикапа в сети, а для решения наших проблем, короче вы поняли...

В целом наша индустрия началась с машинных кодов, потом ассемблера, потом Си и батоебством. Повышая абстракцию, мы начали думать над бизнес логикой, а не над тем, как правильно байты отправить в сеть. Наверное выло бы круто, что то, что мы сейчас наблюдаем это следующий шаг, когда ты уже думаешь не над конкретной функцией в коде, а еще выше, на уровне целого модуля.

На прошлой работе у меня с корешом возник спор. Я сказал, что мне нравится когда функции в классе, сортированы по модификатору доступа. Сверху все public методы, снизу private, protected и т.д. На тот момент я работал в проекте где было так принято и всех все устраивало. Когда я рассказал это другу, он сказал что больше не завидует шреку, ведь у него теперь тоже есть друг осел. 

Аргументная база у него была в виде ссылки на книгу “Чистый код”, в которой автор описывал почему нельзя сортировать методы по модификатору доступа. Суть “правильного” подхода заключается в том, что ты располагаешь методы по мере их использования. Например, делаешь метод public и если в нем есть метод private из этого класса, но ты располагаешь его сразу под public. Ну понимаете да, чтобы далеко не бегать когда код читаешь. Однако с современными IDE приватные методы можно располагать хоть в Саратове, все равно все проиндексируется.

Значительная часть аргументов касательно кода, сводятся к стилю: А вот X на конференции Y сказал что подход Й хрень и поэтому мы его использовать не будем. И чем более именитый докладчика тем больше ему верят. И казалось бы так делать не нужно, однако других вариантов у нас нет.  В IT нет базиса для аргументации. 

Вот допустим взять хардкорную инженерию, там все упирается в четкие физические параметры и законы, там все споры пресекаются на этом. У нас нет такого базиса. Точнее он есть, это CS, но тут обычно и споров то не возникает. Кто будет спорить что быстрая сортировка лучше пузырьковой? Поэтому вполне возможна ситуация, когда два могучих сеньора могут посраться из-за какой-то фигни и никогда не придут к консенсусу, ведь у одного опыт A у другого опыт B, а проверить на эксперименте, что лучше – потратить время команды впустую.

Вы видели где-нибудь статью, в которой бы взяли один проект и параллельно пытались делать его с применением чистой архитектуры, а второй без применения? Ну такой эксперимент провести в принципе невозможно. Тысячи факторов, которые хоть как-то влияют на качество кода, начиная от усталости разработчиков заканчивая фазой луны.

Поэтому в IT у нас и не научный подход, а более эмпирический чтоли. Исходя из этого забавно, когда люди очень серьезно начинают утверждать, что наша сфера больше относится к инженерии. По факту мы больше писатели.

Начнем с того, какие главы мне показались годными, читая ее даже сейчас.

Вся глава про имена переменных. Вся глава – достаточно годные советы, особенно для начинающих. Особенно нравится часть про префиксы. Я до сих пор помню период, когда большинство Андройд разрабов прочитав книгу “Android программирование для проффесионалов”, всегда использовали префикс m для переменных в Activity. Потому как в этой книге все примеры кода были с этим префиксом и ведь никто не задавался вопросом:  “А нафига?”

Вся глава про комментарии. Тут тоже все по делу, добавить нечего. 

Далее я могу лишь рассказать про отдельные советы, которые встречаются в некоторых главах. Потому как остальные главы, кроме тех что выше, полны мракобесия и рекомендовать их полностью я не могу.

Используйте исключения вместо возвращения кодов ошибок. Довольно хороший совет, однако в нем есть нюансы. Например, как ты в kotlin заставишь пользователя обрабатывать ошибку? И ну он в своей же другой книге наоборот критикует этот подход, потому как исключения порой нарушают принцип инверсии зависимостей. Ну и еще момент, что исключения все таки довольно дорогие с точки зрения перфоманса.

Принцип разделения команд и запросов. Неожиданно, в книге есть ссылка на действительно крутую концепцию, я про нее даже делал пост. Можно докопаться лишь до того, что описана концепция так блекло, что я бы точно ее пропустил при первом чтении. Я считаю что это вообще главный и важнейший совет, который сделает код в разы удобнее и читабельнее

В главе про классы есть подглава про Связность и сцепление. Годная вещь, в которой стоит разобраться, помогает правильно разбивать логику на отдельные классы. И в этой же главе упоминаются принципы SOLID. Принципы в целом то неплохие, но опять-таки тот же SRP, ну вот он настолько абстрактный, я до сих пор теряюсь действительно ли у этого класса одна причина для изменения, поэтому ну такое…

В главе про системы есть хорошее описание того, как нужно отделять инициализацию системы от работающих компонентов. Однако всю главу про системы в целом можно сократить до: разберитесь что такое инверсия зависимостей и DI. 

Ну и совсем аккуратно стоит подойти к главе про многопоточность. В ней есть крутые мысли касательно мифа, что чем больше потоков, тем быстрее программа. В остальном все описано крайне поверхностно и туманно. Про многопоточность я бы советовал прочитать “Java Concurrency in practice”, там куча конкретных примеров и она прям на балансе между совсем дебрями JVM и практической пользой.

Я понял, это теория заговора. Gradle сделали специально переусложненным потому что разработчикам выгодно продавать свои курсы, книги, платные статьи, enterprise версию. Они пришли на рынок под видом более гибкого и простого инструмента, чем maven с его дурацким, неповоротливым xml. Выкурили всех с рынка Android разработки, наверняка заплатили гуглу за это.

Когда же у них не осталось конкурентов, они начали специально усложнять систему, чтобы наживаться на этом. А вы думаете каким образом они монетизируют свое детище, думаете только за счет enterprise версии? Неет, они монетизируют его на боли и страданиях обычных разработчиков. 

Помимо этого, они специально тратят больше ресурсов чем нужно, потому как компании производящие технику также им доплачивают за это. Чтобы большим компаниям приходилось чаще обновлять технику для разработчиков затрачивая огромную кучу бабла. Все переплетено…

У меня в лого канала до сих пор гирлянда и вот наверное стоит заменить лого, но мне делать это также лень, как и убирать елку. Да у меня она до сих пор стоит. И да, я решил обсудить это за пару дней до окончания зимы.

Вы в своих приложениях делаете новогоднюю тему? Ну там падающий снег на сплеше или Санта Клаус возле лого. Самое интересное вот что, довольно часто такие задачи, вроде добавления темы для какого-то либо праздника всегда делаются в последний момент. Всегда было забавно, что для очень большого числа менеджеров новый год наступал неожиданно, типо никто даже не предупредил. Ну и вопрос вдогонку, бывало ли у вас такое, что вы делали новогоднюю тему сильно заранее, например летом?

P.S Я делаю посты про Чистый Код, просто, как всегда, крайне продуктивно...

Ох, уж эти противостояния: Android против iOS, PS против PC, Чистый код против здравого смысла...

Идем дальше, обсудим главу про функции, она крайне потешная. В начале книги Боб приходит цитаты знаменитых крутых разрабов, которые акцентируют на том, чтобы в коде было меньше лишних сущностей в виде классов и функций. Ведь если их слишком много, можно просто запутаться. Не хватает Леонида Каневского, с фразой: избегать кучи лишних функций в книге, никто не собирался.

К сожалению формат телеграмма не позволяет прикладывать фото, поэтому если вам хочется посмотреть как это выглядит, то смотрите в книге сами.

Глава про функции начинается с примера плохо написанной функции. Затем он предлагает исправленный пример, правда с выходными аргументами на которые дальше сам же и набрасывает, но да ладно. Затем начинается веселье, он демонстрирует пример класса, в котором почти все функции однострочные... ну это вообще нифига не читабельно, приходится же постоянно бегать по функциям, туда-сюда.
 
Далее четко утверждает что блоки if, while, try, catch, finally и т.д должны быть однострочными. Удачи сделать break в однострочном while.

Отчасти если выбирать м/у большой функцией и мелкой, то конечно мелкая лучше. Однако если выбирать м/у мелкой и читабельной функцией, очевидно лучше выбрать читабельную 

После идет самая забавная часть книги. Автор пишет, что switch плохо использовать т.к он занимает много места и быстро разрастается запомните этот момент. И предлагает его заменить на абстрактную фабрику блять, где у тебя есть интерфейс, затем реализация и еще несколько классов возвращаемых объектов. Смотришь и в коде фабрики точно такой же сука switch, только теперь у нас фабрика и три отдельных класса, отлично сэкономили место.

Ну это же абсурд. Как это связано с чистотой? Мы тупо на ровном месте заменили простое, понятное решение, громоздим, сложным и менее читабельным. Мне кажется именно из-за этого и пошли шутки про enterprise hello world на 10 классов.

Далее он пишет про унарность функций. Идеальные это функции без аргументов. Совет конечно интересный, только потом он говорит, что плохо когда у функции есть side effect. Знатоки внимание вопрос: каким образом сделать так, чтобы у функции не было аргументов, и при этом она была чистой?
 
Аргументы флаги. Отчасти он прав, флаги в качестве аргументов такое себе, однако они точно не показываю, что функция делает сразу две вещи. Для примера есть функция get(force:Boolen=false) которая по умолчанию выдает какие данные из кэша, а если передать true на вход попытается получить свежие данные.

Можно ли сказать что функция делает две разные вещи? Вроде как нет, и, так и так мы просто получаем данные. С другой стороны можно было бы сделать две функции getFromLocal() ,  getFromRemote() ну вот интуитивно, это кажется менее удобным, занимает больше места, так еще и клиенты начинают знать откуда мы тянем данные т.е в некотором смысле логика начинает зависеть от данных. Короче очень холиварный взброс, тут вообще мне кажется у каждого своя правда и спорит можно бесконечно...

Мне казалось это очевидно, но видимо стоит пояснить всем кто есть в канале. Любая реклама сомнительного характера в обход меня как админа канала, сразу будет удалена, а кто такую рекламу постит отправляется навечно в бан.

Вы можете прикладывать ссылки на свои проекты в github, или ссылки на статьи и видосы. Однако реклама всяких халтур или вакансий в комментах под запретом, давайте вы не будете охеревать!

Я тут слегка пропал, по причине того, что моя критика кода, медленно выросла в целый рофельный доклад на прошлой неделе. На весь доклад в сумме я убил часов 16. Где 6 часов это основная работа, а остальные 10 – боль от мучительных воспоминаний о чистом коде. Это было локальное мероприятие, но надеюсь в этом году я лишусь докладческой девственности и уже выступлю хоть на какой-то конфе.

Идем дальше, а дальше у нас объекты и структура данных. Вот тут вообще глава начинается с такой штуки, которая повлияла на целое поколение Java разработчиков. На меня, в том числе. Я уже упоминал, что немного работал бекендером на Java, и вот на бэке принято делать такие классы как DTO. Просто объекты для отправки результата, мы на мобилки такие делаем когда хотим получить какие-то данные от бэка.

DTO классы всегда делались с методами. Задумайтесь об этом на пару минут: есть класс, он используется исключительно для передачи данных, по факту он просто структура.  Однако мы для доступа к данным все равно делаем геттеры, даже если значения не меняются (т.е final)  и даже если нет никакой логики.

И вот только думая над этим сейчас, я не могу ответить себе на вопрос нахуя? После того как я попробовал go, python, typescript, kotlin я не могу понять, нахера джависты страдали и продолжают страдать этой херней? Почему нельзя напрямую к полю обратиться? Да например в kotlin под капотом как бы генерятся методы, но как часто вы в data классах вы getter подменяете на что-то другое?

И возможно я ошибаюсь, но складывается такое ощущение, что это эта дичь с книги Мартина и пошла. Мы решаем выдуманную проблему, а вдруг нужно будет реализацию подменить в поле. Знаете сколько раз мне такое пришлось делать? 0 раз. А знаете сколько такое нужно было сделать коллегам по бэку? Ответ вы уже знаете.

И это доходит до вообще забавных вещей. У нас есть loombok, что означает что всем было впадлу генерить этот лишний код, однако мыши плакались, кололись, но все равно продолжали кушать кактус.

Мало того, что мы делаем лишние методы, он в книге еще и предлагает все интерфейсом закрывать. Поняли да, типо не класс Point, а интерфейс Point и потом еще реализация PointImpl...

Ну ладно, все что я написал выше уже давно не проблема. В kotlin мы и так обращаемся к полям напрямую (ну почти), а в современной java появились record те же data class из kotlin. Радует что развитие языков убивает странные практики.

Это финальный пост про чистый код. Возможно вы уже подустали от этой темы, но я вынужден довести ее до конца. Последняя глава книги, которую я бы хотел обсудить это глава про тесты, в книге она самая потешная. Я даже тут не буду накидывать тираду про данную, главу, достаточно одного только примера.  Вот пример теста который автору кажется максимально всратым:

@Test
public void turnOnLoTempAlarmAtThreashold() {
    hw.setTemp(WAY_TOO_COLD);
    controller.tic();
    assertTrue(hw.heaterState());
    assertTrue(hw.blowerState());
    assertFalse(hw.coolerState());
    assertFalse(hw.hiTempAlarm());
    assertTrue(hw.loTempAlarm());
}

На самом деле я не вижу особых проблем в этом тесте, да много assert смущает, но тест по крайней мере читабельный и можно понять, что в нем происходит. Как же нужно исправить этот тест, спросите вы? Вот так:

@Test
public void turnOnLoTempAlarmAtThreshold() {
    wayTooCold();
    assertEquals("HBchL", hw.getState());
}

Ну как вам идея придумать свой птичий язык для проверок? Язык который мало того что абсолютно не читаемый, так еще его самого нужно тестировать. Я вообще не понимаю как относится к этому примеру? Возможно автору нужно было сдать быстрее книгу, а идеи кончились, либо Мартин таким образом расписался в собственном неумении писать хоть сколько-то вменяемый код.

Как нужно было сделать в данном случае? Да просто использовать конечный автомат, он тут прям напрашивается и не нужно будет городить свои птичий язык или проверку десятка флагов.

В главе очень много посвящено чистоте тестов. И вот тут как по мне есть проблема, я на практике вижу, что в большинстве случаев тесты не должны быть чистыми. Чистота у нас подразумевает избавление от дублирования, или появления каких-то абстракций. Это в свою очередь усложняет код, а тесты должны быть максимально простыми и читаемыми. В противном случае на сами тесты нужно писать тесты. Потому не ссыте в тестах делать большие функции и дублировать код.