如何理解程序设计和架构设计中“简单”这个词?

简单是如何服务于敏捷开发，怎么样的简单有助于真正的敏捷？很多人将简单理解成，直观，易懂，但这并非是简单。

所说的“简单”，可以理解为“恰如其分”，即不会置架构设计于不顾，亦不会以风险驱动过度架构，选择适当的技术、设计降低项目中的风险。

先理解一下，什么是敏捷里的简单？

其设计源自kent beck的极限编程。 kent beck是解释过这个实践的含义的：

即：通得过测试、揭示意图、没有重复、没有不必要的元素。主要表现在管理、沟通、需求分析、系统设计四个过程中。

1.团队管理

平行组织的、自组织的团队是敏捷开发团队的特点，团队成员之间上下级关系淡化、没有管理和被管理关系，成员之间的关系变得更加简单。团队目标一致、团结协作、各司其职是敏捷开发所追求的目标。

2.简单沟通

其在沟通中不要求繁文缛节的文档，表现的是面对面，即直接沟通，因此。

3.需求管理

在敏捷开发过程中决定需求是否采纳和优先级排序的标准是商业价值，进而保证敏捷开发交付呈现的是商业价值，而非单纯的功能。其追求在复杂的业务中提取简单的场景，注重实效。不进行需求变更设置复杂的控制，坚持“拥抱变化”。

4系统设计

敏捷开发的系统设计遵循KISS（Keep it simple and stupid）原则，，即尽量保持设计简单。敏捷开发的系统设计遵循Just Enough原则，也就是够用就好，不做功能预测，不追求超前设计和过度设计。设计的风格上遵循最小化设计（little design up front）的原则，在能把握整体风险的情况下，利用演进的方式对架构进行调整，结合重构、TDD、持续集成等方式来降低架构演进过程中对局部代码修改造成的风险。