阅读 11

[译] 认真的软件专业人必读的经典之一The Pragmatic Programmer 精华录

根据10 Classic Books Every Serious Developer Should Read ,首推的书为The Pragmatic Programmer: From Journeyman to Master

The Pragmatic Programmer作者Andrew Hunt 和 David Thomas为他们的书截取了精华,如果您还没有看这本书,可以先睹为快,如果看过了,也可当座右铭原文链接

实用的软件开发诀窍

关心你的工艺 Care About Your Craft

如果不想做出好作品,何必花一生的时间开发软件呢?

提供选项,不要给站不住脚的理由 Provide Options, Don’t Make Lame Excuses

与其给与借口,不如给选项不要说做不到,要告诉对方什么可以做到

做改变的催化剂 Be a Catalyst for Change

我们无法强迫别人改变,取而代之的是要秀给他们未来可以是什么样子,并帮助他们参与,一起创造

让品质成为需求的项目 Make Quality a Requirements Issue

让用户参与项目真实的品质需求决策

严格分析读到与听到的信息 Critically Analyze What You Read and Hear

不要被兜售的人、媒体炒作或教条给左右 依你个人、团队和项目的状况分析

OAOO(Once and Only Once)规则 DRY—Don’t Repeat Yourself

系统中的每一部分,都必须有一个单一的、明确的、权威的代表

消除无关事物间的影响 Eliminate Effects Between Unrelated Things

设计的组件要能自给自足、各自独立,且有单一与妥善定义的目的

运用曳光弹找到目标 Use Tracer Bullets to Find the Target

曳光弹让你对准目标做多种尝试并观察距离目标有多近

在接近问题的领域做计划 Program Close to the Problem Domain

用你用户懂的语言来做设计与编程

采用迭代循环的进程做编程 Iterate the Schedule with the Code

以你实践时所得的经验推敲项目的时间刻度(如几天一个迭代)

善用命令Shells的威力 Use the Power of Command Shells

当图形用户接口不切断shell时请用shell

代码控制是必要的 Always Use Source Code Control

程序法控制系统就像你工作的时光机-你随时可回去之前的版本

调试时不要惊慌 Don’t Panic When Debugging

深呼吸思考! 想想什么造成这个瑕疵(bug)

不要只做假设-证明它 Don’t Assume It—Prove It

在实际的环境下-以真正的数据和边界条件来证明你的假设

做会自动帮你写代码的编程 Write Code That Writes Code

代码产生器将提升你的生产力且帮你避免复制.

依合约做设计 Design with Contracts

以合约做纪录并查验所写的程序是否就是合约所要的,不要做过多也不要做过少,设计要恰到好处

以断言(assertions)避免不可能 Use Assertions to Prevent the Impossible

断言(assertions)证实你的假设 在这什么都不确定的世界请采用断言来保护你的代码

由谁开始就由谁结束

如果由哪个例行物(routine)或标的物(object)分配一个资源,也应该由其负责收回此资源

设置,不是集成 Configure, Don’t Integrate

为一个应用以设置的选择来实践技术选项,而不是用集成或工程的方式来做

分析流程以改善同步 Analyze Workflow to Improve Concurrency

在你的用户流程中多多利用同步的概念

总以同步来做设计 Always Design for Concurrency

纳入同步概念,你的设计接口将比较干净且比较少假设(if…)

使用白板协调工作流程 Use Blackboards to Coordinate Workflow

采用白板来协调各种事务与代理人, 同时也给每位参与者个人的独立与隔离空间

估计你逻辑运算的次序 Estimate the Order of Your Algorithms

在编码前先估量一下要每一样会花多少时间

早点重构, 经常重构 Refactor Early, Refactor Often

正如你可能需要为花园除草和重新布置,重写、重工以及重新架构代码有时也是必须的 如此才能根本解决问题

如果你不测试自己的软件,你的用户将会帮你测试 Test Your Software, or Your Users Will

要彻底、毫不留情地测试 不要留瑕疵(bugs)给你的用户发现。

不是收集需求-要挖出需求 Don’t Gather Requirements—Dig for Them

需求很少在表面上出现。 他们被深深埋在很多层假设、错误认知与政治下。

抽象比细节长久 Abstractions Live Longer than Details

投资抽象(abstraction),而非实作。 抽象(Abstractions)经得起变更的枪林弹雨,就算采用不同的实作和新的科技也还是有用。

不只要跳脱框框思考-还要知道框框在哪里 Don’t Think Outside the Box—Find the Box

当遇到无法理解的问题,找出实际的限制。 问自己: “一定要用这种方式来做吗? 追根究底,这有需要做吗? ”

有些事情做了比描述还好 Some Things Are Better Done than Described

不要掉入谈规格的螺旋 — 到某一点时就该动工写程序

花大钱买工具不代表你的产品设计会因此变好 Costly Tools Don’t Produce Better Designs

要警觉厂商的炒作业界的教条以及标价所造成的氛围。 请以工具实际的绩效做判断的标准。

不要用手动进程 Don’t Use Manual Procedures

一个外壳文稿进程(shell script)或批次档(batch file)将运行同样的指令,以同样的顺序,一次又一次

没跑完测试都不算完成编码 Coding Ain’t Done ‘Til All the Tests Run

不用多说

测试应包含型态覆盖, 不是只看代码覆盖 Test State Coverage, Not Code Coverage

指认出并测试重大的程序状态(program states)测试完每一行程序其实还不够。

英文也算是写程序的语言之一 English is Just a Programming Language

当你要写程序的时候写纪录: 实践DRY原则、使用元数据(metadata)、MVC 、自动生成等等

