Hegel2011的博客

读书 - 工作 - 生活 - 笔记

Learning Agile: 理解Scrum, XP, Lean and Kanban

初次接触敏捷的概念是很早的事情了,可能始自于Uncle Bob的那本ASD。 其后,因为一直以来认为的软件开发很多事情在做之前其实很多是不确定的,因此日常的开发中虽然没有采用站会之类的形势,也没有单独的产品经理, 但实际上是按照敏捷的精神在进行开发。这些精神包括:

  • 个体和互动高于流程和工具(不过我认为工具十分重要)
  • 可工作的软件高于详尽的文档
  • 客户协作高于合同谈判
  • 响应变化高于遵循计划

这些都是在多年开发实践中所坚持的原则。但是,一直以来忽略了其中最重要的一点:人。

因为之前工作的单位,从客户、领导到同事、下属都是合作多年,彼此也知道对方的能力以及可以信赖的程度,所以敏捷的精神得以贯彻。 然而在两年前去到新环境后,身边合作人员的水平较以往参差不齐的多,主要是上游的产品、BA等怎么合作都没有及时地确立或调整出新的办法, 导致敏捷的原则压根没法贯彻。
直到大约一年半以前,才发现敏捷的形式(实践)其实已较为普及。今年在新单位,有专职的敏捷教练和产品经理,在一年的实践中,体会了不少敏捷的好处,但也 发现了不少问题,尤其是随着时间的流逝敏捷实施似乎越来越难了。而问题依然很类似:

  1. 人员水平参差不齐,其实不是每个人都知道怎么配合
  2. 上游虽然有产品经理,但公司还会安排其他人来提需求,但很可能完全不懂软件开发,导致沟通合作困难

所以,下决心利用假期好好弄明白当前的敏捷到底指什么,然后再看看怎么结合现在面临的情况进行调整。

简单的说,一般的敏捷方式和Scrum是同义词,而XP(极限编程)是软件开发中的一种敏捷模式,Scrum则更偏向项目管理以及集体协作方面。 至于Lean,则只是一种思想,没有具体的形式,Kanban也是来自于日本汽车制造商,其核心作用是找出整个流程中的瓶颈。

与Scrum对应的是上令下行的管理方法,这种方法下需要较完善的需求规格(极难),较强的PM规划设计(很可能是瞎计划)和计划重构能力, 而Scrum则要求团队的主人翁精神(也很难)。但本质上,Scrum把决策和风险都放给了整个团队,基于软件开发很多只有事到临头对着代码 才能明确什么方法最好,因此这种下放或者说要求一线成员能力更大、承担更多责任和决策的模式是有其道理的。整个团队中,开发、产品、PM都能拥有平等的发言权。

Scrum

在项目开始时,只是确定要做的任务(用户故事)有哪些,也会拆分任务,但不一定要完成所有任务的分配。即要有任务清单,但不全部确定计划完成者。 细节在例会后讨论,每天例会可以由不同的人轮流讲3个问题:

  1. 我昨天干了什么?
  2. 我将要干什么?
  3. 我遇到了什么困难?

本质上是让团队成为项目的主人,齐心协力去寻找更有效的工作方式,找到了整个团队就一起成长了。而告诉团队工作成果的价值要好于告诉团度业务收入的价值,对团队而言, 有价值的是软件能带来什么?让用户生活更美好是一种真实、真诚、鼓舞人心的目标。 自我管理集体承诺是Scrum的魂(精神),要求每个人都成为猪而不是鸡,每日例会和积压工作表是Scrum的形式(实践)。产品所有者是Scrum的产物,但实际上也 很难区分和传统的业务分析人员的区别。

Scrum用到的概念还包括用户故事,满意条件,故事点和速度
燃尽图表示随着时间的流逝,还剩多少任务。

Scrum的价值观:

  • 承诺
  • 尊重
  • 专注
  • 开放
  • 勇气

极限编程(XP)

极限编程强调结对以及测试驱动,一切的目的是为了方便自动化测试,比如避免过深的调用栈。着力于消灭代码异味。
有时候过多的边界情况考虑和处理也是过度设计,是某种框架陷阱误区。

