关于构建之法第一、第二与第十六章阅读疑惑

第一章、概论

  原文的1.2.1节中有说到软件的不可见性，其中有这么一段描述：“商用软件出现了错误，工程师可以看到程序在出错的一瞬间留下的一些痕迹（错误代号、大致的目标代码位置、错误信息），但是几乎无法完整的重现到底程序出现了什么问题。”言下之意就是在调试程序时我们很难知道程序到底出了什么问题，对此我有一些疑问。百度百科与搜狗搜索中并没有软件的不可见性的词条，我只能通过自己的理解来理解这句话。在我自己的编写代码经历里，当代码出现了问题时，我可以在编译器中很直观地知道问题的代码是哪些， 可以根据提示做出相应的修改，以达到调试的目的。我们调试一个程序不就是为了让它尽可能地没有bug，可以没有问题地发挥自己的功能。即程序的具体问题所在我们也许不清楚，但是代码的问题所在我们是清楚的，并且可以做出相应的修改，以此来让程序的问题得到修改。所以这个不可见性软件特性的意义到底在哪里？

第二章、个人技术和流程

  原文中2.1.2中有提到单元测试应该集成到自动测试的框架中，书中说：“另一个重要的措施是将单元检测自动化，这样每个人都能随时、随地的运行单元测试。”根据书中的描述与一些我在网上的查找，我对单元测试有了这样的理解：它是为了让我们所编写的程序实现目的功能，而对其中的最小可检测单位做检查和验证。这个最小单元，在百度百科中有一个很具体的定义，比如说是Java中的类，C中的函数等。众所周知，像这样的基本单元，在一个项目中是非常多的。那么当程序员在编写单元测试时，岂不是要面对十分巨大的工作量？而对于此，我们难道没有什么可以优化的方法吗？书中有写到我们可以减少复杂代码的使用比例，但我认为这是一个治标不治本的方法。所以对那些逻辑思维十分缜密或者已经经验十分丰富的程序员，也必须做到每个单元模块都要写一个单元检测吗？  其次，所谓的自动化到底是什么样子的？我通过百度百科了解了不同语言的测试工具，但是对书中提到的自动化到底是指什么，还是不太了解。

第十六章、IT行业的创新

  就第十六章而言，我还是比较赞成作者的那些说法的，其中16.1.1迷思之灵光一闪，伟大的创新就紧随其后、16.1.3迷思之好的想法会赢与16.1.5迷思之要成为领域的专家才能创新令我茅塞顿开。我自己也有参与到科研立项与国创的团队中，在寻找老师点评的过程中，我们一些自认为比较有意义的想法被老师否决掉，当时还是有些郁闷的，现在明白过来，并不是说一个看似有意义的东西就一定有做出来或者说推广的必要。其次，好的创新是来源于平时的积累，厚积薄发，没有什么是能一口吃成个大胖子的。除此之外，我们在创新的过程中，也要分析市场的相应需求，从实际中出发，就算是涉及一些自己不那么熟悉的行业，也没有必要望而却步，白白浪费了自己的创新灵感。