美文网首页
读书笔记 - 《高效程序员的45个习惯》

读书笔记 - 《高效程序员的45个习惯》

作者: ForestSen | 来源:发表于2018-07-06 20:27 被阅读20次

《所有学习上的成功,都只靠两件事:策略和坚持,而坚持本身就应该是最重要的策略之一》

《难以坚持下去的事情基本上都是因为没有迫切的欲望和激情。坚持一件事,至少要有明确的目的,例如健身,为了减肥,塑形等,这样才能驱使着人们一直坚持下去。没有动机,没有欲望,哪来的毅力呢?》


恶魔:代表错误的想法。
天使:代表正确的想法。


敏捷 ----- 高效软件开发之道

不管路走了多远,错了就要重新返回

很多时候,开发人员发现自己走错路后,却不愿意立即回头,而是抱着迟早会步入正规,或者后期再解决这个事情的时候,这种侥幸心理。

敏捷开发 ----- 由来

2001年的2月,有17名之多的软件工程师在美国犹他州的Snowbird举行会议,讨论一个新的软件开发趋势,这个趋势被不严格地称为:“轻量型软件开发过程”

世界上应该有一种更好的软件开发方法 ---- 只关注真正重要的事情,少关注那些占用大量时间而无甚裨益的重要的事情。

这些志愿者给这个方法取名为敏捷。他们审视了这种新的软件开发方法,并且发布了敏捷软件开发宣言: 一种把以人为本、团队合作、快速响应变化和可工作的软件作为宗旨的开发方法。
这标志着敏捷开发的诞生,这一模式随后被硅谷创业公司大量应用,并于近几年被引入国内,让中国的工程师们有机会接触这一新奇的开发模式。

它要求团队中的每一个人(包括与团队合作的人)都具备职业精神,并积极地期望项目能够成功。它并不要求所有人都是有经验的专业人员,但是必须具有专业的工作态度-----每个人都希望最大可能做好自己的工作。


态度决定一切

1、做事

在出了问题后应该如何做:

恶魔:

出了问题,第一重要是确定元凶,找到那个白痴!

天使:

如果只是一味的抱怨或者上海他人的感情,那么你无疑是在火上浇油。

指责不会修复BUG,把矛头对准解决问题的办法,而不是人。这才是真正有用处的正面效应。

一个重大的错误应该被当作一次学习而不是指责他人的机会,团队成员在一起工作,应互相帮助,而不是互相指责。

在敏捷开发过程成功,如果你向团队中的同事抱怨,他们会说:“好,我能帮你做些什么?”他们把精力直接放在解决问题上,而不是抱怨。

如果你找人帮忙,却没有人积极响应,那么你应该主动引导对话。解释清除你想要什么,并清晰地标明你的目的是解决问题,而不是指责他人或者争辩。


2、欲速则不达

恶魔:

你不需要真正理解那块代码,它只要能工作就行了,不用理解它,凑合开发就行了,反正也没人管。

我们经常会遇到这种情况,出现一个bug,时间紧迫。使用打补丁或者临时的方案快速解决。

拙劣的代码工人会这样不加死锁地该玩代码,然后迅速转向下一个问题。

优秀的程序员会挖掘更深一层,尽力去理解为什么这里必须加1,更重要的是他会明白会产生什么其他影响。

天使 :

不要堕入快速的简单修复之中,要投入时间和经历保持代码的整洁、敞亮。

千里之堤-毁于蚁穴,一次又一次的快速修复,每一次都不探究问题根源、代码的清晰度就不断降低。

很可能在你的公司就有人这样告诉你:“无论如何,千万不能碰那个模块的代码。写代码那哥们已经不在这儿,没有人看懂他的代码。” 久而久之形成一个危险的沼泽地,最终吞噬整个项目。


3、对事不对人

天使:

对事不对人,让我们骄傲的应该是解决了问题,而不是比较谁出的主意比较好。

在一个团队中,如果能稍加注意礼貌待人,将会有益于整个团队关注真正的价值,而不是勾心斗角。

如果你准备提出一个想法,却担心有可能被嘲笑,丢面子,那么你就不会主动提出自己的建议了。
然而好的软件开发作品与设计,都需要大量创造力和洞察力。分享并融合各种不同的想法和观点,远胜于单个想法为项目带来的价值。

我们每个人都会有好的想法,和不对的想法,团队中的每个人都需要自由地表达观点。即使你的建议不被全盘接受,也是能对最终解决问题有所帮助,不要害怕受到批评。
任何一个专家都是从这里开始的。“你不需要很出色才能起步,但是你必须起步才能变得出色。”

尽力贡献自己的好想法,如果你的想法没有被采纳也无需生气,不要因为只是想体现自己的想法而拟定的好思路画蛇添足。


4. 排除万难,奋勇前进

恶魔:

如果你发现其他人代码有问题,自己心里知道就好了,毕竟你不想 惹来麻烦。

天使:

