想说却还没说的
文/Cipher Chen
不管路走了多远，错了就要重新返回。”—— 土耳其谚语
谨以此文献给两位我尊敬的人。
我从他们身上学到了两件事：程序员的自我修养以及用正确的方法做事。
在泰捷工作两年，虽然远未达到优秀，但本着对自己负责的原则，觉得该将零零散散地一些东西整理一下。
标题来自于《山丘》—— 李宗盛
理解业务
在接触一个需求时，先问一个 WHY。
1、在很多场景下，需求可能并不能真正地解决问题。
- 需求方很多时候并不清楚问题出现的 根本原因 。
- 产品提了个需求，希望将 letv 的节目单与 youku 的节目单合并，这样可以使节目单列表有最新的节目。
- 而深入了解之后发现原来只是 letv 节目单里有个节目因为更新失败而没有最新的节目列表。
2、理解真正的需求以及后续可能的需求。
- 这需要与需求方多次探讨。需求方或许对产品有一些规划，但还没有很清晰的模型。
3、一个简单的需求背后隐含着一系列关联的事件。
- 新的一个项目发布在即，需要运维（现在，假设我们是运维人员）提供机器部署。
- 然而“我们需要十台机器”并没有提供丰富的信息。
- “机器是什么配置？”
- “机器的用途是什么？”
- “我是否需要给这些机器单独分一个组、一个私有网络、一个路由器？”
- “这些机器是否需要加上监控？”
- “除了基本监控，是否还需要业务逻辑的监控？”
- 这些都是收到一个简单的需求之后需要深入考虑的问题。
- 当然，一套成熟地发布规范能很好地解决这些问题。
到目前为止，我们可以假设需求是“既定”的，不会再发生改变。
鉴于所谓“敏捷开发”模式下，需求通常都比较紧急，我们就需要马不停蹄地开始实现了。
但是，HOW？
如何分解该需求？以怎样的粒度分解？是否有基础服务可以支持？是否有相关技术的成功案例（团队内/公司内）可以借鉴？
更重要的一点是， 该方案是否会影响到现有业务 ？不影响的话，那便是极好。
但我们相信“理想是理想，现实是现实”。
是否需要对现有项目中的相关功能点进行重构，以让新的需求更趋于 概念完整性 ？
做需求不能只是简单的加上一坨代码。
哦，好像需求已经实现了，这真是太好了。
NONONO，需求还远远没有完成。我们只是将技术方案敲定。当然，方案就意味着指示说明书，可以开始愉快地写代码了。
我通常还会再做一件事。WHAT!
对方案的效果与需求方再次确认。有个逼格很高的词叫“愿景”，也就是确保开发与产品确实是在往同一个方向努力。如何确认呢？
鉴于大部分程序员不愿意做过多的交流，此时其实还是很为难程序员的。而一旦程序员不愿意交流，许多问题就由“技术性问题”变成了“社会性问题”。所以我会不厌其烦地跟需求方聊，跟架构师聊，把小学语文课上学的技能（听说读写）都用上。
Balabala…确认。
最后，我们愉快地决定了。产品对开发表示寄予厚望，开发表示坚决完成任务。
此时此刻，你的工作才真正地开始。
简而言之
对于一个新的需求，我们如何应对？
- 当然是，尽可能丰富完善地与需求方确认需求。理解对方的真正意图，以及可能的方向；
- 在确认需求之后，规划方案，并推演该方案可能达到的效果，有何难度，与现有业务逻辑有何冲突；
- 如果没有冲突，则再好不过，实现之；
- 若对现有业务有影响，则与需求方仔细沟通，对现有逻辑的修改还是丢弃；并重复步骤2；
- 如此循环，直至方案完全确定。
编码永远没有真正意义上的“结束”。
时间管理
随着你在一个团队慢慢沉淀之后，你会与许多项目有藕断丝连地关联着。正如刚刚那句话，编码永远没有真正意义上的“结束”。一个项目也是如此。
- 代码出现了 bug，你得去修复吧？
- 有了个新需求，你对该项目最了解吧，得做吧？
- 项目依赖模块／服务更新，你得跟进吧？
要是你整天坐在那里就等着维护项目，那当然是极好。但你愿意甘当一个“维护型程序员”？不管你愿不愿意，我反正不愿意。
那么问题就来了：我正在专注于一个项目的开发，老项目的 bug 来了。怎么办？这是一种再简单再常见不过的场景。暂停手头上的事情，马上修复那个 bug 会打断程序员的“流处理状态”。请跟着我的节奏继续往下看。
“四象限”时间管理法
《高效能人士的七个习惯》 提到：“如何分辨轻重缓急与培养组织能力，是时间管理的精髓所在。”
有关时间管理的研究已有相当历史。犹如人类社会从农业革命演进到工业革命，再到资讯革命，时间管理理论也可分为四代。
第一代理论着重利用便条与备忘录，在忙碌中调配时间与精力。
第二代理论强调行事历与日程表，反映出时间管理已注意到规划未来的重要。
第三代是目前正流行、讲求优先顺序的观念。
- 也就是依据轻重缓急设定短、中、长期目标，再逐日订定实现目标的计划，将有限的时间、精力加以分配，争取最高的效率。这种做法有它可取的地方。但也有人发现，过分强调效率，把时间崩得死死的，反而会产生反效果，使人失去增进感情、满足个人需要以及享受意外之喜的机会。于是许多人放弃这种过于死板拘束的时间管理法，回复到前两代的做法，以维护生活的品质。
现在，又有第四代理论出现。与以往截然不同之处在于，它根本否定“时间管理”这个名词，主张关键不在于时间管理，而在于个人管理。与其着重于时间与事务的安排，不如把重心放在维持产出与产能的平衡上。
史蒂芬·柯维的“四象限”时间管理法可以简单地用一张图来表示：
对于程序员而言，“四象限”时间管理法同样简单适用。
这是我的“四象限”时间管理：
心中有谱
除了时间管理，在做事之前，做到“心中有谱”也非常重要。何为“心中有谱”，列出即将要做的每一步。举个例子，今天下午需要对服务器扩容：
任务：18:00 之前完成服务器香港机房的扩容
任务分解：
1、准备服务器扩容所需资源，包括：服务器镜像、router、load balance 等。
2、初始化新的集群，包括：连通集群网络、添加监控 proxy 配置等。
3、添加数据库同步。
4、添加 API 服务。
- 分配即将添加的服务器域名
- 添加 Primary 服务器
- 配置端口映射
- 初始化数据库
- 添加 MongoDB 服务监控
5、…
在对流程足够熟悉之后，不需要“事无巨细”。唯有一点要求：心中有谱。提前规划好未来一个小时、一上午、一天的工作，会让你每天获得更多的成就感。
当然，我也意识到，“心中有谱”的难度并不在于“不知道可以这样做”，而在于“如何在忙得焦头烂额时冷静下来并说服自己‘ 规划对于提高效率至关重要 ’”。
可持续开发
在 Morgan Freeman 主演的电影《超体》中，露西意识到自己的脑容量将无限扩大，最终无限地知识都在她脑中爆发时，诺曼教授说了一段很经典的对话：“如果你问我该怎么办，你知道。当你回想生命之初，我是说从生物演变最初那一刻起，当第一个细胞分裂成两个细胞。生命的唯一意义一直在于传递已经学到的知识。除此再无更高的意义。如果你问我怎样处理你那些不断增长的知识，我会说，传递下去，就像每一个细胞在时间长河里所做的那样。”
说到“可持续开发”，这点其实是我们的不足之处了。许多程序员都声称“如果只有自己一个人去开发的话，我会更快地实现需求。一旦需求确定下来，既不需要跟其它开发人员沟通项目进度，也不会出现重复造轮子，也没有任何需要额外学习成本的代码。”
我在独立开发过程中也并未感到目前的开发有什么难度。但在项目引进新人的过程中就会发现，试图用语言来向他表述当前的代码环境、开发规范、线上部署规范等时，
我得“不厌其烦”（这当然得怨我们自己）地重复解释，才能让他对整个现状有个较为清晰地认识。即便已经有了较为清晰地认识，在实际操作过程中，仍然会让人有战战兢兢如履薄冰地感觉。这就像“这个系统维持着银河系最精妙的平衡，以至于连多余的呼吸都会使它一击即溃。”
这对于初次接触某项目的开发人员无异于一个噩梦。更有甚者，由于没有丰富的规范，新入手的开发人员在稍微不注意的情况下极有可能自成一套。
从生物学上来讲， 生物多样性 能维护生态平衡，但没有任何系统架构师愿意看到这种结果。
- “知识库”可以有效地降低学习成本。
- “知识库”可以包括 wiki、问答、推荐、规范、流程、检查点等方方面面。
- “知识库”可以有效地降低理解上的分歧。
- “知识库”可以有效地降低沟通成本。
- “知识库”可以传递。
- “知识库”可以...
以上内容纯属个人瞎扯淡。
正文到此结束
热门推荐
相关文章
Loading...
![[HBLOG]公众号](http://www.liuhaihua.cn/img/qrcode_gzh.jpg)
