看了老师推荐的几篇文章，对软件工程的理解真是又加深了很多（感觉比移山之道深奥好多...)，但是随之而来的疑惑也非常多，下面可能没有一一列举，因为我认为其中的许多东西需要隔一段时间反复阅读就能理解，有新收获。
No Silver Bullet: Essence and Accidents of Software Engineering
这篇文章让我在广义上理解了银弹的意义：某个特别强大的技术，能使得软件的开发效率大大提高。
文章从许多方面，说明了银弹不可能存在。但是，可能是因为我对原文理解的不够深入，也可能是英文阅读的不够认真，我总是觉得原文对于未来技术的发展过于悲观了，正如当下飞速的移动设备发展一样，谁也不知道以后的机器学习能达到怎样的高度，而且生物与计算机的结合更是潜力无穷，是否哪天就有可能完全颠覆现在的软件开发模式？当然，我感觉这个问题短期内无法解决，所以原文在分析软件工程的本质上依然有着重要的意义。
The New Methodology
这篇文章介绍的是敏捷开发的一些本质内容。通过这篇文章的阅读，我真是对于敏捷开发又有了更深的理解。于是我产生了这样的想法：是不是可以把传统的瀑布模型看作是生产线生成，而敏捷开发就是组装生产呢？如果可以，他们似乎又有许多相通之处，比如如果要推翻产品的躯干，那么二者都是要重头开始，这个时候敏捷开发的优势如何体现？如果说是在敏捷开发中已经搞定的部分只需要更换接口，那么对于瀑布模型来说，他们的优势是可以借多人之力更快的重新搭建躯干，这里面的时间成本如何衡量？
集市与大教堂
确实，现在的开发经常需要从集市里找到一些东西，不顾质量高低，先完成当务之急。集市里的东西可能质量确实不高，但是是否就是不好的呢？既然他人愿意分享，肯定也有其过人之处，如果碰到有需求，怎样能判断是从集市直接索取还是自己构造高质量产品哪个更加合算呢？在我看来，一方面，解决这个问题还是需要程序员自身技术水平的提高，这样程序员就不会瞎拿瞎用，而是理性的选择，借鉴思路，加以改造。另一方面，程序员毕竟不是万能的，生活中总是能碰到几乎陌生的东西，这个时候，集市还是大有需求。这是否需要我们从另一个角度来考虑，卖方是不是该提高商品质量，而集市管理者是不是该加强管理与鉴别。这也就像现实中的生活一样，如果有质量更好，性价比更高的商品在超市有序出售，注重质量的消费者是基本不会在市集上出现的。
大泥球问题
我一直觉得我写的代码都是一堆泥球。没有详细的模块划分，很多地方只针对现在要解决的问题，可复用性差等等等。但是如何避免这个问题，我却一直没有找到好的答案，也许是能随着编程经验和技术的提高慢慢改变。但是，我觉得在实际的开发中，泥球是不可避免的，只不过有大有小。所以我就产生了一个大大的疑问：既然没有银弹，集市也不好，泥球又存在，那么为什么要如此注重代码而不是注重开发的方法本身呢？正如写文章，有东西写，词如泉涌。没东西写，东拼西凑也憋不出来。这是不是才是解决软件开发效率的根本问题呢？
在我们学生时间管理助手的实际开发中，原版就是一个大泥球！这其中的混乱真是各种各样，任何看似合理的更改一不小心就要让程序奔溃，有时忘了备份真是后悔莫及。而开发模式上，由于是在原版的基础上加以改进，我们这个更多的也可以看做是一种敏捷的方法？不停的修改着预定的需求，不停的去集市上找我们想要的代码，然后往上加。正是由于自身技术的不足，才导致频频上集市找代码，改代码，做测试。如果技术过硬，我觉得只用去集市上看看，缕缕思路，自己就能把问题解决。当然技术的提高就是在找代码改代码中实现的，没有一口吃出的胖子，边做边学确实是更好的办法。此外，在过去的两周里，我深刻的感受到沟通的重要性，很多时候仅凭文字真的很难把问题说清楚，但面对面后的效率也很是问题（比如经常我去找pm讨论一个问题，说着说着就又把整体需求又讨论了一遍，这是不是也是效率亟待提高的一个方面呢？）。总的来说，软件工程这门课不是半个学期的事儿，如果要当程序猿，攻城狮，这是一辈子都该思考的问题。