//一版的《移山》

//10061162 刘俊伟

零零碎碎地花了不少时间看《移山之道》，现在也到了该也总结的时候了。

由于看本书的时候正在进行pair work，因此也并不是按顺序阅读，而是直接从第11章——两人合作开始的。

一．Pair work的得与失

合作编程在以前的学习过程中也进行过，基本也就是各人负责一部分最后再将之拼凑起来，而这次作业要求的双人合作，要求的并不是这样，而是两人应该在一起进行工作，这样的要求理想情况下能在代码编写时提供更高的设计质量和代码质量，也能让结对人员之间做到相互学习，经验共享，促进交流，但是在实际情况中，因为结对对象并不是自选，我们之间的共同的空闲时间（因为课程，生活习惯等）不能得到保障，而在另一方面，合作对象之间的相互熟悉也花去了不少的相同的空闲时间，整体效率上也并不见得比分开工作效率高。

而在我理解起来，pair work要想要高效率的运作起来，结对对象的选择是一个很重要的部分，相比与还需要相互熟悉的之前较少交流的同学，或许室友什么的沟通起来更为方便，空闲时间也更为统一，而至于老师在课上所说的“pair work中两人相互督促”，不是在一个寝室的同学的督促无论是次数还是效果肯定是比不上同寝室的室友的。

疑问：pairwork中工作分量不平衡难道不会影响工作配合么，虽说我们pairwork只合作一次，但是在实际中未必不会出问题么？

二．代码规范的思考

这其实是我们目前编程中最需要学习的。在以往的学习过程中对程序的规范性要求并不高，更注重的是输出的结果，实现的功能，因此某些变量，方法的定义就很难摆脱常用的a,b,c,d,t1,t2,t3。这样的程序不仅他人阅读困难，就算是自己也难免在一段时间之后读不懂自己写的程序。

空行，缩进，下划线，大小写以及注释的问题，之前编程中或许注意过，但也并没有得到过比较系统化的规定，尤其是注释，一般都是想起来就写上两句，没注意就算了。在学习完代码规范这章后，虽然对自己编程能力上提升不大，但是对自己在编程规范上了解的空白有了一定的弥补，受益匪浅。

三．效能分析

其实这也应该是在编程过程中自己摸索出来的经验，但同样是由于之前并没注重这方面，因此在代码效率上个人做得并不好。

就如同书上所举的例子，for(int i=0;i<m_wordlist.count;i+)，其中m_wordlist.count调用次数相当高，但如果改成int count= m_wordlist.count;for(int i=0;i<count;i+)的话，效率将提升不少，而就这点，反观自己第一次wordcount作业中，如：

for (int i = 0; i < dat.Length; i++)

for (int i = 0; i < saveload.begin_a.Length; i++)

for (int m = 0; m < saveload.name.Count - 1; m++)

等等情况出现的次数绝对不少，这种类似躺枪的感觉着实让人惭愧。但另一方面来说，这些约定俗成或者说是惯例的东西也并没有在初学时期就说过，在不良好的编程习惯养成后被指责编程风格不对，代码效率低，代码不规范，这对我们来说也是相当的无奈。

疑问：这应该是二，三一起的疑问，代码规范与提高效率的技巧应该在初学的时候就提出，而且应该是系统话规范化的提出，而现在只是在编程过程中让我们自己摸索？

四．测试与用户测试

书上也并为给出特殊的测试方法，不过其中一点——单元测试需要也必须由程序开发人员来进行。一方面是有些问题在部分代码完成时测试很容易发现，但是在整个工程完成之后却难以寻找，会极大的降低测试人员的工作效率与工作热情；另一方面则是态度上的问题——并不是说代码写好了，编译不出错就算工作完成了，自己的模块要能正确运行才算是完工。比起让他人来研究开发人员的代码，要适应不同的编程风格，弄清楚代码的意思所需要的时间暂且不谈，这也难免让开发人员产生“反正有人来测试”的不负责任的心理。

而用户测试则要求更高，各种神奇/奇葩的情况下都需要考虑到，而且最重要的一点是这些还未必会在用户需求中出现，“如果用户这样这样，会出现什么情况”，如果“用户输入那个，又会怎样”，这固然是要求开发人员在写代码的时候就将情况考虑周全，但另一方面来说人本身就难免出现纰漏，因此就有了后续测试的必要。而后续测试中要如何做到周全？就算是做到100%代码覆盖，也不能保证100%的正确性，所以才会有各种补丁的不断出现，所以才会有各种版本的更新…

总而言之，写代码和做其他事也没有什么区别，负责和担当总是需要的。

疑问：感觉如何接收用户的反馈才是问题所在，很多情况下用户只会说有问题，假设在开发过程中并没发现问题，但实际上存在问题，那么如何加上报错机制方便接受用户反馈？

五．团队开发的若干

规则是死的，人是活的。当然MSF的那一套流程确实是成功经验的总结，但是在实际中能做到什么程度又是另一个未知数了。

在按标准流程走不下去的情况下，我们需要考虑哪些呢？团队项目的最困难的地方就是按时完成任务与队员间的沟通，其实那一套流程为的也就是保障这两点，也还好teamwork中各成员也都比较熟悉，估计相互督促沟通也不会太过于困难。

疑问：这只是针对我们学生的team而言，我们并不是专业开发团队，我们是否可只借鉴MSF中若干部分/按我们自己觉得方便的方式来开展我们的活动？

六.   其他

这只是书中一个小故事，“劫匪与绞刑架”——如果没有绞刑架，劫匪就不用有所顾忌了，但另一方面，劫匪的数量也必然增多，导致劫匪也越来越不好混。当然可以把这个故事理解为对目前我国计算机行业的一个幽默的诠释，现在就算是三本大学照样有个计算机专业，这样的泛滥导致所谓“计算机专业”学生也愈加普遍，那我们与那些泛滥普遍的“同行们”的区别就在于我们在大学期间所受到的教育与我们所能学到的东西。

“码农” 这个词的出现无疑是代表低水平的程序员越来越“不好混”了，因此我们的出路也就是尽量提高自己的技术水平，跨过那道划分优劣的门槛，因此就算是在teamwork中，提升个人的技术水平也是对整个teamwork进展的一大助力。当然在VSTS开发中，如果人人都能独当一面或者说干脆每个人都能独立完成这个项目，那各种团队开发的条条框框自然没任何价值，但是在实际情况中MSF所指出详细流程与具体方法确实值得我们学习参考。

疑问：那么是否可以考虑在团队工作结束后把团队成员在工作中得到的提高也算入个人成绩组成的一部分。

七. 敏捷开发有感

这个是晚上在博客园首页看到的某篇谈论开发过程中敏捷开发模式后，又想到之前看到教材BLOG里所想到的。其价值观——沟通、简单、反馈、勇气，谦逊听起来感觉着实空洞，简单说起来还是上文中说过的两点，责任与沟通，如此文中所示，其实敏捷开发与我们本身习惯的流程差别不大，其更重要的应该是将开发中所需要的原则明确的提出来了，而不是早上一次例会，晚上一次总结的形式。

因此就我们自身来说，本身作为学生团队，一日一总结表示很容易出现“抱歉，今天我什么都没做”，“今天我在写XXX课的作业”的情况，希望老师能体谅。