如果是我带一个团队做项目我会怎么做呢？我时常这样问自己。由于我的想象力比较丰富所以我经常给自己假设这种情景，虽然是假设但是还是些心得体会的，当然这些也是来自实际的工作与学习经验的总结，也并非完全的臆测所得。
我们都知道，在做一个项目的时候我们首先要做的就是获取需求。当然项目规划也很重要，但是那应该属于项目管理方面的，在这里我就不提了因为我不懂这个，虽然最近一直在看这方面的书籍，但是还远远没到能拿出来炫耀的程度，所以我还是和诸位讨论下系统设计方面的经验与体会更实际些。好了，书归正传，我们来研究系统设计。现在假设我们已经从客户那里获得了足够我们启动项目的需求（因为谈论设计，所以需求获取的细节就不说了），此时对于不同的人来说可能会走不同的道路，有些人可能会根据已经有的需求直接去编码实现，当然这些人一般都是刚毕业或者少有项目经验的朋友常犯的错误，或者是美其名曰的“敏捷”，其实敏捷并非没有设计，其实在敏捷的过程中重构环节恰是他的设计环节，再者敏捷是建立在扎实的技术功底以及丰富的基础框架或基础库的基础上的，对于一般工作几年的人或团队来说是不太容易敏捷的（很有天赋的人除外），如果强行去敏捷反而适得其反；当然还有一种人会至少会做少量但是必需的设计，比如说根据现有的需求画系统用例图、画顺序图、系统框图等。其实不要小看这些看似简单的图，他们的作用其实挺大的，就拿用例图来说，通过画用例图可以使我们对获取到的需求有更深的了解，当然也可以通过用例图与用户讨论和确认需求。用例图可能画的人会多点，但是顺序图就难说了，其实对于某些复杂的通信过程我们可以通过顺序图进行清晰的表达，例如一个客户端和服务器间不同命令的通信过程，通过画顺序图我们可以清楚明了的了解到每个命令的交互过程。最后是系统框图，我想如果熟悉MVC的朋友可能会很容易理解系统框图是干什么的以及分层设计的好处，通过框图我们可以将系统分层，为每个分层定义自己的职责、定义每个分层对外提供服务的接口，各层之间的交互都是通过他们暴露出来的接口进行的。分层的好处是能够使系统的结构更加清晰，各自的职责更加明确，每层通过各自的接口对外提供服务，而业务的具体实现会对具体的使用者隐藏，这样当每个层所负责的业务有变更时他们可以更改内部实现而对外的接口并不需要做任何改变，那么这样带来的好处是层与层之间的耦合度自然就降低了，这当然是我们所追求的，因为这样我们维护起来会更简单高效，所以我们在项目的开始是应该离不开系统框图的设计的。当我们必要的设计都按部就班的完成后我们可以进入下一个阶段，对每个层的业务进行分析找到每个分层的核心业务，并将他们作为系统的关注点记录下来，因为这些关注点是决定项目成败的核心问题，所以我们需要重点突破。比如说我们在做的产品涉及到的客户端与服务器之间的通信，那么通信协议的设计就是核心关注点之一，如果我们处理的业务数据量很大，那么大数据量的处理设计可能就是另一个核心关注点。这样当我们记录下所有的关注点后我们就可以有针对性的去设计与解决，当我们解决掉所有的关注点后，剩下的事情应该就是些简单的业务逻辑之类的，这些其实可以很短时间内搞定的。
有些时候我们可能会进入设计的误区，可能有人会尝试设计一个高度智能的系统试图解决所有的问题，但是很不幸，这样的系统是不可能实现的，我们能做的只能是针对不同的问题提供不同的解决方案，也有人提出场景的概念，通过定义不同的场景并解决每个场景中的问题，以达到系统高稳定性和高可用性的目的。我觉得这个挺不错的，通过不同场景的定义我们可以明确不同类型的问题的集合，然后针对每个场景也就是问题的集合制定相应的解决方案，这样通过对不同的问题场景的解决我们就可以获得一整套的系统解决方案，其实这个过程也是一种追求不完美的设计理念，因为试图解决所有的问题是不现实的也是不可能的。
系统设计感悟：
1、获取需求，对需求进行分析，列举将要解决的问题集合；
2、对列举的问题进行分析，提取关注点；
3、对每个关注点进行细致的分析；
4、对需求或问题集合进行场景划分与定义；
5、分别解决每个场景所包含的问题；
6、系统不需要做到完美，而是要做到不完美，解决所有的问题是不现实的也是不可能的；
7、监控和统计分离，好处监控有实时的要求，而统计分析可以不需要实时；
8、可以利用统计分析对用户对系统功能的使用情况以获取更准确的系统改进方案或潜在需求；
不完美的哲学：分离关注点，定义不同的场景，分别解决每个场景所面临的问题！