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

В закладки

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

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

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

В чем проблема?

В приложении много кода, много классов и они как-то связаны. Чтобы управлять этими связями, мы использовали Dip (читай: Swinject)

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

Как решили?

Тем не менее, стало ясно, что нужно выпиливать Dip. А на что менять? Очень своевременно нам попалась статья Dependency Injection in Swift.

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

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

В чем проблема на самом деле?

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

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

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

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

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

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

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

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

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

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

Команда разработки в полном составе не умеет проектировать, т.е. ни один человек в команде не владеет своей специальностью вообще

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

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

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

Выводы

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

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

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

Материал опубликован пользователем.
Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Илитный Иксперт", "author_type": "self", "tags": [], "comments": 5, "likes": 1, "favorites": 5, "is_advertisement": false, "subsite_label": "dev", "id": 108511, "is_wide": true, "is_ugc": true, "date": "Sat, 22 Feb 2020 00:06:44 +0300", "is_special": false }
0
5 комментариев
Популярные
По порядку
2

А в чем собственно обзор заключается? Это больше похоже на развернутый комментарий. Особенно забавляет, что статья была на хабр, а этот "ответ" автор публикует на VC, т.к. на хабре это не вышло бы за пределы песочницы)))

Ответить
0

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

На хабре у меня 4 аккаунта в бане уже, еще один лень регать 

Ответить
1

 На хабре у меня 4 аккаунта в бане уже

Ну в таком случае у меня больше нет вопросов ¯\_(ツ)_/¯

Ответить
0

каждый мнит себя стратегом

Ответить
0

Один знакомый разработчик, когда видит примеры откровенно слабых информационных дизайнов, архитектур и антипаттернов, может громогласно на весь митап заявить: "Вон из профессии!"
Иногда понимаю такую реакцию. Когда спикер утверждает, что тут сложность O(1), но она вызывается много-много раз, и получается медленно, начинает сильно припекать.

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

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

Но, как мне кажется, самый главный вопрос - сможет ли какой-нибудь Google реформировать отрасль разработки ПО, как это получилось с переводами? Куда денутся эти 80% разработчиков, если (когда) появится возможность от них избавиться без потери в качестве/стоимости/сроках разработки?

Ответить

Прямой эфир