高效程序员的45个习惯 敏捷开发修炼之道 读书笔记 第二章 态度决定一切

之前看过类似的书很快就忘了,这样的书,真正上班加入实际的项目开发中才有真正的感同身受。

切身体会。

 

做事

blame doesn‘t fix bugs。

在我们项目中出现问题的时候,经常容易不把解决问题放在最优先级,而是指责犯错者上面的纠缠,如果你说的话会让事态更复杂,这无疑是在问题火上浇油,宁可不说出这样的话

我们要问问自己为了解决这个问题,我能够做些什么。

真实场景,当项目中的员工未能按照约定的时间完成工作的时候,

我们更多是需要如何帮助他完成,而不是指责他效率比较低说这样伤人的话。

永远不要在会议中说出伤人的话,指责不会修复bug。

 

如果大部分团队成员(特别是开发领导者)的行为都不职业,你就应该主动从这个团队中离开,寻找更适合自己发展的团队。

真实场景,领导只会画大饼,只会告诉你这个完成这个项目很简单,只需要学习XX技术就可以了,而无法给你更多帮助,或者领导层已经混乱了,无法确定项目的进展,

你就应该离开,这是一个有远见的想法,没必要眼睁睁地看着自己陷入一个“死亡之旅”的项目中。

 

欲速则不达 Beware of land mines 防微杜渐

千里之提溃于蚁穴,一次又一次的快速修复,每一次都不探究问题的根源,久而久之就形成一个危险的沼泽地,最终会吞噬整个项目的生命。

不要坠入快速的简单修复之中,要投入时间和精力保持代码的整洁、敞亮,说明谁是优秀程序员,谁是拙劣的代码搬运工。

真实场景,我们经常会遇到这种情况,出现了一个bug,快速修复确实可以解决他,只要新加一行代码或者注释掉某行,它就可以工作,但是我们这样不假思索的改完代码真的好?

这样+1,-1的操作会留下隐患。

 

代码复审,不要让开发人员完全孤立地编写代码,花点时间确保团队成员写的代码是可读和可理解的。

场景,像公司的需求会议评审、功能实现评审、代码评审,这些真的能很好发现自己代码的问题,不要害怕自己出错,而应该积极的记录错误,并完善问题所在。

我们写的代码更多的是让别人能看明白和理解,而不是只有自己明白。

 

单元测试,帮助你自然地把代码分层,分成很多可管理、更清晰、更易于理解的小块(待续)

 

对事不对人

巧妙的提出问题,避免尴尬,

那样做很蠢(否定个人能力)

那样很蠢,你忘记考虑他要线程安全(之处明显的缺点,并否定其观点)

谢谢,先生,但是我想知道,如果两个用户同时登陆会发生什么情况(询问你的队友,并提出你的顾虑)

第三种方式还能巧妙避免是自己理解错误的尴尬, 

 

排除万难,奋勇前进

当发现问题时,不要试图掩盖这些问题,而要有勇气的站起来,不是向别人抱怨代码有多么糟糕,而是给出相应的解决方案,重写原因,重写优点等等。

往往项目中会发现一些代码无法很好地重用,我们更多的是充满勇气的重构它,而不是复制修改,尽可能减少项目重复的代码。最近在项目中就犯了这样的错误。

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

posted @ 2016-07-26 10:19  郁闷紫番薯  阅读(123)  评论(0编辑  收藏