Monthly Archives: 三月 2015

想说却还没说的

这篇文章写的
“不管路走了多远,错了就要重新返回。”
—— 土耳其谚语

谨以此文献给两位我尊敬的人。我从他们身上学到了两件事:程序员的自我修养以及用正确的方法做事。

在泰捷工作两年,虽然远未达到优秀,但本着对自己负责的原则,觉得该将零零散散地一些东西整理一下。
(标题来自于《山丘》—— 李宗盛)

理解业务

在接触一个需求时,先问一个WHY。

  1. 在很多场景下,需求可能并不能真正地解决问题。

    需求方很多时候并不清楚问题出现的 根本原因
    产品提了个需求,希望将letv的节目单与youku的节目单合并,这样可以使节目单列表有最新的节目。
    而深入了解之后发现原来只是letv节目单里有个节目因为更新失败而没有最新的节目列表。

  2. 理解真正的需求以及后续可能的需求。

    这需要与需求方多次探讨。需求方或许对产品有一些规划,但还没有很清晰的模型。

  3. 一个简单的需求背后隐含着一系列关联的事件。

    新的一个项目发布在即,需要运维(现在,假设我们是运维人员)提供机器部署。
    然而“我们需要十台机器”并没有提供丰富的信息。

    • “机器是什么配置?”
    • “机器的用途是什么?”
    • “我是否需要给这些机器单独分一个组、一个私有网络、一个路由器?”
    • “这些机器是否需要加上监控?”
    • “除了基本监控,是否还需要业务逻辑的监控?”

    这些都是收到一个简单的需求之后需要深入考虑的问题。

    当然,一套成熟地发布规范能很好地解决这些问题。

到目前为止,我们可以假设需求是“既定”的,不会再发生改变。

鉴于所谓“敏捷开发”模式下,需求通常都比较紧急,我们就需要马不停蹄地开始实现了。

但是,HOW?

如何分解该需求?以怎样的粒度分解?

是否有基础服务可以支持?

是否有相关技术的成功案例(团队内/公司内)可以借鉴?

更重要的一点是, 该方案是否会影响到现有业务

不影响的话,那便是极好。

但我们相信“理想是理想,现实是现实”。

是否需要对现有项目中的相关功能点进行重构,以让新的需求更趋于 概念完整性

做需求不能只是简单的加上一坨代码。

哦,好像需求已经实现了,这真是太好了。

NONONO,需求还远远没有完成。我们只是将技术方案敲定。当然,方案就意味着指示说明书,可以开始愉快地写代码了。

我通常还会再做一件事。WHAT!

对方案的效果与需求方再次确认。

有个逼格很高的词叫“愿景”,也就是确保开发与产品确实是在往同一个方向努力。

如何确认呢?

鉴于大部分程序员不愿意做过多的交流,此时其实还是很为难程序员的。
而一旦程序员不愿意交流,许多问题就由“技术性问题”变成了“社会性问题”。

所以我会不厌其烦地跟需求方聊,跟架构师聊,把小学语文课上学的技能(听说读写)都用上。
Balabala…确认。

最后,我们愉快地决定了。产品对开发表示寄予厚望,开发表示坚决完成任务。

此时此刻,你的工作才真正地开始。

简而言之

对于一个新的需求,我们如何应对?

  1. 当然是,尽可能丰富完善地与需求方确认需求。理解对方的真正意图,以及可能的方向;
  2. 在确认需求之后,规划方案,并推演该方案可能达到的效果,有何难度,与现有业务逻辑有何冲突;
  3. 如果没有冲突,则再好不过,实现之;
  4. 若对现有业务有影响,则与需求方仔细沟通,对现有逻辑的修改还是丢弃;并重复步骤2;
  5. 如此循环,直至方案完全确定。

编码永远没有真正意义上的“结束”。

时间管理

随着你在一个团队慢慢沉淀之后,你会与许多项目有藕断丝连地关联着。
正如刚刚那句话,编码永远没有真正意义上的“结束”。
一个项目也是如此。

代码出现了bug,你得去修复吧?

有了个新需求,你对该项目最了解吧,得做吧?

项目依赖模块/服务更新,你得跟进吧?

要是你整天坐在那里就等着维护项目,那当然是极好。

但你愿意甘当一个“维护型程序员”?

不管你愿不愿意,我反正不愿意。

那么问题就来了:我正在专注于一个项目的开发,老项目的bug来了。

怎么办?这是一种再简单再常见不过的场景。暂停手头上的事情,马上修复那个bug会打断程序员的“流处理状态”。

请跟着我的节奏继续往下看。

“四象限”时间管理法

《高效能人士的七个习惯》 提到:“如何分辨轻重缓急与培养组织能力,是时间管理的精髓所在。”


