Tip 1:
Care About Your Craft
关心你的技艺
我其实一直没有想明白这句话是什么意思. 我的理解是, 我们现在所学所掌握的技艺最后可能是要过时的, 要时刻关心最新的技术并尝试去学习. 不过虽然这么说, 但是如何做就是见仁见智了, 我在最近可能看了看 shell 编程, 学了学 Node.js, 还看了两眼 Golang, 最终我真正吸收的还是 Node.js, 对于 shell 和 Golang 看的我实在提不起兴趣. 不过我也没有强求, 毕竟不是靠这个吃饭的, 而且自己也没有什么兴趣, 索性就放弃了. 不过对于 Node 我还是巨有兴趣的. 这个月我都在为 SportJoin 编写 Node API.
Tip 2:
Think! About Your Work
思考! 你的工作
Tip 3:
Provide Options, Don’t Make Lame Excuses
提供这种选择, 不要找蹩脚的借口
Tip 4:
Don’t Live with Brokwn Windows
不要容忍破窗户
Tip 5:
Be a Catalyst for Change
做变化的催化剂
Tip 6:
Remember the Big Picture
记住大图景
Tip 7:
Make Quality a Requirements Issue
使质量成为需求问题
Tip 8:
Invert Regularly inYour Knowledge Portfolio
定期为你的知识资产投资
Tip 9:
Critically Analyze What You Read and Hear
批判地分析你读到的和听到的
Tip 10:
It’s Both What You Say and the Way You Say it
你说什么和你怎么说同样重要
Tip 11:
DRY — Don’t Repeat Yourself
不要重复你自己
Tip 12:
Make It Easy to Reuse
让复用变得更容易
Tip 13:
Eliminate Effects Between Unrelated Things
消除无关事物之间的影响
Tip 14:
There Are No Final Decisions
不存在最终决策
Tip 15:
Use Tracer Bullets to Find the Target
用曳光弹找到目标
Tip 16:
Prototyle to Learn
为了学习而制作模型
Tip 17:
Program Close to the Problem domain
靠近问题领域编程
Tip 18:
Estimate to Avoid Surprises
估算, 以避免发生意外
Tip 19:
Iterate the Schedule with the Code
通过代码对进度表进行迭代
Tip 20:
Keep Knowledge in Plain Text
用纯文本来保存知识
Tip 21:
Use the Power of Command Shells
利用命令 shell 的力量
Tip 22:
Use a Single Editor Well
用好一种编辑器
Tip 23:
Always Use Source Code Control
总是使用源码控制
Tip 24:
Fix the Problem, Not the Blame
要修正问题, 而不是发出指责
Tip 25:
Don’t Panic
不要恐慌
Tip 26:
“Select” Isn’t Broken
“Select” 没有问题
Tip 27:
Don’t Assume it — Prove It
不要假定, 要证明
Tip 28:
Learn a Text Manipulation Language
学习一种文本操纵语言
Tip 29:
Write Code That Writes Code
编写能编写代码的代码
Tip 30:
You Can’t Write Perfect Software
你不可能写出完美的软件
Tip 31:
Design with Contracts
通过合约进行设计
Tip 32:
Crash Early
早崩溃
Tip 33:
If It Can’t Happen, Use Assertions to Ensure That It Won’t
如果它不可能发生, 用断言确保它不会发生
Tip 34:
Use Exceptions for Exceptional Problems
将异常用于异常的问题
Tip 35:
Finish What You Start
要有始有终
Tip 36:
Minimize Coupling Between Modules
使模块的之间的耦合减少
Tip 37:
Configure, Don’t Integrate
要配置, 不要集成
Tip 38:
Put Abstractions in Code, Details in Metadata
将抽象放进代码, 细节放进元数据
Tip 39:
Analyze Workflow to Improve Concurrency
分析工作流, 以改善并发性
Tip 40:
Design Using Services
用服务进行设计
Tip 41:
Always Design for Concurrency
总是为并发设计
Tip 42:
Separate Views from Models
使视图与模型分离
Tip 43:
Use Blackboards to Coordinate Workflow
用黑板协调工作流
Tip 44:
Don’t Program by Coincidence
不要靠巧合编程
Tip 45:
Estimate the Order of Your Algorithms
估算你算法的阶
Tip 46:
Test Your Estimates
测试你的估算
Tip 47:
Refactor Early, Refactor Often
早重构, 常重构
Tip 48:
Design to Test
为测试而设计
Tip 49:
Test Your Software, or Your Users Will
测试你的软件, 否则你的用户就得测试
Tip 50:
Don’t Use Wizard Code You Don’t Understand
不要使用你不理解的向导代码
Tip 51:
Don’t Gather Requirements — Dig for Them
不要搜集需求 — 挖掘它们
Tip 52:
Work with a User to Think Like a User
与用户一同工作, 以像用户一样思考
Tip 53:
Abstractions Live Longer than Details
抽象比细节活得更长久
Tip 54:
Use a Project Glossary
使用一个项目词汇表
Tip 55:
Don’t Think Outside the Box — Find the Box
不要在盒子外面思考 — 要找到盒子
Tip 56:
Listen to Nagging Doubts — Start When You’re Ready
倾听反复出现的疑虑 — 等你准备好再开始
Tip 57:
Some Things Are Better Done than Described
对有些事情”做”胜于”描述”
Tip 58:
Don’t Be a Slave to Formal Methods
不要做形式的奴隶
Tip 59:
Expensive Tools Do Not Produce Better Designs
昂贵的工具不一定能制作出更好的设计
Tip 60:
Organize Around Functionality, Not Job Functions
围绕功能, 而不是工作职务进行组织
Tip 61:
Don’t Use Manual Procedures
不要使用手工流程
Tip 62:
Test Early. Test Often. Test Automatically.
早测试, 常测试, 自动测试.
Tip 63:
Coding Ain’t Done ‘Til All the Tests Run
要到通过全部的测试, 编码才算完成
Tip 64:
Use Saboteurs to Test Your Testing
通过”蓄意破坏”测试你的测试
Tip 65:
Test State Coverage, Not Code Coverage
测试状态覆盖, 而不是代码覆盖
Tip 66:
Find Bugs Once
一个 bug 只抓一次
Tip 67:
Treat English as Just Another Programming Language
把英语当作又一种编程语言
Tip 68:
Build Documentation In, Don’t Bolt It On
把文档建在里面, 不要栓在外面
Tip 69:
Gently Exceed Your User’s Expectations
温和地超过用户的期望
Tip 70:
Sign Your Work
在你的作品上签名
71 要学习的语言
厌倦C、C++和JAVA?试试CLOS、Dylan、Eiffel、Objective C、Prolog、Smalltalk或Ruby。它们每一种都有不同的能力和不同的“风味”。用其中的一种或多种语言在家里开发一个小项目。
72 WISDOM离合诗
Whatdo you want them to learn? 你想让他们学到什么？
What is their interest in what you're got to say? 他们对你讲的什么感兴趣？
How sophisticatedare they? 他们有多富有经验？
How much detail do they want? 他们想要多少细节？
Whom do you want to own the information? 你想要让谁拥有这些信息？
How can you motivate them to listen to you ? 你如何促使他们听你说话？
73 怎样维持正交性
设计独立、良好定义的组件。
使你的代码保持解耦。
避免使用全局数据。
重构相似的函数。
74 应制作原型的事物
架构。
已有系统中的新功能。
外部数据的结构或内容。
第三方工具或组件。
性能问题。
用户界面设计。
75 架构问题
责任是否得到了良好的定义？
协作是否得到了良好的定义？
耦合是否得以最小化？
你能否确定潜在的重复？
接口定义和各项约束是否可接受？
模块能否在需要时访问所需数据？
76 调试检查清单
正在报告的问题是底层bug的直接结果，还是只是症状？
bug真的在编译器里？在OS里？或者是在你的代码里？
如果你向同事详细解释这个问题，你会说什么？
如果可疑代码通过了单元测试，测试是否足够完整?如果你用该数据运行单元测试，会发生什么？
造成这个bug的条件是否存在系统中的其他任何地方？
77 函数的德墨忒尔法则
某个对象的方法应该只调用属于以下情形的方法：
它自身。
传入的任何参数。
它创建的对象。
组件对象。
78 怎样深思熟虑地编程
总是意识到你在做什么。
不要盲目地编程。
按照计划行事。
依靠可靠的事物。
为你的假定建立文档。
不要只是测试你的代码，还要测试你的假定。
为你的工作划分优先级。
不要做历史的奴隶。
79 何时进行重构
你发现了对DRY原则的违反。
你发现事物可以更为正交。
你的知识扩展了。
需求演变了。
你需要改善性能。
80 劈开戈尔迪斯结
在解决不可能解决的问题时，问问你自己：
有更容易的方法吗？
我是在解决正确的问题吗？
这件事情为什么是一个问题？
是什么使它如此难以解决？
它必须以这种方式完成吗？
它真的必须完成吗？
81 测试的各个方面
单元测试、集成测试。
验证和校验。
资源耗尽、错误及恢复。
性能测试、可用性测试。
对测试自身进行测试。
