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