读构建之法.2

例子。移山公司程序员阿超的宝贝儿子上了小学二年级,老师让家长每天出30道加

减法题目给孩子做。阿超想写-个小程序来做这件事,具体实现可以采用很多语言或工具:

Excel、C/C++、 C#、VB、Unix Shell. Emacs. Powershell/VBScript. JavaScript、 Perl、 Pythn....

请大家估计写好这个程序需要的时间。

我想,程序员用自己最擅长的工具,-袋烟的工夫就搞定了。

阿超一下打印出好多份不同的题目,让孩子做了。老师看了作业之后,对阿超赞许有加。

别的老师闻讯也想要类似的程序,让二年级到四年级都能用,并附带提出一-些小小的要求,例如:

题目避免重复

可定制数量和打印方式可以控制下列参数

是否有乘除法是否有括号数值范围

加减有无负数除法有无余数

是否支持分数(真分数、假分数.... )是否支持小数(精确到多少位)打印中每行的间隔

阿超的儿子兴高采烈地回家来给老爸汇报,并说“老师明天就想要!”阿超有些挠头,原来就是随手

写了个程序,现在怎么来了一些用户,还带来了不少需求?现在大家估计做好这个软件需要多长时间。

阿超熬夜做出了这个软件的一一个初始版本,交给了老师。过了几天老师说,教导主任看了很满

意,提议把这个程序放到学校的网站上,再多-一点点要求,支持二元-一次方程,能开根号,并

且让老师和家长可以通过网站定制各种类型的四则运算作业,还可以生成期中、期末考试的试卷

。当然,希望网站永远是可以用的,至少早上五点到晚上十二点要能访问。

阿超叹了一口气一这是多复杂的- 一个工程啊,如果有一天晚上网站打不开了,我是不是还要修

理服务器?

这里我们看到客户们对阿超的需求从一一个简单的程序,扩展到-一个满足各种功能的应用软

件,再扩展到一个能保证维修的软件服务!现在请大家估计做好这个软件服务需要多长时间。

上面的例子展现了软件工程的一些概念。

很是真实了

几个......

软件=程序+软件工程

软件企业=软件+商业模式

软件工程是把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程。

软件工程包括下列领域:软件需求分析、软件设计、软件构建、软件测试和软件维护。

这和之前的数据库设计有点像呢,这之类的设计都是按照这么个流程?

VSTS写单元测试

https://www.cnblogs.com/zhanglsh/p/5285285.html

https://www.cnblogs.com/xugang/archive/2008/06/06/1215158.html 很是明白...

单元测试的好处 http://www.blogjava.net/square/articles/158103.html

单元测试是指对软件中的最小可测试单元进行检查和验证。

回归测试是指修改了旧代码后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误

PSP 个人软件过程

魔方的故事

大概是在我小学五年级的时候, 大家开始玩魔方,我们家也买了一个。我和几个小孩折腾了一会, 没搞出什么名堂。我哥摆弄了好一会, 嘿! 弄出一面一样的颜色。后来我也琢磨出来怎么把一面颜色拼出来。再后来我才知道魔方有一些模式和一些口诀,按图索骥, 依口诀而行, 就会从一面玩到一面再加一层,再到加两层, 然后把最上层四个角的颜色搞对, 然后再按照一两个口诀翻十几下, 六面就做好了! 我玩着玩着就把各种模式和口诀都掌握了。上初中的时候, 我还在课间表演过, 赢得一些男同学的好评, 女同学似乎对此不感兴趣。

要在当时, 我的简历上一定会在“技能”一栏写上:

“精通玩魔方”。

后来我就不玩魔方了,这样过了二十多年。

几年以前我在一个实习生的桌上又看到了魔方。我拿起来,似乎不用想, 当年的口诀就在手上. 转啊转,一面, 一层, 两层,那个男实习生露出崇拜的目光。。。直到最上一层, 嗯, 口诀是什么来着? 我试了几种可能, 好像都不行。我看到周围的女实习生似乎不感兴趣, 那就算了吧。

看来我的简历要改写成:

“精通玩魔方到第二层”。

后来我想, 把第二层拼好, 我只知道找到某个模式, 按照某个口诀执行即可。但是我并不了解为什么这个口诀能把第二层拼好, 同时又不打乱第一层的结果。我更不知道如果在执行中走错了几步,如何随机应变, 挽回局面。离开了口诀的话, 我只能把魔方的一面拼出来。从这点看来, 我的魔方技能应该是

“能够还原一面, 其他看口诀可搞定”。

那我的这真实的“技能”还值得写上简历么? 看样子是上不了台面了, 那什么是“技能”呢?

看了很有想法,想问同样的问题?

于是有.....书上总结成简单的“已经知道怎么做了”

意外翻看到 惊 https://www.cnblogs.com/xinz/

原文地址:https://www.cnblogs.com/jj-wbsds-n/p/9595438.html

时间: 2024-10-12 02:43:21

读构建之法.2的相关文章

读构建之法之感

读构建之法之感,为什么迟迟没有发构建之法这本书的观后感,是因为想要细细的看,为什么老师这么要求我们这么做,为什么要刻意的去发微博,原因都在构建之法的这本书中.构建之法这本书和其它的软件工程的书不同,构建之法这本书讲的清晰有趣,容易理解,不像其它的软件工程的书籍,写的那么的枯燥和乏味,构建之法的每章都有很大的联系,让人逐渐的去深刻的理解.通过构建之法理解并懂得什么是软件工程,软件工程是系统的,有序的,可量化的方法应用到软件的开发,运营和维护中去.希望通过自己的努力以及软件工程的课能够让自己有一个小

第五次作业《读构建之法的心得》

