关键词：
第一章、概论
原文的1.2.1节中有说到软件的不可见性，其中有这么一段描述：“商用软件出现了错误，工程师可以看到程序在出错的一瞬间留下的一些痕迹（错误代号、大致的目标代码位置、错误信息），但是几乎无法完整的重现到底程序出现了什么问题。”言下之意就是在调试程序时我们很难知道程序到底出了什么问题，对此我有一些疑问。百度百科与搜狗搜索中并没有软件的不可见性的词条，我只能通过自己的理解来理解这句话。在我自己的编写代码经历里，当代码出现了问题时，我可以在编译器中很直观地知道问题的代码是哪些， 可以根据提示做出相应的修改，以达到调试的目的。我们调试一个程序不就是为了让它尽可能地没有bug，可以没有问题地发挥自己的功能。即程序的具体问题所在我们也许不清楚，但是代码的问题所在我们是清楚的，并且可以做出相应的修改，以此来让程序的问题得到修改。所以这个不可见性软件特性的意义到底在哪里？
第二章、个人技术和流程
原文中2.1.2中有提到单元测试应该集成到自动测试的框架中，书中说：“另一个重要的措施是将单元检测自动化，这样每个人都能随时、随地的运行单元测试。”根据书中的描述与一些我在网上的查找，我对单元测试有了这样的理解：它是为了让我们所编写的程序实现目的功能，而对其中的最小可检测单位做检查和验证。这个最小单元，在百度百科中有一个很具体的定义，比如说是Java中的类，C中的函数等。众所周知，像这样的基本单元，在一个项目中是非常多的。那么当程序员在编写单元测试时，岂不是要面对十分巨大的工作量？而对于此，我们难道没有什么可以优化的方法吗？书中有写到我们可以减少复杂代码的使用比例，但我认为这是一个治标不治本的方法。所以对那些逻辑思维十分缜密或者已经经验十分丰富的程序员，也必须做到每个单元模块都要写一个单元检测吗？ 其次，所谓的自动化到底是什么样子的？我通过百度百科了解了不同语言的测试工具，但是对书中提到的自动化到底是指什么，还是不太了解。
第十六章、IT行业的创新
就第十六章而言，我还是比较赞成作者的那些说法的，其中16.1.1迷思之灵光一闪，伟大的创新就紧随其后、16.1.3迷思之好的想法会赢与16.1.5迷思之要成为领域的专家才能创新令我茅塞顿开。我自己也有参与到科研立项与国创的团队中，在寻找老师点评的过程中，我们一些自认为比较有意义的想法被老师否决掉，当时还是有些郁闷的，现在明白过来，并不是说一个看似有意义的东西就一定有做出来或者说推广的必要。其次，好的创新是来源于平时的积累，厚积薄发，没有什么是能一口吃成个大胖子的。除此之外，我们在创新的过程中，也要分析市场的相应需求，从实际中出发，就算是涉及一些自己不那么熟悉的行业，也没有必要望而却步，白白浪费了自己的创新灵感。
《构建之法》第十六章阅读笔记
第一章 问题一:1.2.4软件工程的目标--创造"足够好"的软件 什么是好软件? 原文1.一些同学认为，所谓好软件，就是软件没有Bug，所谓软件工程,就是把软件中的Bug都消灭掉的过程。 软... 查看详情
阅读构建之法第六章
...是怎样的呢？为什么它能有极高的可靠性呢？下面是一些关于形式化方法特点的说明，从中可以看出它能力的缘由。 形式化方法建立在严格的数学基础上，其目标是希望能使系统具有较高的可信 查看详情
《构建之法》第十六章阅读与思考
第一章 概论 市面上有很多种赚钱的方式：有的交钱买断有的“先试用再交钱”，有些软件也提供试用版、免费版和正式版，还有的类似期刊订阅，每年交钱。有的不但免费，连源代码也一并奉送，但是要求获得... 查看详情
《构建之法》读书笔记之：第十六章
这周看了邹欣老师《构建之法》的1,2,16章，获益匪浅。这本书写得妙趣横生，用阿超小飞几个人的生活场景和幽默的比喻帮我理解着软件工程的相关概念，让我对软件工程有了初步的了解：原来开发软件并不是我们... 查看详情
《构建之法》第十六章读后感更正
第十六章IT行业的创新1.关于灵感。灵光闪现固然重要，很多伟大的发明依靠的就是灵光一现的基础，但是灵光闪现的前提是个人的思考，长时间的思考。完成这一灵光的基础是不断的尝试，提高自己的技术。这样才会将自己的... 查看详情
构建之法第七，第十七章读书有感
第四章两人合作 关于合作中算法的使用 在第四章的叙述中，我们看到了代码的编写规范，代码的命名规范，我们还知道要写注释，要有良好的代码设计和错误处理。而这些都是我们在使用语言进行编辑中的问题。我们... 查看详情
《构建之法》——第第十七章
第四章，主要内容为讲述两个程序员（从作者大篇幅讲述代码规范等内容来看…应该是把大部分阅读此章的读者看作基础的程序员了）如何合作。这章我在看完之后分了两个板块：“代码交流”与“合作交流”。“代码交流... 查看详情
构建之法第第五章读后感
第四第五章着重讲了合作的重要性，从两人合作到团队合作，编程开发都不是一件容易的事情，要注意许多要点。代码书写的规范。你写的代码不仅仅是给机器看的，给你看的，也是给其他人看的，是给合作的队友看的，在写的... 查看详情
构建之法第六章
构建之法第六章本章为敏捷流程，主要介绍了敏捷流程及其原则，Backlog、Burn-down、Sprint、Scrum方法论，各种软件开发方法论的优缺点，，选择软件流程根据等敏捷开发：是一系列价值观和方法论的集合敏捷开发的原则：1、尽早... 查看详情
构建之法第六章学习心得
这周我学习了构建之法第六章敏捷流程，本章主要介绍了敏捷流程及其原则，Backlog、Burn-down、Sprint、Scrum方法论。以及什么时候选择敏捷的开发方法，什么时候选择其他方法。.敏捷开发的原则是尽早并持续地交付有价值的软件... 查看详情
读《构建之法》之一，二，十六章有感
...终将得到自己的一份收获。 这几天阅读了《构建之法》的第一，二，十六章，我个人的阅读速度应该属于比较慢的那种，遇到什么不确定的，不理解的概念总要停下来好久，各种百度，否则继续阅读的时候总有种急... 查看详情
构建之法1216章阅读感想
...本书可以说是我进入大学以来读过的最容易理解的一本有关于软件工程的书，语言平易近人容易理解，让我对软件工程在原有基础上有了翻新的认识，让我重识认识了软件工程“知行合一”的思想，加深了我对软件工程行业整体... 查看详情
构建之法第六章敏捷流程
敏捷是一种很“年轻态”的思路/策略，是以“万事万物都在不停地发展变化”为指导去组织软件工程的需求分析、内部的调和、代码编写甚至维护，所以我读起来会觉得很有共鸣。然而并不是所有的地方都适合让“敏捷”去闯... 查看详情
构建之法第十一章读后感
本周进行了构建之法的第十一章软件设计与实现的学习；第十一章主要讲了典型的开发流程，常见的分析和设计方法：ERD，DFD，UML，开发阶段的一些管理方法：每日构建，小强地狱，构建大师；分析和设计方法包括以文字为主的... 查看详情
构建之法第五六章读后感
邹欣老师的这本书，写得形象生动，第五章用体育运动等团队例子引出软件开发团队的形式。软件团队形式多样，适用于不同的人员与需求。团队可能会演变的模式有：主治医师模式、明星模式、社区模式、业余剧团模式、秘密... 查看详情
《构建之法》第第十七章读后感(代码片段)
第四章 在这一章最后一页“让独占一样还有一个好处：一眼就能看出是否有多余的代码行，还有些情况下是致命的错误”给出的参考链接http://lpar.ath0.com/2014/02/23/learning-from-apples-goto-fail/，我还是没明白的致命错误在... 查看详情
构建之法第十十一章
一、动作类游戏(ACT) 玩家控制游戏人物以各种方式技巧、利用各种武器工具等消灭敌人或保全自己或完成游戏任务来过关的游戏。动作类游戏大体分为2D、2.5D、3D三类。 特点： 1.这类游戏讲究打击的爽快感和流畅的游... 查看详情
构建之法第十十二章
用户体验有几个层次：1最基础的是在交互环节，就是usablity，可用性，或者说易用性，大家说得最多的；要把可用性做好，不是太难，业界有成熟的方法，不需要太多天赋，两个字：“用心”即可。2更高层次的乃情感，即诺曼... 查看详情