第二次软工阅读作业-孙胜
2012-11-13 23:57
176 查看
面对全是英文的阅读作业，我开始感到很烦躁，可是通过耐心的阅读，仔细的思考，我有了种“山穷水尽疑无路，柳暗花明又一村”的感觉。这几篇阅读作业分别从不同的角度让我深入的思考到：
1，什么是软件工程。在我以前的脑海中，我觉得软件工程就是编写出精彩的代码实现软件的功能。可是通过这次的阅读我深刻地体会到编程等等都只是软件工程的附属性工作，软件创作的本事是抽象用户的需求，创作出一种由抽象的软件实体所组成的复杂概念结构。软件工程充满复杂性，隐匿性，配合性和异变性。
2，软件开发模式的发展历程，以及每种软件开发之所以被保留或者淘汰都有着必然性。瀑布模型是由Winston W.Royce最早提出的。虽然他不提倡这种做法，可是在当时的背景下，这种方法无疑为软件开发者提供了清晰地思路和系统的开发方法。可是由于自身方法的局限性，注定会随着时代的进步，技术的发展儿被淘汰，取而代之的是适应时代发展，满足社会软件开发需求的开发流程。
3，再完美的代码也不如健壮地体系结构来得重要。现在的软件规模越来越大，使用的范围越来越广，如果软件的体系结构存在不完善的地方，就可能导致很多问题，比如说大泥球，这种系统包含很大的未使用部分。而且未使用的部分还与其他的一切交织在一起，使得识别它们变得不可能，更不要说删除它们了。不仅浪费了时间资源，更事倍功半。因此，在我们开始建造大厦的之前，必需理清楚体系的构架，充分发挥每个部件的作用，避免了时间浪费和后期的错误。
4，两种不同的开发模式，无论是大教堂还是市集，都有着各自的优缺点。《大教堂和集市》的作者就Linux开发成功的案例为我们讲述市集开发模式的特点，前提和优点。但是Poul-Henning Kamp的《有人负责，才有质量：写给在集市中迷失的一代》的一文重点强调:所谓质量，只有在某人对它负责时才有意义，而这个“某人”只能是一个人，不能是几个人——二重奏除外。各执一词，或许他们都有些偏激，我觉得各有所长。
5，深入的了解敏捷开发，并意识到敏捷开发自身的特点和优点。依稀记得第一次阅读作业，我提出了自己的疑惑，感觉敏捷开发和别的没有什么本质的区别，也无法深刻的了解到敏捷的重要性和优越性。可能通过几周团队作业的开发，加之这次阅读，使我深深体会：敏捷开发是适应整个开发过程中遇到的各个问题并提出解决的方案，而不是采用提前设计预知的方式进行处理，敏捷强调的是团队中“人件”的重要性，根据人员的分工，进度来调整整体的计划，而不是让过程主导一切。
下面我就结合前面九周软工课程的经历和这次阅读的感想，谈谈自己的想法：
在开始读《No Silver Bullet - Essence and Accidents of Software Engineering》的时候，我感到很深的困惑。这本书写于一九八几年，文中提及的所谓没有银弹是指没有任何一项技术或方法可使软件工程的生产力在十年内提高十倍。作者根据自身的经验和对未来的预测提出了自己的想法，可是都二十多年过去了，现在有没有银弹呢？我承认作者的观点很是正确，到现在为止：
1，我们无法改变软件开发的复杂性，甚至随着技术的发展，需求的增加，软件开发的复杂性加剧，抽象软件开发模型和方法越来越不易。
2，软件开发的易变性随着适用人群的增长和应用领域的扩展，变化的越来越快速。而且现代社会日新月异，每天都有着很大的改变，这些因素的变化也改变着软件开发的过程。
3，大型软件制作越来越多，合作交流越来越多，那么在软件开发配合性也变的越来越不易。社会经济已经全球化，网络技术更是推广整个地球村，那么彼此能否很好地交流，共同协作呢？
可是，接近三个十年过去了，我们还是欣喜地发现了很多方法极大地促进了软件开发设计的时间和效率。例如：
1，更多规范有效的方法使我们开发越来越明晰。例如随着UML的出现，我们可以很好地展示软件开发的设计方法，用图示法为我们展示出软件的功能。
2，很多优秀的语言减少了我们的代码量，软件基于对底层模块封装，可以减少软件需求变异所导致的软件更改难度。
3，很多优秀的软件开发模型，例如敏捷开发，面向对象编程等等都是软件开发研究成果，对软件工程的发展有着重要的意义。
我们不能悲观的认为，软件工程的本质决定了今后银弹也不会存在。我认为自己没有预见银弹的能力，也没有资格去妄断今后会存在一种方法改变整个软件工程的未来，我们只需要自身在尝试的过程中不断地创新，不断地改进和提出自己的想法，也许凭着一代代的努力会有那么一天的到来。
在谈及《大教堂和集市》以及《有人负责，才有质量：写给在集市中迷失的一代》，我觉得现在windows和linux都没有取代对方，独占市场，那么每一种开发模式都有着自身的优点，同时也并非无懈可击。就集市开发模式而言：
1，俗话说“众人拾柴火焰高”，开源软件的开发比大教堂的建造会多很多开发人员，虽然不一定整体水平比大教堂的建造师厉害，但是每个人都有自身的优势，相信在众多人员的帮助和参与下生产出更符合用户需求，更简洁方便的软件。
2，“早发布，常发布”的方法使软件能不断段时间更新，根据最新的需求和意见来改进和创造。
3，资源共享已然成为这个时代的发展趋势。
但是，缺点和不足之处也是显而易见的，比如说代码重复，结构混乱，效率低下，容易导致软件开发中途而废等等。
就大教堂模式而言，好处也是显而易见的：规范合理的开发，人员水平高，专人负责保证质量等等但是不可忽略的是：
1，私有资源很容易失去市场。现代社会很多人愿意尝试开源软件，这对大教堂模式是一个冲击。
2，参与人员数量有限。这对软件的开发，分析，设计等等都是一种局限。
3，更改困难，不经常发布。虽然力争做到最好，可是不经过实践的检验，只凭借企业内部的力量估计是不够的。
这只是我个人的观点，我觉得彼此都应该吸取对方的优点，不然在未来的发展中不是被淘汰，就是独占鳌头。
其次，就是具体的软件开发过程遇到的问题。我们这次团队作业采用的是敏捷开发。通过实际经历，我体会到首先，要考虑好整体的构架，明白每个部分的职责和任务。就像我负责的UI界面，开始的时候考虑不清楚，界面很多部件功能出现重合。在经过和大家的商榷之后，解决了这个问题。敏捷开发易于其他开发模型的关键之处就在于我们不用一次性的做完每一步的工作。这样基本不现实，而且容易造成修改时无从下手。敏捷开发只需完成最初版本，在一次次的迭代过程中不断地增添新的功能和修改过去的错误。在每次迭代完成后，都会思考有哪些地方做得不够好，有哪些地方必须改进，有哪些部分可以修改和添加等等。通过自身的思考，是我们的软件逐渐变得完善。
我个人觉得在开发过程中遇到以下的问题：
1， 团队成员的沟通不够，彼此之间信息传递较慢。
2， 开发过程中对自己的任务分析不够透彻，对软件需求了解不够。
3， 体系构架开始搭建的不够清晰，有些存在重复性。
4， 对今后的修改思考不够，还没理清头绪。
1，什么是软件工程。在我以前的脑海中，我觉得软件工程就是编写出精彩的代码实现软件的功能。可是通过这次的阅读我深刻地体会到编程等等都只是软件工程的附属性工作，软件创作的本事是抽象用户的需求，创作出一种由抽象的软件实体所组成的复杂概念结构。软件工程充满复杂性，隐匿性，配合性和异变性。
2，软件开发模式的发展历程，以及每种软件开发之所以被保留或者淘汰都有着必然性。瀑布模型是由Winston W.Royce最早提出的。虽然他不提倡这种做法，可是在当时的背景下，这种方法无疑为软件开发者提供了清晰地思路和系统的开发方法。可是由于自身方法的局限性，注定会随着时代的进步，技术的发展儿被淘汰，取而代之的是适应时代发展，满足社会软件开发需求的开发流程。
3，再完美的代码也不如健壮地体系结构来得重要。现在的软件规模越来越大，使用的范围越来越广，如果软件的体系结构存在不完善的地方，就可能导致很多问题，比如说大泥球，这种系统包含很大的未使用部分。而且未使用的部分还与其他的一切交织在一起，使得识别它们变得不可能，更不要说删除它们了。不仅浪费了时间资源，更事倍功半。因此，在我们开始建造大厦的之前，必需理清楚体系的构架，充分发挥每个部件的作用，避免了时间浪费和后期的错误。
4，两种不同的开发模式，无论是大教堂还是市集，都有着各自的优缺点。《大教堂和集市》的作者就Linux开发成功的案例为我们讲述市集开发模式的特点，前提和优点。但是Poul-Henning Kamp的《有人负责，才有质量：写给在集市中迷失的一代》的一文重点强调:所谓质量，只有在某人对它负责时才有意义，而这个“某人”只能是一个人，不能是几个人——二重奏除外。各执一词，或许他们都有些偏激，我觉得各有所长。
5，深入的了解敏捷开发，并意识到敏捷开发自身的特点和优点。依稀记得第一次阅读作业，我提出了自己的疑惑，感觉敏捷开发和别的没有什么本质的区别，也无法深刻的了解到敏捷的重要性和优越性。可能通过几周团队作业的开发，加之这次阅读，使我深深体会：敏捷开发是适应整个开发过程中遇到的各个问题并提出解决的方案，而不是采用提前设计预知的方式进行处理，敏捷强调的是团队中“人件”的重要性，根据人员的分工，进度来调整整体的计划，而不是让过程主导一切。
下面我就结合前面九周软工课程的经历和这次阅读的感想，谈谈自己的想法：
在开始读《No Silver Bullet - Essence and Accidents of Software Engineering》的时候，我感到很深的困惑。这本书写于一九八几年，文中提及的所谓没有银弹是指没有任何一项技术或方法可使软件工程的生产力在十年内提高十倍。作者根据自身的经验和对未来的预测提出了自己的想法，可是都二十多年过去了，现在有没有银弹呢？我承认作者的观点很是正确，到现在为止：
1，我们无法改变软件开发的复杂性，甚至随着技术的发展，需求的增加，软件开发的复杂性加剧，抽象软件开发模型和方法越来越不易。
2，软件开发的易变性随着适用人群的增长和应用领域的扩展，变化的越来越快速。而且现代社会日新月异，每天都有着很大的改变，这些因素的变化也改变着软件开发的过程。
3，大型软件制作越来越多，合作交流越来越多，那么在软件开发配合性也变的越来越不易。社会经济已经全球化，网络技术更是推广整个地球村，那么彼此能否很好地交流，共同协作呢？
可是，接近三个十年过去了，我们还是欣喜地发现了很多方法极大地促进了软件开发设计的时间和效率。例如：
1，更多规范有效的方法使我们开发越来越明晰。例如随着UML的出现，我们可以很好地展示软件开发的设计方法，用图示法为我们展示出软件的功能。
2，很多优秀的语言减少了我们的代码量，软件基于对底层模块封装，可以减少软件需求变异所导致的软件更改难度。
3，很多优秀的软件开发模型，例如敏捷开发，面向对象编程等等都是软件开发研究成果，对软件工程的发展有着重要的意义。
我们不能悲观的认为，软件工程的本质决定了今后银弹也不会存在。我认为自己没有预见银弹的能力，也没有资格去妄断今后会存在一种方法改变整个软件工程的未来，我们只需要自身在尝试的过程中不断地创新，不断地改进和提出自己的想法，也许凭着一代代的努力会有那么一天的到来。
在谈及《大教堂和集市》以及《有人负责，才有质量：写给在集市中迷失的一代》，我觉得现在windows和linux都没有取代对方，独占市场，那么每一种开发模式都有着自身的优点，同时也并非无懈可击。就集市开发模式而言：
1，俗话说“众人拾柴火焰高”，开源软件的开发比大教堂的建造会多很多开发人员，虽然不一定整体水平比大教堂的建造师厉害，但是每个人都有自身的优势，相信在众多人员的帮助和参与下生产出更符合用户需求，更简洁方便的软件。
2，“早发布，常发布”的方法使软件能不断段时间更新，根据最新的需求和意见来改进和创造。
3，资源共享已然成为这个时代的发展趋势。
但是，缺点和不足之处也是显而易见的，比如说代码重复，结构混乱，效率低下，容易导致软件开发中途而废等等。
就大教堂模式而言，好处也是显而易见的：规范合理的开发，人员水平高，专人负责保证质量等等但是不可忽略的是：
1，私有资源很容易失去市场。现代社会很多人愿意尝试开源软件，这对大教堂模式是一个冲击。
2，参与人员数量有限。这对软件的开发，分析，设计等等都是一种局限。
3，更改困难，不经常发布。虽然力争做到最好，可是不经过实践的检验，只凭借企业内部的力量估计是不够的。
这只是我个人的观点，我觉得彼此都应该吸取对方的优点，不然在未来的发展中不是被淘汰，就是独占鳌头。
其次，就是具体的软件开发过程遇到的问题。我们这次团队作业采用的是敏捷开发。通过实际经历，我体会到首先，要考虑好整体的构架，明白每个部分的职责和任务。就像我负责的UI界面，开始的时候考虑不清楚，界面很多部件功能出现重合。在经过和大家的商榷之后，解决了这个问题。敏捷开发易于其他开发模型的关键之处就在于我们不用一次性的做完每一步的工作。这样基本不现实，而且容易造成修改时无从下手。敏捷开发只需完成最初版本，在一次次的迭代过程中不断地增添新的功能和修改过去的错误。在每次迭代完成后，都会思考有哪些地方做得不够好，有哪些地方必须改进，有哪些部分可以修改和添加等等。通过自身的思考，是我们的软件逐渐变得完善。
我个人觉得在开发过程中遇到以下的问题：
1， 团队成员的沟通不够，彼此之间信息传递较慢。
2， 开发过程中对自己的任务分析不够透彻，对软件需求了解不够。
3， 体系构架开始搭建的不够清晰，有些存在重复性。
4， 对今后的修改思考不够，还没理清头绪。
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 