阅读作业
Agile Method - Martin Fowler
关于 Agile Method, 可能是我们团队作业在实践中用的最多的方法了。作者在文章中对这种新的方法给出了一些介绍：它们的发展是出于对 bureaucracy of the engineering methodologies 的抵抗。两者最大的区别在于项目的主导物件：后者是 document-oriented， 而 Agile Method 则属 code-oriented，这么看来，对于只有四五个人的课后作业项目来说，敏捷方法的确一种最省时高效的。
然而，抛开这种“不注重文档”的表象，敏捷方法之所以能 work 还有更深层的原因。工程方法（Engineering Method）往往对于 predictive 的要求很高，至少需要能较准确的预估项目的进度，而敏捷方法（Agile Method）则更加 adaptive。例如我们的 Alpha 项目开始前，老师要求我们指定的 plan 的粒度精细到每人每天（甚至每小时）做什么，这种程度的 predict 对于我这种新手而言简直是难以想象的，而到了后面我们遇到了很多问题和意料之外的事情，这对我们的 plan 影响非常大，逐渐的我们就转为了敏捷的模式。
另一个区别在于，敏捷方法不仅仅是 code-oriented, 更是 people-oriented。工程方法将团队成员的任务明确划分，每个模块都很清楚，资源的分配也是 plan 好的。可能这种模式在专业的团队中比较适用（“专业”不仅仅指有经验，这里还表示“全职的”）。而我们作为各个组的实习生，软件工程并不是我们的全职工作，我们的小组开会时间都可能在会议前五分钟突然得知某成员在开组会而临时调整。连续十天的冲刺时间，也可能因为某个周末组员因事回学校参加考试而暂停。这些 change 对于 engineering method 来说都是非常不希望碰到的，但是在敏捷模式下却并没有多大的影响。
关于 code-oriented 这一点我的体会也很深，由于我们团队被分为前端、后端两组，仅有的文档也只是列出了通信的数据格式。所以在我们前端拿到后端代码开始调试的时候，遇到了问题就会检查一下对方的代码，在这个过程中我们了解后端的工作流程以及发信模式，从而发现问题，更新文档或调整策略。
但是从理论上来说，我觉得 engineering method 看起来是更适合大的团队，大的项目的方法。他对 PM 的要求更高，项目的完成度会可能也会更有保障。
The Cathedral and the Bazaar
选择阅读这一篇，可能是我看到文章标题，大概就能猜到这是说的怎样的内容，并且觉得这样的比喻很有意思。
对于开源软件的开发，作者将它们划分为两种模式，并且以形象的比喻命名。
The Cathedral: 教堂模式
听到“教堂”，第一印象就是欧洲那些结构精妙，装潢华丽典雅的哥特式建筑。这样的建筑的建造是有体系的，有设计图纸的，甚至是有宗教含义的。它对应的开发模式是如 GCC 和 GNU Emacs 那种开源软件，尽管代码是开放的，但是软件的开发是由 exclusive 的团队负责的。
The Bazaar：集市模式
相比于教堂，集市给人的感觉就是乱糟糟，闹哄哄的了。这样的软件开发模式也可以被看作这样的，一群大概不认识的人，通过互联网，出于兴趣爱好等原因，合作一个项目。
那这么看来，通过 “教堂” 和 “集市” 的对比，是不是两种开发模式孰优孰劣就很明显了？毕竟教堂怎么也比集市更气派，更有审美价值。但是作者（Eric S. Raymond）却并不这样认为：
"given enough eyeballs, all bugs are shallow"
Linus's Law: the more widely available the source code is for public testing, scrutiny, and experimentation, the more rapidly all forms of bugs will be discovered.
作者认为，教堂开发模式下，源代码只被 exclusive 的人关注和调试，这样有限的开发者要发现大量的 bug 的代价是很高的。而集市模式下，所有人都能使用和开发的软件，其中的 bug 被发现和修复的概率则更高，成本也很低。
但对于这种观点，我自己有一点疑问：随着开源社区逐渐发展，越来越多的人放出自己的 source code， 也声称将自己的代码供别人使用和开发。但是在这样庞大的集市里，一个人，一个项目被发现、被关注的机会也是非常小的。我能想到一个软件被关注的原因：它很好用。但是这样的话，Raymond 的观点则不具有普适性，甚至现实是相反的：集市模式并不能让有缺陷的软件经过大家的共同开发而变好，相反这些软件将永远不被人关注，bug永远都是bug。与此同时，好的软件会更好，更多的人关注和发展它。（虽然自然规律就是优胜劣汰，但是这种规律似乎对于开源社区并不友好，把门槛设得太高了。）例如我们的现在开发的软件，由于参考资料的缺乏，前端和打包有一些优化的不是很好的地方，以至于现在我们的软件的安装还比较麻烦。这样的一个软件，我很难想象会有人想把它下载安装使用，并给出反馈。（甚至有的问题是我们意识到但还无法解决的。）
A Generation Lost in the Bazaar
出于上面一段对于 Bazaar 模式的疑惑，我自然会选择读一下这篇文章，A Generation Lost in the Bazaar：Quality happens only when someone is responsible for it.
上面那本书的作者 Raymond 说
Just hack it.
并且随着网络的发展，资源越来越丰富，似乎更多的人可以 hack 了。
但是这种抛弃设计图纸的集市开发模式带来的问题也随着版本的迭代而累积，日益突显。例如作者举例说的 Unix 这艘大船就正在因为自身越来越大的重量而逐渐沉没。
作者继续举例说自己安装 FreeBSD 的故事，指出了这个软件随着版本迭代而导致源代码混乱，以及 dependencies 错综复杂的问题。这样看来，整个 source code 看起来就像一个 Bazaar, 但是除了 Raymond 指出的集市的好处，现在看来更加突显的则是它带来的问题：23214个Makefile, 一层又一层的依赖关系……
a pile of old festering hacks, endlessly copied and pasted by a clueless generation of IT "professionals" who wouldn't recognize sound IT architecture if you hit them over the head with it.
这让我想到了之前看过的一张图片：
就像上一段说的，开源社区门槛理应不该太高，但是低门槛也是有代价的。
The Ph.D. Grind： A Ph.D. Student Memoir
作为一个要读 PhD (但愿可以) 的人，类似的文章也看过一些，这一篇也会想看一下。
对于一下作者 (Philip Guo) 的 PhD 的第一年的故事：Year One: Downfall ，虽然经历有很大的不同，但是我却迷之有共鸣。
初入 Stanford， 作者经历了痛苦的长达四个月的 grinding：导师交给他一项听起来并不有趣的任务，并且这个任务似乎是每一个 New PhD 都要经历的一个 Grind。在那之后，拿到了 external funding 的作者终于脱离了这个项目，但是却陷入了不是很好的状态： going solo。 他很详细地介绍了自己当年的状态，不仅是物理意义上的 solo，更是学术、精神上的 solo。不幸的是，这些我也都经历过，以至于作者描述的自己的内心感受和外在表现我都非常有共鸣。
作者站在写回忆录的立场，最后回顾这段经历，觉得是非常不正确的。
In retrospect, going solo so early during grad school was a terrible decision.
对于我来说，这大概是一个非常有用的建议，我也会注意对自己精神状态的调整，以及锻炼与人沟通交流的能力。