Обзор на плохие проекты. Часть 1

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

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

Вот, например, кейс который привлек мое внимание. Некий, Рубанов Михаил, iOS разраб из Dodo-пиццы, написал пост о том, как они решали проблему медленного запуска приложения.

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

Проблему решили, приложение запускается в 2 раза быстрее, вкладки не тормозят и т.п

Казалось бы, все круто? На самом деле нет. И сейчас я объясню почему, по пунктам.

В приложении много кода, много классов и они как-то связаны

Я ради интереса скачал приложение, там 4 экрана. Основных, конечно там есть еще дополнительные, в сумме там экранов 10-15. Часть из которых полупустые с минимумом логики. Т.е. приложение маленькое. И должно быть простым. Какого хера там много кода и много классов?

Недавно видел проектик на 2 экрана на VIPER, так вот там 10+ файлов на каждый экран, суммарно больше 20. На 2 простых экрана, Карл. Вот у додо видимо такая же ситуация.

Очень своевременно нам попалась статья Dependency Injection in Swift

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

Они использовали либу для Dependency Injection, которая по их же словам создает такие проблемы: долго извлекаются зависимости при появлении каждого экрана, очень сложно дебажить, и т.п. Как решили эти проблемы? Заменили на другю либу с помощью костылей и создания других проблем.

По логике, концепция Dependency Injection решает какую-то проблему, ради которой можно потерпеть вышеописанные. Какую же?

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

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

Сформулирую проблему еще раз более четко:

По вашему что, быть разрабом - это кнопочки на форму кидать?

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

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

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

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

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