江西省网站备案,深圳做小程序的公司排名,项目网络计划,网站后台管理界面代码No Silver Bullet - Essence and Accidents of Software Engineering#xff1a; 银弹能杀死狼人。如果我没记错的话#xff0c;在漫画中柯南对黑暗组织而言就是一颗银弹。生活中是不是真的有银弹我还是不太确定。假如有#xff0c;银弹就是 一点弱点也没有么#xff1f;如…No Silver Bullet - Essence and Accidents of Software Engineering 银弹能杀死狼人。如果我没记错的话在漫画中柯南对黑暗组织而言就是一颗银弹。生活中是不是真的有银弹我还是不太确定。假如有银弹就是 一点弱点也没有么如果有能抓住银弹弱点的又被称为什么 在《No Silver Bullet》中强调了由于软件的复杂性本质而使真正的银弹并不存在所谓的没有银弹是指没有任何一项技术或方法可使软件工程的生产力在十年内提高十倍。所以我觉得这篇文章不是在陈述没有银弹这个事实而是希望我们在完成软件工程的时候不需要银弹。我们应该组织好开发团队选择最合适的开发模式。其实人人都是银弹就做到了No Silver Bullet。 真正好的项目需要便捷的开发技术但没有一种技术能彻底的舍弃了人的存在。我们不能忘记的重要事实是软件是为了方便人类而被创造的。 Managing the development of large software systems: concepts and techniques 这是后来大家说的 “瀑布模型”它有什么特点? 根据原文完整的瀑布开发模式应该是这样的 瀑布模型有以下特点 为项目提供了按阶段划分的检查点当前一阶段完成后只需要去关注后续阶段。这个特点决定了瀑布模型的适用范围不适用于经常改动需求的项目可在迭代模型中应用瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。 但是瀑布模型还有以下特点 在项目各个阶段之间极少有反馈只有在项目生命周期的后期才能看到结果通过过多的强制完成日期和里程碑来跟踪各个项目阶段。 瀑布模型对很多类型的项目而言依然是有效的如果正确使用可以节省大量的时间和金钱。对于我们的项目而言是否使用这一模型主要取决于是否能理解客户的需求以及在项目的进程中这些需求的变化程度对于经常变化的项目而言瀑布模型毫无价值。 在瀑布模型中软件开发的各项活动严格按照线性方式进行当前活动接受上一项活动的工作结果实施完成所需的工作内容。当前活动的工作结果需要进行验证如果验证通过则该结果作为下一项活动的输入继续进行下一项活动否则返回修改。 其实不管是瀑布模型还是什么别的模型都是被有意简化以帮助我们解决真实生活中遇到的问题。 big ball of mud 你的项目有一个大泥球么? 有什么解决办法 大泥球是指杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码。 其实很多软件都是靠着大泥球完成的。我觉得大泥球之所以有这么强的生命力肯定有他的可取之处。比如虽然肉体上的工作量大但是思想上的工作量小比如他的逻辑简单易于快速构造。同时弊端也是显而易见的。在现实生活中很多时候无论花费多少时间试图去找出完美的软件结构,客户总是引入一个变化破坏这个结构,不存在完美结构,只存在那些试图平衡当前的代价和收益的结构。有时候,程序员把原因归咎于客户,责怪他们总是改变需求。但是这不是他们的错误他们只是在思考一种最合理、有效的方式为自己的工作服务。 但是客户连源代码都看不到这种怨念却是没道理的。当我们接收时间管理助手的时候感觉就是一个大泥团。没有注释没有文档很难看懂一段代码对应哪块功能。但是还是得慢慢的看理解。我们的解决办法是每人负责一小块将大泥球分成小泥球然后再解决这个小泥球这项相对容易些。但这样也会出现一些问题。如果我的“小泥球”里的一些东西牵扯到别人的”小泥球“那么我就很难做下去。所以加强组员的沟通对解决大泥球也很重要。 CatB – Cathedral and the Bazaar 你的团队是用什么方式建造软件? Lost in CatB. 这些情况在你的团队中出现过么? 所谓的大教堂模式The Cathedral model源代码在本模式是公开的但在软件的每个版本开发过程是由一个专属的团队所控管的。 市集模式The Bazaar model源代码在本模式也是公开的不过却是放在互联网上供人检视及开发。 根据我对阅读材料的理解我们团队的开发模式应该是Cathedral模式。好像与Cathedral and the Bazaar 的倾向相左。 大教堂模式的优点是团队内比较凝聚可以集中到一个点。而我们做的项目相对比较小适合团队集中解决。 在《A Generation Lost in the Bazaar》中作者却报以不同的观点警醒我们不要在市集模式中迷失。他认为Raymond在其书中称颂的集市模式导致的悲哀的现实“一坨脓包似的权宜代码被一群盲目的根本不知IT架构为何物的所谓IT“专业人士”永无休止地复制着粘贴着。” 这确实一个问题但出现这个问题的原因不是模式不够完善而是程序员自己的原则性不够强如果每个程序员对自己所用的代码都了然于胸不可能出现这种情况。 Agile Method – by Martin Fowler 你的团队在开发中用了那些敏捷的思想和做法? 先总结一下原文章里的一些我觉得有意义的观点 在所有敏捷开发方法中XPExtreme Programming是最引人注目的它适用于需求快速变动背景下的中小规模的开发团队。极限编程弱化针对未来需求的设计非常注重当前的简化。因此极限编程适合规模小、进度紧、需求变化大、质量要求严的项目。它希望以最高的效率和质量来解决用户目前的问题以最大的灵活性和最小的代价来满足用户未来的需求极限编程在平衡短期和长期利益之间做了巧妙的选择。极限编程的特点 1.极限编程方法从整体团体的开发小型的系统等方面解决了这些问题。 2.极限编程使用了发布计划的方法。使得开发人员能对前一阶段的开发成果进行评估更好地把握后面工期的任务安排 3.极限编程方法尤为强调面对面的沟通通过现场客户、站立会议、结对编程等方式来保证沟通的有效。 我们团队在开发时间管理助手的时候有采用极限编程方式比如会采用类似Pairwork的方式集中解决一个问题。还有在做团队项目的时候每天更新Daily Scrum以加深组员之间的了解等都符合敏捷开发模式。转载于:https://www.cnblogs.com/WWW-Buaa/archive/2012/11/18/2776611.html
