程序员修炼之道：从小工到专家笔记[更新中]

不要接受破窗户
       负责任，提供更多的选择，而不是提供蹩脚的接口
       不要成为弄脏东西的人
       选择两个个破窗户问题讨论和怎样修复
        1，窗户什么时候破的，反应时什么；如果是他人决策或者管理部门指示，我们能做什么

石头汤：抛砖引玉
       用一块石头吸引别人添砖加瓦
       做变化的催化剂
       留心大方向，关注周围发生的事，不仅仅是在做的事

面对客户各种各样的需求
       定义系统的范围和质量作为系统需求的一部分定下来
       质量成为需求问题
       不要过度最求完美无瑕的软件

模块化软件和单体软件
       单体软件质量，花费更少

知识投资者
       多元化，定期投资，长期的知识投资
       保守投资，高风险投资，高回报投资
       低买高卖
       周期性的评估平衡资产
       每年学习一种新的语言
       每季度阅读一本技术书籍
       也要阅读非技术书籍
       上课
       参见本地组织
       试验不同的环境windows,linux，unix
       跟上潮流
       上网
       思想的异花授粉

批判思考
       批判性的分析你所学的知识和经验
       如果你在进行非常详细的实现和编码，旧阅读设计和架构的书
       如果你在进行高级设计，就阅读编码设计的书
       被打量比被忽略好

规划你想表达的东西讲清楚，并提炼你要讲的东西
       会议时
              简略记录下你想要交流的想法，做好几种准备
              了解你的听众的需要，兴趣，能力
              你想让他们学到什么
              他们对你讲的什么感兴趣
              他们经验如何
              他们关注细节吗
              你想要让谁拥有这些信息
       如何让他们听你说的话
              让听众参与
              做倾听者（掌握他们说的话）
              回复他们
              你说什么和你怎样说同样重要

邮件回复
       删除引用
       检查拼写
       格式简单整洁

DRY:系统中的每一项知识都是具有唯一的，无歧义的，权威的表示
don't repeat youself
不要重复你自己

常见的重复
       必要的重复：强加的重复，环境要求重复（知识归档一处）
       无意的重复:没有意识到的重复
       偷懒的重复：干掉他，欲速则不达
       开发者之间的重复：功能模块划分，责任划分，相互交流

应对重复
       项目资料管理，代码复查
       让复用更容易
       代码生成器
       代码需要注释，且注释写给高级代码
       文档，代码自动化
       无意义的重复，不暴露给外面

可撤销性：如果某个想法是你唯一的想法，这是危险的
       不要依赖于一种实现方式
       不存在最终决策，没有浇筑在石头上的决策
       考虑代码，架构，部署，维护，供应商集成的灵活性
       CORBA（Common ObjectRequest Broker Architecture公共对象请求代理体系结构)

用拽光弹找目标(简单的UI工具，集成平台，演示工具，使目标,工作进度可查看)
       原型方法:为最终目标设计界面，算法,业务逻辑，功能迭代
       拽光弹：系统骨架+核心的基础上搭建演示平台

可以为以下事物制作原型
       架构
       已有系统的新功能
       外部数据的结构或内容
       第三方工具或组件
       性能问题
       用户界面

关于原型
       原型不一定需要代码，可以通过流程，UI体现
       原型可以忽略正确性，完整性，健壮性，风格

 

正交性：

　　用于标识某种不相互依赖性或解耦性；如果两个个或多个事物中一个发生变化，不会影响到其他事物，这些事物是正交的；在设计良好的系统中，数据库于用于界面正交，修改界面不影响数据库，切换数据库而不影响界面改动

正交的好处：Eliminate effects between unrelated things(消除无关事物之间的影响)

正交系统提高生产效率
       改动得以局部化，所以开发时间和测试时间得以降低
       正交的途径还能促进复用
       如果你对正交的组件进行组合，生产效率会有相当微妙的提高

正交系统降低风险
       隔离有问题的代码区域，避免问题扩散
       增进系统健壮，局限化你的修改在区域中
       你不会与特定的服务提供者，产品或者平台紧绑在一起

工作中如何应用正交原则
　　项目团队
　　　　有些团队很高效，每个人都知道要做什么，有些团队老是在争吵
　　　　这常常是一个正交性问题，团队的组织的重叠造成成员堆责任感到困惑，每一次开会都要整个团队参与，每一个人都可能收到别人的影响
　　　　一个修改涉及到的人数越多，团队的正交性越差
　　　　提高团队的正交性，更多的取决于项目本身，以及对可变动的区域的分析，以及可以获得的资源
　　　　一般是从基础设施与应用分离的开始分析
       设计
　　       组件/模块设计完之后，问自己：如果改变某个特定功能的需求，有多少模块回收影响；在正交性系统中，是一个
　　       使用组件/模块化/分层的设计正交系统系统；每个模块的实现不依赖于其他模块，模块内的组件划分多个层次，每个层次提供一个抽象
　　工具箱于库
　　       引入工具类时，是否会对代码做出不必要的修改
　　       (AOP)面向切面编程
        编码
