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

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

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

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

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

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

небо синее, мойте руки с мылом... жаль линия между играется/генерит велью всегда будет субьективна. Один мамкин кодер не пропускал мои PR потому, что у него в каждом классе для пустой строки была константа EMPTY_STRING = "" и так надо было везде. Скорее всего у меня тоже есть какие-то требования, которые покажутся кому-то тут мастурбацией... Но по опыту, 100% команд которые пытались организовать код были лучше, чем те, где была свалка. Даже если их иногда заносило.

И опять крайности

Сейчас речь про то, что хороший инженер - который ищет компромисс

не, ну я за common sense, мир, жевачка.

А не сравнение свалки/не свалки

А я за конкретные вещи

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

А не так, чтобы сесть и переписать с одного фреймворка на другой и зваться синьорами

И знаете ли, на моём опыте огромные проекты имеют успех в большинстве из-за того, что быстрее выехали на рынок и их инженеры были на одной волне с продуктом.
Да, с компромиссами, что где-то что-то отваливается и сырое.
Есть, конечно, исключения, где надо вкладываться в качество (банки, безопасность, рантаймы, большинство системного софта, библиотеки).
Но на практике чтобы просто двигать кнопки и жесоны перекладывать (90% проектов) и как ответственность разделять - уже всё за вас давно придумали.

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

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

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

Нам всем может быть и не на чём было бы писать кроме iOS. Так что следует держать в уме и про долг перед продуктом.

не думаю, что кто-то будет с этим спорить. Кажется очевидным и логичным. Но это все рассыпется, когда дойдет до конкретного проекта, потому что нет никаких метрик на такие скользские вещи. Кому-то кажется, что airbnb заигрался, но может (и скорее всего) оно вам просто не нужно, а для их задач в самый раз. Что насчет Arrow? Ребята вообще из аутсорс агенства какого-то, 47deg.com. Как в аутсорсе кто-то вообще рискнул такое затащить? В монады балуются, еще KEEP для type classes написали. И ничего, для них работает. CTO сам в kotlinlang слаке сидит, контрибутит там что-то )). Видимо это их понимание баланса между бизнесом и кодом.

кстати, неплохо бы их позвать в подкаст, как они докатились до такой жизни.

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

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

Эйрбнб лишь попался под руку. Проблема то куда глобальнее - нам приходится пользоваться результатами их(и не только) работ. И когда ты слушаешь как круто то сделали, как круто это сделали а в итоге у тебя приложение падает. Ну тут как бы возникают вопросы.