Комментарии 9
Первым делом создадим подкласс от UITableView и назовем его AdaptedTableView
дальше не читал
Я думаю, что все же найдутся люди которым это будет полезно. NLizogubov — посмотрите в сторону TableKit, уверен вам понравится ))
storoj Можете описать проблему подробнее? Если есть какая-то конструктивная критика, с большим интересом готов выслушать и исправить свою ошибку)
почему?
MVVC, Viper блабла это все набор слов «стильных модных молодежных» ребят-теоретиков, который любят на кухне поговорить о философии, блабла, эти люди восприминимают проект как полигон, где можно потестить всякие фреймворчики и т.д. все — кроме выполнения плана и получения зарплаты в конце месяце, такие люди думают не о том, что продукт должен приносить бабло, чтобы прокормить разработчиков.
если по существу, mvvc/viper/итд — все это полная херня. из статьи столько модных всяких слов, адаптер отдельный, протокол, фабрика, блабла. работал я с таким любителем-теоретиком — за 3 года так и не могли выпустить mvp, потому что не тру. а можно было просто все это запихнуть во viewcontroller и рубить капусту — так и объяснил учредителю, почему в его компании так долго разрабатывали первую версию приложения.
если по существу, mvvc/viper/итд — все это полная херня. из статьи столько модных всяких слов, адаптер отдельный, протокол, фабрика, блабла. работал я с таким любителем-теоретиком — за 3 года так и не могли выпустить mvp, потому что не тру. а можно было просто все это запихнуть во viewcontroller и рубить капусту — так и объяснил учредителю, почему в его компании так долго разрабатывали первую версию приложения.
Самый глупый комментарий, который я когда-либо читал;) Соглашусь только с тем, что в некоторых случаях, поговнокодить будет профитней. Но как только проект перевалил фазу MVP, его нужно регулярно поддерживать. И без всяких MVVM/VIPER и т.д. будет очень трудно обновлять приложение, чтобы и дальше «стричь с него бабло». Архитектуры нужны, что бы в коде был поряд и этот код можно было поддерживать. А всякие «модные слова, адаптер отдельный, протокол, фабрика, блабла» — нужны, для того чтобы разработчики не общались между собой как грузчики: «вот эту хреновину добавляешь в эту хреновину, чтобы та хреновина стала работать...»
В целом, статья хорошая.
В целом, статья хорошая.
а сколько я глупых проектов видел, которые высосали кучу бабла из учредителя так и не запустившись, потому что набрали «умных» ребят, которые перед началом разработки mvp начали настраивать всякие team city, внедрять модную архитектуру, и переписывать ее изо дня в день, пообщавшись на кухне и писать юнит-тесты на пустом месте, потому что так правильно! конкретный пример знаю еще: ребята выпросили у руководства сразу мощный сервер за 30 тысяч, ну потому что а вдруг у нас после запуска будет резко + 100 000 пользователей… и в итоге пока разрабатывался mvp, сервер продляли год по такой цене! гуляй страна! контора платит!
Я с Вами соглашусь;) Неопытные разработчики уровня мидл, без надлежащего присмотра, всегда что-то переписывают, переделывают, рефакторят и т.д. т.п. На мой взляд, главное отличие синьор разработчика от мидла, это понимание бизнес значимости проекта, фичи, технического решения. Разработчик с опытом понимает, что он в первую очередь зарабатывает деньги, а не делает красивые архитектуры. В Ваших случаях, скорей всего, не хватало толкового лида для любителей попить чай и все настроить, который бы дал по ушам, за лишний рефакторинг и сказал бы, где нужна архитектура, а где лучше сделать код попроще.
Но это никак не уменьшает значимости MVVM/VIPER/MVC, там где это реально необходимо.
Хорошего дня!)
Но это никак не уменьшает значимости MVVM/VIPER/MVC, там где это реально необходимо.
Хорошего дня!)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Адаптируем UITableView под MVVM