程序员修炼之道

关心你的技艺 思考你的工作 不要依靠自动驾驶仪，不间断的思考，实时地批判你的工作。 在一个项目的总体结构中，总有个性和技艺的位置。一百年之后，我们的工程看起来或许已很古老，就像是中世纪的大教堂建造者所使用的技术在今天的土木工程师看来很古老一样，但我们的技艺却仍将受到尊重。 在所有的弱点中，最大的弱点就是害怕暴露弱点。 提供各种选择，不要找蹩脚的借口。不要说事情做不到，要说明能够做什么来挽回局面。 不要害怕提出要求，也不要害怕承认你需要帮助 一扇破窗户，只要有那么一段时间不修理，就会渐渐给建筑的居民带来一种废弃感。于是又一扇窗户破了，人们开始乱扔垃圾。出现了乱涂乱画。严重的结构损坏开始了。 不要容忍破窗户 但更重要的是，士兵充当催化剂，把村民团结起来，和他们一起做到了他们自己本来做不到的事情——项目协作的成果。每个人最后都是赢家。 做变化的催化剂。 知识上的投资，总能得到最好的回报。 1. 严肃的投资者定期投资——作为习惯。 2. 多元化是长期成功的关键——你知道的不同的事情越多，你就越有价值。 3. 管理风险 4. 低买高卖。在新兴的技术流行之前学习它可能和找到被低估的股票一样困难，但所得到的就和那样的股票带来的收益一样。 5.重新评估和平衡 最重要的是定期为你的知识资产投资。 你说什么和你怎么说同样重要。 第二章 注重实效的途径 不要重复你自己（DRY） 系统中的每一项知识都必须具有单一、无歧义、权威的表示。 代码中的文档：把注释保留给其他的高级说明，否则，我们就是在重复知识。用头文件记载接口问题，用实现文件记载代码的使用者无需了解的实际细节。 无耐性的重复：如果你觉得受到诱惑，想一想古老的格言：”欲速则不达“ 正交性：不相依赖性或者是解耦性 消除无关事物之间的影响 可撤销性 没有什么永远不变——而如果你严重依赖某一事实，你几乎可以确定它将会发生变化。 通过DRY原则、解耦以及元数据的使用 在黑暗中发光的代码——快速清晰的获取用户需求。 在背要求进行估算时说什么——”我等会告诉你“。 第三章 基本工具 * 用纯文本保存知识 * 利用shell 的力量 find . -name '*.c' -newer Makefile -print find . -name '*.jave' -mtime +7 -print * 使用单一的编辑器 选一种强大的编辑器，然后学好他 调试心理学 要修正问题，而不是发出指责 不要恐慌 代码生成器 编写能够编写代码的代码 第四章 注重实效的偏执 你不可能写出完美的软件 俺合约进行设计——用文档记载并约定软件模块的权利与责任，以确保程序的正确性。 早崩溃，要崩溃，不要破坏 断言式编程：如果它不可能发生，用断言确保它不会发生 异常留给意外事件，“如果我移走所有的异常处理，这些代码是否仍能正常运行？” 如果答案是否，那么异常也许就用到了非异常的情形中。 错误处理器是另外一种选择 怎样配平资源：分配某项资源的例程或对象应该负责解除该资源的分配。 以与资源分配次序相反的次序解除资源的分配 在不同的地方分配同一套资源时总是使用相同的顺序分配他们，以减少死锁的可能性。 第五章 弯曲，或折断 解耦与得墨忒耳法则 编写遵守得墨忒耳法则的“羞怯”的代码 函数的得墨忒耳法则： 某个对象的任何方法都应该只调用属于以下情形的方法： 1. 他自身的方法 2. 传入该方法的任何参数； 3. 它创建的任何对象； 4. 任何直接持有的组件对象 缩小调用类中的响应集的规模 元程序设计 要配置，不要集成 元数据：关于数据的数据，如调谐参数，用户偏好，安装目录等。元数据在运行时而不是编译时被访问和使用 将抽象放进代码，将细节放进元数据。 以声明的方式思考（规定要做什么，而不是怎么做）：为一般情况编写程序，把具体情况放在别处——在编译的代码库之外。 时间耦合：分析工作流，以改善并发性 为并发进行设计 用黑板协调工作流 第六章 当你编码时 靠巧合编程： 1. 实现的偶然； 2. 语境的偶然；——你的模块必须依赖GUI？是否依靠说英语的用户？你还依靠别的什么没保证的东西？ 3. 隐含的假定； 怎样深思熟虑的编程： 1. 总是意识到你在做什么 2. 不要盲目的编程； 3. 按照计划行事； 4. 依靠可靠的事物； 5. 为你的假定建立文档； 6. 不要只是测试你的代码，还要测试你的假定； 7. 为你的工作划分优先级 8. 不要做历史的奴隶 最好的算法并非总是最好的 重构： 1. 重复 2. 非正交的设计； 3. 过时的知识； 4. 性能 早重构，常重构 1. 不要在重构的时候加入新的功能； 2. 在开始重构之前，确保你拥有良好的测试。 3. 采取短小、深思熟虑的步骤：如果使你的步骤保持短小，并在每个步骤之后进行测试，你将能够避免长时间的调试。 确保对模块做出的剧烈改动，会破坏构建。 易于测试的代码：为测试而设计。 第七章 在项目开始之前 你是否曾经有过你的项目注定要失败的感觉，甚至是在项目开始之前？有时它也许会这样，除非你先建立某些基本准则。 不要搜集需求——挖掘他们 找出用户维护要做特定事情的原因，而不是他们目前做这件事情的方式。 用文档记载需求背后的原因将在每天进行实现决策时给你的团队带来无价的信息。 与用户一同工作，以像用户一样思考。 倾听反复出现的疑虑，等你准备好再开始。你可能无法准确地指出问题所在，但给它时间，你的疑虑很可能就会结晶成某种更坚实的东西，某种你可以处理的东西。 对于某些事情，“做”胜于“描述“ 注重实效的程序员批评的看待科学方法，并从各种方法学中提取精华，融合成每个月都在变得更好的一套工作习惯。这至关重要。你应该不断努力提炼和改善你的开发过程。绝不要把方法学的呆板限制当作你的世界的边界。 第八章 注重实效的项目 不要留破窗户 煮青蛙 交流 不要重复你自己 正交性 无处不在的自动化 文明通过增加我们不加思索就能完成的重要的操作的数目而取得进步。 一切都要自动化。 在现实中，项目的成功是由它在多大程度上满足了用户的期望来衡量的。 温和的超出用户的期望。 交流期望 额外的一公里。 注重实效的程序员不会逃避责任。相反，我们乐于接受挑战，乐于使我们的专业知识广为人知。如果我们在负责一项设计，或是一段代码，我们是在做可以引以为豪的工作。 Sign Your Work 在你的作品上签名。 过去时代的手艺人为能在他们的作品上签名而自豪，你也应该如此。

