美文网首页
读书笔记 - 《高效程序员的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