zoukankan      html  css  js  c++  java
  • 阅读《构建之法》的几点思考

    阅读《构建之法》的几点思考

    一、前言

           最近这两天,我认真阅读了邹欣老师编著的《构建之法》的第1章,第2章与第16章,在获得了许多知识的同时,对于文中的一些知识与观点,我也依然还存在着不少的疑惑。以下就是我在阅读过程中的疑惑与不解,对此,我也做出了一些思考。

    二、第1章

    1.文中说到这样一个例子:

    我上班后,发现以前同事写的程序真是垃圾,根本看不懂,无法维护。我要推翻重写!后来一个老员工笑嘻嘻的告诉我,我们现在看到的程序,就是去年的新员工愤怒地推翻重写之后的结果,大家反应还没有以前的版本好用呢。

    我的疑惑:

    随着科技的飞速发展,技术水平的不断提高,编写程序的语言也更加先进,更加精简。因此,编写出来的程序应当是更加的言简意赅,为什么却说是还没有以前的版本好用呢?对此,我是深感疑惑。

    我的思考:

    通过上网查阅相关资料,我了解到,即便是一个很简单的程序,随着开发的深入,时间的延伸,都会变得慢慢的臃肿与庞大。程序在逐渐衍生的时候,前期的设计会变得越来越模糊,系统会逐渐脆弱,对变化也越来越敏感。到了后期,一般只能在合适的地方增加程序,而不能修改。因为即使是一个小小的修改,都会导致一系列新的问题,并可能产生一些莫名其妙的bug。于是程序会逐渐变得臃肿,重复代码逐渐增加,莫名其妙的问题逐渐增多。写这样的程序完全是种折磨。做好前期的工作会使这种感觉得到改善:  

    (1)完善的需求:应该包括目前所有的需求,以及潜在的需求。

    (2)良好的设计:设计容易走两个极端:一个是完全没有设计。你要什么功能,一个一个给你实现,就得了;第二个是完全彻底的解耦。即使很紧密的关系,也会被完全的分离。好的设计应该能够预测可能发现变化的需求点。并预留可能修改的接口。

    虽然,经过这个介绍,我知道了是因为程序在深入开发的过程中变得越来越庞大,所以才导致了程序越改越乱的问题,但是,文中的这个例子说的,好像并没有说是后来改的程序增加了什么新的内容,所以,对于这版本越改越坏的问题我还是存有疑虑。

     

    2.文章内容:

    IT专业的大学毕业生找工作时声称:我精通Java,会用c++写“Hello World”程序,我懂软件工程,我画了很多图,写了很多文档,最后得了很高的分数......这些同学是真的懂软件工程,是一个合格的软件工程师么?

    我的疑惑:一个合格的软件工程师应当具备哪些素质?

    我的思考:

    首先,我肯定是不认为文中说到的这些大学生是真正懂软件工程的。我认为,一个合格的软件工程师是应该具备好多基本素质的,而文章中说到的这些,都还是太片面了。我认为,一个合格的软件工程师,起码应该既具备以下素质:

    (1)有良好的数学基础,保证基本的逻辑没有问题;

    (2)有程序语言有一定的敏感性,并不一定针对某种特定的语言,一旦有一种比较熟悉的语言,一通百通,其它的语言应该能快速阅读,并在短时间内基本掌握其中的要素,最好能有系统的学习过一门语言,这里的学习和老师上课的那种学习没有太大的关系(上大学如果只是要应付上课和考试不补考,应该算是比较轻松的事),而是要看一些和这门语言相关的一些中大部头的专著,如Java的Java编程思想,C++的C++premier,Javascript的javascipt权威指南等等;

    (3)对程序的整个框架有一定的了解,能独立把整套程序的流程建立起来;

    (4)有比较好的面向对象的思想,其中具体表现在能不间断的抽象出一些类来,以备在不同的项目间能够起到代码复用的作用,这样做项目才会越来越轻松;

    (5)对系统设计要有一定的基础,并且对系统设计时对系统的可扩展要有一定的考虑。

     

    三、第2章

    1.文章说到:

    为了使模块的质量能得到稳定的、量化的保证,单元测试就是一个很有效的解决方案。

    我的疑惑:

    什么是单元测试?单元测试能够解决哪些问题?有没有什么问题是单元测试解决不了的?

    我的思考:

    通过查阅资料,我了解到:单元测试(unittesting),是在计算机编程中,针对程序模块(软件设计的最小单位)来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。对于单元测试中单元的含义,一般来说,要根据实际情况去判定其具体含义,如C语言中单元指一个函数,Java里单元指一个类,图形化的软件中可以指一个窗口或一个菜单等。总的来说,单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动,软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。通常来说,程序员每修改一次程序就会进行最少一次单元测试,在编写程序的过程中前后很可能要进行多次单元测试,以证实程序达到软件规格书要求的工作目标,没有程序错误。单元测试是开发者编写的一小段代码,用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言,一个单元测试是用于判断某个特定条件(或者场景)下某个特定函数的行为。例如,你可能把一个很大的值放入一个有序list中去,然后确认该值出现在list的尾部。或者,你可能会从字符串中删除匹配某种模式的字符,然后确认字符串确实不再包含这些字符了。确实,它可以帮助我们解决好多问题,尽可能多的减少程序中的错误,但是,对于它不能解决哪些问题,我还是不懂。

     

    2.文中小飞和阿超的对话说到:

    小飞:现在我知道为什么有些软件写了好几年都没有发布了,敢情他们都忙着写单元测试了。

    阿超:也许因为他们没有在一开始就写单元测试,所以后来有很多问题要解决。

    我的疑惑:

    写软件与写单元测试有什么先后顺序之分吗?

    我的思考:

    软件的开发是从小的模块开始,不可能没有模块就开始集成,后来才打包成一个软件,形成一个系统。单元测试是测试各个小的模块,通过对他们的测试,才能找出基本的bug,然后为各个模块搭建接口,也就是把模块组装起来,之后进行集成测试,看各个模块的接口是否正常稳定,打包成软件后,再由开发和测试一起进行系统测试。所以说,是先对一个个的小模块进行了单元测试之后,才有了软件;可是,那一个个的小模块,其实也属于软件的一部分,是有了这些小模块之后,才能进行单元测试,所以,这样看来,似乎是矛盾的。或许,写软件与写单元测试,是同时进行的吧!

     

    3.文中说到:

    单元测试必须由最熟悉代码的人(程序的作者)来写。

    我的疑惑:

    单元测试由专人来写的话,是否会由于作者的定式思维而考虑不周,使得不能达到测试的作用?

    我的思考:

    作为程序的作者,确实是最熟悉,最了解代码的人。可是,就是因为作者自己最了解自己的代码,知道自己代码的目的,特点和优缺点,那么,在做测试的时候,难免就会朝着自己预期的方向去做测试,难免会有考虑不周的地方。即便是由于作者很忙,不能及时的去做单元测试,可以由他人代劳来写单元测试,但是,程序的作者依旧还是这个单元测试的负责人,对于测试,他也依旧还是会以自己的思维作为指导。对此,单元测试由程序的作者来写,我还是很不理解这是为什么。我始终觉得,单元测试不应该由作者来做,而应该由同领域的资深专家来进行。

     

    四、第16章

    1.文中有这两条迷思:

    迷思之一:灵光一闪现,伟大的创新就紧随其后。

    迷思之五:要成为领域的专家,才能创新。

    我的疑惑:

    既然说,像阿基米德,牛顿这样的伟人,他们是在顿悟之前就已经在相关学科打下了深厚的基础,同时他们也对这些问题进行了长时间的思考,所以,那些神奇的时刻才会光顾他们,让他们有了创新。可是,为什么又说,并不是要成为领域的专家才能创新,往往那些创新者最成功的创新,却是在他们的拿手领域之外发现的。我觉得,这两种说法是否有什么矛盾的地方?我很是不懂。

    我的思考:

    确实,创新并不是那么轻易就能得来的。“灵光一闪现,伟大的创新就紧随其后”,这未免也太简单了,世界上哪会有这么轻松的事。那些创新之所以是创新,那些伟人之所以是伟人,就是因为他们已经在私下里做了无数的研究,他们已经积累了深厚的基础,恰巧,他们遇上了一个对的时机,于是,这伟大的创新便应运而生了。所以,不可否认,他们确实是这个领域的顶尖人物,称他们为专家也无可厚非。但是,“那些创新者们成功的创新,却更多的是来自于他们的拿手领域之外”,对此,我并不认同这一观点,既然是在他们的拿手领域之外,那么,他们对此花费的研究时间,势必会比自己的专业领域少了好多,那么他们这伟大的创新,又是从何而来呢?

     

    五、结语

           以上内容就是我在阅读了《构建之法》一书中第1章,第2章,以及第16章之后的疑惑与思考,或许,上文中的一些观点,并不一定正确,不过,这也仅仅只是我一人的想法,如有不妥之处,还望老师与读者指正,谢谢!

  • 相关阅读:
    在不申请第三方变量的情况下交换a和b
    指针(pointer)的使用
    数组和链表(arrary & linkedlist)
    Python的学习计划
    Python——函数
    Python——文件操作
    Python——深浅Copy
    我发现的新大陆——好用的~
    我发现的新大陆——好吃儿的
    我发现的新大陆——好玩儿的
  • 原文地址:https://www.cnblogs.com/yangyc/p/8593398.html
Copyright © 2011-2022 走看看