小土刀

一个满怀热爱的手艺人。无论是文字还是代码,我都想写点不一样的。

【卓越程序员密码】自豪感闪耀

开始为下学期的项目做前期筹备调研,最大的问题不在于具体要怎么做,而是怎么把事情做好。看起来有点玄学,但是这之间的差距只有真正经历过不大成功的项目才能体会得到。厌烦、疲倦、泥沼,可是在项目开始的时候我居然还对自己设计的架构颇有信心,好傻好天真。这本书总结了不少实践得出的经验技巧,站在巨人的肩膀上,才能看得更远吧。


五十个卓越程序员密码,配上作者的亲身经历,让你了解常犯的错误(即使知道了第一次也很难避免,有些坑只能自己爬起来)以及养成优良的习惯(这个是可以现在做起未雨绸缪的)。最重要的,是卓越程序员不可获取的——自豪感。

我认识的大多数程序员甚至不关心开发的是什么或是为谁开发。只要是在解决一个有趣的问题,只要有机会能够优雅地创造一些东西,他们就感到满意。将一个问题条分缕析,然后解决得巧夺天工,这种精神鸦片让程序员不能自拔。

我们之所以开发和设计软件,是因为我们真的热爱做这个,无论这种感情是溢于言表还是藏在内心深处。我认识的最优秀的程序员会不断雕琢每一个开发决定,有时甚至是无关紧要的开发决定。正如那些建筑工人一样,我们并不仅仅是写代码,而是要把代码写好。

对热爱这份工作的人来说,工作并不仅仅是为了挣钱。更容易的挣钱方法也有。这个职业完全是我们自己的选择。我们用代码创造奇迹,让梦想驰骋,苦心建造,然后指点江山。

这里挑选一些我深有体会的错误以及下个项目需要开始养成的习惯,与诸君共勉。

  • 发行不过是第1版

上一个项目一直执着于第一版就是一个高质量的版本,以至于每次交付都成了一场灾难。灾难的意思是,交出去的系统因为时间关系几乎只能在很小可行域中运行,我对自己不满意,客户对我们不满意。

现在想想,如果一开始就以逐步细化的模式进行快速迭代推进,先出原型,试错改进,恐怕整个的开发节奏会比原来的好很多。虽然看了不少项目管理的书,但是还是掉到坑里——纸上得来终觉浅啊。

  • “象牙塔”架构师的传说

纯粹的技术架构师可能构思的是最优的构架、最优的设计模式或是最佳实践什么的。但是,只有亲自上手,埋头在代码里的时候,他们才能了解真正的难点在哪里。常常是真正做实现的人才能最清楚地看到前面的障碍。

之前模仿网络 ISO 分层结构设计的系统架构,在实际开发过程中,遇到了各种各样的问题。因为项目开始的前后台代码都是我一个人来写,加上时间紧,所以并没有严格按照分层逻辑去写,各层的接口没有统一,有些甚至为了省事儿直接跨层访问,这也导致了原来所谓“最优”的架构变成了“最糟糕”架构。

  • 扔掉旧代码

不要把代码囤积在注释里,删除代码可以让代码库精简。眼前的页面应该精确地反映出软件现在的工作方式,一分不多,一分不少。现在就扔掉旧代码,在编程中间就不用跳过一堆不相干的垃圾字节。我们以后也用不着去琢磨,这一大团已经注释掉可看起来还很重要的代码,到底还是不是那么重要。

  • 从喜欢处入手

有时候,最难找到动力的地方就是最开始。光是想想编码是很容易的,软件在我们脑子里面编译的时候都完美极了,我们不会纠结于将要面对成百上千个小障碍。可一旦真的动手写起来,就完全是另外一码事了,激情很快就会消退。

Natalie Goldberg的Writing Down the Bones 一书从头至尾都在讲写作者的动力。她给了一个入手小提示,即不要去想什么宏大的开篇,而是从故事的中间找个地方开始写,从最有意思的地方开始,并且立即开始,不要试图从头写起。

  • 早起先测试

早起上班第一件事:测试你的软件。这是你最清醒、最有动力写点好东西的时候。在一天的工作中,我们花了那么多力气去写代码,根本没精神再去挨段测试了。一天下来,会越来越难以统览全局。到了傍晚,人已经沉浸在这个软件中了。疲惫令我们无法判断什么有道理或是直觉上正确,还会让我们漏掉一些细节。

  • 设定一个最后期限,即使是随便设的

虽然它一点都算不上创新,但制定了最后期限,工作才得以完成,否则产品永远难见曙光。最后期限提升了工作的重要性。如果让一个项目从几个月拖到几年,你的产品可能就失去开始时所期待的价值了。最后期限创造了一种紧迫感,敦促你冲过终点线。即使没有人在逼迫你,它也能给你所需的鞭策。

  • 限制所有的因素

如果没有限制,无论是时间限制、成本限制,还是功能集限制,我们就会忽略现实,做出有问题的决定,因为没有东西敦促我们做出明智的选择。生产力也就不会放在真正重要的东西上。如果想要开发伟大的软件,请千万要设定并遵守限制。让你走的每一步都朝着创造更成功的软件的方向,因为没有多余的资源去做其他的事情。

  • 去掉时间表中的细节

如果时间表太详细,交付太频繁,开发过程中就没有做试验或是重新考虑细节的余地。我们只能严格遵守根据设想出来的任务所设定的时间表,就好像被一个无知的“微观经理”一直监督着一样。要是有几个小任务没按时完成,整个时间表就轰然坍塌了。这一点也不会激发我们的积极性,好的软件不是这么开发出来的。

  • 每天改进产品的两个方面

“二”这个数字本身也很重要。做一个改进有时候让人为难,因为我们不知道到底选哪个;而且“一”跟“零”也没有多大差别。此外,“一”很容易让我们觉得,今天不做也没什么,可以明天再补上。反过来,每天做“三”点改进又太多了。所以,“二”才是那个神奇的数字。

  • 提高生产力,避谈“我们”

在高效的团队开发中,明确责任很重要。是的,知道谁负责哪一块很关键,但知道谁不对那一块负责也很重要,他们有其他的责任要承担。当你和同事或客户沟通的时候,特别是开会和写邮件的时候,改掉那种说“我们”的习惯,要明确地说出“谁”。你把问题指向某个人的时候,人们就会行动了。


很多似曾相识的错误,很多对应改进的方法。上一个项目是好是坏都已经结束,这次要重新出发,走的更远。

我不害怕犯错,我害怕的是失去犯错的勇气,庸庸碌碌度过一生。

评论
热度(8)

© 小土刀 | Powered by LOFTER