Я с Вами соглашусь;) Неопытные разработчики уровня мидл, без надлежащего присмотра, всегда что-то переписывают, переделывают, рефакторят и т.д. т.п. На мой взляд, главное отличие синьор разработчика от мидла, это понимание бизнес значимости проекта, фичи, технического решения. Разработчик с опытом понимает, что он в первую очередь зарабатывает деньги, а не делает красивые архитектуры. В Ваших случаях, скорей всего, не хватало толкового лида для любителей попить чай и все настроить, который бы дал по ушам, за лишний рефакторинг и сказал бы, где нужна архитектура, а где лучше сделать код попроще.
Но это никак не уменьшает значимости MVVM/VIPER/MVC, там где это реально необходимо.
Можно быть одним iOS разработчиком, но команда состоит из менеджера, заказчика и много других людей, с которыми стоит (ИМХО) вести себя как джентльмен.
Я тоже довольно долго был одним, но последний год работаю в основном в команде. И по опыту понял, что токсичность, в первую очередь с моей стороны, ни к чему не хорошему не ведет. Даже наоборот, вежливость открвает много возможностей.
«iOS потому, что я сам iOS разработчик и являюсь частью команды. Правила довольно общие, поэтому подойдут для любого направления в разработке программного обеспечения и не только.»
Отдельно хочу прокоментировать ситуацию: задача на один день, а ее неделю не сдают. Это уже вопросы к тимлиду. Зачем отдал задачу тому, кто не может ее сделать? Разве нет понимая уровня способностей своих подчиненных? Почему не поинтересовался прогрессом на следующий день, когда предполагалось завершение работы над задачай? Почему ждал неделю и потом сам все исправил? Это, ИМХО, сведетельствует о некомпитентности тимлида, который неправильно распределяет задачи и не следит за прогрессом.
Вы ошиблись, адресовано скорей джуниор и миддл разработчикам, которые, просматривая код, вдруг решают что-то порефакторить. И проблема тут не в ранимости, а в том что в результате изменений в коде ни автор не может быстро сориентироваться ни тот, кто рефакторил до конца не понимает, для чего этот код был написан. Как раз таки появляются проблемы для бизнесса, увеличиваются затраты времени на внесения изменений или багфикса.
По поводу первой цитаты, я не понял смысла комментария.
По поводу второй, лично я придерживаюсь мнения, что следует соблюдать выбранную архитектуру. Это мое субъективное мнение:) Такой вывод я сделал для себя, после того как на практике такие вот экраны с одной кнопкой разрастались в функционале и уж лучше сразу сделать все правильно, чем потом переделывать.
Спасибо за комментарии! Мне очень интересны мысли других разработчиков;)
Но это никак не уменьшает значимости MVVM/VIPER/MVC, там где это реально необходимо.
Хорошего дня!)
По поводу второй, лично я придерживаюсь мнения, что следует соблюдать выбранную архитектуру. Это мое субъективное мнение:) Такой вывод я сделал для себя, после того как на практике такие вот экраны с одной кнопкой разрастались в функционале и уж лучше сразу сделать все правильно, чем потом переделывать.
Спасибо за комментарии! Мне очень интересны мысли других разработчиков;)