作者还提到了反模式的概念。 所谓反模式就是会给项目带来麻烦和问题的行为模式,比如解决某人只有95%的时间在干活,喜欢称人为资源。

代码异味和反模式都是人制造出来的,又是人识别出来的,并且可以由人来防止或修正。所以解决方案一定是技术和团队两方面一起努力。

然而,测量什么就会得到什么。瀑布式开发的目标也不是文档,但最终会得到很多文档,可运行的软件反而变成了副产品。TDD的目标也不是文档或测试,但最终得到了很多测试,可运行的软件本身反而也成了副产品。

精益

精益针对的反模式就是浪费,目标就是减少浪费。包括无用的功能和形式。同时提到了工作进度面积图,这种图的作用可以反应当前处于各个状态的任务数量及比例。其表示状态的词汇如下:

  • Muda 徒劳无益
  • Mura 不均衡
  • Muri 不合理或不可能

衡量是否精益的一大指标是从需求提出到上线发布的间隔时长,即交付时间,这里是借用了丰田生产汽车的概念。强调0或者低库存。

日常项目中容易遇到两个反精益的模式:

  • 老板的神奇思维(Magic thinking):只要我想要,只要我施压,团队就一定会做出来。
  • 英雄员工:十分肯加班加点的员工

敏捷是无法同上面两个共存的。

神奇思维和英雄员工制造的最大问题是会导致软件产品的质量和测试都很差,最终开发速度会变的慢上2倍以上。因为欠的债太多最终都会变成成本。

Kanban

看板可以让经理不再动不动就分配新功能。比任务处理的内容要更“大”一些。看板中的每个栏目表示工作流程中的容器,是一种分析问题出在哪个环节的可视化分析方法。

Shuhari,借用武学概念,守破离。

  • 守:按套路来
  • 破:打破套路
  • 离:自成一派

小结: 确实如一个十分能干的小朋友曾经跟我交流的,中国的企业没有真正实行敏捷开发的。其实敏捷本身和中国大部分软件企业的文化并不兼容,因此大部分只是具备了敏捷的一些实践,而没有敏捷真正的灵魂。至于我司到底是否能敏捷起来,也只能把决策留到最后再说了。

坚持的成果

坚持,始终是一种美德。 在软件开发的世界里,Java坚持了很多年,Mybatis也坚持了很多年。 尽管动态语言是那么的适合web开发,以至于Java在他们面前有好几年十分的被动。但通过Spring的IOC等特性, 生生造出来了一个具备很多动态语言特性的框架,从而具备了很多原本只有动态语言才具备的特性。

另外,Mybatis从一个起初土的掉渣的东西,经过十几年持续有人使用的努力,现在竟然在mybatis-plus的帮助下形成了 Java持久层最出色的一员。在兼容Mybatis的基础上,完全具备了JPA的优势,但在查询和支持SQL上又要远较JPA灵活许多。 因为坚持,实现了巨大的超越。

所以,有时候我们需要有点耐心,坚持一下。

2018 CRV养车成本汇总

2018年的养车成本和2017年的竟然差不多。

具体比较:

条目 2017 2018
停车费 10123 11029+2000
保险费 4945 3637
油费 6444 7006
高速 368 510
保养 1756 1568
洗车 275 355
上述合计 23911 24105+2000

单位停车比之前每月贵了100,所以合计就是贵了1200.好在保险费用有较大的降幅,最终差别不大。

比较神奇的是油费/公里竟然和去年差不多,都是0.77元/KM。平均油耗去年11.30L/100KM,今年11.49L/100KM,不过去年以95号油为主,今年全部是92号油,因此这一年油费确实涨的相当厉害了。
行使里程方面,去年8416KM,今年8856KM,差别倒不是很大。

保险费用没有,不过违章其实有一笔200的开支。
保养费用因为今年有大保,所以费用依然很高。不过不像去年那样有节气门故障的额外开支。洗车则是中规中矩。

CRV也陪伴三年半多一点了,明年应该会把轮胎换一下,又是一笔开支啊。

洗滚筒洗衣机