有时,绝妙的计划会因为勇气不足而最终失败,尽管前方很危险,你必须有勇气向前冲锋,做你认为对的事情。

假如你发现其他人编写的有块代码很难理解也不好使用,你是应该继保留这些脏乱的代码,并跳出来告诉周围的人,那些代码是多么糟糕,但那只是抱怨和发泄,并不能解决问题。
相反你应该重写这些代码,并比较重写前后的优缺点。

动手证明是最有效的方式,把糟糕的代码放到一边,立刻重写。列出重写的理由,会有助于你的老板(以及同事)认清当前形势,帮助他们得到正确的解决方案。

当发现问题时,不要试图掩盖这些问题。而要有勇气站起来。


学无止境

即使你已经在正确的轨道上,但如果只是停止不前,也仍然会被淘汰出局。

逆水行舟不进则退,那不仅是赛马场上的真理,它更适合我们当今的程序员。

软件开发行业是一个不停发展和永远变化的领域。虽然有一些概念一直有用,但还有很多知识很快就会过时。

从事软件开发行业就像是在跑步机上,你必须一直跟上步伐稳步前进,否则就会摔倒出局。


5. 跟踪变化

恶魔:

软件开发行业变化不大,核心的就那些。继续用你熟悉的语言做你的老本行吧,没问题的,也能跟上技术变化的脚步。

天使:

如何才能跟上技术 变化的步伐呢?

  • 迭代和增量式的学习:
    每天计划用一段时间学习新技术,不需要很长时间,但需要经常进行。
    记下那些你想学习的东西,例如当你听到一些不熟悉术语或短语时,简要地记录下载,然后在计划的时间中深入研究它。

  • 了解最新行情:
    互联网上有大量关于学习新技术的资源,选择一些优秀的技术博客,经常去读一读。

  • 参加活动,会议:
    计算机大会,研讨会,技术社区会等。

  • 阅读:
    找一些关于软件开发和非技术的好书,也可以是一些专业的期刊和商业杂志等。

  • 你不可能精通每一项技术,但需要清楚知道行业的动向,从而规划你的项目和职业生涯。

  • 只要你在某些方面成为专家,就能使用同样的方法,很容易成为新领域的专家。


6. 对团队投资

恶魔 :

不要和别人分享你的知识 --- 自己留着,你是因为这些知识而成为团队中佼佼者,只要自己聪明就可以了,不用管其他失败者。

不要和别人分享你的知识 --- 万一自己分享的是错误的,丢脸了怎么办,是吧。

天使:

通过分享不但可以让自己对知识了解更透彻,也能帮助到别人。


7. 懂得丢弃

在学习一门新技术的时候,多问问自己,是否把太多旧的态度和方法用在了新技术上。

打破旧习惯很难,更难的是自己还没有意识到这个问题。丢弃的第一步,就是要意识到你还在使用过时的方法,这也是最难的部分。另一个难点就是要醉倒真正的丢弃旧习惯。思维定式是经过多年摸爬滚打才构建成型的,已经根深蒂固,没有人可以很容易就丢弃它们。

在学习一门新技术的时候,要丢弃会阻止你前进的习惯。毕竟,汽车要比马车车厢强的多。

8. 打破砂锅问到底

恶魔 :

接受别人给你的解释。别人告诉你问题出在什么地方,你就去看什么地方。不需要再浪费时间追根究底。

天使:

不能满足别人告诉你的表面现象,要不停地提问直到你明白问题的根源。


9. 把握开发节奏

恶魔:

随意安排工作计划,是比较好的,有利于方便开发。

天使 :

在许多不成功的项目中,基本都是随意安排工作计划,没有任何的规律.

解决任务,在事情变得一团遭之前,保持时间之间稳定重复的间隔,更容易解决常见的重复任务。


交付用户想要的软件

  • 提早集成,频繁集成

10. 让客户做决定

天使:

让你的客户做决定。开发者。经理或业务分析师不应该做业务方面的决定。用业务负责 人能够理解的语言,向他们详细解释遇到的问题,并让他们做决定。

记录客户做出的决定,并注明原因。好记性不如烂笔头。可以使用工程师的工作日记或日志、wiki 、邮件记录或者问题跟踪数据库。

如果业务负责人回答"我不知道",也许是他们还没有想那么远,只有看到实物才能评估出结果。尽你所能为他们提供建议,实现代码的时候也要考虑可能出现的变化。

11. 让设计指导而不是操纵开发

恶魔:

代码工人不需要做任何决定,只要简单地把设计转化成代码就可以了。

天使:
  • 设计满足实现即可,不必过于详细
    如果设计师们把自己的想法绘制成精美的文档,然后把它们扔给程序员去编码,程序员会在压力下,完全按照设计或者图画的样子编码。
    就作者本人而言,没有一个愿意在这样的团队中做纯粹的打字员。

  • 战略级别的设计不应该具体说明程序方法、参数、字段和对象交互精确顺序的细节。
    良好的战略设计应该扮演地图的角色,指引你向正确的方向前进。

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

