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