关于《构建之法》第四章和第十七章的问题

关于《构建之法》第四章和第十七章的问题

第四章:

问题一:在关于“缩进”,书中不提倡用tab键。而建议使用四个空格。但是tab键可设置占符数,在实际开发中,tab键是缩进的快捷键, 我无法想像每次使用缩进都要敲四次空格。

问题二:关于开闭括号

在C语言学习中,国外教材普遍使用形式如下,形式一:

int max(int num1, int num2)
{
    return (num1 > num2) ? num1 : num2;
}

而在《Thingking in Java》中,作者使用的风格如下,这也是官方源码的风格。形式二:

public static int max(int num1, int num2){
    return (num1 > num2) ? num1 : num2;
}

书中说形式一的形式比较清晰,所以选择形式一。

但是,我觉得形式二确更容易凭右括号找到左括号,结构比形式一更清晰。观察如下代码:

//形式一:
if (num1 > num2)
{                                         // 1处
    max = num1;
}
else
{
    max = num2;
}                                        //根据此处找左括号可能被1处括号混肴

//形式二:
if (num1 > num2){
    max = num1;
}                                       //2
else{                               
    max = num2;
}                                       //3 根据此处找左括号可轻易找2,3 
                                         //之间的左括号                                   

 

  

我想,对于编码风格,首先按照团队的规定,若团队无规定,则按照官方源码风格。标准的统一是生产力提高的因素之一。

 

第十七章:

问题:关于绩效评比中的“背靠背评比方式”,引文如下。

根据所有其他人的评价来决定某个人的绩效?这样会发生小团体抱团,以及劣币驱逐良币的现象。做游戏的工程师一定听说过维尔福公司(Valve[注释6],开发有半条命、反恐精英等游戏),这家公司的员工手册[注释7]很有意思,大家不妨看看。根据手册的描述,维尔福的员工可以自由支100%的工作时间,做什么项目、在哪儿工作等,员工可以自己做主。但是在绩效评估上,他们用了队友评估这一机制,得出下列四个值:

1. 技术等级/技术能力
2. 劳动生产力/结果
3. 对团队的贡献(做一些工具让大家的工作更容
易,帮助招人)
4. 对产品的贡献(除本职工作外,对产品有帮助
的活动,比如找Bug、预测用户的反馈、产品推
广等)

这种评比方式让我想起了班级内的投票,得票最多的人一般是人际关系不错的人,还有就像书中所说的“萝卜”一样在团队中显眼,看起来高效,看起来给团队带来的贡献最大,但是却使得团队花更多时间在debug上。与之相反,效率中等但是开发稳定的“白菜”是不是吃亏了?这种“背靠背评比”的方式是否太主观了?如果有一个独立于项目的专业人士对团队内的成员进行评比(评比方面为引文中的四点),评比结果为“局外人”的评比和“背靠背”评比的综合,是不是更合理?

posted @ 2018-03-31 19:36  公孙傲空  阅读(129)  评论(1编辑  收藏  举报