[align=center][img]http://t.douban.com/lpic/s4073509.jpg[/img][/align]

本书和其他的"怎么写好出优秀的程序"的书籍基本没有什么两样. 如果说要有些区别的话, 就是里面添加了一些敏捷的元素.
另外为了说明某个问题, 里面的一些比喻非常有趣.

对于里面一些觉得对自己有益的东东, 做了一些笔记.

你深知怎样才是正确的, 或者至少知道目前的做法是错误的. 要有勇气向其他的项目成员, 老板或者客户解释你的不同观点. 当然, 这并不容易. 也许你会拖延项目的进度, 冒犯项目经理, 甚至惹恼投资人, 但是你都要不顾一切, 向着正确的方向前进.

做正确的事, 要诚实, 要有勇气去说出实情. 有时这样做很困难, 所以我们要有足够的勇气.

不停的问为什么, 不能只满足于别人告诉你表面现象. 要不停地提出知道你问明白问题的根源为止.

问问题, 你有可能会跑题, 问了一些与主题无关的问题. 就好比是, 如果汽车启动不了, 你问是不是轮胎出了问题, 这是没有任何帮助的, 问"为什么", 但是要问到点子上.

"这个, 我不知道"是一个好的起点, 应该由此进行进一步的调查, 而不应该到此戛然而止.

以固定有规律的长度进行迭代, 也许刚开始你要调整迭代的长度, 找到团队最舒服可行的时间值, 但之后就必须要坚持.

好的设计应该是正确的, 而不是精确的, 也就是说, 它描述的一切必须是正确的, 不应该涉及到不正确或者可能会发生变化的细节, 它是目标, 而不是具体的处方.

你依赖单元测试, 如果代码没有测试, 你就会觉得很不舒服, 就像是高空作业没有系安全带一样.

开发代码时, 更应该注重可读性, 而不是只图自己方便, 代码阅读的次数要远远操作编写的次数, 所以在编写的时候值得花点功夫让它读起来更加简单. 实际上, 从衡量标准上来看, 代码清晰程度的优先级排在执行效率之前.

注释有时候是为了帮写的不好的代码补漏.

代码必须明确说出你的意图, 而且必须富有表现力, 这样可以让代码更易于被别人阅读和理解. 代码不让人迷惑, 也就减少发生潜在错误的可能. 一言以蔽之, 代码应意图清晰, 表达明确.

应该让自己或团队的其他任何人, 可以读懂自己一年前写的代码, 而且只读一遍就知道它的运行机制.

解释代码做了些什么的注释用处不那么大, 相反, 注释要说明为什么会这样写代码.

编写代码的时候, 要经常留心可以改进的微小方面, 这可能改善代码的可读性. 也许你会发现可以把一个方法拆成几个更小的方法, 使其更易于测试.

在写几行代码之后, 你会迫切地希望进行一次构建/测试循环, 在没有得到反馈时, 你不想走得太远.

如果你和测试循环花费的时间过长, 你就不会经常运行他们了, 要保证测试可以快速运行.

优雅的代码第一眼看上去, 就知道它的用处, 而且很简洁.

代码几乎总是可以得到进一步精炼, 但是到了某个点之后, 在做改进就不会带来任何实质性的好处了.

当然简单的解决方案必须要满足功能需求. 为了简单那而在功能上妥协, 这就是过分简化了.

假定把所有的衣服都扔到抽屉里, 当需要找一双袜子的时候, 要翻遍里面所有的衣服:裤子, 内衣, T恤等, 才能找到. 这很麻烦, 特别是在赶时间的时候. 现在假定所有的袜子都放在一个抽屉里面(而且是成双放置的), 全部的T恤放在另外一个抽屉中, 其他衣服也分门别类, 要找到一双袜子, 只要打开一个抽屉就可以了.

类也要遵循内聚性, 如果一个类的方法和属性共同完成了一个功能(或一系列紧密相关的功能), 这个类就是内聚性的.

一个更具有内聚性的组件不会有太多导致其变换的原因, 也因此更加稳定.

面向过程的代码取得信息, 然后做出决策, 面向对象的代码让别的对象去做事情.

作为某段代码的调用者, 开发人员绝对不应该基于被调用对象的状态来做任何决策, 更不能去改变该对象的状态, 这样的逻辑应该是被调用对象的责任, 而不是你的. 在该对象之外替他做决策, 就违反了它的封装原则, 而且为bug提供了滋生的土壤.

