[读书笔记2]软件开发与如何开发软件的若干感想
//个人英文水准问题，部分理解可能出现偏差。
//10061162 刘俊伟
从“准则”谈起
Eric S. Raymond的为创造良好的开源软件提出的19条准则，对于我来说，第一反应不是想去看下面准则的具体内容，而是想起了推理小说里常常提及的诺克斯十戒和范达因二十准则。对于准则这个概念，个人的理解是长久以来积累的经验，但在另一方面来说，因为要符合长久以来的事实，所以准则往往也只能泛泛而谈了。
把这些准则对比一下就很容易发现这个问题了，比如：
（软件开发）Eric S. Raymond提出的第四条：如果你有正确的态度，那么你将会发现有趣的问题。
（推理小说）诺克斯十戒中的第二条：侦探不能用超自然或者怪异的侦查方法。
什么才算是正确的态度（超自然或怪异的侦查方法）？如果没有发现有趣的问题（没有被读者接受），是不是因为没有正确的态度（使用了超自然或者怪异的侦查方法）？
就如同某次课上谈创新，有些公司成功了，有些公司失败了，因为创新而成功的公司我们可以说他们有足够的勇气，因为创新而失败的公司我们可以说他们不够谨慎，因为专一而成功的公司我们可以说他们足够谨慎，因为专一而失败的公司我们可以说他们没有足够的勇气balabala…
某件事有九成可能成功，就算失败了也可以说是遇上了剩下那一成的可能，但话又说回来。毕竟这些准则是前人总结出来的经验，和前面纯粹的扯淡不同，尽管有些空泛，但依然有其道理，我们依然需要对这些准则（其实我更倾向于说是经验）有所理解。
泥球？线团？
因为编程人员的疏忽/错误/能力问题或是编程环境所限，或者说是需求的不断更改，现有代码中不可避免出现无用/大量一次性代码，也就是“泥球”的雏形，随着上面过程的不断反复，若是不加处理，最后难免整个程序都变得一塌糊涂，难以理解，就如同热力学中的熵增定律。
就个人看法来说，我更倾向于将“泥球”的说法换成“线团”。一开始写得顺利的代码就如同一条直的细线，如果中间出现了需要修改的部分，那我们就把线的中间截断，用一根新的线把原来的那条线连接起来，那么，被截断的部分，我们很可能就丢在身边，重复若干次后，很可能原来一条直线绕成了一团，更有可能被我们“截”下来的无用的部分也混入线团中了。
怎么处理这种情况？一是良好的习惯，阶段性的把“线”理一遍，把“截”掉的部分清扫干净。二则是果断的决策，与其在理不清的线团中折腾时间，不如全部推倒重新来过。当然费劲清理线团不是说不行，只是在效率以及价值上有所差异。
其中感觉最为深刻的就是个人项目了，从应对不完整的需求，到好几个版本的需求，短短一下午时间对代码进行了四，五次修改，分词的方法要改，统计的规则要改，输出的方法要改，旧的代码新的代码在短短几个小时里全混在了一起，就连自己看自己代码想要理清思路都是极为困难，最后也没有敢于推倒重来（- -不交作业或者晚交作业据说要扣分），只能费事费力的去整理自己弄混的“线团”了。
教堂与集市之争
依然是Eric Raymond的观点，开源运动必将盛行，every coin has two sides，编程的入门门槛降低，带来的大量程序员数量的增长，但其中绝大部分都停留在入门水准，因此才有Poul-Henning Kamp文中的提到的“随便依赖，互相纠缠，代码越重用，浪费越严重”，“一坨脓包似的权宜代码，被一群盲目的根本不知IT架构为何物的所谓IT“专业人士”永无休止地复制着，粘贴着”这便是集市理念所带来的负面影响。
仅仅是“对付过去就行”，导致一个整体水准的降低。如同一味提倡“敏捷”，“敏捷万能”一样，终究在软件开发中基础的还是开发人员的基本功底与技术水准，一种开发方式并不能改变大局。但我们或许也应该反思，在入门的基础教育上是否太急于求成。
而至于我们的团队，使用的瀑布（？）式的开发方式，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。
回到敏捷
瀑布模型（感觉和“code and fix”的模式差不多…）对于我们目前的团队项目来说还是适用的，通过很多短期项目决策来将整个项目拼凑起来。至于敏捷开发，其优点不必赘述，但是其对使用对象的要求必然不低——
- 组织文化必须支持谈判
- 人员彼此信任
- 人少但是精干
- 开发人员所作决定得到认可
- 环境设施满足成员间快速沟通之需要
（引自wiki百科）
初次合作的团队难以适用，经验不足的团队难以适用，沟通不畅的团队难以适用。就我们团队而言（典型的敏捷开发经验不足），在返回一标准向量的问题上时，在沟通上妥妥的出现了问题，这也是学生团队和专业软件开发团队的一个很显著的差异——我们的表达和沟通不能和专业人员一样精确高效。
因此，为敏捷而敏捷确实不是太必要。
以及总结
敏捷开发中提到的“以人为核心”，以及集市理念的负面影响，其关键还是在于写程序的人。只有程序员的水平够了，“敏捷”的方法才能实行，也正是因为许多程序员水平不够，所以才会出现“随便依赖，互相纠缠，代码越重用，浪费越严重”的现象。一味的追求开发方式/模式上的进步，也未必比得上实实在在提高程序员水准。而要提高自身水准，自然得多学多练，相比于一味抱怨开发方式不实际太空虚而不去做，也还不如按自身实际情况来多学一点东西，多练一次手。
