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

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

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

Одни говорят что такое в принципе невозможно сделать в одиночку и что история в целом сомнительная. Вызывает подозрение как количество мэтчей в примерно 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());
}

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

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

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

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

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

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

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

Однако решил я сделать бота для телеграма, который бы ходил в chat gpt и генерил тупые шутки и лютый кринж в чате друзей. Да, по сути делал бы то, что сейчас делаю я. Разумеется я начал делать его на python, ибо рот топтал возиться с системами сборки и компиляцией, на работе этой херни хватает.

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

И знаете что, я либу так и не выбрал! А знаете сколько там конфигов внутри? Один! Только токен бота телеграмма. Казалось бы, просто задай через env и все, я это понимаю, но ничего не могу с собой поделать. Прям как главный герой из фильма прочь, вроде все вижу и понимаю, но ничего не могу с этим поделать…

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

Я снова начинаю учиться писать, кажется за два месяца скилл я знатно подрастерял. Пока я учусь, просто накидаю мысли не о чем. В конце концов у меня афторский проект и не обязательно выдавать годноту каждый раз. У меня включился какой-то дебильный перфекционизм. Формат телеграм канала подразумевает короткие заметки, тупо мысли без особой проработки. Да у меня и канал так называется easy notes. Однако я заметил за собой, что каждый раз когда возникает интересная идея, я ее откладываю в долгий ящик, ведь она недостаточно проработана и нужно над ней подумать еще пару лет. И в итоге вообще ничего не пишу.

Помимо этого, если говорить откровенно, то меня немного подустал android. Не то, чтобы я прям хочу свичнутся в другое направление, но и писать про мобилку становится, мягко говоря скучно. Я стараюсь руководствоваться аксиомой, что если про что-то скучно писать, то читать это будет еще скучнее. Это кстати совет для тех, кто хочет писать статьи. Если вы сильно прокрастинируете написание статьи, ваши читатели будут прокрастинировать с ее чтением. Проверял на себе.

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

Довольно много людей подписались на меня, как на чувака который хейтит Gradle. Я не то, чтобы бы прям его хейтил, но…

Сами подумайте, какого качества вы ожидаете от продукта, у которого логотип, это «зеленый слоник»?)

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

Удивительная вещь заключается вот в чем. Я и до этого пытался делать всякие open source либы, как мне казалось очень полезные. Писал чистый и аккуратный код, писал тесты, даже оформлял красивую доку весь набор перфекциониста. Как мы могли догадаться всем было похеру на мои решения. Тут же я вообще не запаривался и решение взлетело, не то чтобы сильно, но учитывая мои затраты (потратил на нее дней пять) вполне неплохо.

Поэтому просто наблюдение, что в этот раз я сделал по-другому:
👉Хорошее open source решение всегда вырастает из реального проекта, без исключений. Никогда не бывает хорошего open source когда вы сидите и думаете: "о а было бы прикольно сделать X". Хорошее решение это всегда произрастает из реального проекта, в котром нужна штука, которой нет на рынке. Вы делаете эту штуку для себя после чего, по доброте душевной делитесь с миром.

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

Выполняете эти два пункта и у вашего open source решения будет успех. И ответ на главный вопрос: "А нахера эти звезды вообще нужны?". По факту они ни на что не влияют, потому как на интервью никто на github уже давно не заходит. Однако я слышал не одну историю когда разрабов завали в крутые места на работу, тупо по тому, что использовали их решения. Эдакая деверсификация личного бренда…

Я в одном из предыдущих постов писал про то, что в Gradle логирование сделано хреново. Однако вы вообще задумывались где оно сделано нормально? Вот смотрите что я имею в виду.

Возьмем уровни логирования, которые есть в каждой либе: debug, info, warning, error. Уровень debug, это какая-то отладочная информация, которая нужна разработчику помогающая понять, что произошло на устройстве, чтобы найти причину бага. Тут все понятно. Есть error, это буквально когда произошла прям критичная ошибка или приложение вообще упало. Опять-таки это информация для разработчика, чтобы он понял что конкретно нужно фиксить.

А вот warning это про что? Как бы произошла ошибка, но не критичная? Ну можно представить, что это момент когда мы не падаем, но отправляем в крашлитику событие, что у нас что-то пошло не так, допустим. А info это что за зверь? Это уже не уровень debug, но при этом и не ошибка. По названию это как будто бы инфа которую нужно показать пользователю и кстати в CLI программах так и делают, но как будто бы лог это не про показ информации пользователю, а исключительно отладочная инфа.

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

