Big Ball of Mud
原文链接：Big Ball of Mud
所谓的大泥球就是指一个杂乱的没有结构化的系统。代码在其中随意的堆砌，对bug的修复往往也是应急性的，不能为整个软件未来的发展做出良好的支持。
实际上在 Judy 的的项目实践中，我作为开发 Judy the Debugger 的后端开发成员之一，就能感受到大泥球对整个项目带来的影响。Judy the Debugger 在整个开发过程中，确实曾经存在着大泥球。产生大泥球的因素很多，正如文中所说：
Time: There may not be enough time to consider the long-term architectural implications of one’s design and implementation decisions. Even when systems have been well designed, architectural concerns often must yield to more pragmatic ones as a deadline starts to loom.
我们在开始Alpha冲刺前没有做好详尽的调研，导致刚开始的架构就为后来的Beta阶段的开发埋下了较深的隐患。
Experience: Even when one has the time and inclination to take architectural concerns into account, one’s experience, or lack thereof, with the domain can limit the degree of architectural sophistication that can be brought to a system, particularly early in its evolution. Some programmers flourish in environments where they can discover and develop new abstractions, while others are more comfortable in more constrained environments (for instance, Smalltalk vs. Visual Basic programmers.) Often, initial versions of a system are vehicles whereby programmers learn what pieces must be brought into play to solve a particular problem. Only after these are identified do the architectural boundaries among parts of the system start to emerge.
实际上，另一个原因也是因为我们不熟悉Julia这个语言，同时又没有对Debugger有过开发的经验，一切都是摸着石头过河，所以导致我们整个过程中会出现架构上的设计问题，导致出现bug或者实现新功能是有时候需要重构。
在我们整个Alpha, Beta 阶段中，我们一共重构了三次，第一次发生在Alpha 的第二天、第三天，这一次重构是放弃了使用Julia自身的源码，转而直接用Julia来开发Julia的Debugger。这次重构的原因是因为我们刚开始不了解Julia的源码情况，后来才知道Julia的源码并没有引入RunTime的Debug的支持。第二次重构发生在Beta的第二天，原来第二天的计划是提供多文件Debug支持，但是我们在修改代码是，发现目前的代码框架只能支持单文件下的Debug，因此才有了第二天、第三天的突发重构任务。第三次重构发生在Beta的最后几天，那几天的任务主要是实现块内（比如函数、if-else语句）断点，我们发现在单一线程下已经无法满足这个需求，所以将整个Debugger的框架改到多线程上。
不过有一点在我们整个开发过程中能做好的是我们不写 Throwaway Code. 除了架构设计，Throwaway Code 也是造成整个软件中存在大泥球的重要因素。每当我们出现bug时，我们总是会设计合理的方法解决这个bug，而不是简单的处理一下出现bug的情况。
关于大泥球的解决办法，这篇文章中给了一个方法，也是我们在Beta阶段采用的方法：重构代码。重构代码虽然需要耗费一定的时间和精力，但是能为我们的之后提供更高效的开发。所以在 Judy The Debugger 经历两次重构后，我们的开发速度也能越来越快。
虽然重构的方法确实能让整个软件在开发的过程中更加顺畅，但是对于我们有限的时间里，全部重构一边Judy the debugger 需要消耗更多的时间，更别说时大型项目了，所以我觉得一个软件不能轻易的重构，那么在时间紧迫的情况下该怎么权衡架构的设计问题和临时性的修复bug呢？这是我看完这篇文章提出的一个问题。
No Silver Bullet
原文链接：No Silver Bullet
这是软件工程中非常著名的一篇断言：作者Brooks认为：
没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步
银弹来源于杀死满月狼人的传说，是一种代表解决所用问题的通用型方法，而作者认为在软件工程中近十年不会有这样的银弹来彻底降低软件开发过程中很高的复杂度和各种各样的困难。
作者从两个角度来分析当今的软件工程所遇到的困难：Essential Difficulties 和 Accident Difficulties.
首先是Essential Difficulties, 这是软件工程本身所具备的问题：概念构建的问题，即如何从抽象的概念上，发展出具体的解决方案。Essential Difficulties 上作者描述了当今软件中不能减少的四点：Complexity, Conformity, Changeability, Invisiblility。 同时作者也指出了过去的软件工程重要性的突破包括 High-level languages, Time-sharing, Unified programming environments 也只是解决了软件工程中的次要性问题(Accident Difficulties).
我觉得作者说的很对，正如我们在前期调研如何开发 Judy the Debugger 的时候，我们尝试着阅读 Julia 的源码来获取一些有用的信息，并准备在这基础上进行快速的开发。但是，Julia 的源码比较庞大，很难在1-2天内理解源码的内容并提出修改的思路。所以干脆重新用Julia这个语言开发一个全新的Debugger，而不是在Julia这个语言源码的软件工程基础上来继续开发。
There is a Silver Bullet
原文链接：http://www.drdobbs.com/there-is-a-silver-bullet/184407534/
这篇文章的作者指出实际上可能存在银弹来产生一个通用的提高软件工程效率的方法。这个银弹就是组建重用。作者认为，可以通过开发出一些基础功能的、在许多软件中重用的小组件，来加入到整个大的软件工程中去。
然而，在我看来，作者所说的小组件，实际上可以理解为更高一层的函数抽象。而一个优秀的软件，必定需要有着自己与众不同的一面，而使用小组建堆砌而成的一个软件，在功能上很可能已经被市场上的软件所具备了，而那些与众不同的功能，在市场上应当找不到能够完成的小组件。所以，也正如作者在文中提到的：
However, this study has also revealed how difficult it still is, even with state-of-the-art object-oriented technologies, to design and build components that are both useful and genuinely reusable, to document their interfaces so that consumers can understand them, to port them to an unceasing torrent of new hardware platforms...
会面临着很大的挑战。
同时，以我们为一个新的语言Julia开发Debugger为例：事实上上面上的Debugger有很多，我们要做的功能也跟绝大部分Debugger很类似，但是却很难使用到现成的小组件来快速完成我们的这个软件。因为Julia由他自己的语言实现逻辑，而一个新的语言，很难找到现成的能够支持这个语言的小组件来协助帮忙开发这个语言相关软件的过程。
PHD Grind
原文链接：PHD Grind
这位Ph.D. 的第一年生活好惨，不能做自己想做的事情。但是同时我觉得他很有目标，有自己一个很想努力的方向，而正是这一点我觉得是他能够最终完成博士毕业的一个因素。同时也是因为他能不停的与领域内的学者们探讨，才能使他自己最终的项目能够成功。
因此我觉得做为Pre-PhD Student, 我们应当有一个自己的追求，为着这个追求能够奋斗五年，并积极的向领域内的专家学者请教探讨。