VIPER：经验教训
我从来都不是VIPER的粉丝。 此外，我一直同意一个广为接受的观点，即VIPER对于任何应用程序中的大多数屏幕都是过大的杀伤力。
互联网上有大量与VIPER相关的出版物，但事实证明，每个团队都以自己的方式烹饪VIPER。 我在这里浏览我最近的食谱。
原因
我认为技术和体系结构决策应与业务需求同步，并取决于项目的特定情况。 期限和截止日期，项目规模，团队规模，预算等。
每个人都在窃窃私语：“让蛇进来”
该项目于2018年年中作为一个初创公司开始，并且将是一个相当大的长期项目。 现在，该应用程序总共有大约一百个屏幕。
我们从一开始就发展迅速。 我们经常对那些很清晰的部分进行工作，这些部分目前可以立即完成，只是为了推动项目的进行。 当应用程序端的服务器API和业务逻辑准备就绪而设计尚未准备就绪时，这通常导致完全颠倒的开发。
我已经作为该项目的唯一iOS开发人员开始了（ 实际上并没有任何改变 ）。 但是我们有计划在需要时扩大移动iOS团队。
我迫切需要尽可能多的去耦，以处理这些不断的变化，保持应用程序稳定，而不会陷入技术负担。
让蛇进来
继续阅读