Я еще при этом не упоминал уровни вроде: trace, verbose, fatal, тут вообще пади разбери кто за что отвечает. При этом либы еще могут свои уровни добавлять. В Timber есть уровень логирования wtf. Это уровень, который ломает 4-ю стену, ты мысленно произносишь wtf когда его видишь.

Получается пытаясь решить проблему того, что либы срут кучу всякой лишней инфы в лог, мы пытаемся защититься уровнями логирования. Но это не работает, потому что ты все равно либо фильтруешь по error либо смотришь все логи. Потому как другой разраб мог сделать важный лог как info, так и warn. Да ты и сам каждый раз в растерянности: это warn, это info или это debug? Как будто тратим усилия на решение выдуманной задачи.

Пока я писал предыдущий пост я подумал вот о какой штуке. Смотрите, я говорил о том, что всякие либы придумывают свои уровни логирования и часто странные. Кто писал плагины для Gradle вы знаете, чтобы логи выводились в общую портянку которую генерит gradle, то для этого нужно использовать уровень логирования lifecycle. lifecycle – уровень который включен по умолчанию и выводится всегда, и выключить его можно только через флаг —quiet.

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

В GUI прогах мы много времени тратим на то, чтобы сделать интерфейс минималистичным и удобным. Не показываем пользователю лишнюю инфу и не грузим его (китайские приложения не в счет). Когда же речь идет про CLI мы на это правило забиваем и фигачим в консоль все подряд и логи и результат.

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

По-хорошему, хотелось бы, чтобы если Gradle нечего делать, он бы так и выдавал одну строку: "No task to do". Я пока писал этот пост, думал найти больше примеров CLI программ, в которых эти ошибки допущены, но прикол в том, что большинство популярных прог как раз таки имеют грамотный интерфейс и не выводят лишней инфы. Проблемы возникают только с системами сборки вроде Gradle и Maven, а также во внутренних тулзах которые делаются на коленке.

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

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

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

Аналогичная история и с финтехом в России, он самый крутой, потому что был отсталый. Когда в России только начали всех пересаживать на сайты, в США они уже давно были. По этой же причине VK на заре популярности был в тысячу раз удобнее facebook. Также и pytorch считается более крутой либой для ML по сравнению с tensorflow – мнение не мое, а знакомых MLшиков с которыми общался. Поэтому telegram круче watsapp и этот список можно продолжать бесконечно. Когда ты делаешь решение, похожее на то, которое уже есть, ты сразу можешь двигаться в правильном направлении, изучая ошибки тех, кто был до тебя.

И что же разработкой под мобилку? Среди других индустрий она по сути тоже отсталая, тупо потому что молодая. Ну по факту, мобильная разработка именно в том виде, в котором она есть сейчас появилась с выходом первого айфона. В мобилке все используют решения, которые на фронте появились более 10 лет назад. Мы вот MVI лет 5 назад продвигали как очень крутой, новый подход для архитектуры. А MVI по сути своей базируется на идеях, которые заложены в языке Elm для фронта, который появился в 2012 году. Поэтому в плане холиваров мобильная разработка скучная, мы интегрировали хорошие решения с дескротопов и фронта, а лишнюю фигню не затаскивали (по крайней мере прям трэшовую) и надеюсь это так и останется.

Вот это одна из причин, почему не каждый готов регулярно вести свой блог. Однако меня это пиздец как забавляет. Я пишу: "в мобилке не так много дичи, потому что она появилась позже всех". В пример аналогии привожу автопром Германии, финтех в России, либы для ML. В посте можно доебаться практически до всего, но разумеется я получаю: "Ты че пес, схерали в России лучший финтех?" и срач про регулятов.

Ладно, хорошо, давайте так, дабы снизить температуру ваших кресел я перефразирую: "В России один из лучших финтехов". Разумеется я не пробовал финтех всех стран и это лишь мое мнение. Однако у меня есть приложения 2-х Казахских банков, Американского брокера, Грузинского банка. Помимо этого я видел интерфейсы нескольких Германских банков и честно сказать, ребятам пока еще есть над чем работать. Но пост то про другое!

Касательно того, что во фронте все делают кто как хочет, а вот в мобилках есть вендор и все такое. А ничего что любой фронт выполняется в браузере, который по сути своей та же экосистема? Да этих браузеров больше чем операционок, но все они также закручивают гайки, и ты уже там не сделаешь как раньше все что тебе вздумается. Другими словами, то что на фронте куча вариантов сделать хрень, а в мобилке меньше, никак не опровергает то, что я написал. Потому как вполне возможно (я лишь предполагаю), что те кто стоял у истоков мобильной разработки как раз таки сразу смекнули, что не нужно идти по пути вэба и поэтому у нас есть вот эти гайдлайны, один UI фреймворк вместо огромной кучи и т.д.