当前位置 > it书童 > 读书笔记 > 正文
推荐小册
java高效编程
怎样更高效地用 java 编程

juc并发工具库
java并发编程工具库

设计模式
设计模式

jvm调优
jvm调优

rabbitmq实战
rabbitmq实战

redis实战
redis实战

Keepavlied高可用集群
Keepavlied高可用集群

nginx入门到实战
nginx入门到实战

java调试
java调试中遇到的各种坑

java输入输出流
java输入输出流

高效程序员的45个习惯

读书笔记 it书童 2019-10-04 09:41:33 0赞 0踩 971阅读 0评论

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

敏捷开发宣言:一种把以人为本、团队合作、快速响应变化和可工作的软件作为宗旨的开发方法

烂代码是有传染性的,当你写下烂代码后,别人很可能会参照你的写法,尤其是对这块业务不熟悉的同事,甚至会以你的写法作为标准参照依据。自己写的代码,一定要保证其质量是可靠的,而不是乱七八糟,未经完全测试的,逻辑混乱的代码,不要以“后面再来优化”的理由让自己心安理得的提交烂代码。事实上,除非出了bug,很多时候,我们懒得再去看以前的代码。 如果你不想三个月后的自己看着以前写的代码,暗骂:“是哪个混蛋写的垃圾”,那么就不要让烂代码提交到生产环境。即便有时你想不出更好的写法,也要备注清楚这么写的原因。

敏捷开发就是在一个高度协作的环境中,不断地使用反馈进行自我调整和完善

在功能不变的情况下,重新设计部分代码,改善代码的质量。这就是所谓的重构,它是软件开发中不可或缺的一部分--编码永远没有真正意义上的“结束”。

程序员接到自己感到不合理的需求的心理活动:这又是哪个傻逼产品经理想出来的,完全没意义嘛,唉,随便实现就行了,只要表面上能运行就得了。反正代码写得怎么样,他们也不懂

为了节省项目的时间而走愚蠢的捷径是会付出巨大代价的。

所有的捷径最后都会被证明是走弯路。软件开发,有方法,但没有侥幸的捷径

反馈是敏捷的基础。一旦你意识到走错了方向,就要立即做出决策,改变方向

归咎于人并不代表问题就解决了。 出现问题,第一要义应该是解决问题。而不是推诿责任。不能两手一摊:"这不是我写的代码“,然后就置身事外。

如果你说的话只是让事态更复杂,或者只是一味地抱怨,或者伤害了他人的感情,那么你无意中在给总是火上浇油。

在敏捷的团队中,大家的重点是做事。你应该把重点放在解决总是上,而不是指责犯错者上面纠缠。

世上最糟糕的工作就是和一群爱搬弄事非的人共事。他们对解决问题并没有兴趣,相反,他们爱在别人背后议论是非。他们挖空心思指手画脚,议论谁应该受到指责

喜欢敏捷开发的文化,就要先把自己培养成一个敏捷开发者。对事不对人,遇到问题,第一要义是商议如何解决问题,让自己参与到问题解决中,而不是去指责或抱怨。 耍嘴炮总是容易的,但bug并不会因此而自动修复好

如果你没有犯过任何错误,就说明你可能没有努力去工作

优秀的程序员不会允许自己负责的业务中有自己看不懂的代码,哪怕只是一行代码。因为这意味着极大的不确定性,软件开发中,任何侥幸心理都不应该有

”那块代码,我们都看不懂,但神奇之处就在于生产环境能跑起来。总之,别去动这块代码,不然可能会引发什么问题,谁也说不清楚”。

只要我们继续进行快速修复,代码的清晰度就不断降低。一旦总是累积到一定程度,清晰的代码就不复存在,只剩一片混浊。很可能在你的公司就有人这样告诉你:“无论如何,千万不能碰那个模块的代码。写代码的哥们已经不在这儿了,没有人看得懂他的代码。”这些代码根本没有清晰度可言,它已经成为一团迷雾,无人能懂。

在项目中,代码应该是很亮堂的,不应该有黑暗死角。你也许不知道每块代码的每个细节,或者每个算法的每个步骤,但是你对整体的相关知识有很好的了解。没有任何一块代码被警戒线或者“切勿入内”的标志隔离开。

