程序员修炼之道--读后感之二

工具是手的扩展

    就像伐木工人手上有各种各样的工具一样，程序员也需要有各种tools，伐木工人的工具会随着时代的进步而进步，比如有斧头到电锯，程序员也需要适应时代的发展，能够很快的接受新的知识和工具，比如shell，python处理文本，IDE开发，cygwin

元编程：---业务逻辑和业务规则等
尽可能的配置：把抽象放到代码里面，细节放到metadata里面去，即数据库或者配置项

不要搜集需求，而要深挖需求
像用户一样和用户一起想问题和需求
文档化需求：用例
词汇汇总
单元测试：要么需要单元测试代码，并需要内部运行关键状态或者错误日志
临时耦合： ---时间
黑板：来协调完全不相关的情况和对象(即中介者模式)
写软件像建花园，而不是盖大楼：因为大楼受物理和现实世界的限制，软件却不受限制，需要定时重构，像花园需要时不时的修剪一样

团队：
破窗：团队不能容忍破窗(产品的不完善的地方)，需要指定人修复，不能一直放着不管
温水煮青蛙：个人和团队假如一直在一个假设的环境或者需求或者条件下继续下去，
就很可能像那只可怜的青蛙一样，或者定时的检测下环境或条件或需求是否变化，或者团队里面专门有人来检测

测试：
单元测试
集成测试
用户验证和确认
现实资源：内存，磁盘空间，cpu速度，时钟周期，磁盘速度，网速，颜色，视频分辨率，crash恢复
性能测试
可用性测试
回归测试:每次测试的结果数据对比，看看有没有什么变化，从而查看有没有出现新的bug

注释：
WHY？goal？ how 是不需要的，否则就违反了DRY原则
内部文档和外部文档都有DRY原则：
不要重复你自己，即任何东西都只有唯一的来源；
首先，比如说数据库表作为唯一的口子，
当数据库表变化时，依赖于此数据库表的各种程序怎么样才能做到动态变化？可以在数据库表的注释里面增加依赖于它的模块代码文件名称列表，这样当以后维护时，假如数据库表出现了变化，则可以依据此文件列表去通知依赖项，否则没有通知到的就等着crash了；但是有个问题就是表的注释有长度限制，所以可以给每张表建立一张依赖表，即给表abc建立abc_dependence,里面就一个字段：依赖列表
依赖于此数据库表的各种文档怎么样才能也动态变化？可以用脚本语言动态生成文档

比如说源代码都有svn作为唯一的入口和出处
写代码的注释有doxgen来自动生成手册
用户手册也要有唯一的口子，比如说用标签书写成普通文本，其他格式，比如说网页形式，pdf形式等
或者word作为唯一的出处，保存为网页形式

针对单元测试(甚至集成测试)的一些思考：
考虑自动化测试，即写脚本程序测试，好处是自动化测试只需要实现一次，后续只需要run一次看结果就可以了
涉及到两个方面：
1， 边界和条件测试，比如说new_order,可以通过脚本程序去分析new_order的日志，看看每个必须得tag值是否满足给定的必须条件，比如说取值范围，tag缺失
2， 回归测试，回归的意思是多次运行，比对结果，比如说，我们的一个模块上线运行了，当有了新的修改后，假如同一天的输入数据，同样的下单逻辑，
需要把它的结果和上次运行的正常日志对比下，看看有没有变化，当然需要程序去对比，并把不同之处打印出来,如果有不同则代表引入了新的bug

针对数据库表变化引起的未知bug的一些思考(有点类似DBA的角色机制---大家都依赖于这个人，每个用到的都注册一把)：
当数据库表变化时，依赖于此数据库表的各种程序怎么样才能做到动态变化？可以在数据库表的注释里面增加依赖于它的模块代码文件名称列表，这样当以后维护时，假如数据库表出现了变化，则可以依据此文件列表去通知依赖项，否则没有通知到的就等着crash了；但是有个问题就是表的注释有长度限制，所以可以给每张表建立一张依赖表，即给表abc建立abc_dependence,里面就一个字段：依赖列表

针对代码变化了文档没有更新到最新的一些思考：
依赖于此数据库表的各种文档怎么样才能也动态变化？可以用脚本语言动态生成文档

C++中的new在分配内存失败时会抛出异常（std::bad_alloc）而不返回0（一些老的编译器可能还在返回0，但这样的编译器实在“太老了”），这跟C程序员的做法很不一样。而且，许多C++程序在使用new创建对象时也根本不检查这种异常。这是一种什么哲学呢？”
使用try catch的地方：
1， 调用数据库，需要回滚时
2， 调用第三方库，或者被调用的函数会抛异常
3， f1 catch调用f2,f2调用f3,调用f4 throw;      f4惹祸，f1收场，中间f2和f3只是一脸无辜地把异常“透过去”
C++中的“new”还不只是分配内存那么简单。对于用户自定义的类型来说，“new T;”相当于operator new再加上对T的构造函数的调用。由于类的构造函数完全可能引发异常，于是，就算内存分配一切顺利，一条new语句还是可能产生异常。看来，需要catch的不止std::bad_alloc。
暂不考虑“哲学”因素，如果有人仍然觉得应该像C程序那样严格检查内存分配，可不可以呢？当然可以，毕竟它还能抛出异常么，它能抛出我们就能捕捉。每分配一次内存都要包上一层try/catch，跟C中的针对返回值的if/else风格比起来凌乱多了。