我们觉得,如果你不关心怎么把软件开发好,那么软件开发领域就再也没什么好谈的事情了。
为了成为一名务实的程序员,我们要求你在做事的时候,思考一下自己正在做什么。这不是对当前实践做的一次性审计——而是对每天里每一个项目所做的每一个决定进行的批判性评估。不要用自动辅助驾驶系统偷懒,而是要不断地思考,即时地批判自己的工作。IBM 公司的座右铭“思考!”,实属每个务实程序员的真言。
伟大的草坪需要每天的点滴护理,伟大的程序员也是如此。管理顾问喜欢在谈话中抛出“改善(Kaizen)”这个词。“改善”是一个日语术语,意思是不断地做出许多小的改进。这被认为是日本制造业生产率和质量大幅提高的主要原因之一,并被全世界广泛效仿。改善也适用于个人。每一天都要努力打磨你的技能,并往技能库里添加新的工具。与伊顿草坪不同,你会在几天内就看到效果。几年下来,你会对成果惊讶不已——经验业已开花结果,技能早就茁壮成长。
务实的程序员的特质是什么?是他们面临问题时,在解决方案中透出的态度、风格及理念。他们总是越过问题的表面,试着将问题放在更宽泛的上下文中综合考虑,从大局着想。毕竟,若不去了解来龙去脉,结合实际如何谈起?又怎能做出明智的妥协和合理的决策?
了解所做工作的来龙去脉有一个好处,那就是更容易把握软件必须做到多好。接近完美往往才是唯一的选项,这通常需要做许多折衷方案。我们将在够好即可的软件中展开。
你的工作环境很糟糕?你的工作很无聊?尝试纠正它。不过,不要一直试下去。正如Martin Fowler 说的,“你可以去改变组织,或是让自己换一个组织。
”如果你的技术过时了,安排时间(你自己的时间)学习一些看起来有趣的新东西。这是一种自我投资,只有为此而加班才是合理的。
想远程工作?要求过了吗?如果他们说不行,就去找个说行的人。
这个行业给了你一系列非凡的机遇。积极主动点,掌控这些机遇。
在你的职业发展、学习教育,以及你的项目、每天的工作等各方面对你自己负责,对你的行为负责,这是务实哲学的基石之一。一个务实的程序员能完全掌握自己的职业生涯,从不害怕承认无知和错误。有些事在编程中会令人不快,但却必然会发生——即使最好的项目也无法幸免。尽管有彻底的测试,有优秀的文档,有完备的自动化,结果还是出了问题——交付被推迟,未曾预料的技术问题出现。
一旦这些事情发生,尝试依靠我们的专业性去解决问题。这意味着要诚实和坦率。我们固然会为我们的能力而骄傲,但面对缺点时也必须诚实——承认我们犯了错误,而且是因为我们的无知而犯下的。
如果你打算跟别人解释为什么做不完、为什么延期、为什么搞砸,在此之前先等等,听一下自己的内心。讲给你显示器上的橡皮鸭听听,或是先对着猫说一遍。你的那些借口听起来合理吗?还是很愚蠢?你的老板听到会怎样?
==把谈话在心里过一遍。其他人可能说什么?他们会问,“你试过这样做吗……”“为什么你不考虑一下那样做?”而你怎么回答?在你跑去告诉他们坏消息前,还有什么你可以再试试的?有时,你已经知道他们会说什么,那么就直接帮他们搞定
给出选择,而不是找借口。不要说搞不定;解释一下要做些什么才能挽回这个局面。是否必须扔掉这些代码呢?给他们讲讲重构的价值(参见第216页的话题40:重构)。你是否需要一点时间来做原型?因为只有这样才能决定后面怎么做最好(参见第57页的话题13:原型与便签)。为了防止错误再次发生,你是否需要引入更好的测试(参见第220页的话题41:为编码测试和第288页的无情的持续测试)或增加自动化流程?
也许你需要额外的资源才能完成这项任务。或许你需要花更多的时间和用户打交道?也可能仅仅是你自己需要时间:你需要学习一些技能吗?需要对某项技能学习得更深入一些?读一本书或许有用?或是学习一门课程?别害怕请教别人,别害怕承认自己需要帮助。 打算敷衍搪塞前,试着驱走这些念头。如果实在做不到,那么就先和你的猫通个气。毕竟你想让这只可怜的小猫背锅……
挑战 · 当某人——比如银行职员、汽车修理工、店员——敷衍搪塞你时,你的反应是什么?你会怎么看他们和他们的公司? · 当你意识到自己在说“我不知道”时,一定要接着说“——但是我会去搞清楚”。用这样的方式来表达你不知道是非常好的,因为接着你就可以像一个专家一样承担起责任
石头汤这个故事讲述了很多道理。村民被士兵骗了,士兵利用了村民的好奇心来获取食物。不过更重要的是,士兵充当了催化剂的角色,将村民们组织了起来。这样他们才能聚在一起做出他们无法单独做到的事情——一项协作的成果。最后所有人都是赢家。
从现在开始,你要考虑仿效这些士兵。
你可能处在这样一种状况下——清楚地知道需要做些什么,以及怎样去做。整个系统就在你的眼前——你知道这样做就对了。但当你为做整件事去征求意见的时候,见到的往往是推脱和茫然的眼神。人们想成立一个委员会,然后申请预算,之后事情会变得异常繁杂。每个人都会守着自己的一亩三分田。有时我们称之为“筹备期的劳累”。这个时候,就该拿出石头了——找出你合理的请求,然后不断完善。一旦有成果产出,展示给人们看,让他们大吃一惊。现在可以用上“当然了,它还可以更好,只要我们再加点……”这句话,而且要假装你并不在意。这时先坐下来,等他们开始问你要不要加些你原本想要的功能。人们都觉得,加入一个推进中的成功项目更容易一些。因为只要一窥未来,大家就能团结在一起。
换个角度来看,石头汤的故事讲述的是一个温和渐进的骗局。因为过于将注意力集中在石头上,村民们忘却了石头外的世界,这很像我们每天陷入俗事缠身的状态。
项目进展缓慢,完全失去了控制——这是很常见的症状。大多数软件灾难都始于微不足道的小事,项目的拖延也是一天天累积而成的。系统一个特性接一个特性地偏离规范,一个接一个的补丁加到代码上,最终原始代码无影无踪。往往就是一件件小事的累积破坏了团队和士气。
这点是很重要的点
现在你已经有了一些指导方针,知道什么时候添加什么内容到知识组合中。对于那些构成知识组合的智力资产,获取它们的最佳途径是什么?这里有一些建议:
每年学习一门新语言
不同的语言以不同的方式解决相同的问题。多学习几种不同的解决方法,能帮助自己拓宽思维,避免陷入陈规。此外,要感谢丰富的免费软件,让我们学习多种语言非常容易。
每月读一本技术书
虽然网络上有大量的短文和偶尔可靠的答案,但深入理解还是需要去读长篇的书。浏览书店页面后挑选和你当前项目主题相关的技术图书。一旦你养成习惯,就一个月读一本。在你掌握了当前正在使用的所有技术后,扩展你的领域,学习一些和你的项目不相关的东西。
还要读非技术书
记住,计算机是由人来使用的,你做的事情是为了满足人的需要,这非常重要。和你一起工作的是人,雇佣你的也是人,黑你的还是人。不要忘记方程式中人的那一面,它需要完全不同的技能集(我们称这些为软技能,听起来很容易,但实际上它们很硬核,难以掌握)。
上课
在本地大学或是网上找一些有趣的课程,或许也能在下一场商业会展或是技术会议上找到。
加入本地的用户组和交流群
不要只是去当听众,要主动参与。独来独往对你的职业生涯是致命的;了解一下公司之外的人们都在做什么。
尝试不同的环境
如果你只在Windows下工作,那么就花点时间在Linux上。如果你只使用简单的编辑器和Makefile,那就试试最新的炫酷复杂的IDE,反之亦然。
与时俱进
关心一下和你当前项目不同的技术,阅读相关的新闻和技术帖。这是一种很好的方式,可以了解用到那些不同技术的人的经验及他们所用的特殊术语,等等。
持续投资非常重要。一旦你进入了对某个新语言或新技术的舒适期,向前走,再学一个。
你是否在项目中使用过这些技术并不重要,甚至要不要把它们放在你的简历中也不重要。学习的过程将会扩展你的思维,为你打开全新可能性的大门,让你领悟新的做事方式。想法的交叉传授是很重要的;试着把你领悟到的东西应用到你当前的项目中。即使项目没有用到某项技术,你也可以借鉴一些想法。例如,熟悉面向对象,你就可以用不同的方式来编写朴素的C程序,理解函数式编程范式,就能用不同的方式来写Java,等等。
学习的机会
你如饥似渴地阅读,已站在你所在领域的最新突破性进展前沿(这可不是件容易的事)。尽管如此,当有人问你问题时,如你的确毫无思路,也只能坦率地承认自己无法作答。
但不要停在这里,把找到答案作为一项个人挑战。问问周围的人,或是上网搜索——不要仅限于大众领域,还要试试在学术领域找一下。
如果你无法自己找到答案,去寻觅有能力找到答案的人,而不要让问题沉寂下去。和其他人交谈有助于构建你的人际网络,而且你还会惊奇地发现,在这个过程中你会找到一些其他不相关问题的解决方案——旧有的知识组合会不断地扩大……
所有阅读和研究都需要时间,而时间总是不够用的。所以你需要提前准备好,确保在无聊的时候有东西可读。在医院排队往往是把书读完的好机会——不过一定要记得带上自己的电子阅读器。不然可能只好去翻医院里的旧年刊,里面折起的那页讲的是1973年的巴布亚新几内亚。
批判性思维
最后一个要点是要批判性地思考读到的和听到的东西。你需要确保组合中的知识是精准的,未受供应商或媒体炒作的影响。当心坚持教条的狂热者,他们将其视为唯一答案——而那些教条未必适合你和项目。 永远不要低估商业主义的力量。网络搜索引擎有时仅仅是把热门的东西列在最前面而已,并不能说明这是你的最佳选择,而且内容提供商也可以花钱把它们的东西排到前列。书店有时仅仅是把一本书摆在显著的位置而已,并不能说明这是一本好书,甚至不能说明这本书很流行,可能只是有人花钱把它摆在了那里。
挑战
也许我们可以向韦斯特女士学习。只拥有是不够的,还要看你如何包装它。即使拥有最好的想法、漂亮的代码、最务实的思想,如果不能和他人交流,最终都无法孕育出果实。缺乏有效的沟通,好点子就成了一个孤儿。
作为开发人员,我们必须在多个层次上进行交流。我们会花数个小时开会,倾听和交谈。我们会和最终用户一起合作,去理解他们的需求。我们编写代码,代码将我们的意图传达给机器;我们编写文档,文档为下一代开发者记录了我们的想法。我们写建议和备忘录,用于解释资源申请、报告现状及提出新的方案。我们每天都在团队中工作——倡导想法、修改实践或提出建议。我们每天的大部分时间都花在了交流上,所以需要把它做好。
把英语(或者你的母语是别的什么语言)看成另一门编程语言。像写代码一样用自然语言写文章:尊重DRY原则、ETC、自动化,等等。(我们会在下一章讨论DRY和ETC设计原则。)=
回应别人
当你问别人一个问题时,如果他们不回答,你会觉得他们不礼貌。那么,当别人发电子邮件或备忘录给你,问你一些信息,请你做一些事情时,你有多少次没有回应?日常生活忙忙碌碌,忘点事情太常见了。一定要记得回复邮件,就算简单地说一句“我稍后答复你”都好。随时知会别人,能让人更容易原谅你偶然的疏忽,让人觉得你并没有忘记他们。