作为软件工程范畴的iosApp，为了保持代码的可维护性和扩展性，必然要遵守软件的基本特性，众所周知高内聚低耦合的程序才能具备这样的特性。
首先，不能依赖于storyboard和xib，原显而易见。第一点是，在源代码管理方面，在团队项目中，一旦有人改变了一点内容storyboard就会显示modify的样子，所以让人看起来很不安，其实带着M的原因很可能就是其他团队成员鼠标手点击了一下而已，最新的源代码管理工具在Xcode中的集成基本上解决了这个问题，但是依然还是会产生严重的代码冲突，这不是团队人员想要见到的样子，所以，很少有用户体验和功能强大的app是采用storyboard的形式的。
下面来聊一下如何能让代码更加的易于维护和易于扩展。
我们在工作中最重要的是什么？当然是进度。我们对于代码的功能抽取和模块重构自然是没法跟上进度的更新的，所以我们需要一个懂得软件生命周期并且看中软件未来的领导来带领团队。开始的时候我们可以为了产品的成型速度而放弃代码的抽取甚至于为了产品能早点上线而写出控制器很重的代码，其实在很多公司中都是这样的上千行的控制器随处可见，国内某地图应用产品的控制器竟然有2+w行，这其中的重复代码和层的代码自然是非常之多的。后期的维护真的很难进行下去。而这个时候作为团队的主管，就需要为团队的为了和公司的为了做出牺牲了，尽量敦促团队成员规范的进行代码的编写，产品经理总是在崔，最为老大的你需要做的是在程序猿和产品之间进行斡旋，即不能忽略产品也不能完全牺牲猿们。斡旋的功夫大家自然都是懂得的，这里讨论的只是程序猿需要遵守的：
1.代码必须进行层次划分，为了赶工期可以产生重复的代码，或者未抽取父类的很多的类，但是代码必须是让版本控制牢牢把控的。
2.刚刚拿到任务的人，除非是工作了许久的大牛，否则，基本都是在试水的，不可能直接完成某个模块的顶层类和方法的抽取，当然模型除外，因为产品设计阶段基本已经完成了这个任务。可以先试着去完成功能，然后在进行代码的顶层父类或者重复功能的抽取。
3.一定要遵守MVC的设计思路，不要出现在控制器中进行属性赋值的操作，而是通过对象来进行数据的传递，作为桥梁的控制器，如果负担过重的话必然会产生程序的不稳定性。
4.本文仅仅是作者自己的心得体会，只是想要记录下来和大家分享。
在设计IOSapp时为了代码的扩展性可可维护性需要遵守的原则,布布扣,bubuko.com