《程序员修炼之道》读书笔记
这本书得到了国内一些知名, 不知名的圈内人的大力推荐(序1, 2, 3 ...). 不过在我看来也就一般般(难道是自己境界不够? 还是跟我看了不少类似的书有关?), 毕竟是10年前的书了, 虽然里面有一些观念放到现在也不过时, 不过随着日新月异的技术发展, 有些东西在现在来看也有些不合时宜, 而有些东西该有所创新了. 而且有些地方翻译的比较生硬, 看起来怪怪的.
不过原著者的兴趣爱好比较有噱头, 一个喜欢木工, 一个玩单引擎飞机
有些观念还是不错, 这里摘抄做个笔记
注重实效的程序员的特征:
新技术早期的采纳/快速的改进者
好奇, 探究事物的本质.
批判的思考
多才多艺
一个程序员的目标参考:
每天至少学习一门新的编程语言
每季度阅读一本技术书籍
也要阅读一些非技术书
参加本地的用户组织
试验不同的环境
跟上潮流
上网
交流越有效, 你就越有影响力
写email的注意事项:
在发送之前校对
检查拼写
让格式保持简单.
除非对方也能阅读富文本格式, 否则采用纯文本
设法让引文减至最少, 没有人喜欢看到一大段回复他人的引文, 最后你的回复确实的两个字"同意"
发送之前检查收件人名单
将重要邮件加以归档
DRY之重复的分类:
被迫的重复, 开发者别无选择, 环境所致.
无意的重复, 开发者没有意识到他在重复
偷懒的重复, 开发者偷懒, 因为ctrl+c&v 似乎更容易
开发者之间的重复, 不同的人重复了同样的工作.
要营造一种环境, 要让复用更容易, 如果不容易, 大家就不会去复用.
正交: 一个的变化, 对另一个不会产生影响, 比如数据库的变更, 不会影响界面
不要依赖你无法控制的事物属性
每当你的代码引用全局数据时, 它就把自己与共享该数据的其他组件绑在了一起
工具是手的延伸
找到导致问题的原因的一种非常简单, 却又非常有效的技术就是向别人解释它. 你一步步解释代码要做什么, 常常就能让问题从屏幕上跳出来, 宣布自己的存在.
当你遇到让人吃惊的bug时, 除了修正它之外, 你还需要确定先前怎么没有找到这个故障.
如果bug是因为一些参数导致的, 这些参数可能在爆发之前穿过了若干个层面, 因此需要加强对参数的检查
如果bug是某些人的错误假定导致的, 那么需要与团队讨论这个问题, 让更多的人知道这一点.
编写"内向"代码是有好处的, 而"内向"的工作方式有两种: 不向别人暴露你自己, 不与太多人打交道
这样的代码:
public void plotData(Date aDate, Selection aSelection){
TimeZone tz = aSelection.getRecorder().getLocation().getTimeZone();
...
}
plotData知道的太多了, 应该减少依赖, 应该写成这样:
public void plotData(Date aDate, TimeZone tz){
...
}
plotData(someDate, someSelection.getTimeZone())
对象依赖的症状:
java的import列表太长
对某个模块的"简单"改动会传遍系统中的一些无关模块
开发者害怕改动代码, 因为他们不清楚哪些代码可能会受影响
有很多不必要的依赖关系的系统非常难以维护, 往往高度的不稳定.
某个对象的任何方法都应该只调用属于以下情形的方法:
它自身
传入该方法的任何参数
它创建的任何对象
任何直接持有的对象
一般情况下, 元数据是在运行时, 而不是编译时被访问和使用
将抽象放入代码, 将细节放进元数据
使用元数据编程的好书是可以迫使你通过推迟细节处理, 创建更健壮, 更抽象的设计--完全推迟到程序之外
我们想要推迟大多数细节的定义, 直到最后的时刻, 并且尽可能让细节保持"软和"--尽可能更易于改动
软件的工作方式与建筑设计并不怎么相似, 与建筑相比, 软件更像是园艺--你可以根据最初的计划和各种条件在花园中种植许多花木, 有些花木需要着重培养, 有些却只能做肥料, 有些需要修剪, 有些需要改变位置以更好利用光照和水土.
更喜欢拿建筑做比喻是因为: 建筑比园艺更科学, 它可以重复.
需要重构的代码特征:
重复
紧耦合非正交的设计
过时的知识
性能
把需要重构的代码比作一种"肿瘤", 切除它需要进行"侵入性"的外科手术, 你可以现在就手术, 趁它还小把它取出来, 你也可以等它增大并扩散--但那时切除它就会更昂贵, 更危险.
早重构, 常重构
要确保受到影响的代码的使用者知道该代码计划要重构, 以及明白这可能会怎样影响他们.
不要试图在重构的同时增加新功能
在开始重构之前, 确保你拥有良好的测试, 尽可能经常运行这些测试, 这样, 如果你的改动破坏了任何东西, 你就能很快知道.
马大叔认为维持良好的回归测试是自信的进行重构的关键.
不要把你创建的测试随便扔掉, 把它放入已有的测试中.
找出用户为何要做特定事情的原因, 而不是他们目前做这件事的方式, 这很重要. 到最后, 你的产品必须解决他们的商业问题, 而不是满足他们陈述的需求, 用文档记录需求背后的原因.
与用户一同工作, 以象用户一样思考
有些约束的绝对的, 有些则是先入为主的偏见, 绝对的约束应该得到尊重, 不管他们看上去多么愚蠢, 而外表上看来的约束可能不是真正的约束. 比如在酒吧的一个老把戏: 你拿出一瓶全新的, 未开启的香槟酒, 打赌说你可以从中喝出啤酒来, 诀窍是把酒瓶倒过来, 在酒瓶凹处倒一点啤酒.
思考如何解决一个问题:
有更容易的方法么?
你是在解决真正的问题, 还是被外围的技术问题转义了注意力?
这件事情为什么是一个问题?
是什么使它难以解决?
它必须以这种方式完成么?
它真的必须完成吗?
寻找bug有点像用网捕鱼, 我们用纤小的网(单元测试)捕捉小鱼, 用粗大的网(集成测试)捕捉吃人的鲨鱼, 有时鱼会设法逃跑, 为了抓住项目中游动的, 越来越狡猾的漏洞缺陷, 要补上我们发现的任何漏洞.
文档是代码的反应, 如果有歧义, 代码最要紧, 无论好坏.
一般而言, 注释应该讨论为何要做某件事, 它的目的和目标, 代码已经说明了它是怎样完成的, 所以如果再加上注释就违反了DRY原则.
代码的注释给你完美的机会, 可以用来把项目中那些难以描述, 容易忘记, 却又不能记载到别的任何地方记载下来: 工程上的权衡, 为何要做出某些决策, 放弃了那些替代方案等等
变量名必须精心选择, 而且必须有意义, 你会好几百次的阅读代码, 而却只会编写几次, 花时间拼写出ConnectionPool, 而不是cp.