絮絮叨叨了n篇序和一坨该死的废话后终于进入了作者写的正题。开篇第一章 俨然有种歪叔在面前吐槽的错觉。中午吃饭时讨论的基本和书中一致。 本书开篇讨论的是「责任」。**a pragmatic programmer**应当对自己的职业生涯负责，不惧怕承认无知或错误。 歪叔中午也提到了「对于没有权限的事，有权**不**去为之负责，权限越大责任也越大」，书中的言辞是不可能做到的事或风险太大的事。这基于自己的道德准则和判断来做决定，也就是常说的三观。现在的软件系统愈来愈大，必须分析风险**是否超出了控制**，然后负担起自己控制得了的那部分责任。说起来 sunyi一直奉行什么权限都别给我加的行事准则 就是三观很正的表现。 在**确实**同意为某个结果负责的情况下，犯错误/判断失误/造坑/没节操代码，应该诚实的承认它，并设法给出选择，**不要pass 不要ignore**，本小节在责任之后的话题是「Provide Options，Don't Make Lame Execuses」。踩坑，可以获得「直接经验」，多看博客/书/交流获得「间接经验」，这些经验为的就是再次遇到坑时可以bypass，或者说知道对应的解决方案/方案选择。 建议预演一遍说出借口后怎么圆都圆不上的尴尬场面吧（当然 三观不正的人可能想象不出来），不要说事情做不到，而要说明做什么能挽回局面。不要害怕提出要求，也不要害怕承认需要帮助（啊 啊 有些事认为很需要 但是别人认为优先级还不够高而延迟了提供帮助 但这种情况似乎又是*职权之外*的suck thing了 隐约觉得本章最后所说的猫要承受指责大概说的就是这情况） 嗯 长得虽萌，但也要练起一条毒舌出来。必须得承认 这两天 我做了一个糟糕透顶的设计 要做有节操的一线基层码农 就要optimize it。