假定送报男孩来到你的门前, 要求你付给他本周的报酬, 你转过身去, 让送报男孩从你后屁股兜里掏出钱包, 并且从中拿走两美元(你希望是这么多), 再把钱包放回去. 这个过程中, 送报男孩作为调用者应该告诉客户付给他两美元, 他不能探究客户端财务状况, 或者钱包的厚薄, 他也不能代替客户做任何决策. 这都是客户的责任, 而不属于送报男孩. 敏捷代码也应该以同样的方式工作.

要遵循里氏替换原则, 相对基类的对应方法, 派生类服务(方法)应该不要求更多, 不承诺更少, 要可以进行自由的替换, 在设计类的继承层次时, 这个一个非常重要的考虑因素.

记录问题的日志内容:
问题发生的日期
问题简述
解决方案详细描述
应用文章或者网址, 以提示更多细节或相关信息.
任何代码片段, 设置或对话框截屏, 只要他们是解决方案的一部分, 或者可以帮助更深入地理解相关细节.

记录问题的时间不能超过解决问题的时间. 要保持轻量级和简单, 不必达到对外发布式的质量.

要记录团队做出一个重要决策的原因, 否则, 在6~9个月之后, 想要重新回顾决策过程的时候, 这些细节就很难再记得了.

警告即错误

在解决问题时, 要将问题域与周边环境隔离开, 特别是在大型系统应用中.

由于大家都是在团队中一起工作, 每个人都要修改自己的个人编码习惯, 来适应团队的其他成员.

关于站立会议
要保证会议议题不会发散, 每个人都应该回答下述三个问题:
昨天有什么收获?
今天计划要做哪些工作?
面临哪些障碍

只能给予每个参与者很少的发言时间(大约两分钟), 也许要用计时器来帮助某些收不住话头的人, 如果要详细讨论某些问题, 可以在站立会议之后, 在召集相关人员(在回忆中说"我需要跟Fred和Wilma讨论一下数据库"是没有问题的, 但是不要是深入讨论细节.)

一般来说, 在大家到公司之后的半个小时到一个小时之内举行, 是个不错的选择.

每日站立会议的好处:
让大家尽快投入到一天的工作中来
如果某个开发人员在某一个点上有问题, 他可以趁机将问题公开, 并积极寻求帮助.
帮助TL了解哪些领域需要更多的帮助, 并重新分配人手.
让团队成员知道项目其他部分的进展情况.
帮助团队识别是否在某些东西上有重复劳动而耗费了精力, 或者是不是某个问题有人已有现成的解决方案.
通过促进代码和思路的共享, 来提升开发速度.
鼓励向前的动力:看到别人报告的进度都在前进, 会彼此形成激励.

注意事项:
站立会议的时间最多不能超过30分钟, 10~15分钟比较理想.
虽然大多数团队需要每天都碰头, 但是对于小型团队来说, 这样做可能有些过头了, 不妨两天举行一次, 或者一周两次, 这对小团队来说足够了.
如果觉得站立会议是浪费时间, 那可能是大家都还没有形成真正的团队意识. 这并不是坏事, 有利于针对问题进行改正.

最基本的code review列表
代码是否被读懂和理解
是否有任何明显的错误
代码是否会对应用的其他部分产生不良影响?
是否存在重复的代码?
是否存在可疑改进或重构的部分?

代码复查需要积极评估代码的设计和清晰程度, 而不只是考量变量名和代码格式是否符合组织的标准

