The Pragmatic Programmer

[dive2Pro]

Knowledge Portfolio

It’s important to continue investing. Once you feel comfortable with some new language or bit of technology, move on.Learn another one.

It doesn’t matter whether you ever use any of these technologies on a project, or even whether you put them on your resume. The process of learning will expand your thinking, opening you to new possibilities and new ways of doing things. The cross-pollination of ideas is important; try to apply the lessons you’ve learned to your current project. Even if your project doesn’t use that technology, perhaps you can borrow some ideas. Get familiar with object orientation, for instance, and you’ll write plain C programs differently.

学习到的东西, 有的不会立马就可以用在项目, 学习这些是有潜移默化的效果的, 在学习的过程中, 自己的思维得到发散, 增加并改进看问题的角度, 这些看不到的是更有价值的东西.

Critical Thinking

Never underestimate the power of commercialism. Just because a Web search engine lists a hit first doesn’t mean that it’s the best match;

现在通过 web, 和大师的距离只有 一个 enter 键.

Challenges

• Start learning a new language this week. Always programmed in C++? Try Smalltalk [URL 13] or Squeak [URL 14]. Doing Java? Try Eiffel [URL 10] or TOM [URL 15]. See page 267 for sources of other free compilers and environments.
• Start reading a new book (but finish this one first!).
  1. If you are doing very detailed implementation and coding, read a book on design and architecture.
  2. If you are doing high-level design, read a book on coding techniques

Communicate

we work daily within our teams to advocate our ideas, modify existing practices, and suggest new ones. A large part of our day is spent communicating, so we need to do it well

1. Know What You Want to Say

科幻作家在成书前, 会plot out 所有的细节. 而我们却习惯坐在电脑前, 输入 1. Introduction, 接着就输入脑海中蹦出的内容.

Plan what you want to say. Write an outline. Then ask yourself, “Does this get across whatever I’m trying to say?” Refine it until it does

2. Knowning Your Audience

在 大会 上发言, 所有的人都等着你读完冗长的发言稿, 这并不是交流. 这是演讲.

WISDOM Acrostic

                *W*hat do you want them to learn?
            What is their *i*nterest in what you’ve got to say?
                        How *s*ophisticated are they?
              How much *d*etail do they want?

Whom do you want to own the information? How can you motivate them to listen to you?

Get Back to People

If you ask someone a question, you feel they’re impolite if they don’t respond. But how often do you fail to get back to people when they send you an e-mail or a memo asking for information or requesting some action? In the rush of everyday life, it’s easy to forget. Always respond to e-mails and voice mails, even if the response is simply “I’ll get back to you later.” Keeping people informed makes them far more forgiving of the occasional slip, and makes them feel that you haven’t forgotten them.

不要忘记回答, 日常的提问有的被大脑过滤, 但被过滤前, 如果记起来了, 一定要回复. 保持交流是同步的

[dive2Pro]

A Pragmatic Approach

`axiomatic` 
1. 自明之理的；公理的
2. 原則的
3. 格言的；充滿格言的

`Orthogonality`
1. 正交性
2. 直交性
3. 正交
4. 相互垂直

`insulate`
1. vt.[(+from/against)]隔離；使孤立；
2.【物】使絕緣；使隔熱；使隔音

The Evils of Duplication

`contradictory`
adj.矛盾的，對立的[（+to）]；好反駁的，喜爭辯的
n.[C]矛盾因素，對立物；【邏】矛盾命題；否定項

`harness`
vt. 治理；套；驾驭；披上甲胄；利用
n. 马具；甲胄；挽具状带子；降落伞背带；日常工作

收集, 组织, 利用的知识, 不是 stable 的, 而是飞速发展的. 一次会议或者客户的需求, 可能就会对我们现有 使用在我们系统 的知识 产生影响.

Most people assume that maintenance begins when an application is released, that maintenance means fixing bugs and enhancing features. We think these people are wrong.

维护不是交付完成后开始的.

maintenance is not a discrete activity, but a routine part of the entire development process

discrete
adj. 离散的，不连续的
n. 分立元件；独立部件

The problem is that it’s easy to duplicate knowledge in the specifications, processes, and programs that we develop, and when we do so, we invite a maintenance nightmare

