软件设计杂谈<一>

　　disclaimer: 本文所讲的设计，非UI/UE的设计，单单指软件代码/功能本身在技术上的设计。UI/UE的主题请出门右转找特赞（Tezign）。

　　在如今这个Lean/Agile横扫一切的年代，设计似乎有了被边缘化的倾向，做事的周期如此之快，似乎已容不下人们更多的思考。MVP（Minimal Viable Produce）在很多团队里演化成一个形而上的图腾，于是工程师们找到了一个完美的借口：我先做个MVP，设计的事，以后再说。

　　如果纯属个人玩票，有个点子，hack out还说得过去；但要严肃做一个项目，还是要下工夫设计一番，否则，没完没了的返工会让你无语泪千行。

　　设计首先得搞懂要解决的问题

　　工程师大多都是很聪明的人，聪明人有个最大的问题就是自负。很多人拿到一个需求，还没太搞明白其外延和内涵，代码就已经在脑袋里流转。这样做出来的系统，纵使再精妙，也免不了承受因需求理解不明确而导致的返工之苦。

 

　　搞懂需求这事，说起来简单，做起来难。需求有正确的但表达错误的需求，有正确的但没表达出来的需求，还有过度表达的需求。所以，拿到需求后，先不忙寻找解决方案，多问问自己，工作伙伴，客户follow up questions来澄清需求模糊不清之处。

　　搞懂需求，还需要了解需求对应的产品，公司，以及（潜在）竞争对手的现状，需求的上下文，以及需求的约束条件。人有二知二不知：

1. I know that I know

2. I know that I don’t know

3. I don’t know that I know

4. I don’t know that I don’t know

　　澄清需求的过程，就是不断驱逐无知，掌握现状，上下文和约束条件的过程。

　　这个主题讲起来很大，且非常重要，但毕竟不是本文的重点，所以就此带过。