《高效程序员的45 个习惯》读书笔记相关推荐

  1. 读书笔记 | 墨菲定律

    1. 有些事,你现在不做,永远也不会去做. 2. 能轻易实现的梦想都不叫梦想. 3.所有的事都会比你预计的时间长.(做事要有耐心,要经得起前期的枯燥.) 4. 当我们的才华还撑不起梦想时,更要耐下心来 ...

  2. 读书笔记 | 墨菲定律(一)

    1. 有些事,你现在不做,永远也不会去做. 2. 能轻易实现的梦想都不叫梦想. 3.所有的事都会比你预计的时间长.(做事要有耐心,要经得起前期的枯燥.) 4. 当我们的才华还撑不起梦想时,更要耐下心来 ...

  3. 洛克菲勒的38封信pdf下载_《洛克菲勒写给孩子的38封信》读书笔记

    <洛克菲勒写给孩子的38封信>读书笔记 洛克菲勒写给孩子的38封信 第1封信:起点不决定终点 人人生而平等,但这种平等是权利与法律意义上的平等,与经济和文化优势无关 第2封信:运气靠策划 ...

  4. 股神大家了解多少?深度剖析股神巴菲特

    股神巴菲特是金融界里的传奇,大家是否都对股神巴菲特感兴趣呢?大家对股神了解多少?小编最近在QR社区发现了<阿尔法狗与巴菲特>,里面记载了许多股神巴菲特的人生经历,今天小编简单说一说关于股神 ...

  5. 2014巴菲特股东大会及巴菲特创业分享

     沃伦·巴菲特,这位传奇人物.在美国,巴菲特被称为"先知".在中国,他更多的被喻为"股神",巴菲特在11岁时第一次购买股票以来,白手起家缔造了一个千亿规模的 ...

  6. 《成为沃伦·巴菲特》笔记与感想

    本文首发于微信公众帐号: 一界码农(The_hard_the_luckier) 无需授权即可转载: 甚至无需保留以上版权声明-- 沃伦·巴菲特传记的纪录片 http://www.bilibili.co ...

  7. 读书笔记002:托尼.巴赞之快速阅读

    读书笔记002:托尼.巴赞之快速阅读 托尼.巴赞是放射性思维与思维导图的提倡者.读完他的<快速阅读>之后,我们就可以可以快速提高阅读速度,保持并改善理解嗯嗯管理,通过增进了解眼睛和大脑功能 ...

  8. 读书笔记001:托尼.巴赞之开动大脑

    读书笔记001:托尼.巴赞之开动大脑 托尼.巴赞是放射性思维与思维导图的提倡者.读完他的<开动大脑>之后,我们就可以对我们的大脑有更多的了解:大脑可以进行比我们预期多得多的工作:我们可以最 ...

  9. 读书笔记003:托尼.巴赞之思维导图

    读书笔记003:托尼.巴赞之思维导图 托尼.巴赞的<思维导图>一书,详细的介绍了思维发展的新概念--放射性思维:如何利用思维导图实施你的放射性思维,实现你的创造性思维,从而给出一种深刻的智 ...

  10. 产品读书《滚雪球:巴菲特和他的财富人生》

    作者简介 艾丽斯.施罗德,曾经担任世界知名投行摩根士丹利的董事总经理,因为撰写研究报告与巴菲特相识.业务上的往来使得施罗德有更多的机会与巴菲特亲密接触,她不仅是巴菲特别的忘年交,她也是第一个向巴菲特建 ...

最新文章

  1. redis重启会清除数据吗_从零开始手写 redis(三)内存数据重启后如何不丢失?...
  2. Python开发Day03
  3. Kafka团队修改KSQL开源许可,怒怼云厂商
  4. 全球及中国磁性分离滑轮行业竞争战略及未来产销需求预测报告2022版
  5. squid之反向代理服务器
  6. Nacos(六)之Spring Boot集成
  7. JAVA实现把指定文件夹下的所有文件压缩成zip包
  8. 每一个程序员都是自学成才?
  9. 浅谈Java设计模式
  10. Search in Rotated Sorted Array
  11. spring boot 全局异常处理的实现(@ExceptionHandler),以及@InitBinder、@ModelAttribute的作用
  12. 感知机(Perceptro)二分类算法原理学习小结记录
  13. [Linux] ubuntu 安装 Wireshark
  14. 计算机操作系统|汤小丹|第四版|习题答案(五)
  15. 单维度量表验证性因子分析_探索性因子分析(EFA)和验证性因子分析(CFA)
  16. 【完结】囚生CYの备忘录(20220525-20220813)
  17. Big Endian 和 Little Endian 详解
  18. 手动实现循环神经网络RNN,神经网络rnn是什么意思
  19. pycharm背景色和字体设置
  20. 简单的美团-web前端页面

热门文章

  1. 1044 mysql_Mysql的常见几种错误:1045,1044
  2. ldc-uni-cli发布
  3. 数据要素市场的发展及运行
  4. 业财一体化升级设计说明
  5. 打造高效能团队之测试能力提升
  6. 寻迹Arduino智能小车
  7. 低成本营销有哪些策略 分享总结的营销方式思维导图
  8. JavaScript:使用Canvas绘图
  9. Docker上部署SpringBoot项目并推送镜像到Docker Hub上---以MacOS为例
  10. 丽思·卡尔顿:是如何创造出忠诚顾客人均120万美元的终身消费的?