《构建之法》（第四、十七章）读书笔记

一、关于代码规范

1.1

因为软件开发多数是一个团队的事情，所以需要格外注意代码规范。我们的代码日后通常是需要去维护的，是需要去给别人看的。但是，不同的编程语言对代码规范的要求是否相同呢？

因为在工作室学的是前端语言，我对前端的代码规范比较了解。

有一位博主总结的前端代码规范，个人感觉非常好：https://www.cnblogs.com/qinyi173/p/7150644.html

 

1.2

书中（P63）页提到 ”匈牙利命名法“  ，并说到：

”在这类语言中，前缀就不是很必要，匈牙利命名法并不适用。微软的.NET框架就不主张用这样的命名法则。“

这句话说明不同的语言、不同的框架，所适合的命名法则是不同的。那我们常用的命名法则有哪些呢？

我上网搜索了一下这个问题，找到了一篇博客：https://www.cnblogs.com/Offie/p/5021368.html

这篇博客中提到了3种命名方法：驼峰命名法、帕斯卡命名法、匈牙利命名法。

 

以下，简单总结一下这3种命名法的特点：

驼峰命名法：函数名中的每一个逻辑断点都由一个大写字母来标记。在许多新的函数库和Microsoft Windows这样的环境中，它使用得当相多。

帕斯卡命名法：与骆驼命名法类似只不过骆驼命名法是首字母小写，而帕斯卡命名法是首字母大写。

匈牙利命名法：通过在变量名前面加上相应的小写字母的符号标识作为前缀，标识出变量的作用域，类型等。顺序是先m_（成员变量）， 再指针，再简单数据类型，再其它。

以下是3种命名法的举例：  

 

MyData 就是一个帕斯卡命名的示例 
而myData是一个骆驼命名法,它第一个单词的第一个字母小写,后面的单词首字母大写,看起来像一个骆驼 
而iMyData是一个匈牙利命名法,它的小写的i说明了它的型态,后面的和帕斯卡命名相同,指示了该变量的用途.

 

 

二、关于代码复审

之前我们了解了单元测试，是确保代码质量的一种方法。乍一看代码复审，好像功能与测试差不多，但其实这是两件不一样的事情。

书中（P72）说到：

 

“要注意避免不必要的繁文缛节，我们做代码复审的目的是为了减少错误的发生，而不是找一个人来对着你的代码点头。一些简单的修改不是非得要一个复审者来走一遍形式。在项目开发的早期斤斤计较于一些细枝末节（例如：帮助文件里的拼写错误，数据文件格式不够最优化等）也是于大局无补的，但是，这些问题并不是不用处理了，我们可以建立一些优先级较低的工作项来跟踪处理。”

      

我觉得，书中这一段说得很好，代码复审的过程就如同我们解决问题的步骤一样。

做一件事情，我们要不时回过头去查漏补缺一番，在查漏补缺的过程中，我们要给发现的问题确定优先级，从而判断这个问题是否亟待解决。

所以，我想知道，在代码复审的过程中，哪些问题是属于优先级低的问题？

 

我查了一些相关的博客，主要有以下观点：

1：Code review 不应该承担发现代码错误的职责。

     Code Review主要是审核代码的质量，如可读性，可维护性，以及程序的逻辑和对需求和设计的实现。

     代码中的bug和错误应该由单元测试，功能测试，性能测试，回归测试来保证的（其中主要是单元测试，因为那是最接近Bug，也是Bug没有扩散的地方）

2：Code review 不应该成为保证代码风格和编码标准的手段。

     编码风格和代码规范都属于死的东西，每个程序员在把自己的代码提交团队Review的时候，代码就应该是符合规范的，这是默认值。

     属于每个人自己的事情，不应该交由团队来完成，否则只会浪费大家本来就不够的时间。

      

而代码复审需要注意的问题在书中（P73）的核查表中已有详细说明。

 

三、关于敏捷开发

书中（P75）提到：

“结对编程随着敏捷思潮的兴起而广为人知，然而这种实践早已有之。”

什么是敏捷思潮？这是怎样的一种开发模式？

我在百度百科上找到了详细的关于敏捷开发的介绍，并仔细地阅读了。

其中，敏捷开发的宣言原则叙述得既有艺术性又简洁明了，故摘录如下：

 “最重要的是通过尽早和不断交付有价值的软件满足客户需要。

 我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。

 经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。

 业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。

 围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。

 在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。

 以工作的软件是进度的主要度量标准。

 敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。

 对卓越技术与良好设计的不断追求将有助于提高敏捷性。

 简单——尽可能减少工作量的艺术至关重要。

 最好的架构、需求和设计都源自自我组织的团队。

 每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。“

 

