标签：fc7 团队 规范 需要 process 根据 ESS 时代 规模
软件系统随着业务的发展，变得越来越复杂，不同领域的业务所涉及到的知识、内容、问题非常非常多。如果每次都从头开发，那都是一个很漫长的事情，且并不一定能将它做好。团队协作开发时，没有了统一标准，大家各写各的，同样的重复的功能到处都是。由于没有统一调用规范，很难看懂别人写的代码，出现Bug或二次开发维护时，根本无从下手。（无框架不堪回首的黑暗日子请看前面章节的讲述）而一个成熟的快速开发框架，它是模板化的代码，它会帮我们实现很多基础性的功能，我们只需要专心的实现所需要的业务逻辑就可以了。而很多底层功能操作，就可以完完全全不用做太多的考虑，快速开发框架已帮我们实现了。这样的话，整个团队的开发效率可想而知。另外对于团队成员的变动，也不用太过担心，快速开发框架的代码规范让我们能轻松的看懂其他开发人员所写的代码。
搭建快速开发框架时，我们要如何定位
是不是快速开发框架的扩展性、可移植性、功能越强大就越好呢？
好的快速开发框架是相对的，它都有自己特定的应用领域，合适才是最好。
个人觉得在实际开发中要根据具体情况来看的，因为功能越全面它的复杂度就越大，所需要的开发人员能力和技能就会要求更高，付出的成本也就最大。比如做一个还未发展起来的电商网就想 将系统做成像京东那样，直接用京东分模块分布式的框架来开发，那得怎么来组建这个团队？更不用说开发成本了。就算团队有能力做到，也没有那个必要这么去做，因为从成本预算和开发周期等方面来看，得不偿失，更多的可能项目还未完成公司就给拖垮了。
一般来说，一个中小型项目，1到5人左右的开发团队，使用一般的三层结构就可以了，不用去细想框架要分三层还是五层，每个层之间要怎么实现解耦，要用什么设计模式.....因为当今飞速发展的互联网时代，快才是王道，做一个中小型项目能用一周完成的，绝不能拖了一个月还未做完。人工与时间成本才是重点中 的重点，唯有快才能更好的生存下来并壮大。至于扩展功能、接口、分布式、并发、大数据......等等问题，实际上过早考虑太多并不是好事情，有经验的程序员在写这个快速开发框架时早已留下扩展方案或思路，而没到这一层次的开发人员你想再多也可能想不明白，还不如先做出来积累一定经验后再慢慢学习，慢慢升级框架。
当然也不是说设计框架时不用考虑高内聚低耦合，而是要根据自己的能力与经验来设计出自己能把控的框架出来。因为框架不是开发出来后就不再变动，它也需要不停的进行升级，将你所学到的新知识新技术融合到框架中，使它的功能更加强大，更加健壮。而对于自己不能把控的快速开发框架，在团队协作开发和上生产环境后，你就发现有一大堆的坑等着你去填埋，这种框架只能拿来先练练手，有空再慢慢完善。
快速开发框架通过小步快跑，不断的迭代升级来慢慢扩展的，当项目上生产环境后，根据新的需求和所碰到的问题，去不停的调整，最终越来越强大。所有框架都是从1.0版本到2.0、3.0......发展而来，而不是直接跳过最初版本到最终成熟版本。
所以说我们在创建一个框架时，必须根据我们当前个人的技术能力、团队成功技术水平、时间、投入成本、项目现状（规模与需求复杂程度）、以后的发展前景来决定所要开发的框架的最终设计方案。当然也不是说不能一步到位，心有多大世界就有多大，只要个人能力和团队能力配得上，老板资金成本雄厚，时间充足，直接上大项目使用超级框架也完全没有问题。
标签：fc7 团队 规范 需要 process 根据 ESS 时代 规模
原文地址：https://www.cnblogs.com/ymsoft/p/13175584.html