　　       保持代码的解耦，不爆露不必要的功能，也不依赖其他模块的实现
　　       避免使用全局数据，使用全局数据，就相当于吧自己与共享数据的其他组件绑在了一起
　　       避免编写相似的函数，那些相似的函数，可以考虑策略模式
　　  测试
　　       当你进行编写代码进行单元测试时，你就会明白你设计的系统和模块的正交性是否合理
　　  认同正交性
　　       运用DRY原则，设计系统时重复键值最小，组件间的依赖降低

领域语言：语言的界限就是一个人的世界的界限
　　       计算机会影响你思考问题额方式，看待交流的方式，每种语言都具有一系列的特性运用
　　       某些情况下，我们可以考虑领域的词汇，语法，语义---语言---实际进行编程
　　       Program close to the problem domain（靠近问题领域编程），有点类似面向问题设计，面向错误设计
　　       Tip:应用有许多用户
　　       具体领域的错误：使用标准的，通用的领域术语错误消息
　　       数据语言与命令语言
　　       数据语言：数据描述语言，数据传输语言
　　       易于开发还是易于维护
　　       权衡扩展性和维护性，选择易于扩展和理解的实现方案，即使实现方式编码难
估算：Estimate to avoid suprises(估算，以避免发生意外)
　　       估算应用，程序，某段代码需要处理的数据量级别，处理的时间长
　　       多准备估算才足够准确
　　              面临的场景是什么样的，对估算的准确性要求
              估算来自哪里，所有的估算都以问题的模型为基础，建模前，先去问处理过这件事的人，在周围找找曾处理过类似问题的人，看看他们是如何解决的，借鉴他们的意见
　　        理解提问内容，确定问题的范围，想问题前先思考问题的范围；需求是有范围的
　　        建立系统的模型 
　　               从整体上理解系统，一个粗略的系统模型，粗略的画面感
　　               建模可以是创造性的，也可以是长期有用的 ；建模过程中会常常发现一些表面上不明显的底层模式和过程
　　               建模会存在不可避免的不精确性
　　         把模型分解成组件
　　               将系统模型往组件级上拆分
                       确定组件的功能和组件之间的关系，参数
　　          给各个组件上的参数指定值
　　          估算，更新你的估算

　　　估算项目进度
　　          Iterate the schedule with the code(通过代码对进度表进行迭代)
　　　　   当被要求进行估算项目进度时说什么
　　          估算，更新你的估算

 

第3章，基本工具

　　工具放大你的才干，你的工具越好，你越是能更好掌握他们的用法，你的生产力就越高

　　用纯文本保存知识：keep knowledge in plain text

　　     Unix哲学，提供锋利的小工具，其中每一样都意在把一件事做好，Unix就是围绕这样的哲学设计的

       Shell

              Use the power of command shells（利用命令shell的力量）

　　　　命令行可以提高你的生产力，投入一些精力去熟悉你的命令行

       编辑器

　　　　Use a Single Editor Well（用好一种编辑器）

　　　　用精一种编辑器，彻底了解他，用于绝大部分的文本编辑获得

　　　　编辑器的自动完成，语法突显，初始化代码和模板

　　源码控制：Alaways use source  code control(总是使用源码控制)

　　调试：没有人能够写出完美的软件

　　　　 调试的心理学

　　　　　　有许多开发者写完实现，会偷懒不调试，或者调试的覆盖范围小

　　　　　　要接受事实，调试是解决问题，一旦出了问题，你躲不开

    　　　　　在技术的竞技场上，发现别人的bug时，应专注于修正问题，而不是指责

　　　　　　Fix the problem, not the blame（要修正问题，而不是指责）

　　　　调试的思维(最容易欺骗的一个人，是自己)

　　　　　　调试之前，忘掉你可能面临的任何项目压力，调试的第一准则

　　　　　　　　Don't Panic（不要恐慌）

　　　　　　面临压力的情况下进行调试时，忘掉这些压力，不要为了迫切急于解决问题而导致在解决过程种出现新的问题或者没发现你的解决方式距离目标还差几步

　　　　　　从何处开始处理bug：

　　　　　　　　查看bug前，先看一下是否可以成功编译通过，不要浪费时间在寻找编译器就可以帮你找到的问题上

　　　　　　　　确保你的代码的代码控制版本是正确的，不是合并，解决冲突，或者未拉取到最新代码导致的

　　　　　　　　和反馈bug的人面谈，从一开始就获取足够全面的场景数据

　　　　　　　　出现bug，先考虑是否是新修改了什么东西导致的

　　　　　　Don't Assume ite -prove it(不要假定，要证明)

　　　　　　　　遇到让人吃惊的bug时，除了修正它，还要确定为什么之前测试或者使用没有出现这个bug

　　　　调试检查列表

　　　　　　1，该问题是底层bug的直接结果，还是只是症状

　　　　　　2，bug是否真的是你的代码造成的

　　　　　　3，如何向同事解释这个问题

　　　　　　4，如果可以代码通过了单元测试，测试是否足够完整？

　　　　　　5，系统其他地方是否存在类似条件/场景的问题