个人阅读作业

最新推荐文章于 2024-10-10 12:01:53 发布

weixin_30457065

最新推荐文章于 2024-10-10 12:01:53 发布

阅读量71

点赞数

文章标签： c# java 爬虫

原文链接：http://www.cnblogs.com/thereisnoname/p/6275636.html

版权

对软件工程的学习做一个总结。

　　　　且从头讲起，之所以选了这门课而没有选择另一门软件工程，便是因为以为这一门课中对于文档之类不怎看中更看重做的东西。然而博客分数在最后得分明细中却占有者不小比例，直接被来开差距。更何况一次阅读感想，我阅读完确实没有什么感想，并且作为诸多阅读的博客中的批判对象，我也不想与之争论，故没有多写，却被要求写出更多的阅读心得，似乎是想要我把它当做小学语文阅读作业来写，不过仔细想想这也有它的道理，是我当初为了避开写文档的作业选了这门软工而不是另一门时，在心里埋下了这门课并不那么的教条的种子致使我随手写下了阅读完后的当时的内心感想便以为作业已经完成，然而知小学语文明明是要求仔细阅读多遍找出值得称赞之处值得学习之处一一列举出来。

　　　　至于结对编程，结对编程的时候我们团队刚好三个人，然后并了没有按要求来坐一起编程，一个人编程两个人提供改进意见检查错误之类，其实当时也考虑过要不要完全按照要求来，但是一是当时我们都觉得有个人看着写程序浑身上下鸡皮疙瘩都快起来了，坐在那里如坐针毡根本集中不了注意力，效率太低（某次在教室写代码队友要求加一个很简单的东西，然而旁边坐个人看着太紧张总是改了这里忘了改那里，随手一改便是一个标准的bug）便各自编程，可谓是结对编程的反面教材。如果这学期只选了软件工程课程的话，结对编程说到这里便以失败结束了，不料我还选了一门其他课程，而这门课程恰巧也需要两人结对完成大作业，而且因为我们的拖延症，这个作业拖到期末才开始动手完成。说来也搞笑，我们当初完成这个作业的时候也没想着结对编程，但是由于需要整合两个人写的代码并且进行多处交互，在整合时需要修改多个地方，我们在这时竟然如结对编程一般坐在一起一个人敲代码一个人在一旁看。这个作业的完成过程严格来讲并不能说完全是结对编程，但后来整合的编程过程中却是实打实的结对编程，也确实让我事后感受到结对编程的优点，提升工作质量。

　　　　然而回过头再想现在重来一次结对编程的那次作业，我仍不认为结对编程对于那次编程作业是一个有效策略。诚然，结对编程的好处大家都知道，诸多文献也都在谈，这里便不提了，只讲讲为何不是有效策略。结对编程需要双方的配合，而这需要一个较长的磨合期[1]（注：后来那次其他课程上的结对编程之前，我已经与该队友共同完成过多次项目，变相度过了磨合期）,然而我们那次双方配合也并不好，发生过一个人问另一个人他写的代码中的一个问题，然而另一个人觉得你这你自己看代码就能解决为毛要问我，自己读代码啊，然后不予回复的情况，结对编程需要要求两边都是乐意和他人沟通和合作，彼此尊重，愿意与他人分享自己的知识[2][3]，然而实际上年轻气盛的年轻人并不能保证都可以做到这些看似简单的美德，周围年轻气盛的例子都是校丑不方便外扬，不过个人觉得这应该不是我们学校问题，毕竟南方某高校舍友之间都投毒了。

　　　　团队编程本以为会是一个一群人坐在一起编程的工作，结果却因为凑不出时间前期都没有这么做而是各自为政，工作效率非常的差，只在后来有一次抽出机会坐在一起编程了一天，就我个人感受而言，大家坐在一起编程的那次可谓是效率相当之高，预想要解决的问题当时都解决了，想要修复的bug也当时都解决完毕，而且大家坐一起编程做的时候也心情愉悦，不像平时做的时候遇到烦心的地方烦半天下不了手。平时的跟pm汇报的每日任务经常出现比预估时间长得多的完成时间，就那简单的我做的一部分java调用c#讲起，本以为这是一个很轻松的活，因为网上有现成的，讲解清楚的，看起来一副猴子也能学会的c#调用java的教程，然而实践起来却困难重重。教程中没有提及运行时的后台机制，同时c#本身不够熟练，只是当时大大超出预期。举个简单的例子，教程中全然未提c#和java 中string的汉字编码格式不一致，去其他网站也没有找到什么好的办法能够直接把c#中的string转换为java中的string。当时调研半天都没有找到什么好的解决策略能够直接把c#的string直接转换为java中的string，最后还是借助于团队中另一人的想法，将其先以UTF8写入文件再在java中以UTF8读出。这里希望这门课的这次作业能够稍微减轻任务量，这样我们平时分散工作的时间可以花的少些有时间完成其他事情才能有更多的机会进行这种一个团队坐在一起一起工作一天的机会。整个团队编程中就这点感到十分遗憾，整个团队编程中留下最深印象的便是那次编程，然而这种事情只做过一次。