实行代码复审,不仅有助于代码更好理解,而且是发现bug最有效的方法之一

结队编程的好处之一:避免写出只有一个人能看懂的代码。 事实上,不少程序员写代码时思路就不清晰,虽然最终能实现功能,但其中的逻辑十分混乱,要理解其思路,其难度还大于重写。 如果有代码复审,至少能避免这种情况。 只有自己能看懂的代码,就如同只有自己能读懂的文章一样,都是垃圾

如果没有人来复审你的代码,就自己复审自己的代码,每天一早第一件事就是复审昨天写的代码

你必须把重点放在解决总是上,而不是去极力证明谁的主意更好。在团队中,一个人只是智商高是没有用的,如果他还很顽固并且拒绝合作,那就更糟糕。

解决问题才是宗旨,谁对谁错不重要,一旦带有情绪化,就会产生敌对

你不需要很出色才能起步,但是你必须起步才能变得很出色

写代码时发现其他同事写的代码很难理解,甚至排版格式都错了,这时要怎么做? 置之不理,因为不想有纠纷,这是大多数人的做法。 可这样只会让代码越来越差,直接修改代码,会有顾忌,而且可能自己改写后引入了新的bug。

迭代和增量式的学习。每天计划用一段时间来学习新技术。不需要很长时间 ,但需要经常进行

跟踪技术变化。你不需要精通所有技术,但需要清楚行业的动向,从而规划你的项目和职业生涯

避免在一时冲动的情况下,只是因为想学习而将应用切换到新的技术、框架或开发语言。在做决策之前,你必须评估新技术的优势。开发一个小的原型系统,是对付技术狂热者的一剂良药。

原来的知识与经验一方面能有助于我们更好地理解新技术,同时也会成为我们更深入理解的阻碍。 php学会了,再学python, 很容易理解语法,能马上就写出可运行的python程序,但写出来的python却是php风格的

工作要有节奏感,写了一半的代码,没有经过任何测试,这种代码是不应该提交的。 要将自己的开发任务切割成各种小模块,细化到单元测试,经过测试的代码才能提交。

小而可达到的目标会让每个人全速前进

即使所在的团队没有用敏捷开发方式,自己也可以运用。先让自己成为一个敏捷开发者,再将理念传播。 当自己能很好地践行敏捷开发时,有上进心的开发人员自然会跟上

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

如战争的指挥:把那座山头打下来是正确的方针。因为战略位置很重要。但不可能去精细设计每一步攻击的流程,细化到每个人该如何开枪

“简历驱动设计”:之所以选择这个技术,是因为它很美,也许还能提高程序员的技能。但是,盲目地为项目选择技术框架,就好比是为了节省税款而生孩子,这是没有道理的

冻结需求是极其可笑的,只是一个掩盖自己无能的蹩脚借口罢了。 需求变动是正常的,但程序员应该在需求确定之前进行充分沟通,尽可能理解客户最终想要的产品是怎样的。如果只是把自己当成一个实现需求的工具,而不参与到需求的讨论中,那就是在自讨苦吃

现实中的需求就像是流动着的油墨,你无法冻结需求

开发人员与需求方的关系: 现实中很多是这样的:开发人员以为自己理解了需求,闷头开始写,时隔一个月,终于完成了。需求人员以为开发人员一切都明白了。就等着项目上线,可最终的成品一测试,连业务逻辑都错了。几乎要重写。这种代价是极其沉重的。而且也会让开发人员与需求方的矛盾加剧。 良好的关系应该是:开发人员一边开发,一边部署,需求人员可以很明确地看到产品是如何在完善的。一旦偏离了轨迹,及时修正。这种才是良好的互动。 开发与需求之间的沟通:彼此真的理解了对方的想法了吗?

迭代开发是,在小且重复的周期里,你完成各种开发任务:分析、设计、实现、测试和获得反馈,所以叫作迭代。

对付大项目,最理想的办法就是小步前进,这也是敏捷方法的核心。大步跳跃大大地增加了风险,小步前进才可以帮助你很好地把握平衡

关于我
一个文科出身的程序员,追求做个有趣的人,传播有价值的知识,微信公众号主要分享读书思考心得,不会有代码类文章,非程序员的同学请放心订阅
转载须注明出处:https://www.itshutong.com/articles/40/45-habits-of-efficient-programmers