想说却还没说的_最新动态_新闻资讯_程序员俱乐部

中国优秀的程序员网站程序员频道CXYCLUB技术地图
热搜:
更多>>
 
您所在的位置: 程序员俱乐部 > 新闻资讯 > 最新动态 > 想说却还没说的

想说却还没说的

 2015/3/13 18:27:07    程序员俱乐部  我要评论(0)
  • 摘要:文/CipherChen不管路走了多远,错了就要重新返回。”——土耳其谚语谨以此文献给两位我尊敬的人。我从他们身上学到了两件事:程序员的自我修养以及用正确的方法做事。在泰捷工作两年,虽然远未达到优秀,但本着对自己负责的原则,觉得该将零零散散地一些东西整理一下。标题来自于《山丘》——李宗盛理解业务在接触一个需求时,先问一个WHY。1、在很多场景下,需求可能并不能真正地解决问题。需求方很多时候并不清楚问题出现的根本原因。产品提了个需求
  • 标签:

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

  文/Cipher Chen 

不管路走了多远,错了就要重新返回。”—— 土耳其谚语

  谨以此文献给两位我尊敬的人。

  我从他们身上学到了两件事:程序员的自我修养以及用正确的方法做事。

  在泰捷工作两年,虽然远未达到优秀,但本着对自己负责的原则,觉得该将零零散散地一些东西整理一下。

  标题来自于《山丘》—— 李宗盛

  理解业务

  在接触一个需求时,先问一个 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

  心中有谱

  除了时间管理,在做事之前,做到“心中有谱”也非常重要。何为“心中有谱”,列出即将要做的每一步。举个例子,今天下午需要对服务器扩容:

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

任务分解:

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

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

3、添加数据库同步

  • 分配即将添加的服务器域名
  • 添加 Primary 服务器
  • 配置端口映射
  • 初始化数据库
  • 添加 MongoDB 服务监控
4、添加 API 服务。
5、…

  在对流程足够熟悉之后,不需要“事无巨细”。唯有一点要求:心中有谱。提前规划好未来一个小时、一上午、一天的工作,会让你每天获得更多的成就感。

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

  可持续开发

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

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

  我在独立开发过程中也并未感到目前的开发有什么难度。但在项目引进新人的过程中就会发现,试图用语言来向他表述当前的代码环境、开发规范、线上部署规范等时,

  我得“不厌其烦”(这当然得怨我们自己)地重复解释,才能让他对整个现状有个较为清晰地认识。即便已经有了较为清晰地认识,在实际操作过程中,仍然会让人有战战兢兢如履薄冰地感觉。这就像“这个系统维持着银河系最精妙的平衡,以至于连多余的呼吸都会使它一击即溃。”

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

  这对于初次接触某项目的开发人员无异于一个噩梦。更有甚者,由于没有丰富的规范,新入手的开发人员在稍微不注意的情况下极有可能自成一套。

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

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

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

  • 相关文章
发表评论
用户名: 匿名