高效能程序员的修炼 --读书笔记

高效能程序员的修炼 –读书笔记

这是我读完Jeff Atwood的<高效能程序员的修炼>这本书后的一些回顾, 我会根据这本书的章节依次写下对每章节的理解和认识.

第一章 入门须知

你想成为一个程序员

我大学本科学的就是计算机, 但是大学的前两年时间基本搞得东西和专业无关, 直到大三的时候我发现创业比想象中要困难得多, 所以我决定学一门技术, 那我是计算机专业的, 理所应当的就选择了程序员.

程序员天生就是Thinker的子类, 我觉得自己还算是一个喜欢动脑子的人, 所以我励志做一个优秀的程序员. 但是我并不限定自己一定要做一个架构师或者CTO什么的, 因为我们的人生就是不断的解决问题, 技术或者程序只是解决问题的一种方式, 我不希望把自己解决问题的方式限定在了程序上. 如果有一天干程序员工资很低了, 或者没什么前途了, 我会毅然决然的往另一个方向发展. 所以即使我现在朝着优秀程序员的目标前进, 但是我也会涉猎其他知识, 而且不同的知识会为自己开启不同的维度, 对于写代码本身也是有益的.

我认为这样才是我自己做事的标准和方式吧!

程序员的八种境界

Jeff归纳了程序员的八种境界
- 不朽的程序员
- 成功的程序员
- 知名的程序员
- 胜任的程序员
- 普通程序员
- 业余程序员
- 低调的程序员
- 烂程序员
从我工作到现在, 除了不朽的程序员, 其他类型的都见过了. 我现在公司的老大算得上是一个成功的程序员.
我自己的目标也是成为一个成功的程序员. 不朽的程序员我还是不去搅这个浑水了, 自认没有这个能力. 为了达到成功程序员的目标, 除了要学习相关的知识外, 更要涉猎其他的学科. 比如商业, 经济, 心理学等等.

如何培养写作习惯

我的写作才刚刚起步, 之前在CSDN写过几篇文章, 包括技术和日记等等. 技术的关于CAS的也半途而废了. 所以我希望从今年起开始写作.
- 如果用CSDN什么写, 显得逼格不够高, 而且也不是很爽, 我用github的pages项目搭建了一个自己博客平台, 购买了www.chenxinhua.cn这个域名指向cxhcode.github.io正在投入使用, 还不是很熟练
- 学习别人的写作经验
- 技术文档, 翻译技术文档, 读书笔记, 以及其他一些琐事
- markdown编辑器, 这是必须要会的, 这样你才能全身心投入写作中, 这篇文章正式markdown编写的, 格式非常棒

其实我写博客的最重要的目的, 一是感觉自己已经工作这么长一段时间了, 没有什么积累, 以后找工作, 别人也看不见, 可以增加自己的筹码, 二是真正的增加自己的能力. 写作能锻炼自己的思维能力, 这是毋庸置疑的.

第二章 把一堆烂事搞定的艺术

学海无边(优秀的的管理方式)

对于优秀人来说, 萝卜加大棒是最愚蠢的管理方式. 优秀的人不需要过多的管理, 我们做的工作是有创造力和想象力的工作, 而不是重复的富士康式的劳作.

如果你想造一艘船, 就不要催着工人们去收集材料, 分派工作, 发号施令, 你应该教会他们的是对无边无际的大海的渴望
–Anotoine de Saint-Exupery

磨刀不误砍柴工

还是我最初的想法, 编程并不是我的全部, 我需要学习编程相关的知识, 比如我正在写笔记的这本书.

应该将一些时间花在讨论反思和学习上, 这样对自己才有进步. 如果知识埋头的编程, 结果只能编程普通程序员, 连胜任的程序员都谈不上.

我身边有一些同事就是这样, 只有想法, 但是并没有用学习的知识去验证自己的想法. 结果就是只会BB, 身边的人对他提出来的东西不加以重视, 即使他的某些想法是正确的.

最近正在学习groovy和grails, 学习一门新知识就给我打开了一个认识世界的新维度. 这就是极好的, 比如我学习了google plugin的开发, 并且我在工作中用他们解决了工作中很麻烦的事情.因此让同事刮目相看, 这就是学习的重要性

一路向前冲

