可能有银弹 There Is a Silver Bullet – Brad J Cox
这篇文章说到随着信息时代的来临，出现了一个软件危机，在一个“已故”的软件项目中添加更多的功能，只会让事情变得更为糟糕。进而提出了一个强大的武器，银弹，是一种范式转变，一种基于可重复使用和可互换部件的软件工业革命。这个在我平时的coding过程中，就会有很深的感触，如果只是为了一次性的完成某一个任务，而不考虑以后的复用，每一次进行一个任务，哪怕是一个与以前的任务非常的相似，都得重新的建立一个工程，这是非常的耗费时间，并且造了一个差不多一样的轮子，真是一种罪过。
big ball of mud你的项目有一个大泥球么? 有什么解决办法
这篇文章说到，我们为了快速的完成一个任务，并且因为不断变化的增长的要求改变一个软件系统的结构，原本整洁的系统变得过度生长，不受控制。这个在我们平时完成作业时，也是一个经常发生的情况。仅仅为了快速的完成任务，马虎的写了一个版本，然后下一次的作业，又在这一次的版本上加上臃肿的功能，代码结构乱的连自己都看不懂，更不用谈下下次的增加功能了。这篇博客对我感触最大的一句话就是，当一我的代码已经够乱了的时候，我还是重写一个吧。不要想着上一次的代码还能用，到了最后，可能整个任务都崩了。
CatB – Cathedral and the Bazaar 你的团队是用什么方式建造软件?
这篇wiki介绍了两种不同的软件开发模式，大教堂模式和市级模式，作者认为大教堂模式的软件开发让程式除错的时间大幅增加，因为只有少数的开发者可参与修改工作，市集模式因为有足够多的人一起开发，发现问题并且解决问题，这样几乎所有的问题都能得到解决。这样的感触我在这次的软件工程的大作业中深有感触，因为我在其中好不容易写了一个load and save model的功能，最终好不容易完工，非常高兴，简单的测试了一次，就push到了我们的github。可哪知，队友帮助我测试出了bug，最终解决了这个难题。可见一个人因为视野受限，对于问题的审视程度，不够深刻全面，无法解决所有存在的bug，所以，人员越多，对于整个项目越好。
Lost in CatB. 这些情况在你的团队中出现过么?
这篇博客，和上面的一篇，咋一看，似乎有点矛盾，因为他建议，一个项目，还是应该有人负责，才能保证质量。但是这篇文章是，写给在集市中迷失的一代。集市模式纵然很好，但是因为某些人的滥竽充数，导致了整个团队的质量，或者一个团队互相扯皮，这最终会导致团队项目的失败。我在学校的课程合作作业的经历中，就深有感触，大家刚一开始组建团队的时候，踌躇满志，信心满满，可是谁也不干活，到了ddl，草草了事，最终能有什么喜人的结果？所以一个项目，不仅仅是需要有人参加，有很多人参加，还需要参加的人对其负责。如果大家都不负责自己的任务的质量，那么这个人等于没有，只是占了一个人数，形同虚设。
Is “Computer Science != Software Engineering” an excuse to teach programming poorly?
在我心目中的计算机科学，并不是软件工程。科学，是一个面向理论的词汇，应该能有一个正确的深刻的理论，在背后支撑着科学。软件工程，来自实践，也服务于实践。可能理论的成功，能够更好的进行实践，实践的进行，更好的理解理论， 二者相辅相成，但绝对不是同一个东西。有的时候，我在本科的课程中，觉得有些理论课非常的难，但是在自己的实践中发现，似乎并不是这么一回事，自己不懂那些理论，似乎也能完成一个任务。或许这就是完成一个工程任务，而不是去弄懂一门科学。
为什么计算机系的老师教不好软件工程水平的编程?
这篇博客，应该是一位学生对于自己学校的课程或者老师的吐槽，认为在他们学校，貌似和我们一样理论第一，实践排在后面。我一开始也怀疑过这种方式，但是想一想，一个计算机科学，难道就是要教你编程吗？理论很重要，编程要靠自己的练习，老师能教给你的，也是最重要的，也是最难学的，便是相关的理论知识，实践得靠自己，而不是在课堂上去学的。