《构建之法》第4章、第17章阅读笔记
阅读了《构建之法》第4章、第17章后，感触良多，下面是我阅读课本的一些思考与感悟。
第四章 两人合作
在第四章中了解到了很多关于代码规范的知识，明白了写代码时需要特别注意代码规范，就拿以前说，写代码时就只是知道代码首行要缩进，但是不知道具体的要缩进几个空格，通过这一章的阅读让我以后再敲代码的时候更加注意到代码规范，方便他人也方便自己，也了解到了结对编程的魅力，应如何更好的与我的搭档进行交流。但在阅读第四章的过程中我也有一些自己的思考。
问题一：在结对编程时，应如何正确的给我搭档给予反馈？
引用：“人是复杂的，动画片《怪物史瑞克》的怪物都知道这一点，它说过人都像洋葱一样，有很多层次。”
思考：在日常生活中，有很多这样的时刻，跟我一起合作的搭档，有一些跟我意见不合的地方或者有一些小错误，那么我应该如何巧妙地给我搭档提出他的一些问题，又不会让他心里感到难受，还心甘情愿的去改正，这就需要学习说话的艺术，应对不一样的人，应该用不一样的方法，书上也给了具体例子，用三明治来代表如何说话，第一个阶段应该鼓励搭档，第二个阶段再指出搭档的错误与缺点，第三个阶段在呼应第一个阶段再鼓励一下队友。我觉得这种方法还是很实际可行的，但是也还是要根据搭档的实际情况而定。
问题二:为什么为了代码规范程序里面就可以写goto语句？如果一定要写那在什么条件下写？
思考:以前上课时，老师都会建议我们不要使用goto语句，但是在这本书中说为了代码规范可以使用，这就让我产生了疑惑，我去百度上搜寻了goto语句，“goto语句的语义是改变程序流向，转去执行语句标号所标识的语句，其通常与条件语句配合使用，可用来实现条件转移， 构成循环，跳出循环体等功能。但是，在结构化程序设计中一般不主张使用goto语句，以免造成程序流程的混乱，使理解和调试程序都产生困难。”正如百度上所说，不加限制地使用goto破坏了清晰的程序结构，使程序的可读性变差，而且经常带来错误或隐患。那我们为了代码规范到底应该怎样使用goto语句，在什么时候什么条件下使用比较好。
第十七章 人，绩效和职业道德
我们都知道，一个团队中领导是一个最重要的部分之一，团队中的领导好不好决定了一个团队是否能成功，通过第十七章的阅读，我更加明确了一个领导在团队中的作用，应该如何平衡团队内的人员，了解到作为软件工程师最基本的职业道德。但在阅读第十七章的过程中我也有一些自己的思考。
问题三:领导应该如何带领团队成长？
引用:“团队合作也有跟两人合作类似的阶段，平时大家似乎都相安无事，但是一但出现催化剂，团队合作的状态就会出现剧烈变化。变好或者变坏，还要看团队的成员，特别是领导者的智慧了。”
思考:我认为一个团队能否发展好，其中领导是起至关重要的作用的，作为一个好的领导首先要带领团队弄清五个奠定团队基础的问题1.目的，2.原则，3.优先级，4.计划，5.人员。其次在平时工作中领导还需信任他人，其中信任他人不仅包括对他人工作上的信任，还包括情绪上的了解和包容，而且有明确的团队目标，并且在团队出现问题时，有良好的解决冲突的能力，在重大事情面前有良好的决策力，还要对员工和工作有责任感，作为一个领导只有具备了这几个能力，才能更好的领导一个团队走向成熟。
问题四:一个团队如何进行绩效管理？
思考:很多公司把日常考核与严格的奖惩制度结合起来，这样做的结果势必导致管理工作的短期化和员工行为利益化，更破坏了组织与团队的和谐关系，我也在网上查了很多关于绩效管理的相关资料，索尼公司曾经因“绩效主义”而一度走向衰败就是典型例证。为了实行绩效管理，索尼公司成立了专门机构，制定了非常详细的评价标准，并根据对每个人的评价确定报酬。这种一切以工作绩效为导向的管理，使索尼公司内追求眼前利益的风气蔓延，职工逐渐失去工作热情，公司失去活力。面对当年索尼公司的衰败趋势，索尼的前常务董事天外伺郎说：“绩效主义企图把人的能力量化，以此做出客观、公正的评价。但我认为事实上做不到。它的最大弊端是搞坏了公司内的气氛。上司不把部下当有感情的人看待，而是一切都看指标、用评价的目光审视部下。”所以他认为“是绩效主义害了索尼”。现在，许多企业，甚至是政府机关都在实行绩效管理。但对于考核，很多管理者有这样一个误区，认为考核出绩效。他们的通常认为，因为员工有懒惰、讨巧、逃避工作的思想，所以必须举起考核这个"大旗"，出台一些严厉的考核政策，员工做不好就动用惩罚措施，这样员工就有了畏惧感，就会努力工作，员工的绩效就能提高，但事实正好相反，所以作为一个团队应该如何进行绩效考核呢？真的要一切看指标，用评审的眼光来审视部下么？还是应该更加偏向于鼓励？