沿着那条路下去, 一定要快, 如果有什么东西挡住了你的去路 —-绕开它
空战胜利的重要因素, 是快!!!

只有又快又好的产品, 慢的产品不可能是好产品, 市场都被人占领光了, 做的再好的产品也会无人问津.

所以适当的产品或者程序设计是必要的. 但是一定要拒绝过度分析

关于多任务的神话

一句话, 同时干很多事的人会变傻

我们应该把自己todo放进自己的任务池. 做完一项, pop掉一个, 这样做有以下好处
- 不会忘记做某些事
- 在做一件事的时候不需要记忆其他的事, 而对当前正在做的事造成影响, 可以沉浸在当前做的事里面
- 不会变傻…

第三章 高效编程之原则

永远都是你的错

我身边有些朋友经常抱怨产品经理(或者使用者, 如我们的运营妹子)提出的一些非常合理的需求, 或者测试测出来的一些不属于bug, 但是属于产品设计上的问题(虽然可能这是后台系统, 我们自己使用的). 他的第一反应不是看需求是什么, 而是叹气, 一大堆理由搪塞, 然后不修改.

我总结的自己的错误的点:

• 用户没有错, 用户每天都在使用产品, 所以他们最了解我们的产品
• 操作系统没有错, JVM没有错, 如果实在解决不了重启一下windows, 重启一下tomcat, 也可能解决掉, 但是这种概率非常低. 去考虑他们是否有问题的成本高得多.

大道至简

代码评价的多个维度:

• 代码简洁度
• 功能完整性
• 执行速度
• 编码所花费的时间
• 健壮性
• 灵活性

但是这些维度相互之间是互斥的, 所以你必须在他们之间找到一个平衡

避免写注释

我在看这本书之前, 一直认为在任何时候写注释是一个好习惯, 但是Jeff说, 这并不好. 好的命名其实就是注释, 所以以后应该花更多的时间用在方法的命名上面. 对于类似于selectById这种就不需要写注释了
还要避免用简单的命名表达了不是这个意思的方法, 比如selectById, 但是逻辑上增加了更多参数的查询, 这种命名极易误导其他同事, 非常不可取

学会读源码

我以前读过最多的源码应该是springmvc和lucene, 但是都是没有怎么精度, 而且知识积累不够, 很多时候是不太理解他的设计的(庆幸自己是java coder 不是 其他非开源的语言).
总结的几个读源码的步骤:

• 查看类图
• 从别人的阅读经验中, 找到整个框架大致的设计
• 深入理解源码的设计模式和一些关键实现

向橡皮鸭求助

其实就是一种在没有找到答案之前, 屡清楚自己逻辑的方式.

当你想清楚自己的问题的时候, 那么你已经离答案不远了

很多时候我们会遇到, 找很久没有找到的问题或bug, 在同事来帮助你还未开口的瞬间你就知道了答案. 我们在遇到问题时, 尽可能的理清自己的思路, 我要问什么? 可能答案就在你理清楚思路的时候已经得知了.

创新以人为本

不管多么优秀的idea, 都需要人去执行, 所以最好的创意如果没有一个强力的团队, 是不会成功的.
培养卓越的团队非常重要

你的团队能通过电梯测试吗

简单来说, 就是团队的交流问题, 团队之间需要有一套成熟的交流语言, 这样可以在团队之间顺畅的沟通, 有助于提高工作效率.
我们只有知道自己做的是什么东西, 才能明白我们怎么做好, 怎么优化我们的产品
我们的项目需要一个清晰的远景声明
有一个简单的表述方式:
- 为了(目标客户)
- 他们(关于需求或者机会的说明)
- 这个(产品名称)是(产品类别)
- 它的(关键优势,吸引人的购买理由)
- 不像(主要竞争对手的产品)
- 我们的产品(主要的差异化的特性说明)

举例产品包装盒的设计, 应该有以下特征:
- 用最简单可行的方法来解释我们的产品是什么;
- 把潜在客户愿意购买这个产品的原因解释得一清二楚;
- 与货架上所有其他吗的产品包装盒相比具有独一无二的辨识度.

性能致胜

网页或app加载速度直接影响着用户继续用下去的愿望. 所以对网站的优化非常的重要. 亚马逊曾经做过AB测试, 在网页加载速度增加几百毫秒后, 购买率直线下降了.