10.27 程序员修炼之道读后感_3
前言
- 编程不存在某种最佳解决方案，我们应该注重失效，在拥有足够广博的背景和经验基础上，以保证能在特定情况下选择好的解决方案。
- 背景源自对计算机科学的基本原理理解，经验来自广泛的实际项目。
第1章 注重实效的哲学 1
1 我的源码让猫给吃了 2
- 诚实面对我们的无知和错误
- 在做某件事情时除了尽你所能外，必须分析风险是否超过你的控制。对于不可能做到的事情或者风险太大，你有权不去为之负责。
但是一旦承诺某件事完成，同意为某个结果负责就必须承担其责任。 - 当自己犯错误的时候，诚实承认它，并设法提供各种选择。不要责备别人或东西，或是拼凑借口。
在跟别人说做不到之前请先把自己的辩解说给猫听，看看是否合理还是愚蠢。你的老板听来又是怎样？
2 软件的熵 3
- “不能容忍破窗户”
- “破窗户”：低劣的设计，错误的决策或者糟糕的代码
- 没时间修理的对策：用木板把它钉起来-加入注释 加入TODO 用虚设的数据加以替代。
3 石头汤与煮青蛙 5
- 知道某件事情是对的，但是涉及到其他人，为了对抗漠然和拖延，就需要欺骗，让同事们开始在路上，那么我们离成功就不远了。
- 煮青蛙：避免拖延和偏离设计，这会导致如青蛙一样被煮熟。
4 足够好的软件 8
- 足够好的软件时满足用户的需求，所以必须让用户参与权衡
- 知道何时止步：不要在过度修饰和过于求精中损坏完好的程序，迷失其中。
5 你的知识资产 10
-
知识资产：所知的关于计算机技术和所工作的应用领域的全部事实以及他们的所有经验视为他们的知识资产。
-
经营资产
- 定期投资：具体见示范目标
- 多元化：你知道的不同的事情越多，你就越有价值。由于计算机技术变化很快，所以掌握的技术越多，越能更好的进行调整，赶上变化
- 管理风险：高风险高回报 低风险低回报
- 低买高卖：靠自己的判断了
- 重新评估和品和平衡：评估当前用户的技术，为适应市场变化或者职位需求是否需要学习新的东西。
-
示范目标
- 每年至少学习一种新语言
- 每季度阅读一本技术书籍
- 也要阅读非技术书籍。记住计算机是由人使用的。
- 上课
- 参加本地用户组织：主动参与了解公司以外的人在做什么，不要与世隔绝
- 试验不同的环境
- 跟上潮流
- 上网
-
学习的机会：
- 不懂可以问人
-
批判的思考：警惕唯一的答案，批判的分析听到的和读到的。
6 交流 14
- 知道自己想要说什么：规划你想要说的东西-》写出大纲-》问自己“这是否讲清了我想要说的内容”-》提炼-》直到确实如此
- 了解自己的听众：
- 面对不同的听众，讲出他们感兴趣的东西。
- 你想要听众知道什么
- 他们对你讲的什么感兴趣
- 他们的知识背景是什么
- 你想要谁拥有这些信息
- 他们想要多少细节（程度）
- 你如何促使他们听你的话。
- 选择时机：合适的时机事半功倍
- 文档除了内容形式上的美观也至关重要。
第2章 注重实效的途径 19
7 重复的危害 20
DRY：don't repeat yourself
强加的重复：
- 信息的多种表示：在编码一级，信息需要在不同平台（客户端和服务端）上表示，即使是在客户端不同语言的表示也会带来重复。解决方法：编写代码生成器，针对文本生成不同语言平台的代码。 尽量让低级的知识放在代码中，将注释保留给其他高级说明，否则一旦代码修改，注释就得一并修改。
- 文档与代码：有些东西改变就得修改文档和代码，所以有能力的话建立文档到代码的生成机制。
- 语言问题
无意的重复：原因来自信息结构的不规范，一旦发现多个相互依赖的数据元素时，就需要考虑去重复的问题
无耐性的重复：懒
开发者之间的重复：通过高层设计避免
8 正交性 25
正交性：两条直线相交成直角，两条直线互不依赖， 沿着某条直线移动，投影到另外一条直线上的 位置不变
正交的好处：
- 提高效率
- 修改得以局部化，开发和测试时间得以降低
- 促进复用，当组件有明确具体的职责，就可以与设计时未想到的新组件在一起。
- 降低风险
- 问题代码区被隔离开来，不会 扩散到其他部分
- 所得系统更健壮
- 测试更容易
怎么做 - 项目团队管理
- 设计：设计时思考如果我显著改变某个特定功能背后，有多少模块会受影响。
- AOP：面向方面编程：可以让我再一个地方表达本来会分散到源码各处的某种行为
- 编码：
*让代码保持解耦 羞怯代码，Law of Demeter- 避免使用全局数据
- 避免编写相似的函数（《重构》《设计模式》中提到策略模式）
- 构建单元测试不仅因为它比集成测试更容易规定和进行，还因为其 本身也是对正交性的一项测试
- 认同正交性，就要时刻记住运用DRY原则，寻求系统中重复降至最小；
9 可撤消性 33
不存在最终决策
为了达到可撤销性：需要灵活的架构，使用项CORBA技术能够将项目某些部分与语言分割开来。
10 曳光弹 36
先动手，然后观察各种反馈，立即改进
曳光开发与项目永不会结束的理念是一致的：总有改动需要完成，总有功能需要增加。这是一个渐进的过程。
曳光开发其实大家或多或少都在参与。新项目创建时搭建框架代码，逐渐为框架添加功能正是这样一个过程。我们会在框架中让关键流程能够运行，以检验新技术
曳光开发和原型模式有明显区别。原型中的代码是用过就扔的，寻求以最快的速度展示产品，甚至会采用更高级的语言。曳光代码虽然简约，但却是完成的，它拥有完整的错误检查与异常处理，只不过是功能不全而已。
优点：
- 用户能够及早看到能工作的东西
- 开发者构建了一个他们能再其中工作的结构
- 有了一个集成环境
- 有了用于演示的东西
- 感知工作的进展。
曳光代码vs 原型制作
-
原型开发
- 有一个非常重要的前提：你写的这段代码，将一定会被遗弃！如果不满足这个条件，请不要使用这种方法，否则会出现很悲惨的事情。既然是一个原型，那么我们可以考虑使用更加简单的方法来实现他。比如C#或者java？或者使用一些项目不建议使用的库来简化开发？甚至直接用黑板，将你的想法画出来？这样你不但能很快让大家看到一个基本的效果，还能减少不少的开发量。在原型中也不要担心效率问题，实现的优不优雅等等因素，因为请谨记：你的这段代码将被丢弃。所以请放心大胆的在上面实验你的各种想法吧。
-
曳光弹
- 一旦使用原型找到合适的方向了之后，我们就可以将原型抛弃而转入曳光弹的开发了，这也是这两种开发模式本质的区别。在曳光弹开发时，你可以为产品或特性想一个较为合适的实现了，搭建一个足已支撑项目的框架，然后开始慢慢进入正常的产品开发迭代：完成一定的功能，交付使用，根据反馈再继续修改这部分功能……直到最终成型并交付。
作者：白桦叶
链接：https://www.jianshu.com/p/18ebc4747386
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