家中一滚筒洗衣机购买多年,夏天的时候清洗过一下,但不得要领成效不大。原因在于清洗剂和其他很多说明其实都是针对波轮洗衣机,而波轮这方面的经验对滚筒并不适用。原因则在于水位。

清洗剂本身要求溶解后在高水位浸泡2小时才有效果,网上甚至有人建议浸泡一夜。然而对于滚筒洗衣机来讲,水位普遍偏低,很难泡满。直到看见网上针对滚筒的建议,才明白解决的办法。关键在于适度轮转

具体方法为:

  1. 放入清晰剂/粉直接到滚筒
  2. 按漂洗模式放满水
  3. 随后换筒清洁模式继续放水后暂停,并开始浸泡
  4. 满2小时候,通过恢复铜滚动,类似于换个姿势(面),然后继续浸泡2小时
  5. 如果操作几回后,就一切顺手了。

最终从效果来看,还真的洗出不少东西来。

Clean Code

Uncle Bob的这本书也是一本名著了,书籍本身其实就是讲编程风格的,可以把编码技能磨砺的 更锋利些。

全书的要旨在于每一次重构都要让代码更加整洁,同时测试代码和业务代码一样对待。具体开始做起来,则是从很小之处开始着手。

  1. 命名是很重要的一个东西,好的命名可以省下很多注释,因为好的命名本身就帮助理解程序。命名包括了方法名和变量名。

  2. 函数要尽可能的短,比如20行,可以在一屏里面显示,如果一个方法太长,那么肯定是命名没有弄好,可以继续拆分。此外,参数要尽可能的少,能不要参数就不要参数,一个参数好于二个参数,二个参数好于三个参数,三个参数是大部分方法的极限。

  3. 注释以阐述为主,不要使用太多的废话,如果确定要写注释,也要认真编写。

  4. 格式是多个代码之间的关联和布局规则。Bob推荐类似报纸的编写方式,大标题后面跟随小标题,比如大的public方法后面跟随小的private方法。和函数的规则一样,垂直相关的内容尽量放在一起。

  5. 数据和对象牵涉偏向过程还是偏向面向对象。对于面向对象来讲,一般不增加method而是增加类型,对面向过程来讲,一般增加方法而不动数据结构,现实中肯定是二者皆有。

  6. 错误处理错误处理粗返回码外,也可以考虑使用异常来进行封装。

  7. 边界划分好后,对第三方的库和方法要单独测试和封装,以减少对本系统的影响。

  8. 也要单一权责,内聚,可以用许多短小的类来构建程序。

多用Enum,少用const
多用strategy, template,少用if, switch

青轴的蓝牙键盘

去年听同事介绍买了一个Filco的红轴蓝牙键盘。一千多的东西虽然用着也不错,但始终谈不上喜欢。 而且在用了一年之后,其键帽毕竟是ABS材质,打油、磨损等接踵而至。加上2月底摸了下老同事的Filco青轴键盘, 于是对青轴开始长草。

但是,依然对Filco的ABS键帽心有余悸,于是做了一番研究。发现相对于ABS, PBT/POM的键帽相对不容易打油的多, 于是开始在PBT+Cherry青轴+蓝牙之间寻找。找来找去,发现要么只能满足PBT+Cherry轴的那些Cherry原厂键盘或者Leopold这样的韩国品牌,要么就是键帽是ABS的大F,唯有IKBC在去年下半年推出了完全符合我要求的键盘,正好京东又搞活动价格只要499,于是入了一款。

使用之后,确实爱上了这款键盘。清脆高级的手感,漂亮的颜值,无线的简洁,一下子让敲击多了很多很多的乐趣。真有相见恨晚之感!

– Update On 2019.01.01
随后在12月初又购入Ganss的茶轴键盘。也是PBT+原厂Cherry轴,键帽是PBT双色印刷,较IKBC的更为细腻。 购入原因有二: 1.想体验一把茶轴的感觉;2.想要一把全尺寸键盘。

为你自己学Git笔记

