《程序员修炼之道》读书笔记

当小说读吧,争取两天看完。

——2017年6月25日

编程是注重实效(pragmatism)的,不应该局限于任意特定的技术,而是应该拥有足够广博的背景和经验基础。注重实效的程序员不仅要完成工作,更要完成的漂亮。

注重实效的程序员有以下特征:

  • 早期的采纳者/快速修改者,具有技术和技巧上的直觉,喜欢试验各种新技术。
  • 好奇
  • 批判的思考者
  • 有现实感
  • 多才多艺。

要保持学习,每天坚持。

注重实效的哲学

根据职业发展、项目和每天的工作,为自己和自己的行为负责,不害怕承认无知和错误,这一点一定要诚实。

要防止破窗效应,低劣的设计,错误决策,糟糕的代码,发现一个就要修复一个,如果没有足够的时间进行管理,就用木板(TODO的注释之类)钉起来。

有想法的时候,利用空闲时间开发出来,再给同事们看,不要只停留在口头上。

在做开发的时候,最好能让用户参与设计,最终使用产品的是他们。

技术的知识都是有“时效的资产”,随着新技术、语言的发展环境的变化,我的知识会变的过时,所以要保持一直在学习。

管理只是财产和管理金融财产相似:

  • 严肃的定期投资——作为习惯
  • 多元化是长期成功的关键
  • 在保守的投资和高风险高回报的投资之间平衡
  • 应设法低买高抛,以获取最大回报
  • 应周期性的重新评估和平衡资产

把投资换成学习,把回报替换为成就/收入等…

不要把所有的技术都放在一个篮子里,不要只会一种技术。

书中的建议:

  • 每年至少学习一门新的语言,
  • 每季度阅读一本技术书籍,
  • 也要阅读非技术书籍,

新技术新语言,非技术书也许不能放进简历,但会让我们朝着新的可能性发展,思想的“异花授粉”十分重要。

例如学了JAVA的面向对象,即使写C也会有面向对象的感觉。

最后,要批判的思考问题

学会交流,有时候,简单一句“我们可以谈谈吗”就可以了,在发表言论的时候,按下面的方式思考:

  • 想让他们学到什么?
  • 她们对你讲的东西感兴趣吗?
  • 他们经验丰不丰富?
  • 他们想了解多少细节?
  • 想让哪些人了解这些信息?
  • 如何促使他们听你说?

文档要美观,这本书竟然还让我们别忘记回人信息,回复邮件/信息之前还要再三检查。

哈哈哈,有点逗但确实挺细心的,希望能谨记这些小忠告,成为一个优秀的职场人吧。

注重实效的途径

重复

虽然在开发时总希望重复尽量的少,多合理的使用设计模式,但实际情况总会有重复的代码,书中分析了产生重复的四种情况:强加的重复,无意义的重复,无耐性的重复,开发者之间的重复。

总之,尽量提高复用性,尽量在函数和类的信息上互通,免得有重复的工作量。

“正交”

消除事物之间的影响,多对系统进行解耦。

团队项目管理也需要“正交”,免得某一个人的工作变化会影响很多人。

多思考这个问题:如果显著地改变某个特定功能背后的需求,有多少个模块会受到影响?

在引入新的工具箱或者库的时候,要注意保存系统的正交性,要明智的选择技术。

忽然意识到那些分布式常用的中间件,如果自己设计的分布式系统中没有那些中间件对应的逻辑,那总的来说还是有一些失败的。那么设计成功的优秀的分布式系统,一定需要多学习这些设计优秀的中间件/库所在的位置和设计想法,回头要多了解常用的分布式中间件。

每次写代码都可能降低正交性,要维持正交性可以使用下面这些技术:

  • 让代码保持解耦,
  • 避免使用全局数据,
  • 避免编写相似的函数,

测试

建议让每个“正交”模块都拥有自己的测试单元,并且能够自动构建(类似google test)。

曳光弹

感觉…像是在说敏捷开发,先开发大概的东西,然后根据用户的需求快速做出反应。

因为开发是一个不断迭代的过程,最开始的时候没人知道产品最后是什么样子的。

估算

对系统计算力的估算,对系统容量的估算,对项目进度的估算。

在对项目进行估算时,不要乱夸海口,分阶段分步骤的给出估计,根据代码进度表进行迭代,对不同部分的开发时间有所取舍。

基本工具

不要只会使用一个IDE。

学会使用shell,永远不会过时。

学会使用版本控制。

学会调试,在调试时不要恐慌。

调试时把编译器警告提高,把时间浪费在编译器能找到的问题上没有意义。

其实调试的过程就是寻找程序在特定数据下到底发生了什么的过程。

学习操纵文本的工具,如awk, sed。

一再要重复的代码可以考虑使用代码生成器,提倡类似google protocol buffer的那种东西吧。

注重实效的偏执

你不可能写出完美的软件。

记住上面的这句话,你不可能写出完美的软件。

在团队合作中要制定标准,并且最好有自动化测试的工具。

不要过分的相信“不可能”发生的事一定不会发生,在所有不可能发生的情况下放一个日志打印是个好习惯。

绝对不要断言不会发生,多做检查。

发布的程序也不能关闭“断言”。

许多异常正在被用在非异常情况中。

类似于C之类不支持宜昌的语言,可以使用错误处理器。

The End。

发表评论

电子邮件地址不会被公开。 必填项已用*标注