对于银弹:
在《No Silver Bullet》这篇IBM大型电脑之父佛瑞德·布鲁克斯（Fred *s）在1987年所发表的一篇关于软体工程的经典论文中，强调了由于软件的复杂性本质，而使真正的银弹并不存在；所谓的没有银弹是指没有任何一项技术或方法可使软件工程的生产力在十年内提高十倍。
作者用了诸多的例子，从多方面阐释了这一认识的正确性。虽然反响强烈，争议颇多，但是，抛开复杂的论证过程，我们却不能忽视这篇文章想要强调的最重要一点：真正好的项目，需要便捷的开发技术，但没有一种技术能彻底的舍弃了人的存在。我们做的项目，不可能做到一劳永逸，好的项目是要能够持续更新保持生命力的，而这其中，我们人才是主体，难以想象如果脱离了人，一个软件还有什么生命力可言。我们不能忘记的重要事实是，软件是为了方便人类而被创造的，离开了人类，它也就失去了存在的价值与动力。
对于大泥球：
顾我自己写的大泥球代码，整片都是杂乱无章的堆砌，大泥球是指杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码。这对于我来说写出来的额东西也很难去让一个外来人去读懂和维护。读了这个大泥球的文章之后我觉得首先有个成本问题——软件开发可以说是没有物质成本的。可以看到大泥球能够工作，而且，造成一个大泥球并不比有道理的开发架构需要更多的物质成本，多调几个大泥球经费也不会被马上耗光——一个失败的设计在量产时需多焊很多的电路板可能会马上被产品经理批评——相反，软件工程中的大泥球还能提高时间效率，它能减少了架构设计的思考占用的时间。我理解中架构的一个有点就是层次地整理可以重用的代码来减少代码量，提供可维护性，缺点在于不灵活，然后对于经验不足的初学者来说，开发周期有时候是更长的。还有一点，当一个人做的不完全是真正的产品，而是一个试验品、或者说是简历填充物的时候，能见度原因就不起作用了，因为要是说代码给别人一看，让别人觉得，这TM写的一坨大……肯定没有前途。所以我必须坚信写软件要有架构。我们团队一开始也是写大泥球，但是经一番调整之后我们开始进行合理的构思和计划，以至于效率和代码质量都有了提高。
关于catB：
此文描述两种软件开发模式，即：“大教堂式”和“市集”两种。这两种都是开源的，但区别在于“大教堂式”的每个软件版本代码在团队的手中，而“市集式”的源代码是在互联网上的。此次我们是*项目，有组员们自己选题，软件代码是自己编写，属于第一种——“大教堂式” “市集式”的开发带来许多情况。在有些人称为是.COM热潮时，认为在这个大热潮的时代IT人员大量涌现，代码的产量也是吓煞前人，有些人大为称赞此状况的时候，作者提出这只是在“市集式”开发的一种迷失。作者认为这只是一种泡沫，是一种与“教堂式”恰恰相反的“集市式”。在这种情况下，各种参差不齐的代码与模块化不够清晰，最为严重的是强行使用不必要的代码重用导致将整个WEB弄得混乱不堪，与自己声称的种种优点背道而驰，因为被作者称为只是“Lost in CatB”。此次我们并不是使用“市集式”开发模式，且我们软件调理已经理清，框架明了，不会出现这种混乱情况。
关于瀑布：
瀑布模型（Waterfall Model） 是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，我们做软件的时候可能常常希望有一项技术或方法可使软件工程的生产力得到突破性的提高，然而事实上真的存在这样的东西么？
关于敏捷：这次团队作业用到了SCRUM方法论。Scrum是一种迭代式增量软件开发过程，SCRUM方法论中其核心仍然迭代和增量，首先对于产品需求会划分为多个迭代或增量，每个迭代都需要在1个月能够交付，而一个月即是一次冲刺，而一个迭代版本又需要转化到每天的进度跟踪和问题解决，这就是每天的15分钟会议，2-3天开一次会研究下下一步要做什么需要具体完成什么。同时，任何一个软件项目都可以 从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。我们用近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的 小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整 开发过程。