从Rails把代码库迁至GitHub起,接触Git已经很长时间了。但限于svn的惯性思维,其实我始终没有真的理解Git。 毕竟,上班一直是用的svn,去年12月后才开始迁移到git,而之前一个人用用GitHub的话,也确实是当一个svn在使用,主要就是实现通过中心节点实现多个终端的内容和代码共享。

没有真正弄懂git的另一个原因,则是没有好的简明的说明教材,毕竟只是一个scm工具,自己舍不得在这上面花太多时间也是事实。而高见龙的这本《为你自己学Git》,目前只有繁体版,则写的够简洁也够深入,并且配合了很多例子,让人对git的原理、应用场景、使用方法都可以做到很清楚。

git基本操作

从Git设计之初来讲,它是去中心化的。所以本书的大部分运行环境和讲解例子都是基于本地目录。 git存储结构

git add index.html只是把文件从工作目录加入到了暂存区(staging area),git commit才能把内容放到存储库(repository)中。

不想让git管控可以给git rm加上--cached参数。 git rm welcome.html --cached,在git目录里的状态就从tracked变成Untracked

git commit --amend 可以修改最近的一次commit的内容和备注。如果要修改其他更久远的,则可以git rebase, git reset,极端情况删除.git目录重来。
同时, --amend还能往前一次commit中加入新文件。

.keep往往用于新增目录时,为了目录进入仓库而作的占位文件。

.gitignore搭配git clean -fX可清除已经被忽略的档案。

git log增加-p参数可打印输出文件的变化内容。

git blame index.html 可以看见每行是谁写的。

1
2
3
4
5
6
7
8
9
10
11
86145428 (swachian 2018-02-20 21:05:05 +0800  1) ---
86145428 (swachian 2018-02-20 21:05:05 +0800  2) layout: post
86145428 (swachian 2018-02-20 21:05:05 +0800  3) title: "Peopleware读书笔记"
86145428 (swachian 2018-02-20 21:05:05 +0800  4) date: 2018-02-16 14:20
86145428 (swachian 2018-02-20 21:05:05 +0800  5) comments: true
86145428 (swachian 2018-02-20 21:05:05 +0800  6) categories:
86145428 (swachian 2018-02-20 21:05:05 +0800  7) - 管理
86145428 (swachian 2018-02-20 21:05:05 +0800  8) ---
86145428 (swachian 2018-02-20 21:05:05 +0800  9)
86145428 (swachian 2018-02-20 21:05:05 +0800 10) 读完软件随想录,自然而然被吸引
去了另一本这个领域的名著《人件》

git checkout index.html可以把误删除的文件恢复出来,如果有多个文件可以使用git checkout .一下子切出。
上面是从staging区域切出到工作目录,如果使用git checkout HEAD~2 welcome.html则是把上两个版本的文件切出到working目录和staging目录。

checkout主要是动staging和working 区域,git reset 则会涉及版本库区域:

1
2
3
4
5
git reset master^
git reset HEAD^
git reset 85e7e30
git reset e12d8ef^
git reset HEAD~5

^的作用是表示“前一次”。

git reset 可配合模式使用,--mixed,--soft, --hard,默认是--mixed,它们对staging和working区域的反应是不一样的。因为reset的本意只是重新设置HEAD指向,顺便解决了staging和working的内容。

  • soft: 只改HEAD指向,其他都不改
  • mixed: 只动staging的内容
  • hard: 改HEAD指向,改staging,改working

git reflog 可以调出每次HEAD移动的记录日志,找回相应的commit标识。命令等于git log -g,加上-g参数也有类似效果。

HEAD指向的是某个分支,内容是具体文件ref: refs/heads/master,而这个文件里的内容则是某个commit形成的hash: ef5dcf2ab28d2ec47252703815ab97bd4108f937

git add -p index.html 可以选择编辑要加入暂存区的行。

git本地分支操作

设置分支最大的目的是保证主干不受影响。

git branch cat 增加分支,git branch -m cat dog分支改名, git branch -d cat删除分支,git checkout cat切换分支, git checkout -b cat增加并切换分支,git merge dog合并分支

