读 10x 程序员有感。

用户头像
AdonisPeng
关注
发布于: 2020 年 10 月 13 日
读10x程序员有感。



作为一名程序员我一直也在探索什么样的工作方式是正确的、高效的。读了极客时间的《10x程序员工作法》 感受颇深,让我有好多的思考。同时非常认同弗雷德里克·布鲁克斯(Frederick Brooks)统计结果,优秀程序员的开发效率是普通程序员的10倍。我总结了一套适合自己的工作方式,虽不能适用所有人,也想和大家一起探讨和思考适合每一个人的工作方式。



以前的我,学了一项技术的时候总会把他锁在自己的笔记里,也不会去跟别人分享与探讨,所以导致“只是学完,没有学会”。

1. 每天的必要思考(吾日三省吾身):

1.我现在是一个什么样的水平。(现状)

2. 我想达到什么样的水平。(目标)

3. 我将怎么样达到这个目标。(实现路径)

2. 没有写过的代码,是最好维护的代码(以终为始):

任何事物都要经过两次创造:一次是在头脑中的创造,也就是智力上的或者第一次创造(Mental/First Creation),然后才是付诸实践,也就是实际的构建或第二次创造(Physical/Second Creation)。

---《高效能人士的七个习惯》

当前的”终”为:接到需求后,开始在头脑里解析需求,并构思在写代码中可能遇到的问题。

接下来进行写接口文档和注释。

最难维护的代码,是一个月后看你自己写的代码。如果注释没有写流程可能一个月后,你可能会忘记的一干二净。(文档详尽(welldocumented)也是好代码的一种表现)



以终为始,遇见什么事儿,先倒着想。

附《亚马逊是如何开发一项产品的》

1. 写新闻稿

2. 写FAQ(常见问题解答)

3. 写用户文档

4. 写代码

 

3. 做任何事之前,先定义完成的标准(DOD:完成的定义(Definition of Done))

准备写代码前:需要对接好相应的完成标准。

比如说某个功能的DOD:

1. 写接口文档。

2. 写接口注释。

3. 开发人员编写好功能代码。

4. 编写好单元测试(自测)。

5. 测试可以通过。

6. 代码通过代码风格检查。

7. 代码处于可部署状态。



实际项目的DOD

1. 某个功能的DOD:比如这个功能特性已经开发完成,处于一个可部署的状态。

2. 一个迭代的DOD:比如迭代规划所有功能已经完成。

3. 一次发布的DOD:上线计划,整个软件处于一个可发布的状态。

4. 接到需求任务时:可以使用用户故事。



用户故事:

用户故事=用户+故事=人+故+事,那就是一个人因为什么原因要做什么事,提炼出来三要素就是who、why、what。用户故事通常的表达格式为:作为一个<用户角色>,我想要<完成活动>,以便于<实现价值>。



角色(who):谁要使用这个

活动(what):要完成什么活动

价值(why):为什么要这么做,这么做能带来什么价值。



①标题:简要地说明用户故事主要内容,比如:登录需求,使用用户名密码登录。

②概述:简要的介绍这个这个用户故事主要内容,作为一个角色,要做什么事,能达到什么效果。比如用户想登录网站,需要输入用户名密码,登录网站成功。

③详述:详细地描述这个用户故事的完整流程,操作流程,用户界面等信息都放在这里,比如用户输入正确用户名密码,提示用户登录成功,用户输入错误用户名密码,提示用户登录失败,用户名或者密码错误。

④验收标准:验收标准会描述一个正常使用的流程是什么样的,以及各种异常流程系统是如何做出相应(制定DOD)。

5.集成本身就是写代码的一个环节。

客户不需要编写的代码文本,需要的是一个可执行文件,尽早提交代码做集成。







6.解决了技术问题,为什么还在坑里

1. 扩大自己的上下文,总是在自己的的视角里,或者说是在程序员的角色思维里,什么问题都想用技术来解决。手里有锤子,看什么都是钉子。花很多时间来解决的问题,可能并不是问题,常常是程序员的盲区。

2. 扩大自己的上下文,当你知道整个软件的开发周期后,你看到就不只是你做的单个的功能点,而是一条线,虽然写的代码都是一样的,但你看到的是树,别人看到是整个森林,更能用全局来思考问题。



独善其身,不是好事。

 

7. 数字改变生活

1.在我们的工作中,经常会发生的一个现象是,一个人说,我觉得这个缓存有作用,另一个人说,我觉得那个缓存没有。几个“觉得”下来,双方就开始进入了隔空对话的环节,谁也无法说服谁。 既然这样倒不如增加一个测量尺度,用数据(访问时间)来证明两个人是否说的正确。

2.每天干什么是你的领导最关心的,如何知道让你的领导知道你每天都干什么,也可以通过日报的尺度,(不是说你写得多,你干的活就多)而是你相对昨天(完成度30%)相比 今天(完成度60%) 是否有增加。通过数据来测量每天的生产量,也可以作为自己进步的标准。

3.通过数字来解决同事之间扯皮问题:某项功能访问特别慢,是否有前后端扯皮现象。

前端:接口返回慢。

后端:css js加载慢。

可以使用SkyWalking、Jaeger 来进行链路追踪,通过数据来说话。

8. 迭代0

需求方面:

当项目开始时,会有一大堆需求,当需求分解后,大部分的需求都还没有细化,先别去细化所有需求,可以先区分需求的优先级,哪个先做,哪个后做,再进行需求细化。

在这里分享一个小故事:

在p2p盛行时期,大部分金融类的APP都在抢时间上线,来分行业空白的一杯羹,时间显得特别可贵,等你的APP所有的需求都做完了以后,可能你与这个行业已经“天各一方”。

思路:p2p类型的App,可以第一个月App1.0就只做借款方面的需求,还款时间定为一个月以后,可以在第二个月内做还款功能,等到需要还款时上线2.0,既不耽误用户使用,也能快速上线,节约时间成本。



系统发布阶段:

这个清单在我们组(可能每个公司不一样)使用屡试不爽,当系统上线时,对照清单选项,工作会有条不紊的进行。

当项目上线后,如果出现问题能通过清单快速定位问题所在。

 



个人的感受是:公司不缺技术,公司缺的是规范的流程和规范的工作方法。如果说技术是硬技能的话,那么规范的流程和方法就是软技能。工作中碰到的问题有很多都是因为软技能缺失引起的。



发布于: 2020 年 10 月 13 日 阅读数: 233
用户头像

AdonisPeng

关注

你必须比别人更努力 才能看起来毫不费力! 2019.10.26 加入

还未添加个人简介

评论

发布
暂无评论
读10x程序员有感。