注重实效的程序员之快速参考指南
最近读完了《程序员修炼之道——从小工到专家》,收获颇多。其实这本书早有耳闻,只是中文书名初听起来有点市侩气息,以为是速成秘籍之类唬人的书,读完后却有相见恨晚之感。本人觉得此书的英文名《The Pragmatic Programmer From Journeyman to Master》的直译注重实效的程序员——从初学者到专家才是很好的揭示了本书的中心思想——注重实效。
最深有感触的就是发觉编程不仅仅是一个智力活动,更是一个心理活动,涉及到心理学。比如不要容忍破窗这节,我们平时工作的时候肯定有时会发现某些代码写的很烂,但是我们或许是太懒,或许是太匆忙,或许是某些政治因素,总之会容忍这些很烂的代码一直存在,并没有人去重构它。它很难重构吗,其实仔细想想并不是,它会花费很多时间吗,其实仔细想想也不见得,但我们却一直迟迟没有行动,甚至有的人会说既然有如此烂的代码,我为了图省事,再写点烂的代码也无伤大雅。
此书的一大特色就是作者将书中的观点都以清单的形式一一列了出来,这些清单是这本书的精炼,也许许久之后,你会忘记书中大多数所讲,但是某些短语清单很可能一直伴你左右。为了以后方便自己随时浏览,也为了分享给大家,特摘抄于此。
1. 关心你的技艺
Care About Your Craft
如果你不在乎能否漂亮的开发出软件,你又为何要耗费生命去开发软件呢?
2. 思考!你的工作
Think!About Your Work
关掉自动驾驶仪,接管操作。不断地批评和评估你的工作。
3. 提供各种选择,不要找蹩脚的借口
Provide Options,Don’t Make Lame Excuses
要提供各种选择,而不是找借口。不要说事情做不到;说明能够做什么。
4. 不要容忍破窗户
Don’t Live with Broken Windows
当你看到糟糕的设计、错误的决策和糟糕的代码时,修正他们。
5. 做变化的催化剂
Be a Catalyst for Change
你不能强迫人们改变。相反,要向他们展示未来可能会怎样,并帮助他们参与对未来的创造。
6. 记住大图景
Remember the Big Picture
不要太专注于细节,以致忘了查看你周围正则发生什么。
7. 使质量成为需求问题
Make Quality a Requirements Issue
让你的用户参与确定项目真正的质量需求
8. 定期为你的知识资产投资
Invest Regulary in Your Knowledge Portfolio
让学习成为你的习惯
9. 批评地分析你读到的和听到的
Critically Analyze What You Read and Hear
不要被供应商、媒体炒作、或教条左右。要依照你的自己的看法和你的项目的情况去对信息进行分析。
10. 你说什么和你怎么说同样重要
It’s Both What You Say and the Way You Say It
如果你不能有效地向他人传达你的了不起的想法,这些想法就毫无用处。
11. 不要重复你自己
DRY - Don’t Repeat Yourself
系统中的每一项知识都必须具有单一、无歧义、权威的表示。
12. 让复用变得容易
Make It Easy to Reuse
如果复用很容易,人们就会去复用。创造一个支持复用的环境。
13. 消除无关事物之间的影响
Eliminate Effects Between Unrelated Things
设计自足、独立、并具有单一、良好定义的目的的组件。
14. 不存在最终决策
There Are No Final Decisions
没有决策时浇铸在石头上的。相反,要把每项决策都视为是写在沙滩上的,并未变化做好计划。
15. 用曳光弹找到目标
Use Tracer Bullets to Find the Target
曳光弹能通过试验各种事物并检查它们离目标有多远来让你追踪目标。
16. 为了学习而制作原型
Prototype to Learn
原型制作是一种学习经验。其价值并不在于所产生的代码,而在于所学到的经验教训。
17. 靠近问题领域编程
Program Close to the Problem domain
用你的用户的语言进行设计和编码。
18. 估算,以避免发生意外
Estimate to Avoid Surprises
在着手之前先进行估算。你将提前发现潜在的问题。
19. 通过代码对进度表进行迭代
Iterate the Schedule with the Code
用你在进行实现时获得的经验提炼项目的时间标度。
20. 用纯文本保存知识
Keep Knowledge in Plain Text
纯文本不会过时。它能够帮助你有效利用你的工作,并简化调试和测试。
21. 利用命令shell的力量
Use the Power of Command Shells
当图形用户界面无能为力时使用shell
22. 用好一种编辑器
Use a single Editor Well
编辑器应该是你的手的延伸;确保你的编辑器是可配置、可扩展和可编程的。
23. 总是用源码控制
Always Use Source Code Controll
源码控制是你的工作时间机器——你能够回到过去。
24. 要修正问题,而不是发出指责
Fix the Problem,Not the Blame
bug是你的过错还是别人的过错,并不是真的很有关系——它仍然是你的问题,它仍然需要修正。
25. 不要恐慌
Don’t Panic When Debuging
做一次深呼吸,思考什么可能是bug的原因。
26. "Select"没有问题
“Select” Isn’t Broken
在OS或编译器、甚或是第三方产品或库中很少发现bug。bug很可能在应用中。
27. 不要假定,要证明
Don’t Assume It - Prove it
在实际环境中——使用真正的数据和边界条件——证明你的假定。
28. 学习一种文本操作语言
Learn a Text Manipulation Language
你用每天的很大一部分时间处理文本,为什么不让计算机替你完成部分工作呢?
29. 编写能编写代码的代码
Write Code That Writes Code
代码生成器能提高你的生产率,并有助于避免重复。
30. 你不可能写出完美的软件
You Can’t Write Perfect Software
软件不可能完美。保护你的代码和用户,使它(他)们免于能够预见的错误。
31. 通过合约进行设计
Design with Contracts
使用合约建立文档,并检验代码所做的事情正好是它声明要做的。
32. 早崩溃
Crash Early
死程序造成的危害通常比有问题的程序要小的多。
33. 用断言避免不可能发生的事情
Use Assertions to Prevent the Impossible
断言验证你的各种假定。在一个不确定的世界里,用断言保护你的代码。
34. 将异常用于异常的问题
Use Exceptions For Exceptional Problems
异常可能会遭受经典的意大利面条式代码的所有可读性和可维护性问题的折腾。将异常保留给异常的事物。
35. 要有始有终
Finish What You Start
只要可能,分配某资源的例程或对象也应该负责解除其分配。
36. 要使模块之间的耦合减至最少
Minimize Coupling Between Modules
通过编写“羞怯的”代码并应用得墨忒耳法则来避免耦合。
37. 要配置,不要集成
Configure,Don’t Integrate
要将应用的各种技术选择实现为配置选项,而不是通过集成或工程方法实现。
38. 将抽象放进代码,细节放进元数据
Put Abstractions in Code,Details in Metadata
为一般情况编程,将细节放在被编译的代码库之外。
39. 分析工作流,以改善并发性
Analyze Workflow to Improve Concurrency
利用你的用户的工作流中的并发性。
40. 用服务进行设计
Design Using Services
根据服务——独立的、在良好定义、一致的接口之后的并发对象——进行设计。
41. 总是为并发进行设计
Always Design for Concurrency
容许并发,你将会设计出更整洁、具有更少假定的接口。
42. 使视图与模型分离
- Separate Views from Models
- 要根据模型和视图设计的应用,从而以低廉的代码获取灵活性。
43. 用黑板协调工作流
- Use Blackborads to Coordinate Workflow
- 用黑板协调完全不同的事实和因素,同时又使各参与方保持独立和隔离。
44. 不要靠巧合编程
- Don’t Program by Coincidence
- 只依靠可靠的事物。注意偶发的复杂性,不要把幸运的巧合与有目的的计划混为一谈。
45. 估算你算法的阶
- Estimate the Order of Your Algorithms
- 在你编写代码之前,先大致估算事情需要多长时间
46. 测试你的估算
- Test Your Estimates
- 对算法的数学分析并不会告诉你每一件事情。在你的代码的目标环境中测定它的速度。
47. 早重构,常重构
- Refactor Early,Refactor Often
- 就和你会在花园里除草、并重新部署一样,在需要时对代码进行重写、重做和重新架构。要铲除问题的根源。
48. 为测试而设计
- Design to Test
- 在你还没有编写代码时就开始思考测试问题
49. 测试你的软件,否则你的用户就得测试
- Test Your Software,or Your Users Will
- 无情的测试。不要让你的用户为你查找bug。
50. 不要使用你不理解的向导代码
- Don’t Use Wizard Code You Don’t Understand
- 向导可以生成大量代码。在你把它们合并进你的项目之前,确保你理解全部这些代码。
51. 不要搜集需求——挖掘它们
- Dont’t Gather Requirements - Dig for Them
- 需求很少存在于表面上。它们深深地埋藏在层层假定、误解和政治手段的下面。
52. 与用户一同工作,以像用户一样思考
- Work with a User to Think Like a User
- 要了解系统实际上将如何被使用,这是最好的办法。
53. 抽象比细节活得更长久
- Abstractions Live Longer than Details
- “投资”于抽象,而不是实现。抽象能在来自不同的实现和新技术的变化的“攻击”之下存活下去。
54. 使用项目词汇表
- Use a Project Glossary
- 创建并维护项目中使用的专用术语和词汇的单一信息源。
55. 不要在盒子外面思考——要找到盒子
- Don’t Think Outside the Box - Find the Box
- 在遇到不可能解决的问题时,要确定真正的约束。问问你自己:“它必须以这种方式完成吗?它真的必须完成吗?”
56. 等你准备好再开始
- Start When You’re Ready
- 你的一生都在积累经验。不要忽视反复出现的疑虑。
57. 对有些事情“做”胜于“描述”
- Some Things Are Better Done than Described
- 不要掉进规范的螺旋——在某个时空,你需要开始编码。
58. 不要做形式方法的奴隶
- Don’t Be a Slave to Formal Methods
- 如果你没有把某项技术放进你的开发实践和能力的语境中,不要盲目地采用它。
59. 昂贵的工具不一定能制作出更好的设计
- Costly Tools Don’t Produce Better Designs
- 小心供应商的炒作,行业教条、以及价格标签的诱惑。要根据工具的价值判断它们。
60. 围绕功能组织团队
- Organize Teams Around Functionality
- 不要把设计师与编码员分开,也不要把测试员与数据建模员分开。按照你构建代码的方式构建团队。
61. 不要使用手工流程
- Don’t Use Manual Procedures
- shell脚本或批文件会一次次地以同一顺序执行同样的指令。
62. 早测试,常测试,自动测试
- Test Early.Test Often. Test Automatically
- 与呆在书架上的测试计划相比,每次构建时运行的测试要有效的多。
63. 要到通过全部测试,编码才算完成
- Coding Ain’t Done 'Til All the Tests Run
- 就是这样。
64. 通过“蓄意破坏”测试你的测试
- Use Saboteurs to Test Your Testing
- 在单独的软件副本上故意引入bug,以检验测试能够抓住它们。
65. 测试状态覆盖,而不是代码覆盖
- Test State Coverage,Not Code Coverage
- 确定并测试重要的程序状态。只是测试代码行是不够的。
66. 一个bug只抓一次
- Find Bugs One
- 一旦测试员找到一个bug,这应该是测试员最后一次找到它。此后自动测试应该对其进行检查。
67.英语就是一种编程语言
- English is Just a Programming language
- 像你编写代码一样编写文档:遵守DRY原则、使用元数据、MVC、自动生成,等等
68. 把文档建在里面,不要拴在外面
- Build Documentation In,Don’t Bolt It On
- 与代码分离的文档不太可能被修正和更新。
69.温和地超出用户的期望
- Gently Exceed Your Users’ Expectations
- 要理解你的用户的期望,然后给他们的东西要多那么一点。
70.在你的作品上签名
- Sign Your Work
- 过去时代的手艺人为能在他们的作品上签名而自豪。你也应该如此。
注重实效的程序员之快速参考指南相关推荐
- 注重实效的程序员(The Pragmatic Programmer)
注重实效的程序员(The Pragmatic Programmer) 推荐一本好书 <The Pragmatic Programmer - From journeyman to master&g ...
- 程序员如何快速上手一个自己不太熟悉的新项目
程序员如何快速上手一个自己不太熟悉的新项目 在知乎上看到的,由作者Jim Jin(奔四老码农,只想做点有意义的事情)写的. 原文出处:http://www.zhihu.com/question/388 ...
- *【思路】程序员怎么快速接手一个项目
可能不管新手老手有些程序员,接手一个项目之后都会多少有些迷惘. 以下是本人总结出来的一点小心得,如果错误希望大家给我留言,一起讨论: 最重要的事儿 如果你总是看见代码多就发愁,看见代码脏乱差就诅咒埋怨 ...
- PHP初级程序员能力测试参考答案
PHP初级程序员能力测试参考答案[闭卷] 注:①本测试满分100分,80分及格,形式为闭卷,不得翻阅任何手册和参考书籍.本试卷使用的PHP版本为5.2.6+,WEB服务器使用APACHE2+,开发平台 ...
- 程序员怎么快速接手一个项目-接手项目指南
目录 维护项目 最重要的事儿 接手方法:不变应万变 维护实用技巧: 项目的常见套路 熟悉项目的套路 vue 项目 快速梳理大型vue项目整体架构技巧方法总结 快速熟悉内部组件模块技巧方法总结 提升工作 ...
- 如何快速阅读java源码_程序员如何快速阅读源代码
科学研究已经证明:人类进行传统阅读时,主要使用左脑的功能;而在采用速读方式阅读时,则充分调动了是左右脑的功能作用,各自发挥左右脑的优势共同进行文字信息的形象辨识.意义记忆和理解,所以速读又被称之为全脑 ...
- 趣图:早上睡醒后,程序员如何快速清醒头脑?
(点击上方公众号快速关注,不错过趣图) 早上睡醒后,程序员如何快速清醒头脑? ↓↓↓ 关注「程序员的那些事」 每天看 IT 趣图 ↓↓↓
- OWL2 Web本体语言快速参考指南
2019独角兽企业重金招聘Python工程师标准>>> 本文档<OWL2 Web本体语言入门>是W3C发布的OWL 2 Web Ontology Language Pri ...
- 初级程序员面试不靠谱指南(二)
3.read-only的const.如果你突然冒出一句看似很高深的话但又不解释一般都是装逼,就像前面提到过const准确的应该理解为一个read-only的变量而不是一个常量,那么常量和变量的区别到底 ...
最新文章
- 自己编写linux系统,自己动手 编写Linux系统的设备驱动程序
- python 面试题 博客园_python面试题
- mysql按章_mysql按时间范围分区
- ORA-10997:another startup/shutdown operation of this instance in progress解决方法
- 【OpenStack】OpenStack系列9之Compute节点安装
- 基于Docker搭建私有镜像仓库
- g hub安装失败_树莓派k8s集群安装mysql及监控
- php 同义词词库,php实现seo伪原创,同义词替换 | 学步园
- 什么是敏捷开发(Scrum)?
- 实模式8086 与 保护模式80286
- JavaWeb核心技术——RequestResponse用户登录注册案例
- python提示IndentationError: unexpected indent错误
- 从懵懂无知到独挡一面——那些萌新程序员的进阶之路
- LINUX之静态库共享库
- 游戏建模你必须要掌握的六类软件
- 咪咕代理php,【独家创业】新七星修改2开正咪咕影视7.2全版/支持自定义解析/支持PHP7.0及以上...
- 超轻量级的Gow,替代cgwin
- Android中arm64-v8a、armeabi-v7a、armeabi是什么?
- 三种常用的UI库的安装使用:iview,element与vant
- 局域网限速软件_百度网盘竟良心发现,下载不再限速?
热门文章
- SpringBoot项目启动异常:Field settlementMissService in...Service required a single bean, but 2 were found:
- 如何恢复删除掉的压缩文件
- The Tennessee Waltz
- 软件随想录:程序员部落酋长Joel谈软件(阮一峰译)-3
- 2.1 zio入门——把函数作用作为工作蓝图
- 天龙八部的BillingServer
- 注意:网站中出现以下违规内容-搜索引擎百度都不收录
- 国家示范性高职院校名单(109所)
- DevOps ACA 阿里云效软件测试和质量保证(八)
- c语言调用函数的方法案例,C语言经典例题100例——C语言练习实例34解答(函数调用)...