<读构建之法的体会> <构建之法>这本书是软件大大神邹欣的作品之一,这本书体现邹欣老师的情怀,很简洁的讲述了软件设计的各个阶段,描述了一个微软软件大神对软件的理解.构建之法对我帮助挺大的,通过构建之法这本书使我对软件的构建很清晰的了解,让我对软件设计更加的清晰的认识,增加了我对软件的认识的兴趣,好了,现在来讲述讲述里面的内容,第一张讲概论:软件等于程序加文档,软件工程是什么,第二章讲 个人技术和流程 单元测试,效能分析工具,个人开发流程第三章讲软件工程师的成长 个人能力的衡量与发展

对读构建之法后提出的五个问题

读构建之法有以下几点疑惑: 1.如何使自己的开发思维更加敏捷? 2.如何分配好团队里面成员的任务,来达到最好的工作效率? 3.当面临用户的需求和优化后的软件起冲突时,用户的需求一定是最重要的吗?那么用户根本不了解优化的软件的好处,一定强制要求修改怎么办? 4.如何使自己的产品在市场上占有绝对的优势? 5.什么样的软件开发团队要开发什么样的软件才适合敏捷流程?

第五次软件测试作业 读构建之法有感

之前没有什么认真的看完构建之法这本书,最近用了一星期的时间紧赶慢赶的认真的把书看完了,越看越起劲,后悔之前怎么没有早看着一本书,看了邹欣老师写的构建之法,感觉和读其它软件技术方面的书感觉截然不同,邹欣老师的构建之法想要告诉我们的是一种第一线的编程思想,比起平常所学的技术感觉起来更富有实用性,他用了程序员的第一视角来告诉我们软件编程者一思想,从第一章概论的软件工程是什么开始,就给予人一种引人入胜的感觉,给程序员一种深深的代入感,书中不仅有丰富的代码示例,还采用了一种一问一答的方式来解答问题,我想邹

读构建之法,重入编程之门

在翻开这本<构建之法>之前,我以为从专业划分角度来讲我多少算是一个计算机人,最起码算得上一个计算机专业的人.但是在当我谨慎的选择了一个自认为适合学习的好环境,怀着一种对编程无比向往的心情阅读这本书的时候,才意识到,之前的我可能是迈入了计算机隔壁班的门. 不得不说,邹欣老师的书,确实不像其他同类书籍那样全篇皆是各种枯燥无味的理论体系和大量读完也不知所云的专业术语及定义,虽然以我的基础程度对于此书中提到的各种编程案例理解的也不是很透彻,但是本书的趣味性着实使枯燥的编程更容易被接受.它刷新了我对软件

读构建之法之笔记

<构建之法>这本书一到手,我就迫不及待的要把它打开来.我心中满是期待:这究竟是本怎样的书,为什么老师会向我们推荐这本书,而不是其它的呢?带着这样的疑惑,我开始阅读这本书. 在大致的看了这本书之后,我发现这本书的确有其过人之处.相比于其它的相关书籍,这本书更加通俗易懂,更加生动有趣.书中常常通过生活中的例子或者对话来阐明一些枯燥乏味,深奥难懂的知识.这让读者读起这本书来并不是那么难,使读者能更快速的理解那些知识. 简而言之,<构建之法>的确是一本与众不同的好书,值得我们花时间去阅读.

初读构建之法

 以前对软件工程没有特别详细的看法,有些模棱两可.经老师介绍购买了构建之法,初步看了构建之法的   第一章.第五章以及十七章,对软件工程有了一定的了解,下面想要说一说我的个人看法.         百度中有这样的定义,软件工程是一门研究用工程化方法构建和维护有效的.实用的和高质量的软件的学   科.又或者说,比较认可的一种定义认为:软件工程是研究和应用如何以系统性的.规范化的.可定量的过程   化方法去开发和维护软件,以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法  

读构建之法8、9、10章有感

第八章.需求分析 书中介绍了一些获取需求的常用方法.流程.及分析框架,看了后才发现原来需求分析还有着者这么多的学问. 以前听人说,需求分析在实际项目开发中所占分量很重,甚至往往需要花的精力比敲代码要多.我听到时不以为然 ,认为需求分析不就是看一下软件要什么功能,要做成什么样而已吗.再后来,我真的接手了一个小商业项目的需 求分析任务,才明白需求分析是一件多么让人崩溃的事情,客户对软件编程一无所知,只是含糊地给我一些文档, 而我又不清楚他们的业内流程.业内术语等,不知道如何去获取对需求,只能像只无头

初读构建之法的感想和对课程的期待

看了构建之法的前几节,最开始的发现在于我之前理解的软件工程是错误的,连狭隘都谈不上吧,因为机器的以为软件工程就是编程,其实不然,像书中所说软件=程序+软件工程.可以说软件的基础是程序,而软件工程是将一个编好的程序通过需求分析,测试等操作变成一个较成熟的程序.他需要一个规范的流程,团队的协作,当然也需要个人的技能.这里我们就要提到个人技能了,虽说以团队的形式合作,但一个人的职业技能还是能够影响甚至决定全局的,如书中提到一场足球赛可以有很多种战术协作,但每一次的传球射门都要凭借每个球员单独来完成,所

(第九周)读构建之法有感1

构建之法第四章:两人合作 在这一章节里面,我才深刻地认识到自己所编写的代码是有多混乱,多么的不规范.编写规范的代码是程序人员良好的习惯.书本里面提到的代码复审以及结对编程都是要合作的,我们曾经也进行过结对训练,能在实践进行中感受到每个人的角色和作用,学习到很多,对于代码复审则是比较陌生.但是在书中还是了解到代码复审的作用是很强大的,非常适合一些中型以上的程序的测试检查.