理解或心得

　　No Silver Bullet：

　　　　购买与建造不得不承认是一个好办法，但这个办法太过依赖第三方程序的可靠性，经不起滥用，我们在这次项目中便吃了滥用的亏。我们的项目中爬虫部分起初使用到了一些网上的jar包，出现了在本地跑完全没问题但在服务器上无法正常实现功能的现象，我们经过定位后发现jar包出了问题，然而这给我们的修复这个bug带来了极大的困扰。弃掉换一个又得重写调用和使用部分的代码，以及重新学习该jar包的功能；修复又由于jar包是第三方完成，对于其jar包内部的实现了解甚少，修复的代价可能比前一条更高。

　　There Is a Silver Bullet：

　　　　这篇文章看似也在讲面向对象，但却和上篇文章质疑的面向对象部分不同，上篇文章质疑的面向对象更偏向于质疑面向对象思想应用在编程中是否能成为银弹，而这篇文章个人看来更类似于上篇文章中的提及的建造。

　　big ball of mud：

　　　　何止是一个，我们接手时项目本身就是个大泥球，接手时甚至上届提及不要依赖他们的代码，阅读其代码也十分费力，举个简单的例子，其在代码中定义了大量全局变量，单单这样的话这倒也没啥，但其使用时却往往其自己都忘了在哪里修改过这些全局变量的值，这给我们无论是阅读其代码，还是解决其bug都带来了极大的困难，虽然代码没有文中提的报废那么不堪，但是已经俨然是一个大泥球了，最终贝塔阶段重构。

　　CatB – Cathedral and the Bazaar

　　　　单讲我们做的，则是cathdral方式，若是考虑到上下届做的人，则更像可能有些接近集市。

　　Lost in CatB.

　　　　从集市上拿来的爬虫确实对我们带来了困扰，责任不能精确到人或者说不能追究这个问题我们确实出现了，这也是我们重构的原因。

　　Worse is better：

　　　　确实两篇文章都讲了是实现上的简单比起接口，一致性等其他事项的简单更为重要，但是我很怀疑第一篇文章举出的unix的例子，个人没有用过unix系统不方便讲个人体验，单就上篇LOST IN CATB中提及的我只想要安装火狐，而你却让我安装122个包，，然后安装完后还无法渲染TIFF图片，这真的好吗？？我很怀疑。确实若是这段代码写完便过去了，如某些课程的大作业提交后便无需二次更改，确实worse is better，但是若我们有足够时间的时候，或者当这段代码需要在未来很长一段时间内被使用的时候，在这种情况下我不认为我们应该写出一个worse的代码，这将给未来使用和修改代码的人带来极大的困扰，这在另一门课程面向对象上也有体现，面向对象课程中对我们写的同一份代码进行需求变更了多次，这里真是庆幸当初第一次交的时候时间比较充裕好好写了一下，若是写出个worse的版本恐怕到学期末他要我加功能时我都不太记得当初的函数应该如何正确调用。

　　敏捷已死：

　　　　这两篇似乎都在讲一个现象，管理人员号称敏捷讲了半天，却做的时候未按照敏捷思路，然而我们离这个还是有些远，我们的pm自己也只是学生，较为谨慎，没有“盲从”敏捷，更何况我们本身也时间比较紧张，没有时间完成那些仅仅是取悦管理者的东西，在我看来并没有犯这些文章中指出的错误。

　　方法论：

　　　　软件工程中之所以专门强调方法论，是因为软件工程具有特殊性，需求总是在不断变化，而且想要实现预见到种种情况是十分困难的一件事，这就使得我们难以用传动的工程方法。例如建造建筑物需要先进行周密的设计，然后工人只需要按照设计图纸一步一步来便可以，而软件工程注定了他不可能这样。这时不同方法之间的差异便会很大的体现出来.敏捷开发这个方法为我们提供适应性能够满足我们在需求不断变化的环境下在较短时间内给出可行解。