软件开发中的一些疑惑和探讨

         我们今天聊一聊我们软件开发中遇到的一些困惑和疑虑，一起探讨下其背后的深层次原因。

        做开发也许有好多年了，我们每次看到高端的架构思想方法时，总觉得没有和应用很好的结合起来，我们就会起了怀疑，到底是架构设计实践不够，还是对各种实现的分析和思考太少了？其实，我们缺少的不但但是架构的实践，还有不同场景的实践，例如我们可能平时做企业应用架构，流量少，没什么数据，复杂的地方全在业务逻辑上，这个时候我们讲大数据、高并发就很难带入场景里，还有一些架构，不自己搭一遍是很难了解其中的优缺点的。所以我们有机会要自己把看到的一些好的架构用原型搭一遍，造出一些数据，用工具模拟压测一下，也许feeling就出来了。有的时候迫切的业务需求会促使我们更去跟实际应用相结合。

       正规的软件开发流程，一般设计的规范文档有哪些呢，作用又是什么？对于瀑布模型，每个阶段结束后都有对应的验收文档，敏捷开发是根据项目需要写必要的文档。有些团队在测试阶段，有测试用例文档、测试验收报告，发布前还有部署文档、维护手册，但是在敏捷开发中这些都被自动化测试工具、部署脚本等替代了。所以我们总结必要的文档，有设计类文档，用来记录需求设计、架构设计等评审，说明类文档，用来规范API、配置、操作等，便于规范和统一，报告类文档，用来验收、故障、调研等。

      针对软件外包问题，考虑人员水平参差不齐，稳定性差，我们需要考虑优先项目稳定、低成本运行，业余可以考虑做一些新项目，甚至开源项目来提升自己的技能，当然我们在项目选型开源项目时要考虑开源项目代码质量、有无测试、文档的健全度、Issue的处理情况，最后更新时间、Star数量，google和stackoverflow的使用问答情况。

      对于技术选型，我们需要考虑技术可行性和风险是否可控，我的原则基本是成熟的好过新酷的、流行的好多小众的、团队熟悉的好过陌生的、简单的好过复杂的、开源的好过商业的。

      关于项目架构重构问题，我们首先需要写一部分自动化测试代码，保证重构后这些测试代码能够帮助我们检测出来问题，也就是测试驱动，然后在重构模块的时候，老的代码需要保留，用一些开关来回自如切换新旧代码，自动化测试通过后再部署测试，完全没问题了可以考虑删除旧代码。

     互联网架构和企业应用架构的区别和联系；企业架构迭代快，用户规模大，业务相对单一；企业应用通常业务比较复杂，针对特定行业结合，用户规模要小，这些特点，都会影响架构设计的选择。