第四章和第十七章阅读笔记

阅读了第四章和第十七章，了解了一些全新的概念，对开发流程有了更深的体会。

第四章：

1

原文：

在结对编程模式下， 一对程序员肩并肩、 平等地、 互补地进行开发工作。 他们并排坐在一台电脑前， 面对同一个显示器， 使用同一个键盘、 同一个鼠标一起工作。 他们一起分析， 一起设计，一起写测试用例， 一起编码， 一起做单元测试，一起做集成测试， 一起写文档等。 结对编程不是程序开发者独到的发明， 在现实生活中， 也存在类似的搭档关系：越野赛车（ 驾驶， 领航员）驾驶飞机（ 驾驶， 副驾驶） [注释2] 这些任务都有共同点： 在高速度中完成任务， 任务有较高的技术要求， 任务失败的代价很高。 结对编程中有两个角色：
1. 驾驶员（ Driver） ： 控制键盘输入。
2. 领航员（ Navigator） ： 起到领航、 提醒的作用。

结队编程就是两人并排坐在一台电脑前，一个人写代码一个人在一边看着，我觉得这是一个很有新意的模式。

 

问题：结队编程真的现实么？

我觉得结对编程模式有点“危险”，因为写代码可能比读代码要轻松得多，所以我们怎么能保证看着的人不出洋工呢？而且两个人很可能因为风格不同或一些细枝末节搞砸。有一篇博文，谈到了结队编程的一些误区：

 

 

 

 

 

还有一篇文章谈到了结队编程的利与弊：

 

也就是说，结队编程多少有点麻烦：需要找两个合适的人，他们技术水平不能差太多，而且观察的人应该要有某种品质：耐心，负责，不计较于细枝末节。结队编程作为一种古老的敏捷编程，可能在调试等其他方面更加有用，应用的范围更加广。

 

 

 

 

2 原文：

注意： 有些程序设计语言的教科书对于基本的语法有详细的注释， 那是为了教学的目的， 不宜在正式项目中也这么做。 下面的示例代码中有很多注释， 但是那些注释是非常必要的吗？ 哪些错误处理是多余的？

 

我的问题也就是这里的问题，就是代码的注释要怎么写才显得好看又规范，另外，某些一块块的注释要不要删掉，或者留着？

查阅了一些资料，发现很多人认为：优秀的代码就是最好的注释，也就是代码写得越清晰明快，那么就不用太多的注释，而不得不加上注释的时候，我们必须要遵循奥卡姆原则：如无必要，勿增实体。在具体遇到那些麻烦的代码时，应该把自己写代码时怎么思考的用精简的语言写下来，最好在注释里写个例子，对于接口来说应该做到一看就能懂，如果确实做不到一看就能懂，那就加一点注释描述这个接口是在整个代码中是处于什么角色，如果有例子，也把例子写下。在风格和格式上，注释要优秀，注释排版必须要好看。

第十七章：

1 原文：

用专业知识教育人是不够的。通过专业教育，他可以成为一种有用的机器，但是不能成为一个和谐发展的人。要使学生对价值有所理解并且产生热烈的感情，那是最基本的。他必须获得对美和道德上的善恶鲜明的辨别力。否则，他 —— 连同他的专业知识 —— 就更像一只受过很好训练的狗，而不像一个和谐发展的人。为了获得对别人和对集体的适当关系，他必须学习去了解人们的动机、他们的幻想和他们的疾苦。

    ---- 爱因斯坦

 

.一个新人能加入一个团队，团队领导看重他什么呢？首先是知识。

 

 

问题：作为一名软件工程师，到底什么是道德的，什么是不道德的？

 

我们以魏则西事件为例，在这次事件中，那些勤劳能干的程序猿们扮演了怎样的一种角色呢？他们对魏则西的死应不应该负责呢？如果他们没有责任（即是把一切责任都可以归为上层决策层），那么作为普通用户的我们是否应该自发地抵制百度？作为技术优秀的毕业生是否应该自觉地不去百度？那些一行一行敲出竞价排名代码的工作者，知道他们在做什么吗？如果是知道，他们应不应该继续干下去呢？

经常可以听到一种论调：技术是无罪的。可是技术的应用是不是有罪的？李在此次事件中一直强调自己的公司损失了几百亿，可我们又怎么知道它是否得到了应有的惩罚呢？

极客很像手中拿着刀剑的侠客，他们有着常人不能拥有的能力，那么，如何看待他们用这些“特权”去谋一些小利呢？对，接下来我想说的就是阿里的月饼事件，五个用脚本抢月饼的人，因为不符合公司的价值观被开除了。我认为，如果这是不合适的，此事件的性质与前面所说的事件性质完全不同，在今年，阿里爆出的一次抄袭丑闻中，带头骗取抄袭他人代码的团队几乎没受损失，与抢月饼的人遭受的待遇完全不同。这倒是可以凸显另一个问题：就是程序员自身相对于大公司的脆弱和渺小。

我想，技术和道德，总是一个两难的问题。将这个问题推到极端的情境里，如果组织/公司要求程序员做一件显然违背公俗良知的事情，他应该将把责任都推给命令者去完成这个任务，还是出于良心不做呢？