12. 合理地使用技术

恶魔:

你开始了一个新项目,在你面前有一长串关于新技术何应用框架的列表,这些都是好东西,你都需要,并给还能在简历上留下漂亮的一笔。

天使:

当你在考察一个框架(或任何技术)的时候,也许会被它提供的各种功能吸引。但是你真的需要这些功能吗,这很想站在结账处一时冲动而买些无用的小零碎。

如果你发现自己在做一些花哨的东西,那就应该认真评估下,是否值得去做。

比如,使用后是否被栓住了,一些技术是贼船,一旦你使用了它,就会被它套牢,很难回头。

比如,维护成本是怎样,会不会随着时间的推移,它的维护成本会非常昂贵。

根据需要选择技术,首先决定什么是你需要的,接着为这些具体的问题评估使用技术。

13. 保持可以发布

天使:

保持你的项目时刻可以发布,保证你的系统可随时编译、运行、测试。

14. 提早集成,频繁集成

天使:

敏捷的一个主要特点是持续开发,而不是三天打鱼两天晒网似的工作,特别是几个人一起开发同一个功能的时候,更应该频繁地集成代码。

代码集成是主要的风险来源,要想规避这个风险,只有提早集成,持续而有规律地进行集成。

15. 提早实现自动化部署。

天使:

有了自动化部署系统后,在项目开发的整个过程中,会更容易适应互相依赖的变化。

这些工作都应该是无形的。系统的安装或者部署应该简单、可靠以及可重复。一切都很自然。

16.使用演示获得频繁反馈

17.使用短迭代,增量发布

魔鬼:

我们为后面的3年制定了漂亮的项目计划,列出了所有的任何和可交付的时间表,只要我们那时候发布了产品,就可以占领市场。

天使:

大部分用户都是希望现在就有一个够用的软件,而不是一年之后得到一个超级好软件。确定使产品可用的核心功能,然后把它们放在生产环境中,越早交到用户的手里越好。

18. 敏捷反馈

小步前进,不停地收集反馈,时刻矫正自己。

24. 倾听用户的声音

魔鬼:

用户就是会抱怨,用户太蠢了,连使用手册都看不懂,它不是一个bug,只是用户不知道如何使用而已。

天使:

每一个抱怨的背后都隐藏一个事实,找出真相,修复真正的问题。
没有愚蠢的用户,只有自大的开发人员。

25. 代码要清晰的表达意图

开发代码时,应该更注重可读性,而不是图自己方便。代码阅读的次数要远远超过编写的次数。

是要编写清晰的而不是讨巧的代码。向代码阅读者明确表达你的意图。

不要明日复明日,如果不现在做的话,以后你也不会做的。

26. 用代码进行沟通

使用细心选择有意义的命名,用注释描述代码意图和约束。注释不能替代优秀的代码。

·#### 27. 动态评估取舍
考虑性能,便利性,生产力、成本和上市时间。
如果性能表现足够了,就将注意力放在其它因素上,不要为了感觉上的性能提升或设计优雅,而将设计复杂化。

·#### 28. 保持简单
开发可以工作的、最简单的解决方案。除非有不可辩狡的原因,否则不要使用模式、原则和高难度技术之类的东西。

29. 编写内聚的代码

让类的功能尽量集中,让组件尽量小。要避免创建很大的类或组件,也不要创建无所不包的大杂烩类,每个类或组件只做一件事,而且要做得很好。

34. 警告就是错误

签入带有警告的代码,就跟签入有错误或没有通过测试的代码一样,都是极差的做法。

35.对问题各个击破

在解决问题的时候,要将问题域与周边隔开,特别是大型应用中。

37. 提供有用的错误信息

提供更易于查找错误细节的方式。发生问题时,要展示出尽量多的支持细节。

41. 成为指导者

分享自己的只是很有趣,付出的同时便有收获。还可以激励别人获得更好的成果,而且提升了整个团队的实例。

给予别人教导,也是提升自己学识的一种方式,并且其他人亦开始相信你可以帮助他们。

42. 允许其他人自己想办法

授人以鱼不如授人以渔,告诉团队成员解决问题的方法,也要让他们知道如何解决问题的思路,这也是成为指导者的一部分。

指给它们正确的方向,而不是直接提供解决方案,每个人都能从中学到不少东西。

43. 代码复查

对于提升代码质量和降低错误率来说,代码复查是无价之宝。如果以正确的方式进行,复查可以产生非常实用而高效的成果,要让不同的开发人员在每个任务完成后复查代码。

45. 及时通报进展与问题

发布进展状况,新的想法和目前正在关注的主题。不要等着别人来问项目状态如何。

相关文章

网友评论

      本文标题:读书笔记 - 《高效程序员的45个习惯》

      本文链接:https://www.haomeiwen.com/subject/sbhsyftx.html