• 《构建之法》读书笔记


    前言

    一直很喜欢静心读书的感觉。认真阅读《构建之法》的过程中,首先我的直观感觉就是我很喜欢这本书,这本书并不是一味的讲解理论知识,而是结合很多现实生活中的小例子来写,不仅便于理解,而且很有趣,吸引着我一直读下去。以下是我阅读1,2,16章之后提出的一些问题和自己的想法。很多想法可能不一定正确,但确实是我的真实看法,希望大家能互相交流讨论。

    第1章

    1.“什么是好的软件,一些同学认为,所谓好软件,就是软件没有缺陷(bug),所谓软件工程就是把软件中的bug都消灭的过程。这的确抓住了软件工程的一个要素”                                                      


    问题:

    (1)好的软件除了从用户满意度,可靠性,软件流程的质量,可维护性这样宏观的角度衡量,具体可以用哪些指标衡量?

    (2)bug数和软件好坏的关系是怎样的?

    我的看法:

    (1)这句话引发了我对如何衡量软件的好坏的思考。也通过百度得知了衡量软件质量的5个最常用的指标:SLOC(源代码行,可以使用Metrics工具来统计);每个代码段/模块/时间段中的bug数;代码覆盖率(单元测试阶段考虑);设计/开发约束(可维护性,可读性);圈复杂度(用来衡量一个模块判定结构的复杂程度,已经成为评估软件质量的一个重要标准,能帮助开发者识别难于测试和维护的模块,在成本、进度和性能之间寻求平衡。圈复杂度可以使用pmd工具来自动化计算。)

    (2)我认为没有bug的软件不一定是好软件,好的软件bug数一定是尽量少的。由第一个问题的解释也可以看出,bug的确是软件工程中重要的一个方面,但是不能只由这一个方面来衡量。这里引用一篇博客(http://www.iteye.com/news/26178)中的这句话:“Bug数可以作为评估开发者效率的指标之一,但必须注意,如果过分强调这种评估方法,软件开发者和测试者可能会成为敌人。”我觉得这句话很好的强调了bug数和软件好坏的关系。在看到这个指标的同时,我们也应该重视其他衡量软件好坏的指标。

    第2章

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


    问题:

    (1)代码开发人员应该先开发代码还是先写单元测试?

    (2)代码和单元测试都由同一个人编写的话,他会不会习惯性的往理想的方向编写测试代码而导致单元测试没有起到应有的作用,规避了可能出现的错误?

    我的看法:

    (1)我的第一想法是要先写开发代码,觉得没有代码就不知道测试的对象,没有具体的对象不知道测试从何写起,但又觉得如果代码都写好了,在测试的过程中可能会不自觉的规避掉可能出现的问题。在自己的思维里觉得测试是通过的,但其实是存在问题的。带着这样的疑惑,我查了百度,得到的大部分答案都是说应该先写单元测试。对于没有对象怎么写单元测试这个问题,给出的解决方案是:我们可以通过先画流程图,写伪代码或者建模来解决这个问题,这样让我们站在用户的角色去开发,尽早的发现问题。

    (2)我同样也认为写单元测试的人一定要足够熟悉代码,但是也有了上面的疑问。我觉得平时我们敲代码的不足之处有一部分就体现在没有考虑到很多极端或者不易想到的情况,如果是同一个人写单元测试的话,可能仍然在测试的时候,没有选用这些极端的情况或没想到的情况,而得出错误的结论。我觉得专业的测试人员可能有更好的测试思想,更好的保证用例的覆盖。但他们又不够熟悉代码。感觉各有优缺点,这也是我比较纠结的一个问题。

    第16章

    看书本的16章时觉得这章的内容轻松有趣,在有很强的故事性的同时,也蕴含了很多使我们受益的看法和想法。对于这一章我想要针对一些作者的语录发表一些我自己的看法。相比前两章提出具体的问题,我觉得这一部分我更愿意把它称之为我的读书笔记。

     

    1.谜题之一:“不要一开始就想着找到并拼对所有的拼图块,以为能够打造一个巨大的创新。”           

      谜题之五:“为什么领域的专家有时候没有领域外的创新者那么有创意?”                           


    我的看法:

    (1)对于第一句话,我很认同。这句话并不是教导我们目光只看到当前,我们要在有统筹观念的同时,注重脚下的每一步,过于追求结果只会使事不如人愿。一步一步,不急不躁,踏实稳步的走,你会发现,走着走着,你想看到的一切风景,尽在你眼前。

    (2)我之所以把这两句话写到一起,是因为我觉得第一句话正是第二句话的部分原因。领域的专家有时候正是被第一种思想所支配,才会限制了他们的思想。还有就是我认为领域内的专家可能形成了太多关于这个领域的固有思维,反而忽略了很多天马行空,灵光一现的想法。我也很喜欢书后链接的书名《像外行一样思考,像专家一样实践》。

    2.谜题三,好的想法会赢与谜题四创新者都是一马当先                                               


    我的看法:

    谜题三中Dvorak键盘在功能上其实是好于QWERTY键盘的,却由于“先入为主”的思想使用率很少;而谜题四中很多有“先行者”的产品仍能够通过创新,后来者居上。这也引发了我们更深入的思考。为什么下面这种情况就没有因“先入为主”的思想而没人使用呐?这也充分的提示了我们要掌握好创新性和实用性的关系。正是因为后者创新的价值性体现的十分明显,相比之前的产品有突出的优越性,才使得人们战胜了“先入为主”思想而选择它。

    3.谜题五,“正是这种看似简单的无状态的网页,改变了世界。”                                         


    我的看法:

    这句话让我想起了一句特别文艺的话“我们都是远视眼,模糊了最近的幸福”。我觉得很多越是简单的东西越不好解释。这句话也提醒了我们,要时刻注意细节。我认为细节在软件的开发过程中也是十分重要的。正是一个一个小的细节上的优点的堆积,才使软件整体有很好的质量,才能使用户满意度更高。

    以上就是阅读《构建之法》1,2,16章后,让我想到的问题和我的思考。

  • 相关阅读:
    如何编写优雅的代码:05. 设计模式(下)
    ArcGIS之Cartogram地图变形记
    GIS规划应用——基于哈夫模型的GIS服务区分析
    基于GIS的旅游辐射区人口统计
    图斑整理之字段计算器使用技巧
    ArcGIS制作放射状流向地图(Radial Flow Map)
    SQL Server时间粒度系列
    (原)SQL Server 代理作业执行持续时间简述
    (原)SQL Server 系统提供功能的三个疑惑
    sql server实现自定义分割月功能
  • 原文地址:https://www.cnblogs.com/zmbeijixing/p/8575986.html
Copyright © 2020-2023  润新知