本来是想写最近看到的大型网站的发展演化之路，写着写着就跑偏了，后来就索性抹掉，重新动笔写了这篇。
作为一介码农，我想我是幸运的，从实习至今，我大致看到并经历过不同规模的网站或产品的开发，小到两个人就能撑起一个网站，大到需要和来自不同国家的团队一起合作完成产品开发。产品质量有好有坏，但是开发模式很难评出最优，只能说适合的就是最好的。
小型项目
开发规模
2人左右（其实一个人也可以）
需求
需求确定流程较为简单。因为都是用一套框架做东西，用户群体单一，功能变化不多。所以在项目初期和用户谈好，没有特殊需求，基本就能按照原有的逻辑完成开发。
开发
因为开发模式和流程相对固定，所以不太重视写文档。即使有文档，也可能是存在张三的c盘，张三装个系统，文档就没了，张三离职了，文档也没了，张三自己忘记放哪了，文档还是没了。但是只要项目组老大不走或者自己在项目中干过一段时间，对于项目的逻辑也就比较清楚。
敲代码之前，比较重视的是表结构设计，因为和以往的项目业务流程相似，所以侧重点放在表结构上面。一旦设计好表，基本就可以大刀阔斧的编写代码了。
测试
测试人员就是开发人员，开发人员就是测试人员。自己写过的代码自己做主，测不测由你，出事了有锅就由不得你了，你得来背。但是因为业务流程比较固定，所以出问题的概率较小，这样的小型项目，一般用户也不是很多，相对来说即使出了问题也不是十万火急，有比较充足的时间让你修复。
部署
结合上面再补充下，测试人员即开发人员，开发人员即部署人员。你只需要拷贝出你修复bug后的代码（class文件或者html又或是js文件）放到服务器上（也就是一台电脑），然后重启tomcat。OK，那么你就完成了部署。
中型项目
开发规模
5~10人
根据公司的项目管理制度来决定。有的是一个大组共同开发，也有是将大组在拆分为小组，分别负责相应模块的开发。
需求
需求不再是仅仅由开发人员来对接，一般会有商务法务等角色介入，因为一个项目最终决定是否做，需要从各个角度来考量。不再像小型公司的小型项目都是千篇一律，中型项目具有一定的灵活性，特殊性和扩展性。
经过商务等需求的初步确定，需要内部沟通产品经理和开发团队，对项目的可行性以及项目周期完成评估。最终开发团队将任务拆分为可执行的小任务进行开发。
开发
鉴于中型项目一般拥有相对较大的用户量以及异常激烈的竞争环境，所以开发新功能和业务功能增强较多。开发前要考虑的问题比较多，比如对老接口的向后兼容，对数据库数据对缓存的影响等等。所以，文档显得比较重要，包括接口文档和设计文档。开发人员会先设计文档，其中包括业务流程设计，数据库设计，接口设计和对接等。之后会按照设计文档与多人完成功能开发。
测试
一般团队会配备测试，但是数量不多，仍以开发为主，开发人员往往兼职测试人员。开发人员能够自己完成单元测试，也可以和其他开发人员完成集成测试，还有专业测试人员的补充测试。当然，这个测试流程仍然不规范，但是快节奏的开发和迭代很少能给出充裕的测试时间，尤其是互联网企业。
部署
部署细节不详。但是起码从这里就可以看出比小型项目要谨慎和专业。作为开发人员的我们不再参与部署事宜，我们的最后一道工序就是上线，将写好或者改好的代码上线，之后有相应专业人士配域名和分配主机等等操作最终将项目部署到云端让用户可以访问网站或者使用产品。
##大型项目
开发规模
10人以上（人数也不是评价项目规模的决定性因素，有时候也非正相关关系）
需求
最为开发人员，这时候在项目链中应该是最后一级，你只会从team leader哪里得到一个开发任务。而这个任务可能经过了多道工序。比如经过了客服的问题收集，公司管理层的决议是否接下或者完善项目以及如何做，大区leader如何安排项目进度以及项目人员等，最后到产品经理告知team leader，最后到了你的手上。也许，真正的需求来的比这个还要复杂。
测试
测试人员的数量在项目团队中的比重大大增加，一般一个测试对应2到3个开发人员。他们需要写出详细的测试用例并提交系统，对新功能或者修复的bug进行功能测试，对于修改代码可能对过去功能有影响的，需要针对可能影响功能的模块做回归测试，对于不同环境做充分的测试，后面还会讲到测试也需要开发人员的参与。如此规范的测试流程保证了上线的代码几乎不出问题。
开发
开发人员因为有了规范的设计文档，所以只需要按照文档开发就可以，一般来说文档已经经过仔细的斟酌，业务逻辑一般不会有问题。作为开发人员，需要写好单元测试，可以毫不夸张的说，写单元测试的时间往往比编写功能代码的时间还长。同时对于有些功能还要写集成测试代码，当然，如果公司有自动化测试工程师的话，这活可以交给他们。最终这些功能代码和单元测试以及自动化测试都会在项目编译的时候在jenkins上都跑一遍，如果有问题，开发人员首当其冲就要进行修改。
部署
部署这活对于开发来说是个谜，有点遥不可及，因为产品的服务器可以在世界各地的各个地方，产品可以部署到公司自己的云上。这时候应该需要公司的其他的大部门的合作，最终完成上线对外可以使用。
不同规模的项目有自己的开发模式，有自己的生存方式，指着一个2个人就是提供一条龙服务的小型项目说，你们有没有做回归测试，你们有没有考虑可扩展性和高并发等等，其实不公平也不一定有意义；指着好几百人开发维护的一个产品说你们的产品更新迭代怎么慢，我们一周就能完成，你们怎么不把前端框架换成时髦的angular2.0不把JDK升到8，这么也是不负责任和不切合实际的。
项目有大小，生存各有道！
文章是个人一孔之见，有砖头，求轻拍~~~
如果您觉得阅读本文对您有帮助，请点一下“推荐”按钮，您的“推荐”将是我最大的写作动力！如果您想持续关注我的文章，请扫描二维码，关注JackieZheng的微信公众号，我会将我的文章推送给您，并和您一起分享我日常阅读过的优质文章。