Fast Forward在一个分支相对于另一个分支只有新增的commit内容时可以使用, 这是没有小耳朵的。 否则,git会再造一个commit来合并两个分支,并把一个分支向前推到新增的这个commit。 commit信息里面,Parents字段中被合并的分支名位于后面。 commit合并信息
使用--no-ff可以强制产生小耳朵的效果:git merge cat --no-ff
分支只是一個指向某個 Commit 的指標。

git rebase dog是重新嫁接分支,原理是将当前分支的全部提交一个一个提取出来, 重新计算后作为新的提交加到基准分支dog当前commit的后面,最后把当前分支的Head 指向重新apply的最新提交。所以rebase之后,之前分支commit的日期就延后了。

要回退rebase,可以使用git reflog找到rebase前的最新的commit号。
简化版本是git reset ORIG_HEAD --hard,使用ORIG_HEAD指针。

有冲突的话,先编辑,然后git add加回暂存区,再commit
如果是rebase的,则git rebase --continue

二进制的内容: git checkout --ours cute_animal.jpg, git checkout --theirs cute_animal.jpg

git rebase -i bb0c9c2 可以整理提交历史, squash: 合并commit

revertreset的作用基本相同,但revert是再增加一个commit来实现取消前一次提交的效果, 一般用于多人合作时取消某些提交。

git tag,善用tag,标签和分支最大的区别是标签打好之后这个指针不会再变化,分支则会继续前进

git stash,配合git stash list, git stash pop/apply使用, 存放手头工作,也可以先commitreset .

要从.git中完全删除文件有很多步骤要做,要先解除,在gc,最后才能删除掉。当然,不如直接删除.git算了。

产生detached HEAD的原因:

  1. 使用checkout到了一个没有分支指向的commit
  2. rebase过程中,其实都是处于detached HEAD状态,所以一旦rebase有coflct,分支状态必然不对
  3. 切换到某个远端分支的时候

git branch tiger b6d204e && git checkout tiger 该命令可以把当前的commit纳入到一个分支中,从而摆脱断头分支的状态

git远端分支

GitHub是最有名的远端版本库,可以用git clone获得远端repo库。

upstream意在设置上游分支,也就是下面这个命令中-u选项的作用。 git push -u origin master,会把origin/master设置为本地master分支的upstream。然后就 不必每次git push origin master, 直接使用git push即可。
-u = --set-upstream

git push origin master:cat 会把本地的master分支推向远端的cat分支。
git push origin :cat 可以删除远端的cat分支

git pull = git fetch + git merge, fetch同步了origin/master中的内容, 而此时orgin/master比本地master领先,那意味着原本是一个分支分出去的且京都更新,其实就是merge了, 有时候甚至还是Fast Forward方式进行,有时候可能会再造一个commit以完成任务。
但是,pull也可以是rebase方式的,例如git pull --rebase, 这就是用rebase替换上个等式右面的merge
如果push有问题,则只能先拉再推

Pull Request(PR)

简而言之,把项目fork到自己的帐号即建立一个新的远端仓库,然后修改先push到这个新仓库, 然后比对自己和origin库的异同拉出一系列commit集合,这个集合就是Pull Request。 意思是请求原作者拉回去(Pull)的请求(Request)。 原作的叫base fork,自己的叫head fork

公司内部PR的用法:每个人fork到自己的帐号下,待完成后PR回公司的项目。负责管理这个项目的人受到PR后, 进行Code Review并确认这个提交无误后进行合并,从而保证这个分支处于随时可上线的状态。

