《构建之法》第四&十七章读书笔记

  《构建之法》第四&十七章读书笔记

一．         前言

       再次阅读《构建之法》，愈发被其中生动有趣的举例吸引。作为一本给予软件工程学生的书籍，其不以枯燥的理论知识为核心，而是基于对知识和方法的引导。本次研读的这两章内容主要涉及了代码规范，两人结对与多人合作的团队方面等相关知识，从其中逐渐明白与人相处作业等方面的技巧与艺术。以下是我对这两章节的思考与疑惑。

二.        第四章《两人合作》。

       本章主要涉及代码规范，极限编程，结对编程，两人合作不同阶段，影响他人技巧几方面的知识点。以下是我的问题：
1. 原文：注释（包括所有源代码）应该只用ASCII字符，不要用中文或特殊字符，否则会极大的影响程序的可移植性。

根据对注释的解释，注释就是对代码的解释和说明，其目的是让人们能够更加轻松地了解代码。注释是编写程序时，写程序的人给一个语句、程序段、函数等的解释或提示，能提高程序代码的可读性。注释是为了让人们了解代码，为什么只能用ASCII字符，对于使用别的语言的人来说，强制使用ASCII注释会不会增加对注释的理解难度。对于中文注释的问题，是不是应该适度放宽，毕竟注释就是为了能让简单直白的明白代码而存在的。

根据知乎上的“大型公司代码注释是怎样？”这个问题有以下评论。

                       

                       

                    

       在我看来，ASCII注释可能在国际的运用率和广泛度比较高，因而导致的此种注释规范。但是根据实际情况，结合平常习惯和以上评论，我认为因地制宜的代码注释可能会比固定的代码规范在一定程度上效率更高。对于内部而言，只要能使团队人员理解，代码注释风格可以随自己决定，但在交流学习方面，可能ASCII注释的广泛度会更高

关于编程注释规范方面的博客：https://blog.csdn.net/xiaoxiaopengbo/article/details/51583631

2.原文：

“软件工程中最基本的复审手段，就是同伴复审。

谁来做代码复审？即最有经验，熟悉这一代码的人。对于至关重要的代码，我们要请不止一个人来做代码复审。”

“在代码复审中发现的问题，绝大多数都可以有开发者独立发现。从这一点说，复审这是在替开发者干开发者本该干的事情。”

  既然绝大多数问题都可以有开发者自己发现，那么代码复审的基本不应该是自我复审阶段吗？为什么会说同伴复审是最基本的？对于最有经验，熟悉这一代码的人来做代码复审，如何保证复审者对代码的熟悉？对于新人而言，经验可能不足，为什么通过复审来学习先进的代码？

对于开发者而言，自我复审可能会因为自己的过度自信而导致复审效率不高的问题出现。所以请不止一人做代码复审是有必要的。即使是很完美的代码，也具有教育和学习的功效，对于复审者而言也是一种成长。因此可以在有经验审查者审查后再次复审以期得到学习。

但对于如何保证对代码的熟悉？熟悉到何种程度才能作为复审者有衡量标准吗？

3.为什么结对编程？结对编程能否大幅度提高效率？

“结对编程让两个人所写的代码不断的处于“复审”的过程，程序员们能够不断的审核，提高设计和编程质量，可以及时发现并解决问题，避免把问题拖到后面的阶段”这样对效率的提高有好处，但会不会出现两人在磨合阶段导致效率低下，共同编程真的会比个人编程效率高吗？1+1>2并不适用于每个结对编程。

               

              

               

       以上评论来自于“工程师结对编程能否大规模提高效率？”，由此可见，绝大多数工程师对此种结对编程的评价都很好，但在具体实践过程中却出现问题。问题并不是处在效率上，而是在工程师工作方面的前提要求很多。很多评论都提到了高强度长时间的工作，以及水平相当的程序员能更好的完成。如果两个人在水平方面相差很多或者磨合期间出现问题，会不会导致结对效率还不如个人效率高的情况发生？在无法保证结对双方都满意对方，或者两人水平相差悬殊的情况下，又该如何调整和改变呢？

参考评论：https://www.zhihu.com/question/20188422

三.  十七章《人，绩效和职业道德》

       本章节是对分配，绩效，团队成长阶段和职业道德等方面的分析，首先先以猪，鸡与鹦鹉的动物体系反映真实的工作体系以及对于工作分配绩效调整方面的理解。然后再展示团队成长的不同阶段和处理分歧的方法。最后点明软件道德规范。

    对于这个章节，我有以下的思考和想法。关于如何作为一名优秀的领导者？ 怎样的猪，鸡和鹦鹉的分配比例更有利于团队长效发展，在绩效方面他们的评定方式又该如何？对于道德规范的要求，是否该随着客户需求而进行适当转变？ 
    在我看来，在软件团队的中的领导力有几个要素：
*  设定目标
*  知人善任
*  带领团队解决问题
*  绩效管理
        工作分配的重要性。对于工作分配，作为一个团队的领导者，更是这个团队的灵魂。领导不单是管理方面，更应该侧重于领导的作用。它不仅需要了解随时掌握成员的动向，更重要的是，他需要了解各组员的能力，然后根据个人的能力，然后再去分配相应的任务，只要这样才能做到“物尽其用”，才能更好的完成我们的项目，达到更完美的状态。这不仅是领导的能力的体现，也体现着整个团队的团结力和创造力。作为一个集体，为了共同的目标而努力奋斗是必要的，这个过程就是团队成长的不同阶段，在磨合期也许会有不同的想法和思维导致矛盾，这是就要体现领导的作用。不是一概而论或者唯我独尊，而是倾听成员声音找到一个更好的权衡方法，在尽可能使大家满意的基础上去完成，这才是一个领导的作用。 
       一定比例上的三者协调在提高效率方面是有益处的。在实际的工作中，这些存在都是有一定作用和必要性的。遵循“重大决定由“猪”负责”的原则是现实的。所以这三种不同的存在是合理的。但对于如何协调之间比例的问题上，可能还是需要各自根据自己项目的要求进行调整。但这三者的绩效管理问题，如何分配和权衡还是一个需要考量的问题。书上所述的区别对待，根据完成任务维度和团队贡献维度形成的二位评价体系，可能是区别对待的一个较好的解决方式。那么猪，鸡和鹦鹉都充斥的团队，也适合这种区别对待的绩效评定吗？

       关于道德规范问题，“这并不是一个简单的道德算法，并不能产生所有道德上的决定”，所以“解决道德冲突最好的方法是对基本原则进行全面的思考，而不是盲目某些具体条目。”由于软件工程的多变性和苛刻性，应对新情况发生的道德规范在很大程度上还是需要工程师的自我约束和道德规范。面对纷乱复杂的市场和竞争，保持职业操守是很重要的事。面对不合理的客户需求，不能一味追求经济利益，更要考虑长远发展和社会影响。因此“软件工程师应当终生学习以提高自身的专业水平，并在工作实践中推动落实道德准则”。