c**l
发帖数: 9003 | 1 标 题: 码工三部曲- 二- (大)系统设计の蹲坑随想
发信站: BBS 未名空间站 (Fri Aug 2 01:41:25 2013, 美东)
码工三部曲 - 序 - 码工与发考题
码工三部曲 - 一 - 码工的素质和修养
码工三部曲 - 二 - （大）系统设计之蹲坑篇
码工三部曲 - 三 - Idea, Research & Execution!
码工三部曲 - 后 - 码工的未来
摘自无底线书评：
<<<<<
四大恶人：“ 老屁蹲坑系列的最好总结： 蹲坑人蹲写得废寝忘屎；蹲坑人蹲看得忘用
手纸；”
马甲：“这是一部让你看到腿麻的作品！”
老梅：“老屁的作品，总是那么屎无前例地考验着我的平滑肌！“
<<<<<<
本文以一位初窥门径的IT民工视角， 用民工蹲坑式的思维写作方式，对（大）系统设
计的实现流程进行粗浅剖析。不求入木三分，但求童叟可欺。现在，让我们开屎吧 。
[ If you don't care about 码工 jobs, you can stop reading now. ]
系统工程就好比建房子，建房子就好比搭积木。如果一个房子满足某个用户功能，那么
一块积木就对应于一个具体的实现模块。所谓“大”系统工程，无非就是实现一个满足
用户多种需求的产品。就像一个猪蹄公园（产品），在这里各种房子（功能）本身成为
了建筑的模块。
=====系统实现======
实现一个大系统大致应该包括如下5个阶段。
阶段一》》产品定义和用户需求
“马桶为什么要坐垫？马桶边缘为什么不直接做成坐垫的形状？为什么呢？”
用户需求定义阶段主要包含三个步骤。
第一步：Idea! Idea! Idea! 。确定要做什么，什么值得做。这一部分仁者见仁，智者
见智，码工三部曲之第三部将会带着大家一起探讨Idea产生的几种pattern和容易犯的
常见错误。
第二步：一个演示用户交互的presentation或者UI mock demo。做好这么个东西后，产
品定义就非常直观了。可以内部讨论后让高层拍板。得到认可之后， 在进入技术细节
之前，进入下一步。
第三步：从工程和用户角度对需求进行分类。一般而言，我倾向将需求划分为如下3类：
1. 不可妥协的部分：一定要有的功能，即launch minimum requirement。假设是F1,
F2。(F as Function)
2. 可以取舍的部分。主要取决于技术或者时间上的风险。这也是属于可以跟PM互相扯
皮的部分，要讲求一些技巧。假设是F3，F4，F5。
3. 锦上添花的部分。目前可做可不做。
第二阶段》》系统设计
“马桶边上为什么放两卷手纸？为什么呢？”
一旦有了明确的用户需求（主要是头两类）定义，下面就是系统设计阶段了。本人主要
遵循几个原则，分别按优先级排序如下：
- 系统的复杂度：越简单越好
- 系统的可维护性：越稳定越好。有现有成熟工具或团队维护尤佳
- 系统的可拓展性：新功能越容易加越好
- 系统的可重用性：前人栽树，后人乘凉。可以被其他项目或者产品使用也不错。但是
这个基本不靠谱也不考虑。有点吃屎忘了拉屎人，本末倒置了。
基于以上原则的详细系统设计步骤：
1. 初步调研+全盘规划：要搞清楚的问题包括：哪些功能目前技术可以做，哪些功能用
什么现有模块做，每个现有模块的优劣势，哪些功能需要新开发模块，时间和技术上开
销的考量等。前期调研阶段对这些因素都要综合考虑，运筹帷幄。不确定的地方快速找
相关的专家熟人问清弄懂个大概（多认识不同领域的人在这个时候就派上用场了）。
2. 初步设计。把用户需求划分阶段确定的需求对应到各个功能模块上，然后草拟一个
大的系统流程，把各个主要模块串联起来。 这里需要注意一点：尽量重用现有模块。
原因很简单：节省时间，简化系统，而且节省将来的维护开销。不要想靠个人英雄主义
搞创造发明。天真地想靠奇兵一战成名的往往死得都很惨。
3. 设计优化。这是一个相对繁琐，需要循环反复的过程。分享一些小心得：
- 去繁求简求稳。检查各个模块，是不是有些可以合并，有些可以替换取舍。举个实际
一点的例子：比方说，用现有模块M1+M2 (M as Module) 能够支持F1+F2+F3, 但是用现
有M1+M3+M4能够支持F1+F2+F3+F4+F5，但是实现M3+M4比实现M2要多花2倍的工程师*天
资源。那么也许可以考虑用M1+M2再加一个customized的新模块M'5就能实现剩下的F4+
F5。在这里，这个方案很可能就是我最后采用的方案，它既保证了我能够顺利按时
deliver 必须有的功能，也有了和PM讨价还价的空间：只要争取把M'5做好就行。
- Plan B。对有疑问的模块，做好最坏情况和最好情况的打算。 准备好plan A和plan
B。这壶万一不开开那壶，千万不要最后逼到一颗树上吊死。设计上偏好那种能够
isolate最坏情况的设计。如有不测，将损伤降到最低，不至于满盘皆输。
- 锦上添花的功能，同理类推，如果是相似的设计，可以优先考虑那些拓展性容易的，
但是这绝不是设计原则的重点。
- 最终设计。在以上基础上，初步定下一套设计方案后，可以邀请主要模块，尤其是不
确定部分的那些模块的的TL过目确认。可能的话，iterate 2-3次最终定下大的流程。
培养这个阶段的能力，需要一定的经验积累，需要对整个公司涉及到当前产品的各个现
有系统模块的功能有比较清楚的理解。不可速成，需要要熬一定的年头。
第三》》 数据流
“为什么大马桶比小马桶冲屎反而省水？”
大方案确定好了以后，便可以开始细化系统实现了。俗话说， devils in details。这
个阶段的目标就是要排除devils，避免将来不可预料的意外。这一阶段的任务就是对于
定义一个流经系统各个模块的数据流（数据格式和接口），以及数据在每个模块内的处
理逻辑。
举个web前端后端应用开发的例子，比方要求如下功能：通过拖放一个页面元素（比如
图片）添加到你的个人收藏夹。出现这么个需求，脑子里10分钟内可能就会出现下列问
题：前端的网页内嵌什么样的代码来实现拖放？什么样的浏览器支持拖放？拖放的时候
怎么支持前端logging用户动作? 拖放结束需要向后台需要发什么类型的数据？发送的
数据要不要加密？这些数据首先到达哪个模块？依次经过哪些模块，做什么样的处理？
如何返回结果？有没有数据需要存储？如何存储? 如何在各大数据中心拷贝从而达到近
乎实时的全球共享？如何cache? 等等等等等等。接下来的几天几周日子里，就需要找
到上面问题的答案，记录下来，然后分享给全体组员作为参考文档。
相信大家都有过准备某次重要presentation的经历，为了做到尽善尽美，上台之前，演
讲稿在心中往往早已默念n遍。数据流设计的冥想也是一样：当你走路时，洗澡时，蹲
坑时，或者睡觉前， 你每次冥想着，指引着系统各个功能的数据， 好比一条条的河流
， 在你的脑细胞间奔流不息。每次冥想之后，往往都能发现一些以前忽略的细节。
数据流冥想习惯一旦养成，后遗症也不少，基本上就是失眠，失语，失禁，但是不失身。
第三》》 系统实现
“小马桶造出大漩涡？干得过吗？”
真正写代码便进入了干苦力活的阶段。 一旦开发具体函数或者功能模块分配到各个人
手上，大伙就开始吭哧吭哧按要求码code写测试，看似无脑运动，但是这其实是个艺术
活。这就好比精工实习的时候，要求在车床上做一个工具扳手，目标就是追求两个字：
好用。如果写一个烂函数，就像做出不合手的工具，怎么用都觉得别扭。要做到“好用
”，一般需要注意几个方面：
- 函数接口： 80%原则。设计函数接口的时候，多从他人角度来想问题。 因为代码
share，码工的工作配合度紧密度很高。码工其实是一种较容易获得同事认可的职业。
你自己写代码的时候，把别的程序员当成顾客来对待。那么，很多时候，只要多花30分
钟，对，就是30分钟，就足够写一个80%情况下好用的接口了。注意，只要80%，不需要
强求做满，很少有一个api能解决100%的问题而又不失简单。api做得太复杂被80%的程
序员顾客complaint 的情况比比皆是。结果是吃力不讨好。
- for readability: 宁可多写几行代码，甚至copy代码，都不要写别人看不懂的代码。
- for scalability and easy maintenance but not future uncertainty. 这个原则
其实和80%原则密切相关。总得来说，还是不用做“过”了。不要迷失在自己想象的需
求中，哪怕很有可能发生，但是只要还没发生，就别急着实现。就像剃刀原理一般：
若无需要，勿增实体。
第四》》 维护和反馈
"马桶怕堵怎么办？装个厨房的insink disposer怎么样？”
如果你设计的是一个好系统。系统有自己的logging, alerting, monitoring 等支持。
那么运行以后，维护起来的代价应该是很小的。在以后这段漫长日子里，可以做的是根
据用户反馈改进系统，做些优化，有利系统长期发展，保持用户稳定增加。选择考量更
新系统，可能是performance ，可能是新功能，也有一些策略，这里就不详述了。
=====系统管理=======
管理实现一个大的项目，技术上是一方面，技巧上又是另一个方面。说说我自己的一些
经验：
1。任务划分和优先级定义。划分任务的时候，应该尽量以并发而不是并行完成为目标
，这样可以消减任务间相互的dependencies。一个fast pacing的team最怕的就是某人
被其他人给block住。定义任务的优先级时，尤其任务多人手不够的时候，一定要分清
主次，抓重点，憋大招，首先确保在主项目线上must-have的任务能够按时完成，锦上
添花的东西可以同步进行或者必要的时候拖后。
2。任务管理。这方面我自己遵循的一个大原则可以概括成：始终将项目保持在一种可
维护和可优化的状态下进行开发。一些小漏洞可以妥协容忍，但是如果出现违背这个原
则的情况要被及时纠正。follow这样的原则最大的好处是为在短期内及时完成项目创造
条件；最大的坏处是可能会遗留下一些todos，使得项目完成初期不能达到尽善尽美。
但是话说回来，没有时间压力的项目都不会是什么好项目，所以这一原则应该还是普遍
适用的。还有一点需要注意的就是，任务开始实施后需要细致follow进度，随时做动态
调整。比方很多时候出现的一些临时性非计划内的任务，它们就如同围棋中的“急所”
， 看似不眼，但其实花不多的时间来解决却能够显著影响整个项目的进展。遇到这类
新问题就需要依靠经验来及时判定和调整了。
3. 松紧结合。对于有经验的队员，不要管得太细。应该放手让他们去做，给予充分信
任。适时友善提醒。着重培养盯牢那些junior的容易犯错的。
4. 好人不过三的113原则。宁可问不同的5个人，每人一个问题，也不要在同一天内，
问同一个人超过三个问题。给同事留下坏印象，惹恼了，是千金难买的损伤。
====闲话你的屎盆======
蹲了这么久，大家都不容易。在结束之前，请大家回过头来，看看聊聊你的屎盆吧。
你的屎盆，这到底是个什么东西？很多人，尤其是一些长期的individual contributor
，被老板或peer指出没有或者缺乏你的屎盆后，就感到很迷茫。觉得屎盆这个这东西很
抽象很悬，不知道怎么才能拥有。
其实你的屎盆这东西再具体不过了，每个人天生就有，关键就看能不能扣到在工作的项
目上。我这里给分享点经验，只要你顺序渐进祭出下面三大法宝，你想不得到你的屎盆
都难。
法宝一：passion
首先，应该做自己喜欢的事情。如果你对自己做的事情没有基情，没有perseverance，
那么很难进入第二阶段。
法宝二：ownership & responsibility
一旦你对某样事物有长期的兴趣。你就会慢慢拥有自己的观点，提出新的问题和解决方
案。 那么你就会对它像自己的孩子一般，开始在乎它，希望拥有它，为它负责，替它
思前想后，比别人想得更多更远更深。
法宝三：leadership
一旦有了ownership, 你的屎盆就是屎到渠成的事情了。你想要解决你的问题，就一定
要有求于人，要推动别人做你想做的事情。只要别人做的是你想做的事情，你就会显得
有leadership，显得比别人聪明。但是实际上呢？只是你先想了一步而已。
passion ==> ownership ==> leadership。嗯，啊，噗通，这就是培养你的屎盆最简单
的按部就班的三部曲。现在你已经得到了它。
终于，腿麻到了起不来的时刻，让我尽快用一首小诗来结束这场讨论吧。最后，再次与
大家共眠。
断续拼凑的 废弃
缠绵积累的 回忆
起起伏伏 起起伏伏
在身体 在脑里 挥之不去
辗转反侧的 压力
反复折磨的 思绪
汹汹涌涌 汹汹涌涌
有时缓 有时急 几乎昏迷
枯竭的脑垂体
干燥的平滑肌
疯狂肆虐的地心力
拉扯 抽泣 放弃 起立
参考文献：
http://wapbaike.baidu.com/view/571034.htm?adapt=1& |
|