git format-patch fd7cd38..6e6ed76 会产生补丁文件。git am /tmp/patches/* 则是更新补丁

Git Flow

git的工作流。主要定义了5中分支组织的方式。

Effective Java 3rd Edition

「Effective Java」第三版在过年期间出版了,对比第二版主要补充了lambdastream的内容,序列化方面 则希望大家不要再使用java原生的内容,其他变化不大。但是,和第一版比较起来,变化就很大了。除上述内容外, 第二版较第一版增加了autoboxing/autounboxingenum, annotation,generic programming, 整个的编程建议也从57条增长到78条再到第三版的90条。

借用作者在第三版的前言,在1997年,Java的创始者Gosling描述java是一种“蓝领语言”(blue collar language),意味着当时的java相当简单(pretty simple)。与此同时,C++的创始人Stroustrup则警告所谓java的简单和其他很多新语言一样,只是误解以及功能上的不完善,随着时间的流逝,Java在尺寸和复杂性上都将大规模成长。不得不说,三者都是大师,而Java虽然依旧还是工业级的语言,但复杂度和规模已经较我十几年前初学时多了许多。或许,也因此大学里正在寻求一门其他语言来取代Java的教学地位吧。

此书非常经典,虽然作者说不用从头到尾通读,但是,建议还是全部都读一遍,甚至可能需要反复阅读并加以实践。比如其中的primitives和boxed primitives,即intInteger,其间的坑在新项目中就踩过,而之前阅读后只是尽量不去用Integer这些boxed的类型,而这个新项目中由于前后交互的需要必须使用了Integer,于是就把==, 内容为null的坑都踩到了。

开卷有益,何况经典!

Peopleware读书笔记

读完软件随想录,自然而然被吸引去了另一本这个领域的名著《人件》

质量

只有愿为质量倾其所有的人,质量才是免费的。一个组织如果为了质量一毛不拔,那么收获的质量也将一文不值。 制造者本身对质量会有更高的要求,良心循环下更高的质量会有更高的产出,但如果组织不愿意为此付出代价,比如高工资、项目延期等,那么就得不到这种质量

帕金森定律

工作会自动膨胀并占满一个人所有的工作时间。进度压力是一种惩罚,不能滥用。

苦杏素

李彦宏眼中的AI,就指望这个翻本了。

读到后面感觉有点泛泛而谈,只是本书确实强调工作环境要好,要相信people,减少鼓励,减少加班等等,Joel的思想确实来源于此。

Joel 谈软件- 软件随想录

《Joel谈软件》,我一直是这么称呼《软件随想录》的。 倒是才注意到,原来黑客与画家、软件随想录都是阮一峰老师翻译的,而且翻译的真不错。与此同时,阮老师也很好地推销了一下自己。本书与《我编程我快乐》不同,是很有深度的书,所以决定边读边记笔记。尤其要说一句,阮老师的注解是很显功力的。

在2004年之前,Joel的网站文集就被按blook集合由Apress出版,而阮老师翻译的是集成了2004年之后发布的文章,英文名称《More Joel on Software》。但国内的出版顺序则是先引入了阮老师翻译的《More》,后来又有另一个译者翻译了04年的那本书作为了卷1. 所以,在中国很长时间只有《More》而没有第一本。考虑到时效性以及译者的知名度,04-09这本更值得关注就是必然的了。下面的笔记是两本合计的版本,并未区分来自哪里,毕竟原作者是一个人,所以基本是一脉相承。

人员管理

第一次Bill Gates 审查

微软程序经理(Program Manager):技术水平是程序员队伍里最高级别,能做最多且最难的工作,有人格魅力,程序员队伍中最聪明的那个家伙。

比尔盖茨通过不断问问题来确认对方是否有实现任务的把握。

怎么寻找优秀的程序员

  1. 优秀的程序员很少找工作
  2. 简历投的多的大部分是不怎么样的程序员
  3. 从应届生中招募是个发现美材的办法

从工作环境开始招募程序员

  1. 私人办公室:作者的公司在纽约,但程序员都有独立办公室,当然,这个在国外也是凤毛麟角
  2. Aeron出品的名牌电脑椅
  3. 大显示器
  4. 好的办公环境和园区
  5. 同事要好,管理层要有程序员出身的人,物以类聚
  6. 像代码一样公正、有序,严格的能者上庸者下的地方,对的就能赢得任何争论的地方
  7. 有趣的活,或者简单的或者流行的活
  8. 一定自由地使用新技术
  9. 编程框架体现美、幸福和激励

三种管理方法

团队、公司、军队、国家,问题:“使得人们去做你要他们做的事”,或者说如何使得所有人都向同一个方向前进。

军事化管理法

每个人做的事情都不同的情况下,军事化管理方法很难奏效,因为没有那么多经理实现微观管理。但对军队则是必须的。

经济利益驱动法

经济驱动把内部激励变成了外部激励。内部激励是发自内心想做好这件事情,内部激励通常比外部激励强。

经济驱动也容易陷入kpi骗局,鼓励大家和制度博弈。不能把铜板丢给鸡,让鸡自己去买吃的。创造一种制度的时候,不能放弃自己的职责。

认同法

一起干活的人要一起吃饭。团建,以及营造一致的目标,爱上这个城市和工作内容。第二部分是提供必要的信息,让下属感觉被尊重。

结论:hybrid根据时间和对象灵活运用各种方式。

面人指南

千万不要雇“可能”合适的人,招人标准:1,聪明 2,能干

测试人员

测试人员独立性的必要性

大学生技术学习建议

大学只教java的危害

危害主要是两点:1. 基础知识不够扎实 2.会有很多不达标的人浑水摸鱼通过,导致招聘困难。   但是,国内国外都这样。

耶鲁大学的演讲

技术派(the geek)和务实派(the suit,穿西装的)   消灭bug的边际报酬是递减的,即随着错误越来越少,解决bug带来的收益也在变少,务实派的理论

程序本身包含多少香农熵规格说明书也要包含同样的数量

作者在微软纽约的咨询部门做过一段时间的客户顾问

做外包软件开发不好之处:1.无法用正确的方法做事 2. 做不出优秀的产品,因为都是乙方外包,能用就行。

管理只是一种不得不做、让人讨厌的杂物活,之所以公司需要管理,只是为了不影响聪明人工作,真正的天才才能做出优秀的成果。

作者在大学里学会了写作,学会了从动态逻辑课里不要读研究生,进入了Unix这座宏伟的教堂,但其实作者也从微软身上获益良多,变得足够聪明,但还是没有学到怎么开发软件。

给计算机系的建议

  1. 写作
  2. C语言
  3. 微观经济学:供给和需求,竞争优势,净现值(NPV),贴现,边际效用
  4. GPA反应4年的总体表现

设计的作用

艺术性和实用性 form follow function

进入最后测试阶段就会变得特别挑剔

你之所以会有好运气,那是因为你寸土必争

设计不用太宏伟,但细节要跟上

太多的选择会损坏内心的幸福感

作者以自己软件论坛作为例子,说明了功能和倾向性方面取舍。

大型的项目管理

微软ie8.0的开发,雷克萨斯pk橄榄树,要不要向过去兼容的问题

标准也会引发误解、困惑甚至争议

一半是理想主义,一半是实用主义

项目管理其实就是做抉择

日程安排经验的主要依据是历史数据,但相应原则如下,不过这个前提是招的都是有能力和自我驱动程序员:

  1. 只有一线程序员才能提出完成日期的估计值,管理层制定的通常效果不好
  2. 发现错误就更新原来的计划
  3. 防止管理层向程序员施压,这样的产量至多提高10%,但埋下的隐患不少
  4. 一份日程规划就是一个装备积木的盒子,要么删功能要么拖延

优秀的项目经理会让开发者觉得所有重要的设计工作都是开发者在做,而项目经理只负责打打酱油,和一些非常官僚主义的事情周旋,比如应付客户写写规范。

软件开发-冰山之谜,你能看见的永远只是实现的一部分,如同冰山露出水面的部分,而水底的部分可能还有90%

每日编译发展到现在就是持续集成

排计划

  1. 使用excel,不要用project,后者是为建造办公楼设计的  
  2. 保持简单,7列:feature、task、优先级、预估、现在预估、已流逝、剩余工时,最终完成时剩余工时==0,现在预估==已流逝
  3. 每个功能点要分解任务列表  
  4. 只有负责些代码的程序员才能预估时间
  5. 细分任务到小时单位,作者理解的设计就是决定要做什么  
  6. 记录原始和当前的时间估计,实现不断练习估算时间  
  7. 每天更新消耗时间栏  
  8. 考虑假期  
  9. 考虑调试代码的时间,考虑修复bug的时间  
  10. 考虑集成时间,就是几个人的工作拼接起来  
  11. 预留缓冲时间:第一预估可能有延时,第二可能有新任务,第三可能有冰山  
  12. 永远不要让开发经理压缩程序员预估的开发时间  
  13. 计划就像积木:通过强迫做减法(挑出不要的积木),你将开发出更强、更好、功能配比更优秀的产品,避免延期避免交付了还有很多鸡肋的功能  

软件世界的分类(5类)

作者把基于网络的web应用列为盒装软件,咨询软件(SAP德勤)这样的介于盒装和内部软件之间。
如果只有一个企业使用其实就是内部软件,由于边际成本的原因,内部软件通常不用质量很好。
嵌入式软件
游戏和嵌入式软件一样,对软件的质量要求高,因为一般来讲游戏和嵌入式软件很少升级,也很少会出2.0版。即往往只有一个版本。
临时性软件,比如一段脚本。

编程建议

应用型匈牙利命名法 vs 系统型匈牙利命名法,后者臭名昭著,前者其实意图是表明变量的用途而不是type。

开软件公司

做生意就像看植物增长,是一种乐趣

如果你想压低程序员的工资,那么你就会得到质量很垃圾的软件,而这实际上也不会为你省下很多的钱。举了耶鲁大学的例子说明程序员的生产率差距有5-10倍。

此外,生产率不同的同事而是“普通”程序员根本做不到优秀程序员所做的事情,“飙不出高音”

Seinfeld中Soup Nazi一集很看好

作者的程序员价值论断是针对生产最终产品的公司,如果只是为了内部使用,配合运营而不是销售,那么只要够用就行了,不需要特别优秀

Jonathan Ive, 苹果的设计师

办公室的租金成本是2004年人均700美金/月,人均建筑面积40平米,所以每个人有自己的办公室,目的就是招募到优秀的程序员

对你最重要最关键的部分,你一定要使用更原始的工具

客服不外包有利于永久性地解决问题

面向整个市场的软件(产品)和定制化软件

一家软件公司要想成功,必须要有一名程序员执掌大权

只有招聪明的人,才能充分授权。

“麦当劳的”厨师 pk 真正的大厨,军事化标准化的流程只能产出麦当劳,大厨都是随意的。

NIH(Nothing in Here)对于关键部分,要坚持自己的研发

慢慢发展和烧钱发展的适用场合

兼容性是先有鸡还是先有蛋问题的一大解法

用户粘度和离开的门槛是要在你占据优势地位之后的,在此之前,最好的办法是降低用户使用门槛。

开源软件的策略:是使得硬件标准化、商品化,02年就列举了sun公司的错误

FUD战术,就是欺骗和恐吓的意思了。所谓雾件,就是对各种功能特性和产品作出口头许诺。但实际上根本拿不出可以卖的东西。把微软黑的厉害。 因为含糊其辞,大家会产生微软与自己的观点不谋而合的错觉。

.net缺少链接器(linker)。把编译后版本和程序中所有函数库的编译后版本合并起来,然后剔除掉所有不需要的库函数,生成一个二进制文件。

发新股不分红是为了让报表的利润好看

以最终用户为主和以程序员为主构成了windows和unix两类不同的文化,然而实际上以最终用户为主的文化来源于Apple

关于规格说明书

规格说明书体现的是写作能力,他的规格说明书写的让人很容易阅读。

待解决的问题需要在说明书里确定,不要觉得可以先让程序员做简单的部分,之后再慢慢思考并解决剩下的难题,这不是好主意,因为在实现代码的过程中会冒出许多新问题。

项目经理/产品经理没有权利让程序员听命,必须努力争取大家的认同才行,这种方式才能确保团队永远在做正确的事情。

规格说明书古今中外其实都不太有人爱读,因此写好很难。所以要写出引人入胜的规格书可以遵循一下几点:

  1. 要幽默  
  2. 像编写用大脑执行的代码一样写规格书,仅仅做到正确不够还要易于理解  
  3. 写的尽可能简单, 并擅用排版  
  4. 重读并修改几遍  
  5. 尽量不要套用模板