之前的文章中，提及软件开发专业化。今天来简单概况下专业化，主要有如下的几个方面：
1.统一编码规范
通常是Coding Guideline(编码标准)，包括注释，变量，方法名，命名规则。编码标准在好处在于80%的时间里，代码都不是初始编写者来维护或扩展的，仅这一点就足以说明编码标物业从一开始就具备的经济优势。不可维护的代码比其他任何事情都会更快地消耗开发人员的精力。
2.注重软件质量
高内聚，低耦合，低冗余，可测试性，可读性，测试。
内聚是系统内部的各个部分对同一个问题的专注程度，以及这些部分彼此联系的紧密性。用来衡量对目标的专注度或专一性的标准，并且使得实体(类，方法)的命名和理解变得更容易。涉及到方法，类，包，应用程序，系统，解决方案的内聚。
耦合用于描述系统某一部分以某种方式影响系统另一部分的情况。在OOP面向对象编程中，我们指的是两个类，当其中一个与另一个耦合时，第二个类中的变化会使第一个类也发生变化(或需要发生变化)。
质量反映在代码中，一切工作最后都归结为代码。
不得不去处理变更需求是件令人头痛的事情，但是如果代码清晰可读，如果解耦使得代码更易扩展，内聚性强，可以轻松确定系统中必须修改的部分，代码没有冗余，每个修改只需在一个地方进行，那么处理变更请求就会容易得多。
开发高质量代码最终并没有要求你付出更多，只是你需要对资源进行重新分配，以低廉的成本来防止缺陷出现，从而避免代价高昂的修正工作。
计划测试，测试用例，单元测试,集成测试,确认测试,系统测试,验收测试,回归测试,Alpha测试,Beta测试等。而自动化测试发生错误的机率比手动测试要小。程序测试的过程具有破坏性,程序员应避免测试自己的程序,程序设计组织不应测试自己的程序。
3. 注重原则与智慧结晶
S.O.L.I.D, DIY(Don’t repeat yourself),KISS, GRASP (object-oriented design)，YAGNI， Separation of concern(分散关注), Design Patterns(设计模式)，DDD(Domain-driven design)领域驱动设计等这些都是前人总结出来原则与模式。模式本身并不是它们之所以重要的原因，我们之所以有必要知道模式是因为它们能够帮助我们做出优秀的设计，能够帮助我们与同行进行更高层次的沟通，它还为我们提供了一种途径，使人们能够采集我们对某些特殊的，反复出现的开发场景已经掌握的知识。
4. Code Review(代码复查), Code Inspection(代码审查)， Walk-through(走查)
优秀的CodeReview工具可支持设置强制性，未通过Review的代码无法提交的正式的代码库。支持多人Review，标记，评论，类似邮件一样的To,Cc到每个人，与邮件服务紧密结合。甚至应用自动Code Review工具。
代码审查是最正规的审查会议。一个检验的唯一目的是为了在文档中发现缺陷。可以用来检查审阅计划文档，需求，设计或代码，总之，产生在任何产品开发团队。代码审查甚至于具体的规则多少行代码来一次审查，审查会议必须是多长时间，和审查小组的每个成员应该做多少准备，在其他的事情上。
Walk-through会涉及两个或者更多的人，进行设计或者代码的相关讨论，重点在于检测错误，而非修正它们。
5. TDD测试驱动开发，BDD行为驱动开发，结对编程, FDD(Feature-Driven Development)
TDD确保重构能够达到所要求的测试覆盖度，而且，当一个模式在设计中是否适用并不是很明显的时候，TDD可以帮助我们提高设计的质量。
行为驱动开发是测试驱动开发的进化，但关注的核心是设计。行为驱动开发中，定义系统的行为是主要工作，而对系统行为的描述则变成了测试标准。在行为驱动开发中，我们需要使用通用语言来定义系统行为。
结对编程鼓励双方保持双方保持代码的高质量，结对能够使人们在压力之下保持更好的状态，能缩短进度时间表。
FDD是以客户、架构为中心，迭代与演进的实用的软件开发过程。它是敏捷软件开发方法中一种。
6. 软件设计原则与方法
原则: 适于目的，简单，分散关注，易于维护。方法: 抽象是关键，信息隐藏，发现现实世界中的对象，鉴定出可能出现的变化点，使用原则与模式在合适场景下，使用图来做为设计语言。
7. 持续集成(Continuous integration)
实现的目标包括维护代码库，自动化编译，保证快速编译，便于提交最新发布，每个人能看到最新构建结果，自动化部署。实现Daily Build与冒烟测试，与IDE(集成开发环境)集成在一起的工具有助于团队协助，例如微软的Visual Studio Team Found Server，管理Project进度，燃尽图。团队信息共享站点，如SharePoint构建的文档共享与Wiki,与OneNote等笔记工具整合。实现知识分享的工具，又如构建Bugs缺陷跟踪管理系统。
8. 持续交付(Continuous delivery)
自动化开发一切过程(构建，测试，部署，打包，发布), 并把它们集成到版本控制系统。
公司内部花费时间去设计构建这样的自动化平台，后期则能极大得高工作效率，最终也是标准，规范化。 例如，OneBox与虚拟化结合，最终构建一个盒子用于测试与发布。自动化是部署流水线的前提条件。因为只有通过自动化，才能让大家仅通过单击一下按钮就得到他们所想要的。当然，你不需要把所有的东西一次性地全部自动化。在构建、部署、测试和发布过程中，哪个环节是瓶颈。随着时间的推移，最终可以将所有环节全部自动化。通过采用自动构建、测试和部署技术，可以获得很多益处，我们将能够验证变化，重现各种环境中的部署过程，在很大程度上减少产品出错的机会。
最终的目标一致：为了更加快速且可靠地交付有价值的软件，鼓励所有参与软件交付整个过程中的人进来。
行更好的协作。
9. 重构（Refactoring） 
在今天IT信息化发展过程中，必定存在对已有软件维护开发情况，这时还需要重构。重构就是在不改变软件现有功能的基础上，通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。现在还演化出数据库重构，如上面所示。
10. 系统架构文档 
专业的文档应该描述：上下文，变化点，架构决策.
接口文档，组织接口文档，干系人接口文档，用来传达词汇，语义信息。
行为文档，架构设计文档。它们通常会使用到以下描述语言：
UML(Unified Modeling Language)
SysML(System Modeling Language)
AADL(The SAE architeture Analysis and Design Language)
软件开发领域还涉及需求分析，系统分析，架构设计，开发方法论，团队管理，项目管理等体系的内容，在这里未能都涉及。上面各个方面与软件开发专业化与实践点过而止，由于篇幅有限未能展开描述，如有兴趣可以查询相关资料。
希望对你软件开发有帮助。
您可能感兴趣文章:
软件架构中质量特性
企业服务总线Enterprise service bus介绍
作者：Petter Liu
出处：http://www.cnblogs.com/wintersun/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
该文章也同时发布在我的独立博客中-Petter Liu Blog。