有关时间管理的研究已有相当历史。犹如人类社会从农业革命演进到工业革命,
再到资讯革命,时间管理理论也可分为四代。

  • 第一代理论着重利用便条与备忘录,在忙碌中调配时间与精力。

  • 第二代理论强调行事历与日程表,反映出时间管理已注意到规划未来的重要。

  • 第三代是目前正流行、讲求优先顺序的观念。

    也就是依据轻重缓急设定短、中、长期目标,再逐日订定实现目标的计划,
    将有限的时间、精力加以分配,争取最高的效率。这种做法有它可取的地方。
    但也有人发现,过分强调效率,把时间崩得死死的,反而会产生反效果,
    使人失去增进感情、满足个人需要以及享受意外之喜的机会。
    于是许多人放弃这种过于死板拘束的时间管理法,
    回复到前两代的做法,以维护生活的品质。

现在,又有第四代理论出现。与以往截然不同之处在于,它根本否定“时间管理”这个名词,
主张关键不在于时间管理,而在于个人管理。与其着重于时间与事务的安排,
不如把重心放在维持产出与产能的平衡上。

史蒂芬·柯维的“四象限”时间管理法可以简单地用一张图来表示:

http://7vijbz.com1.z0.glb.clouddn.com/blog_generic_time_manage.jpeg

对于程序员而言,“四象限”时间管理法同样简单适用。
这是我的“四象限”时间管理:

http://7vijbz.com1.z0.glb.clouddn.com/blog_programmer_time_manage.jpeg

心中有谱

除了时间管理,在做事之前,做到“心中有谱”也非常重要。

何为“心中有谱”,列出即将要做的每一步。

举个例子,今天下午需要对服务器扩容:

See also

任务:18:00之前完成服务器香港机房的扩容

任务分解:

  1. 准备服务器扩容所需资源,包括:服务器镜像、router、load balance等。

  2. 初始化新的集群,包括:连通集群网络、添加监控proxy配置等。

  3. 添加数据库同步。
    1. 分配即将添加的服务器域名
    2. 添加Primary服务器
    3. 配置端口映射
    4. 初始化数据库
    5. 添加MongoDB服务监控
  4. 添加API服务。

在对流程足够熟悉之后,不需要“事无巨细”。唯有一点要求:心中有谱。

提前规划好未来一个小时、一上午、一天的工作,会让你每天获得更多的成就感。

当然,我也意识到,“心中有谱”的难度并不在于“不知道可以这样做”,而在于
“如何在忙得焦头烂额时冷静下来并说服自己‘ 规划对于提高效率至关重要 ’”。

可持续开发

在Morgan Freeman主演的电影《超体》中,露西意识到自己的脑容量将无限扩大,最终无限地
知识都在她脑中爆发时,诺曼教授说了一段很经典的对话:“如果你问我该怎么办,你知道,
当你回想生命之初,我是说从生物演变最初那一刻起,当第一个细胞分裂成两个细胞,
生命的唯一意义一直在于传递已经学到的知识。除此再无更高的意义。
如果你问我怎样处理你那些不断增长的知识,我会说,传递下去,
就像每一个细胞在时间长河里所做的那样。”

说到“可持续开发”,这点其实是我们的不足之处了。

许多程序员都声称“如果只有自己一个人去开发的话,我会更快地实现需求。一旦需求确定下来,
既不需要跟其它开发人员沟通项目进度,也不会出现重复造轮子,也没有任何需要额外学习成本的代码。”

我在独立开发过程中也并未感到目前的开发有什么难度。

但在项目引进新人的过程中就会发现,试图用语言来向他表述当前的代码环境、开发规范、线上部署规范等时,
我得“不厌其烦”(这当然得怨我们自己)地重复解释,才能让他对整个现状有个较为清晰地认识。
即便已经有了较为清晰地认识,在实际操作过程中,仍然会让人有战战兢兢如履薄冰地感觉。

这就像“这个系统维持着银河系最精妙的平衡,以至于连多余的呼吸都会使它一击即溃。”

http://7vijbz.com1.z0.glb.clouddn.com/blog_balance.jpg

这对于初次接触某项目的开发人员无异于一个噩梦。

更有甚者,由于没有丰富的规范,新入手的开发人员在稍微不注意的情况下极有可能自成一套。

从生物学上来讲, 生物多样性 能维护生态平衡,但没有任何系统架构师愿意看到这种结果。

  • “知识库”可以有效地降低学习成本。
  • “知识库”可以包括wiki、问答、推荐、规范、流程、检查点等方方面面。
  • “知识库”可以有效地降低理解上的分歧。
  • “知识库”可以有效地降低沟通成本。
  • “知识库”可以传递。
  • “知识库”可以。。。。。。

以上内容纯属个人瞎扯淡。

http://7vijbz.com1.z0.glb.clouddn.com/blog_life_is_beautiful.jpg