Part 1 No Silver Bullet - Essence and Accidents of Software Engineering
软件工程中没用通用的方法或者技术让软件工程在短时间内快速进步，这一点其实我也没有很明确的概念。其实近几年的敏捷开发框架，mvc结构，rest风格，这些的出现都大大提高了软件工程的效率，在我看来银弹的出现也是不无可能，毕竟单纯一个rest风格结合html5，给我的感觉让开发效率提高了起码百分之三十。
Part 2 big ball of mud你的项目有一个大泥球么? 有什么解决办法？
所谓大泥球，是指杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码。其实在一开始写工程的是偶，就是我大一的时候，我写的代码都是这种大泥球式的代码，我觉得这种代码的产生主要是由于开发人员没有开发经验和合作编程经验，有要急于完成任务。解决这种代码的方法就是要做好分层解耦和回调，拿后端来说，我们起码要做到的一点是，逻辑处理和数据模型的分离，之后可以进一步解耦，前后端交接的api分离为路由，数据的处理逻辑主体分离为控制器，参数的预处理逻辑分离为中间件，后端的整体动作分离为系统服务和触发器，数据的处理分离为模型，数据库结构和填充分离为数据迁移和数据填充。这样就很好的保证了代码的条理清晰，重用性，易于维护。
Part 3 CatB – Cathedral and the Bazaar
关于教堂和大集市，这是对开源软件开发模式的分类，教堂模式，源码公开，但是开发过程有一个团体控制；市集模式，同源源码公开，且源码放在互联网上供人阅览，并可以贡献代码，进行开发。提倡市集模式，认为在足够的人的检视之下，BUG将无处藏身。我是认同作者的观点的，举个例子，国内的大部分开源cms都是大教堂模式，或者说连大教堂模式都不能算，由顶层控制太严重。可以说这些cms的安全性是非常差的，但是反观国外的开源项目，大部分都是在github上让众人一起维护，包括php这种非常流行的语言（尽管php的漏洞略多，或者我接触的比较多。。。），其安全性与国内的cms相比高了一个层次。
Part 4 Lost in CatB这些情况在你的团队中出现过么?
过度依赖的问题并没有出现在我们的开发中，因为在一开始制定api和开发文档时，我就为团队成员撰写了环境搭建的教程和要求，并规范了各种数据的存储形式和结构，在我们的项目中，数据都是存储在数据库中，进行报告生成的数据都是以文件形式。
其实唯一出现过一次依赖问题是这样的，我们需要用latex进行报告生成，我们调试脚本时发现，在普通用户下执行是可以成功的，然而通过php调用生成脚本时却一直在报so库文件引用错误，之后我放了一个木马获得apache守护进程用户的权限，发现在该用户下运行是不成功的，之后我用ldd看那个出错的so库的引用指向，发现，他竟然指向了apache的库文件，也就是说py的库和apache的库有重名冲突，之后发现apache会给他的用户自动添加他自己的lib路径到ld_library_path，然而php的命令执行是不起bash的，所以无法添加环境变量，最后我写了一个sh起一个bash把/lib路径添加到环境变量里最终解决了依赖问题。。。。。。
Part 5 Managing the development of large software systems: concepts and techniques
瀑布模型在我们的工程中是得到了充分的使用，一开始是制定计划和需求分析，之后计划其实对我来说只是一个大体的概念，知道大家会在大体什么时间做什么就好，因为如果是针对我的计划时间，我一般会超前完成很多，之后需求分析交到我手中后，我根据他们的网站原型进行后端路由和api的设计，之后交给前端和后端开发人员，我们一起进行开发，最后完成后进行对接，之后进行测试，上线后维护。
Part 6 软件工程的方法论到底有多少用处?
他其实可以指导大多数的合作项目，有通用性。
-----------------------------我是优雅不要污的分割线-------------------------
其实写到最后我还想写一点其他和作业无关的事情，您在我们团队的博客下评论，用户名密码的传输过程没有加密，后端存储时是不是也是明文。先说明一点的是，后端是采用加密的，并且加密方式是动态salt之后进行hash，以我的认知水平来看，在我们规定的最小密码长度6位下，这个加密方式是无法破解的。
之后是关于明文传输的问题，我的主业的搞信息安全的，其实我遇到很多很多人跟我提漏洞的时候都是跟我说，这个密码是明文传输的，我其实很不理解，就这样来说，单纯在前端做一次加密是没有任何卵用的，我遇到过很多网站，他们前端做了md5，之后进行传输，但是这个传输过程中我如果嗅探到数据包，照样可以拿这个数据包进行登录，并且，这些网站在拿到他们的数据库权限或者注入得到密码后，发现起码有七成是直接拿前端传过来的md5进行存储的，这是一种愚蠢到爆的方式。如果前后端都做加密，安全性确实会好一点，但是我同样可以拿数据包登录。
我能提出来的唯一一种可靠的前端加密方式就是使用时间戳作为动态salt，也就是说，我们拿一个时间间隔比如15s作为单位，来用时间戳计算出一个salt之后与密码做hash，后端同样拿这个方法进行校验，这样可以保证每个数据包的有效时间最多是15s，但是，就算是这样，也会出现随机的验证失败（比如验证时间刚好在更换salt的一瞬间），并且，我完全可以使用脚本，在嗅探到数据包后立即重放攻击，甚至不需要重发，我既然可以嗅探到你发出的包，同样可以嗅探到你接收的包，普通用户的密码并不重要，重要的是登录后开放的接口，这样才有更多的漏洞暴露，也就是说，重要的是cookie和session。然而，这是任何前端加密都不能解决的安全问题。
并且，还有一个很重要的成本问题，我能想到的最有效的办法就是如上的时间戳方案，但是，这个方案也是个可以被轻易攻破的方案，然而，实现这个方案也是需要成本，如果这个应用真的有这么高的安全需求，他不会去付出如此的成本去实现一个破绽百出的方案，而一定会使用ssl。然而没有这种安全需求的网站也不会去付出这个成本。
以上的讨论都是站在一个黑客或者运维的角度出发的，我的确没有为用户暴露明文密码着想，因为我觉得，用户密码被嗅探，无论如何都是极小范围内的，如果嗅探者是在服务器C段，那我觉得服务器安全是岌岌可危的，并且关键并不是在传输中。密码并不重要，密码是为了得到权限，数据和权限才是一个黑客想要得到的。
综上。
谢谢。