Недавняя слегка хайповая история с Антоном Назаровым натолкнула меня идею периодически делать обзор на текущее состояние дел в мире разработки. Дело в том что сейчас 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 разрабов, которые изза этого пилят некачественный продукт, но зато пишут статьи о том, какие они молодцы.
Команда наверняка больше чем нужно, а сроки разработки явно в разы больше чем могли бы быть. Причем время они тратят не на распитие смузи, а на попытки решения детских проблем, которые сами себе сделали.
Формошлепов в индустрии стали считать нормальными разработчиками, и это и есть деградация общего уровня в индустрии. Даже само понимание того что деградация идет, и она ощутимая отсутствует
А в чем собственно обзор заключается? Это больше похоже на развернутый комментарий. Особенно забавляет, что статья была на хабр, а этот "ответ" автор публикует на VC, т.к. на хабре это не вышло бы за пределы песочницы)))
Какой контент, такой и обзор. Ты лучше по делу ответь, своим снобизмом ты приравниваешь себя к авторам хабра-статьи
На хабре у меня 4 аккаунта в бане уже, еще один лень регать
Ну в таком случае у меня больше нет вопросов ¯\_(ツ)_/¯
каждый мнит себя стратегом
Один знакомый разработчик, когда видит примеры откровенно слабых информационных дизайнов, архитектур и антипаттернов, может громогласно на весь митап заявить: "Вон из профессии!"
Иногда понимаю такую реакцию. Когда спикер утверждает, что тут сложность O(1), но она вызывается много-много раз, и получается медленно, начинает сильно припекать.
И, да, соглашусь, что подавляющее большинство разработчиков (80-90% от общего числа) не могут работать, если архитектор не подготовит правильную постановку задачки, когда разрабу остаётся только написать несколько функций и встроить их аккуратно в кодовую базу.
Они получаются чем-то вроде инструментов, используемых архитектором в своей работе по созданию решения.
Что-то вроде переводчиков. Никакой реальной добавленной полезности не создающие, но помогающие упростить переписку. Google Translate помножил на ноль много зарплат таких вот работников.
Но, как мне кажется, самый главный вопрос - сможет ли какой-нибудь Google реформировать отрасль разработки ПО, как это получилось с переводами? Куда денутся эти 80% разработчиков, если (когда) появится возможность от них избавиться без потери в качестве/стоимости/сроках разработки?