程序员修炼之道 学习笔记 之一
关心你的技艺 Care About Your Craft
如果你不在乎能否开发出漂亮的软件,你又何必要浪费时间去开发软件呢?
思考你的工作! Think! About Your Work
我们向你发出挑战: 在你做每件事情的时候,思考你在做什么.它是对你每一天、在每一次开发上所做出的每一项决策的批判评估.不间断地思考, 实时地批判你的工作.
提供各种选择, 不要找蹩脚的借口 Provide Options, Don't Make Lame Excuses
对你自己负责, 对你自己的职业生涯负责,不要害怕承认无知或错误, 这意味着诚实与坦率.
当发生问题时, 要提供各种选择, 而不是找借口.不要说事情做不到, 而要说明能够做什么来挽回局面.不要害怕提出要求, 也不要害怕承认你需要帮助.
不要容忍破窗户 Don't Live with Broken Windows
不要留着"破窗户"(低劣的设计, 错误的决策,或是糟糕的代码)不修. 发现一个就修一个.如果没有足够的时间进行适当的修理,一定要采取某种行动防止进一步的损坏. 从点滴抓起,防止软件的"熵"一点点增长.
团队作为一个整体, 也不应该容忍破窗户.团队必须为产品的质量负责.支持那些了解"不留破窗"哲学的开发者,并鼓励那些还不了解这种哲学的人.
做变化的催化剂 Be a Catalyst for Change
设计出你可以合理要求的东西, 好好开发它. 一旦完成,就拿给大家看, 让他们大吃一惊. 然后说: "要是我们增加…可能就会更好. " 假装那并不重要,坐回椅子上, 等着他们开始要你增加你本来就想要的功能.人们发现, 参与正在发生的成功要更容易. 让他们瞥见未来,你就能让他们聚集在你周围.
你不能强迫人们改变. 相反,要向他们展示未来可能会怎样,帮助他们参与对未来的创造.
记住大图景 Remember the Big Picture
留心大图景. 要持续不断地观察周围发生的事情,而不只是你自己在做的事情.大多数软件灾难都是从微不足道的小事情开始的,常常是小事情的累积破坏了士气和团队.
团队应该确保每个人都主动地监视环境的变化.团队无需拒绝无法控制的变化――你只需要注意到它们正在发生.
经营好你的知识资产 Manage Your Knowledge Portfolio
定期投资. 对学习持续投入十分重要,学无止境. 并且设法把你学到的东西应用到你当前的项目中,把知识转化成你的技能和经验. 下面是一些建议:
- 每年至少学习一门新语言. 不同语言以不同方式解决相同的问题. 通过学习若干不同的方法, 可以帮助你拓宽你的思维, 并避免墨守陈规.下面是一些你可以尝试的语言: TOM, Smalltalk, Objective C, Eiffel.
- 每季度阅读一本技术书籍. 在你掌握了你正在使用的技术之后, 拓宽范围, 阅读一些与你的项目无关的书籍.如果你在进行非常详细的实现和编码, 就阅读关于设计和架构的书. 如果你在进行高级设计, 就阅读关于编码技术的书.
- 也要阅读非技术书籍.
- 试验不同的环境. 用惯了Windows, 那么就试试UNIX. 用惯了IDE, 那么就用用makefile和编辑器.
- 订阅商务杂志和其他期刊. 以下是一些推荐刊物: IEEE Computer, IEEE Software, Communications of the ACM, Dr. Dobbs Journal, Software Development Magazine.
- 上网.
多元化. 你知道的不同的事情越多,你就越有价值. 你掌握的技术越多,你就越能更好地进行调整, 赶上变化.
把握学习的机会. 保持好奇心.当你遇到不懂的问题时, 不要把问题搁在那里,把找到答案视为对你个人的挑战, 去请教高手, 上网搜索,或去图书馆.
你说什么和你怎么说同样重要 It's Both What You Say and the Way You Say It
知道你想要说什么. 规划你想要说的东西,写出大纲, 并准备好几种把它们讲清楚的策略.
了解你的听众. 想清楚如下的问题,你就确实了解了你的听众:
- 你想让他们学到什么?
- 他们对你讲的什么感兴趣?
- 他们的专业程度怎样?
- 他们想要多少细节?
- 你想要让谁拥有这些信息?
- 你如何促使他们听你说话?
选择时机. 要让你所说的适得其时,在内容上切实相关. 有时候,只要简单问一句"现在我们可以谈谈…吗？"就可以了.
选择风格. 调整你的交流风格,以适应你的听众. 有的人喜欢你仅陈述事实,有的人喜欢你多发表看法, 有的人喜欢你给出正式的文档,而有的人喜欢你的文档只是简单的备忘录或电子邮件.如果你对风格有疑问, 就询问对方.
让文档美观.太多程序员在制作书面文档时只关心内容,我们认为这是个错误.
让听众参与. 与制作文档的过程相比,我们制作出的文档最后并没有那么重要.如果可能,让你的读者参与文档的早期草稿的制作,获取他们的反馈, 并汲取他们的智慧.你将建立良好的工作关系,并很可能在这个过程中制作出更好的文档.
电子邮件交流.下面是一些针对电子邮件交流的提示:
- 检查拼写.
- 让格式保持简单.
- 设法让引文减至最少.
- 如果你引用别人的电子邮件, 一定注明出处, 并在正文中引用(而不要用附件).
- 检查收件人名单.
- 将你的电子邮件―你收到的重要文件和你发送的邮件―加以组织并存档.
不要重复你自己 DRY - Don't Repeat Yourself
可靠地开发软件, 并让我们的开发更易于理解和维护的唯一途径, 是遵循这样的原则: 系统中的每一项知识都必须有单一、无歧义、权威的表示。有时, 重复似乎是强加给我们的. 同一项信息, 可能需要以多种形式表示(比如Word文档, HTML文档, C++代码, Java代码,数据库schema). 解决问题的关键是采纳模型-视图的概念, 把信息的权威表示看作模型, 而信息的多种表示形式只是该模型的视力.使用自动化工具(代码生成器或文档生成器)完成视图的更新.
消除无关事物之间的影响 Eliminate Effects Between Unrelated Things
项目团队.可以试试从把infrastructure与high-level application分离开始. 每个主要的基础设施组件(数据库, 通信接口,中间件层, 等等)有自己的子团队. 如果应用的功能划分显而易见, 那就照此划分.设计.像模块化、基于组件、或分层这样的术语实际都是在描述设计松散耦合的的系统. 一些经典的设计模式也体现了松散耦合的思想, 例如MVC架构模式,Subscribe-Publish模式, Bridge模式和Strategy模式.
编码. 遵循依赖抽象原则, 你就能编写出松散耦合的代码.此外, 采用数据驱动法, 将逻辑与数据解耦, 可以使程序的代码变得灵活.
测试. 构建单元测试本身就是对系统耦合程度的有趣测试.修正bug也是评估整个系统的耦合程度的好时机.
不存在最终决策 There Are No Final Decisions
不变的就是改变. 因此应该设计和实现灵活的软件, 使之能更容易地应对改变. 下面是一些常见的考虑.- 使用配置文件, 而非硬编码.想一想如何通过配置文件来设置程序的算法、数据库产品、中间件技术、用户界面风格、操作系统相关配置、以及单机/CS架构/n层架构.
- 依赖于抽象, 而不要依赖于实现细节. 将抽象放入代码, 而把细节放入元数据.
不要在盒子外面思考—要找到盒子 Don't Think Outside the Box - Find the Box
解开谜题的关键在于确定加给你的各种约束, 并确定你确实拥有的自由度.你必须挑战任何先入之见, 并评估它们是否是真实的、必须遵守的约束. 问问自己以下的问题:
- 有更容易的方法吗?
- 你是在设法解决真正的问题, 还是被外围的技术问题转移了注意力?
- 是什么使它如此难以解决?
- 它必须以这种方式完成吗?
- 它真地必须完成吗?