《程序员修炼之道》笔记 ========= ###1. 注重实效的哲学 A Pragmatic Philosophy - 负起责任，不要找借口。Provide options, dont make lame excuses. - 不要容忍破窗，一扇破窗足以使软件开始腐烂。Dont live with broken windows. - 在人人自危不团结时，拿出自己能做的最好的东西，做变化的催化剂，聚结起团队。Be a catalyst for change. - 投资知识财产，评估管理风险。新语言、书籍、组织、网络。批判地学习。Critically analyze what you read and hear. - 交流 * 写出大纲，理清想要说什么 * 了解听众 （WISDOM) - what: 想让他们学到什么 - interest: 他们对你讲的什么感兴趣 - sophisticated: 他们有多富有经验 - detai: 他们想要多少细节 - own: 你想要让谁拥有这些信息 - motivate: 如何促使他们听你说话 * 选择适合的时机，风格 * 让听众参与，倾听反馈，回复他人。 ###2. 注重实效的途径 A Pragmatic Approach - 重复的危害 * DRY - dont repeat yourself. Make it easy to reuse. - imposed duplication 强加的重复 >编写简单的过滤器, 代码生成器 - inadvertent duplication 无意识的重复 - impatient duplication 缺乏耐性的重复（偷懒） - interdeveloper duplication 开发者间的重复。 - 正交性（两条直线相交成直角，不相互依赖） * 消除无关事物之间的影响。Eliminate effects between unrelated things. - 提高生产力 * 改动得以局部化，缩短开发测试时间 * 促进复用 - 降低风险 * 代码隔离。某个模块的问题不会扩散到系统的其余部分。 * 更易测试。 * 编码 - 保持解耦 - 避免使用全局数据 - 避免编写相似的函数 - 可撤销性 * 灵活的架构。不存在最终决策 there are no final decisions. - 曳光弹 > 构建未接触过的新项目，使用不熟悉的算法、技术、语言、库，面对着大量未知的事物。传统使用繁重的工程方法，制作大量分档，确定所有未知的因素，限定环境。 * 在黑暗中发光的代码。 Use tracer bullets to find the target >> 曳光代码并非用过就仍的代码：编写它是为了保留它，包含错误检查、结构、文档。只不过功能不全而已。 - 让用户及早看到能跑起来的东西 - 开发者能构建一个他们能在其中工作的结构 - 有了一个集成平台。 - 能感觉到工作进展 * 曳光代码 vs 原型制作 > 原型是对概念进行试验，试验完成后代码即抛弃。所以一般选用更高级的语言，不考虑正确性、完整性、健壮性。 - 领域语言 * 实现小型语言 - 定义语法(BNF表示法），转换为解析器生成器(parser generator)<yacc(c,cpp), javaCC(java) - 扩展现有语言。 - 估算 > Estimate to avoid surprises * 需要多准确 > 选择单位。1-15天，3-8周，2-6个月。 * 估算 - 理解提问内容，把握问题域的范围 - 建立系统模型 - 把模型分解为组件，组件的参数，影响整个模型 - 给每个参数指定值。对那些影响较大的参数，估值应尽量正确。 - 计算答案 - 追踪你的估算能力 * 估算项目进度 - 检查需求 - 分析风险 - 设计、实现、集成 - 向用户确认 ### 3.基本工具 The basic tools - 纯文本 > 用纯文本保存知识，keep knowledge in plain text * 缺点：需要更多控件，计算处理时间更长 > 用户密码进行加密，不让改变参数值时，增加参数值的MD5作为校验和 * 文本的威力 - 保证不过时（相对二进制文件，更已读） - 杠杆作用 （更有益于版本控制，部署等。。） - 更易于测试 - Shell游戏 * Use the power of command shells. > GUI的好处是what you see is what you get, 缺点时what you see is all you get. - find . -name '*.c' -newer Makefile -print - zip archive.zip *.h *.c - find . -name '*.java' -mtime +7 -print - find . -name '*.java' -mtime +7 print | xargs grep 'java.awt' - grep '^import' *.java | sed -e's/.import *// ' -e's/;.*$//' | sort -u >list > windows下可用cygwin. <perl power tools> - 编辑器 Use a single editor well. > 精通一种编辑器，用于所有编辑任务：代码、文档、备忘录、系统管理。 * 编辑器特性 - 可配置 - 可扩展 - 可编程，执行复杂、多步骤的操作。通过宏或内建脚本进行编程。 - 语法突显 - 自动完成 - 自动缩进 - 初始代码或文档样板 - 与帮助系统挂接 - 类IDE特性（编译、调试等） * 编辑器 - The Emacs Editor - The XEmacs Editor - The Vim Editor - The elvis Editor - Emacs Viper Mode - 源码控制 Always use source code control. - 调试 * Fix the problem, not the blame. * Donot panic. * Donot assume it, prove it. * 调试检查列表 - 正在报告的问题是底层bug的直接结果，还是只是症状 - bug真的在编译器里？在OS里？或者是在你的代码里？ - 如果你向你同事详细解释这个问题，你会说什么？ - 如果可以代码通过了单元测试，测试是否足够完整？ - 造成这个bug的条件是否存在于系统中的其他地方？ - 文本操纵 > unix开发者喜欢使用shell，用awk、sed一类的工具增强，偏爱结构化工具的喜欢python, * 数据库schema维护 >> 一组Perl脚本读取含有数据库schema定义的纯文本文件，根据他声称 - 用于创建数据库的SQL语句 - 用于填充数据词典的flat数据文件 - 用于访问数据库的c代码库 - 用于检查数据库完整性的脚本 - 含有schema描述及框图的网页 - schema的xml版本 * Java属性访问，用脚本修改源文件，做适当标记。 * 测试数据生成。将散布在不同文件、不同格式的大量数据汇合，转为适于放入数据库的格式 * 写书。提取树种的代码片段 * C与Object Pascal的接口 * 生成web文档 - 代码生成器 * 被动代码生成器 - 创建新的源文件。模板、源码控制指示、版权说明，标准注释块 - 在编程语言之间进行一次性转换 - 生成查找表及其它在运行时计算很昂贵的资源 * 主动代码生成器 > 遵循DRY原则的必需品。需要根据定义文件生成代码 ### 4. 注重实效的偏执 Pragmatic paranoia. you canot write perfect software. - 按照合约设计（DBC） > precondition前条件，postcondition后条件，class invariant类不变项 * 断言。c/c++中可以参考Nana，在运行时监控断言 - 死程序不说谎 Crash early * 要崩溃，不要破坏trash - 断言式编程 > 如果他不可能发生，用断言确保它不会发生 If it canot happen, use a assertions to ensure that it wonot. - 何时使用异常 Use exceptions for exceptional problems. > 什么是异常: 异常应保留给意外事件，不作为程序正常流程的一部分。 - 怎样配平资源 > 管理内存、事物、线程、文件、定时器。 Finish what you start ### 5. 弯曲，或折断 Bend, or break. - 解耦与德墨忒尔法则 > minimize coupling between modules. - 元程序设计 Configure, donot integrate.算法、数据库产品、中间件技术和用户界面风格，应该作为配置选项，而不是通过集成或工程实现。 元数据即关于数据的数据。如数据库schema，schema含有按照名称、存储长度及其它属性、对字段进行描述的数据。 '元数据驱动应用'。Put abstractions in code, details in metadata. 把抽象放进代码，细节放进元数据。 - 时间耦合 不只考虑线性 分析工作流，以改善并发性。analyze workflow to improve concurrency. Design Using Services. 用服务进行设计。 Always design for concurrency. 总是为并发进行设计。 - 它只是视图 * 发布/订阅协议 > 如果对publisher生成的特定事件感兴趣，只需要登记自己。publisher追踪所有感兴趣的subscriber对象，当publisher生成又去的事件时，将依次调用每个subscriber，通知他们事件已经发生。 * Model-View-Controller. separate views from models. - 模型。 表示目标对象的抽象数据模型。 - 视图。 订阅模型中的变化和来自控制器的逻辑事件 - 控制器。 既向模型、也向视图发布事件。 - 黑板 用黑板来梳理工作流, Use blackboards to coordinate workflow. 黑板方法的一些关键特征： * 侦探查看黑板，不需要知道其他侦探存在，从中了解新的信息，加上他们的发现； * 侦探可能接受过不同的训练，具有不同程度的教育背景和专业经验，甚至不在一个辖区工作。他们的共同点是渴望破案； * 在破案过程中，不同侦探可能会来来去去，工作班次也可能不同 * 对放在黑板上的内容没有什么限制，可以是图片、判断、物证等等。 >图像处理：简单的并行进程间工作负载调度，共享的工作队列也许就很足够了。如果涉及反馈，如模块图像的处理结果对其他块有影响，可以考虑黑板系统。 >机构日程安排： > 网络监控工具：收到用户发来的问题报告和自动报告统计信息，把他们公布在黑板上。人或软件代理可以分析黑板，诊断网络故障。 ### 6. 当你编码时 When you are coding. - 不要靠巧合编程 Donot program by coincidence. * 意识到自己在做什么 * 不要盲目，理解应用，谨慎使用不熟悉的技术。 * 按照计划行事 * 依靠可靠的事物，不要依靠巧合和假定。 * 为你的假定建立文档 * 不要只是测试你的代码，还有测试你的假定。 * 为你的工作划分优先级。 * 不要做历史的奴隶。如果不再适用，所有的代码都可以被替换。 - 算法速率 * O()表示法 > O()表示法，把O视为“阶为……”(on the order of)，表示对度量的事物的值设置了上限。 * O(1) 常量型，访问数组元素 * O(lg(n)) 对数型，二分查找 * O(n) 线性型，顺序查找 * O(nlg(n)) 比线性差，但不会差太多，快速排序、堆排序的平均时间 * O(n2) 平方律型，选择和插入排序 * O(n3) 立方型， 2n x n矩阵相乘 * O(Cn) 指数型，旅行商问题，集合划分 * 常识估算 - 简单循环，O(n) - 嵌套循环, O(m*n) - 二分法, O(lg(n)) - 分而治之,O(nlg(n)) - 组合,可能失控，常用启发式方法(heuristics)减少时间 * 估算 > 使用code profiler进行精确估算 - 重构 > 不要在重构的同时增加功能 > 在开始重构前，保证拥有良好的测试。 > 才去短小、深思熟虑的步骤。 - 易于测试的代码 * 测试装备(test harness) 应具有的功能： - 用以指定设置与情理(setup and cleanup)的标准途径 - 用以选择个别或所有可用测试的方法 - 分析输出是否是预期结果的手段 - 标准化的故障报告形式 * 构建测试窗口 部署后的软件包含跟踪消息的日志文件，可用在运行时显示状态信息，通过“热键”开启，最终用户不知。 - 邪恶的向导 不要使用不理解的IDE向导代码，Dont use wizard code you dont understand. ### 7. 在项目开始之前 Before the project. ### 8. 注重实效的项目 Pragmatic projects. - 无处不在的自动化 * 项目编译 makefile, 脚本化、自动化。生成代码，自动运行回归测试。用一条命令完成签出、构建、测试和发布。 * 构建自动化 1. 从仓库中签出代码 2. 从头开始构建项目，典型情况下从顶层的makefile开始。每次构建都会标注版本号或日期戳。 3. 创建可分发映像。确定文件所有权和权限，严格按照发运时所需的格式，产生所有的例子、文档、README文件。 4. 运行规定的测试化。 - 无情的测试 Test early, test ofen, test automatically. Coding ainot done till all the tests run. 1. 测试什么 * 单元测试 * 集成测试 * 验证和校验 * 资源耗尽、错误及恢复(内存、磁盘、CPU带宽、挂钟时间、磁盘带宽、网络带宽、调色板、视频分辨率) * 性能测试 * 可用性测试 2. 怎样测试 * 回归测试，确保新代码没有破坏旧代码 * 测试数据。大样本、边界数据、展现特定的统计属性的数据。 * 演练GUI系统 * 对测试进行测试。通过“蓄意破坏”测试你的测试。Use saboteurs to test your testing. * 彻底测试。测试状态覆盖，而不是代码覆盖。Test state coverage, not code coverage. 3. 何时测试 频繁进行测试，不要等到最后。 如果bug绕过了现有的测试网，你需要增加新的测试。Find bugs once. - 全都是写 把代码与文档紧密的结合在一起。Build documentation in, dont bolt it on. Treat english as just another programming language. * 注释 > 注释应用于讨论为何要做某事、它的目的和目标。DRY

作为程序员要对自己有严格色要求：破窗理论. 发现问题快速解决，不留隐患. 不要因为一个污点影响一幅画，保持一致性，最求完美. 能在追求完美的路上适可而止，项目的效率和质量做好平衡.