但是，看了书中关于结对编程的内容，仍然有一些疑问。书中也提到，程序各方面的质量取决于一对程序员中各方面水平较高的那一位（P76）。按这样的逻辑，理应是两个互补的人结对编程会提高效率，因为每个人都有各自擅长的部分，代码中各部分是取决于水平高的一方，代码质量自然提升。但是两个互补的人因为不了解对方擅长的部分，一个作为“驾驶员”的时候，另一个并不能胜任“领航员”的角色，这样是否失去了结对编程的意义？因为他们完全可以分开完成各自擅长的部分。或者说，结对编程对两个人的要求并不是互补，而是水平相当、擅长技术相似的两个人？

      

四、关于牛仔式编程

名词解释：“牛仔式编程”，这个词我们用来描述那种直接在生产环境服务器上修改代码的行为。“戴着粉红色的大檐帽”表示你要严格的检查，谨慎的决定。

书本在第77页提到 “牛仔式编程” ，这是一种不提倡的行为。

 

五、关于提意见

书中（P81）中提到的4种影响他人的方式，分别是断言、桥梁、说服、吸引。

”没有绝对正确或错误的方法，只有合适或不合适的方法。“

书中讲的是我们要根据不同的情形，选择说服别人的方法，温和的方法有助于彼此的理解，但遇到紧急情况就要态度坚决。

我觉得，这4种方法是否不仅可以根据不同的情形选择使用，还可以根据不同的用户性格选择说服的方式，使用户与开发者的目标达成一致呢？

在 “如何正确地给予反馈” 这一节里，我学习到，你批评别人的不同层次会给别人带去不同程度的影响。

应该要这样做，不论你多么生气，都不要评论别人的本质和固有属性，尤其是对待你的亲人和朋友，永远都别说出最伤人的那句话。

 

六、关于猪、鸡和鹦鹉

书中大致是这么为3种动物的贡献排序的（如果我没理解错的话）：猪 > 鸡 > 鹦鹉。

因为猪是 ”全身心投入“（Committed）、鸡是 “参与”（Involved)、鹦鹉是 “围观”（Bystander）。

但我觉得，这么说是不合理的。这3种动物的特长不一样，他们在团队中都贡献了自己擅长的部分。

比如在一个企业中，鹦鹉好比是市场推广，或者是领导人员，他们虽然不像一线程序员那样埋头苦干，但他们只要是全身心的为这个项目筹划，就是全力以赴的“猪”。

我们不能用做的事情类别去定义一个人的贡献度，企业需要分工，每个人在自己的岗位上全力以赴，才能完成项目，不是吗？

因为常看见软件行业的一些求职鄙视链，我觉得这是不好的。

由这个话题引申，我觉得对于我们本科生，应该尝试着去发现自己擅长的部分，为以后我们的职业定位做一个基础。

 

七、关于绩效管理

绩效管理确实是提升团队绩效、提升部门乃至企业效率的好方法。我觉得，我们应该学习绩效管理。但这个不适合在我们的组队作业中实行。

首先，绩效管理其实是有淘汰制的，他在企业中是用利益驱动的。但我们的团队成员是我们的同学，我们的目的是互相帮助、互相学习，我们可以在讨论的情况下确定每个人的贡献比，因为这是有目共睹的，而不是采用淘汰制。

其次，取得好成绩是团队共赢的模式，而内部竞争会导致内部损耗。企业由于人数多，每个人之间的联结小，共同利益少，因此需要个人为单位的竞争。但我们的学生团队本就有共同目标，应该 ”一致对外“、一起努力才对。

最后，在百度百科中有关于绩效管理的这句话：

“绩效管理体现着“以人为本”的思想，在绩效管理的各个环节中都需要管理者和员工的共同参与。”

绩效管理一定需要一个管理者，那在我们的团队中如何确定这个管理者呢？不管是对推举形式上，还是管理者的个人素质都有很高的要求吧。

总之，我觉得绩效管理应该用于较多人数的团体，因为这个管理做不好是会带来矛盾的，而小团队的内部崩坏无疑于是灭亡。

 

八、last but not least：职业道德

这里引用一篇关于软件工程师职业道德规范的博文：https://blog.csdn.net/dipolar/article/details/61413999

我们学习的计算机这门技术，有很大的功用。如果被居心不良的人随意使用，后果会很严重。所以，职业道德是第一位的。

各种职业道德的文件都表明：计算机专业人员应当以公众利益为最高目标。