逐渐地超越你用户的期待 Gently Exceed Your Users’ Expectations

下去了解你用户的期待,然后交付比期待好一点点的东西

多动脑筋! 关于你的工作 Think! About Your Work

关掉自动导航模式,拿回你的掌控权经常地批判与评价你自己的工作。

别忽视破窗效应 Don’t Live with Broken Windows

当你看到很糟糕的设计、错误的决策和很烂的代码请想办法修正

记住事情的全貌与长远的远景 Remember the Big Picture

不要因为太专注细节而忘了看周遭发生的事物

经常投资你的知识组合 Invest Regularly in Your Knowledge Portfolio

让学习成为你的习惯

你说什么与你如何表达都很重要 It’s Both What You Say and the Way You Say It

如果没有被有效的沟通怎么棒的想法都没有用

让它容易重复使用 Make It Easy to Reuse

如果容易重复使用的话就会有很多人如此做 创建一个支持重复使用的环境。

没有所谓的最终决定 There Are No Final Decisions

没有一个决定是刻在石头上的相反的 ,考虑每一个决定是写在海滩的沙子上,且计划变更

制做原型来学习 Prototype to Learn

制作原型是个学习经验其价值并非你产出的这些代码,而是你从中学得的功课。

事前估算以避免意外 Estimate to Avoid Surprises

开始前先估计 你将是先发现潜在问题 。

将知识存于纯文本档 Keep Knowledge in Plain Text

纯文本档(Plain text)永不会过时 ,它帮助你工作上的杠杆也简化调试与测试

好好使用单一的编辑器 Use a Single Editor Well

编辑器应该就像你手的延伸确定你的编辑器可被设置、延展且可被编程

解决问题,不是抱怨 Fix the Problem, Not the Blame

瑕疵是你造成的或是别人造成的其实并不重要—它仍是你的问题 ,且需要你去解决

有问题时先别假设你选的外部系统出问题 “select” Isn’t Broken

其实很少问题出在操作系统(OS)或编译器(compiler) ,或是你选的第三方产品或函数库 (

library
) 大多问题都出现在你写的用程序中

学习一种纯文本操作语言 Learn a Text Manipulation Language

你每天花大部分的时间用纯文本工作,为何不让电脑帮你分担一些工作呢?

你不可能写出完美的软件 You Can’t Write Perfect Software

软件不可能完美 请保护你的程序与你的用户 ,免于受害于无法避免的错误

如有问题早点崩溃比较好 Crash Early

死的程序通常比跛的程序少做很多破坏

采用例外处理解决例外的问题 Use Exceptions for Exceptional Problems

典型的杂乱代码(spaghetti code)其可读性与可维护性的问题容易导致例外发生为例外储备例外处理。

尽量减少模块间的耦合 Minimize Coupling Between Modules

编写”害羞”代码并采用得墨忒耳定律(Law of Demeter,缩写LoD)以避免耦合。

把抽象(Abstractions)置入代码,把细节放入元数据 Put Abstractions in Code, Details in Metadata

为一般的案例写程序,将特殊状况放在编译的程序基底外。

以服务的观点来设计 Design Using Services

以服务的观点来设计—独立、在妥善定义下同时并行的对象、一致的接口。

分开视图和模型 Separate Views from Models

低成本的方式,分别以模型和视图的角度来设计应用程序,取得更大的弹性

不要用瞎猫碰到死耗子的方法写程序 Don’t Program by Coincidence

请只依靠可靠的事物。 小心偶然事物将让事情变得复杂,不要混淆刚刚好做对就以为达到计划中的目的。

测试你的估计 Test Your Estimates

算法的数学分析不能告诉你所有的事。 请在目标环境下试着计时你的编码。

设计前考量测试 Design to Test

在写第一行代码前先想想要如何做测试

不要用你不懂的精灵代码 Don’t Use Wizard Code You Don’t Understand

精灵(Wizards)可产生大量的代码。 在你把它并入你的项目前请先确定你了解它所有的一切

与用户合作并如用户思考 Work with a User to Think Like a User

最好的方法是洞见系统将被如何使用

编纂项目的词汇表 Use a Project Glossary

於单一来源创建并维护一个项目所有的特殊名词和字汇

当准备就绪的时候就开始 Start When You’re Ready

你已经不断在你的生涯旅途中累积经验。 不要忽视一直烦扰你的疑惑。

不要成为正规方法的奴隶 Don’t Be a Slave to Formal Methods

不要盲目采用任何不适合你真正开发实践和能力情境的技术

围绕着功能来组织团队 Organize Teams Around Functionality

不要将设计人员与编码人员分开,也不要分开测试人员与数据建模人员。 团队创建的方式要像程序创建的方式。

早点测试.经常测试. 自动测试 Test Early. Test Often. Test Automatically.

随着每一次建置(build)做测试将比束之高阁的测试计划有效多了

用破坏者来测试你的测试是否有效 Use Saboteurs to Test Your Testing

故意带入某些瑕疵(bugs)另做一个代码的版本来验证所做的测试能否抓到这些瑕疵(bugs)

每个瑕疵只让你找到一次 Find Bugs Once

一旦被人类的测试员找到瑕疵,这应该是人类测试员最后一次找到这个瑕疵才对。 从此之后应该让自动化测试帮你抓它出来 。

将文档纪录内置, 不是拴上 Build Documentation In, Don’t Bolt It On

文档纪录如果和代码分开而非内置就比较不可能在代码更新时也一起被修改

在你的作品上签名 Sign Your Work

早期的工艺家都会以自己的作为为荣并在作品上签名。你应该也是如此。


更多 Soft & Share 分享內容



关注下面的标签,发现更多相似文章
评论