软工我的博客-week7

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段，那我以为服务器安全是朝不保夕的，而且关键并非在传输中。密码并不重要，密码是为了获得权限，数据和权限才是一个黑客想要获得的。
综上。
谢谢。