解决办法的原则: DRY (Don't Repeat Yourself!)

EVERY PIECE OF KNOWLEDGE MUST HAVE A SINGLE, UNAMBIGUOUS, AUTHORITATIVE REPRESENTATION WITHIN A SYSTEM

原则的关键在于 It isn’t a question of whether you’ll remember: it’s a question of when you’ll forget.

DRY 也是作为 Pragmatic Programmer 的最重要的一个工具.

Duplication 出现的原因, 解决之道

• Imposed Duplication

  1. Document in code. good code has lots of comments., bad code requires lots of comments. 代码是 low-level的程序解释, 在 注释中, 要遵循 DRY 原则, 需要将 注释提高到 high-level . 否则, 我们就是在 重复知识, 每一次 code 的改变, 注释也需要改变.

• Inadvertent Duplication

• Impatient Duplication

  short cuts make for long delays

• Interdeveloper Duplication code review, communicate

Orthogonality

Two or more things are orthogonal if changes in one do not affect any of the others.

[dive2Pro]

Reversibility

we don’t always make the best decisions the first time around.

Instead of carving decisions in store, think of them more as being written in the sand at the beach. A big wave can come along and wipe them out at any time.

问题的解决办法不是只有一种, 在改变到来之前, 确定使用的办法是 具有可逆性的. 比如 使用的数据库, 应该将这一层抽象出来, CRUD, 系统的其他组件是不会考虑它的内部是由哪一个实现的.

Flexible Architecture

While many people try to keep their code flexible, you also need to think about maintaining flexibility in the areas of architecture, deployment, and vendor integration.

[dive2Pro]

While You Are Coding

once a project is in the coding phase, the work is mostly mechanical, transcribing the design into executable statements.

上面的观点是错的, 而且它正是 the single biggest reason that many programs are ugly, inefficient, poorly structured, unmaintainable, and just plain wrong. 在编程中, 我们每分钟都在做着决定, 这些决定最终都会影响整个程序在之后的是否能拥有长, 准确 和生产力 的 生命.

优秀安全的司机会不断的审查情况, 检查潜在的危险, 把自己置于一个好的位置, 以应付难以预料的事情发生. 这些措施对程序员来说也是一样, 这可能是 largely routinebut keeping your wits about you could well prevent a disaster.`

Programming by Coincidence

有士兵趟在雷区中, 并不意味着整片雷区是安全的. 而是刚刚好, 这个士兵趟过的地方是安全的. 太过乐观的话, 也许下一秒就是灾难.

编程中, 我们就是在趟雷区, 每一天, 都有数不尽的陷阱等待我们.

How to Program by Coincidence

输入一些代码, 验证一下, 看起来是正确工作了. 再输入下一段代码, 验证一下, 仍是正确工作的. 按照这样的 工作方式, 最终, 当 bug 出现时, 就很难发现正确的解决办法. 为什么?
doesn’t know why the code is failing because he didn’t know why it worked in the first place., 它们都只是刚好工作 的代码.

How to Program Deliberately

1. 用文档记录假设. 这些会帮助我们更好的思考程序, 同时也可以帮助到与他人的交流.
2. 不只是测试代码, 能同时测试假设是最好的. 不要猜, 实地去测. 写一个断言来测试你的假设. 如果断言是正确的, 这改进了代码的文档. 如果断言是错误的, 帮助你发现了一个错误, 应该感到庆幸
3. 优化努力的方向. 将时间花费在重要的方向上, 同时这些也是难点所在.
4. 不要成为历史的奴隶. 不要让现有的代码去命令未来的代码. 代码一旦不适用了, 它就是可替换的. 在一个程序中, 不要让已有的代码限制你接下来要写的代码. -- 总是准备着重构, 这些比你不做任何的改变, 在未来要更加的有效率.

Refactoring

Change and decay in all around I see...

编程不是建筑, 更像是园林艺术. 它是更有机的一种形式, 阳光, 阴影, 植被的布局, 植物的裁剪, 这些更符合现实中程序的进程. 假设某一片植被生长的太繁杂, 或者要完成目标太过复杂 --- 需要分割成 2 块. 如果事情的发展超出了预期, 那么有些地方就需要被铲除或者修整. 这就是 Refactoring

When Should You Refactor?

• Duplication. 遵循 DRY原则
• Nonorthogonal Design. 违背正交性
• Outdated knowledge
• Performance

面对现实, 重构是一件挑战疼痛管理的事情 ---- 这些代码工作的差不多和预想的一样, 现在你要我把它们重新开发? --- 只是因为程序不完全正确就要重构? 这是许许多多的程序员不情愿做这些事情的出发点

Real-World Complications

我们不能对 Boss 或者客户说, "这些代码可以工作, 但是我需要额外的一个星期来重构它"

用脚想也知道他们会怎么回复

时间的压力经常作为略过重构的理由. 但这个理由并不能站得住脚: 现在不重构, 在将来就会花费远超预期的时间去调查, 修复问题 -- 而且这跟程序的依赖的增多成正比.

现在假象 这份代码是一个 肿瘤, 切除它是一个侵入式的手术. 你可以在它还是小的时候, 也就是现在把它取出来. 也可以等到它慢慢长大, 扩散 --- 但等到那个时候, 花费的代价就会更加的昂贵, 风险也会成倍的提高. 如果时间再久一点, 你会失去治疗的机会.

立即重构, 不能马上处理的, 将它写入计划表.