??xml version="1.0" encoding="utf-8" standalone="yes"?>
“如何?#8221;是一个开发h员在团队生活中需要知道的最有h值的信息。但遗憾的是Q有些h却认是开发h员在目中唯一要知道的事情?/p>
我们不能q么认ؓ?/p>
如果不知道自己做的究竟是个什么东西,即是最高效的Ruby on Rails家伙Q最熟练的Spring开发h员,或PHP~程者,也不可能做出最有h值的东西?/p>
你们中有多少人,曄写出了APIQ但却不能说出它们将被在哪里、如何用?有多h曄气的q问“你们要怎么用它们?我按照规g里的要求?7个Web Service都开发完了,但现在你们只用了其中?个。该歅R?#8221;
我认为,一个开发h员如果想把工作出色的完成Q除了要知道“怎么d”外,q必ȝ道自q竟做的是什么?/p>
然而,知道做的是什么和如何做,q还不够?/p>
我深信一个开发h员还需要知道和理解“Z么这样做“。只有当你知道这些后Q你才能开发出最有h值的产品?/p>
Z么会有这个项目?Z么需要这L产品Q该死,Z么会有这L公司Q每个h都需要问q样的问题。当知道q理解了“Z?#8221;后,我们才能做出最优的解决Ҏ?/p>
知道?#8220;Z?#8221;Q我们才能真正的理解目的目标,产品的目标和公司的目标。它能激励我们,因ؓ我们看到了大蓝景?/p>
理解?#8220;Z?#8221;会决策更加准确?/p>
我们要坚持从是什?/strong> ?Z?/strong>入手。这h们就知道如何最好的d了?/p>
q一招对我很有效。而你又是如何C成功之\的呢Q?/p>
[英文出处]Q?a minmax_bound="true">Developers should know How, What and Why 所谓谚语,是用言意赅、通俗易懂的方式传达h生箴a和普遍真理的话,它们能很好地帮助你处理生zd工作上的事情。也正因如此Q我才整理了10句编E谚语,每位开发h员都应该铭记他们Q武装自己?/p>
1. 无风不v?/strong> 《注重实效的E序员》一书中有这样一D话解释“破窗理论”Q不要留着“破窗?#8221;Q低劣的设计、错误的决策或者糟p的代码Q不修。发C个就修一个。如 果没有够的旉q行适当的修理,先把它保留h。或怽?以把出问题的代码攑ֈ注释中,或是昄“未实?#8221;消息Q或用虚拟数据加以替代。采取一些措施,防止q一步的恶化。这表明局势尚在掌控之中?br minmax_bound="true" />
毫无疑问QY件已成ؓ我们生活中一个既基本又重要的一部分。正因如此,开发优U软g格外重要。乒乓球游戏中的Bug是一回事Q航天飞机导向系l或者航 IZ通管制系l中的Bug是另外一回事。Slashdot曑֏表一文,讲述了单单Google News的一个小p使一家公司股蒸?1.4亿美元。其他例子参见?a minmax_bound="true">软gBug引发的十ơ严重后?/a>》。这些例子便说明了我们正行着多大的权利。你今天写的代码Q无Z是否有意Q说不定有朝一日在重要的应用程序中z上用场Q这x都o人害怕。编写正合格的代码吧! 国际力_l织调查表明Q在国、英国、d国、芬兰和波兰Q?/10的IT从业者或L重患有心理疾病。主要表Cؓ_沮、心理焦虑、怀疑和~Z工作Ȁ情。如果不采取适当措施Q到2020q_心理问题可能过车祸、艾滋病和暴力而成为全球头h手?/p>
IT行业一直是一个很让外人M慕的行业Q而且薪酬也高。由于IT从业者常常在电脑前工作数时不运动,w体素质较差的问题早已被C会所xQ但
心理素质斚w的问题却没有受到应有的重视。这里简要列出IT从业者经帔R临的心理问题以及一些应Ҏ法:人际关系的压力有的IT从业者因为全心投入工作,
C会接触面窄且不善于发展人际关系Q对他们来说Q最隄不是技术上的问题,而是相对复杂的h际关pR然而,在这个领域内Q很多Q务需要团队的合作才能?
成。因此,如果不懂得徏立跟同事之间的融z关p,互补长短Q将会在工作和生zM面重重困难?/p>
应对{略Q?/p>
①心中要有别人。这里不是指别hҎ们的看法Q而是别h的需求值得我们xQ别人的痛苦值得我们同情Q别人的牚w值得我们学习Q别人的困难值得我们帮助?/p>
②注重与同事的交谈,掌握与同事交谈的技巧。在与同事交谈时Q要注意們他的讲话Qƈl予适当的反馈?/p>
③不要刻意搞好关p,更不要拉帮结z。要明白Q徏立长久健L人际关系需要一定的旉Q要站在长远的角度看待这个问题?/p>
情感~Z有些员工因ؓ至今没有对象Q来自父母的压力非常大,工作状态也不佳。虽然有很优的物质条gQ但感情世界却是I白。IT的特性又军_?
整个行业h从业者的数量占绝对优势,其在很多IT企业的技术部门,x员工更是寥寥无几。长旉与电脑朝夕相对,使他们失Ml交异性的Z和勇气?/p>
应对{略不要闭自己Q多参加集体zdQ你会发现许多有的东西Qƈ逐渐喜欢与h交往Q由此改变独处的习惯。要抽时间和朋友打成一片。培养自?
多方面的情趣Q以爱好l交朋友Q也是一U好办法。另外,互相交流信息、切彼此的体会都可以让自己的情感得到寄托,同时也能扩大交友范围Q找到合适的?
侣?/p>
理想与现实的矛盾对于q轻人来_IT行业仍具有很大的吸引力。他们都梦想着白手起家Q似乎IT行业能够q速创造英雄,像比?#183;盖茨、张朝阳?
丁磊、陈天桥{hQ感觉可以让人在很短的时间内创造奇qV但事实上,能成L人毕竟是数Q因此当他们开始工作后Q才发现原来q不像想象得那么好?/p>
应对{略中国有句古话叫做“既来之,则安?#8221;Q是团队我们要适应当前自己所处的环境Q那么,既然我们已经面了这一现状Q就要先把自己手头的?
作做好,才能有希望成功。因此,对于IT从业人员来说Q要在心理上做好自我疏导和调节,善于适应环境变化Q保持积极向上的心态?/p>
]]>
代码设计是否p糕Q从某些地方可以看出来。比如:
E序员们通常U它们作代码异味(Code Smell)Q但是就我个?#8220;代码警报”q个名字更ؓ合适一些,因ؓ它有更高的紧q感的含义。根本问题处理不当,l将引火烧n?br minmax_bound="true" />
译注QCode Smell中文译名一般ؓ“代码异味”Q或“代码味道”Q它是提CZ码中某个地方存在错误的一个暗C,开发h员可以通过q种smellQ异呻I在代码中q捕到问题?br minmax_bound="true" />
2. 预防ZQ治疗ؓ?/strong>
20世纪80q代Q丰田公司的水作业U因为它在缺陷预防方法上的革新变得出了名的高效。每个发现自q部门有问题的成员都有权暂停生产。这个方法意在宁可发现问题后马上暂定生、解决问题,也不能由其l生产而导致更手且更高代L修复/更换/召回后的问题?br minmax_bound="true" />
E序员M做出生率就{同于快速编码的错误臆断。许多程序员都会不假思烦地直接着手代码设计。可惜,q种Leeroy Jenkins式鲁莽的做法多会D软g的开发过E变得很邋遢Q拙劣的代码需要不断的监测和修改——也可能会被d地替换。最l,生率所涉及到的因素?不仅仅是写代码所消耗的旉了,q要有调试的旉。稍不留就?#8220;捡了芝麻丢了西瓜”。(因小失大。)
译注QLeeroy Jenkins 行ؓQWOW游戏中一位玩家不֤家独w一敌,D灭团?br minmax_bound="true" />
3. 不要孤注一?/strong> Q过度依赖某人)
一个Y件开发团队的公共要素Qbus factorQ是指那些会影响整个目q程的核心开发h员的L。比如某车撞了或某h生孩子或某hx了,目可能׃无序Q甚至会搁置?br minmax_bound="true" />
译注Q?bus factor x公共要素Q比M开发过E中的一些共同因素。如果挤?bus ?factor 多Qbus p不稳定,所以要控制?bus factor Q以免问题发生?br minmax_bound="true" />
换句话说Q如果你的团队突然失M一个主力成员,你会怎么办?生意依旧q行q是戛然而止Q?br minmax_bound="true" />
很不q,大多数Y件团队都陷入了后一U情c这些团队把他们的开发员培养成了只会处理他们自己专业领域?#8220;领域专家”。v初,q看h是一个比较合?的方法。它 Ҏ车制造装配生产线很适用Q但是ؓ什么对软g开发团队就不行呢?毕竟Q想让每个成员都掌握所~程序的l微差别也不太可能,对吧Q?br minmax_bound="true" />
问题是开发h员不ҎL替换掉。虽然当每位成员都可用时Q?#8220;抽屉Ҏ”很有效,但如果当“领域专家”H然因h事变动、疾病或H发事故而无法工作时Q?抽屉 Ҏ立马土崩瓦解。(所以,QY件团队有一些看似多余实则重要的后备力量是至关重要。代码复查、结对编E和共有代码可用成功营造一个环境,在这个环境中Q?每位开发h员至表面上是熟悉自己非擅长领域之外的系l部分?br minmax_bound="true" />
4. U瓜得瓜Q种豆得?/strong>
我们见过整洁良好的系l在出现“破窗”之后立马崩溃。虽然促使Y件崩溃的原因q有其他因素Q我们将在其他地Ҏ触到Q,但(?#8220;破窗”Q置之不理,肯定会更快地加速系l崩溃?br minmax_bound="true" />
而言之,好的代码会促生好的代码,p糕的代码也会促生糟p的代码。别低估了惯性的力量。没人想L理糟p的代码Q同h人想把完的代码弄得一团糟。写好你的代码,它才更可能经得住旉的考验?br minmax_bound="true" />
译注Q《注重实效的E序员》,作者Andrew Hunt / David Thomas。该书直ȝE陈圎ͼI过了Y件开发中日益增长的规范和技术藩,Ҏ心过E进行了审视――即Ҏ需求,创徏用户乐于接受的、可工作和易l护 ?代码。本书包含的内容从个d职业发展Q直至保持代码灵zd易于改编重用的架构技术。从本书中将学到防止软g变质、消除复制知识的陷阱、编写灵zR动 态和易适应的代码、避免出现相同的设计、用契约、断a和异常对代码q行防护{内宏V?br minmax_bound="true" />
译注Q破H理论(Broken Window theoryQ:是关于环境对Z心理造成暗示性或诱导性媄响的一U认识?#8220;破窗效应”理论是指Q如果有人打坏了一q徏{物的窗L璃,而这扇窗户又得不 到及时的l修Q别人就可能受到某些暗示性的U容L烂更多的H户。发现问题就要及时矫正和补救?br minmax_bound="true" />
5. Ʋ速则不达
l理、客户和E序员正日益变得急躁。一切都需要做的事Q都需要马上就做好。正因如此,快速修复问题变得非常急迫?br minmax_bound="true" />
没时间对一个新功能q行适当的单元测试?好吧Q你可以先完成一ơ测试运行,然后你就可以随时回来l箋试它?br minmax_bound="true" />
当访问Y属性时Q会不会到奇怪的对象引用错误Q无论怎样Q把代码攑ֈtry/catch语句块中。我们要钓到大鱼啦!
是不是似曄识呢Q这是因为我们在以前已经都做C。ƈ且在某些情况下、它是无可非议的。毕竟,我们有最后期限,q得满客户和经理。但不要q于频繁 ?作,否则你会发现你的代码不稳定,有很多热修复、逻辑重复、未试的方案和错误处理。最后,你要么是把事情草草做完,要么是把事情好好做完?br minmax_bound="true" />
6. 三思而后?/strong>
“敏捷开?#8221;q个词最q被频繁滥用Q经常被E序员用来掩C们在软g开发过E中的糟p规?设计阶段。我们是设计者,看到产品朝正当方向有实质q展Q?我们理应高兴。但意外的是QUML囑֒用例分析gq不能满x们的愿望。所以,在不知自己做什么的情况下或者不知自pn处何处时Q我们开发h员经常就E 里糊涂地写代码了?br minmax_bound="true" />
q就好比你要d饭,但你Ҏ没有惛_d里吃。因Z太饿了,所以你q不及待地找个餐馆,定个桌位。然后你上R开车后沉K在惻I扑֜方吃饭)。只 是,q样会耗费更多的时_因ؓ你要q较多的U型弯道,q在馆前停车,也许最后因{待旉q长而不吃了。确切地_你最后应该能扑ֈ地方吃饭Q但你可?吃的饭ƈ不是你想吃的Qƈ且这栯费的旉Q可能比你直接在惛_的餐馆订所q旉更长?br minmax_bound="true" />
7. 如果你惟一的工h一把锤子,你往往会把一切问题看成钉?/strong>
E序员有一U們Q当一谈到他们工具Ӟ其视野就变狭H了。一旦某U方法在我们的一个项目上“行得?#8221;Q我们就会在接下来所有的目上都用到它。学?C 西仿佛是一U煎熬,有时候甚至会心神不定。从始至l都在想“如果我用之前的方法做、这个就不会q么ȝ?#8221;。一定要摒弃q种xQ按我们所知道的去做,?佉K不是最完美的解x法?br minmax_bound="true" />
坚持自己所知很单,不过从长q的角度Ԍ选择一个适合q项工作的工兯Ҏ得多。否则,׃与你的职业生涯格g入?br minmax_bound="true" />
8. 沉默卌?/strong>
"破窗理论"?变成惯性理?有着宏观的联pR?br minmax_bound="true" />
~程C好像一个现实社区。每个作品都是一个开发者的~媄。糟p的代码发布的越多,pҎ反映现状。如果你不去努力~写优秀、整z和E_的代码,那你每天都将和糟p的代码怼了?br minmax_bound="true" />
同样圎ͼ如果你看到别人写Zp糕的代码,你就要跟q个人提出来。注意,q时候机智就应该用上Z。一般情况下Q程序员都愿意承认他们在软g开发中q是有不懂的地方Qƈ且会感谢你的好意。互相帮助对大家都有利,而对问题视而不见,只会佉K题一直存在?br minmax_bound="true" />
9. 双鸟在林Q不如一鸟在?
如果可以讨论pȝ架构和重构,那么差找个旉把事情做完。ؓ了正常q作的东西更加简z而做改动Q权衡改动的利弊很重要。当然了Q简z是一个理想目 标, 但M有可以通过重构改进的代码。在~程世界中,Z代码不过Ӟ会频J简单改动代码。但有时候你又必M证代码对客户有h倹{那么,你面临一个简单窘 境:你不能一石二鸟。你在重构旧代码上所发时间越多,你编写新代码的时间就少。在及时改进代码和维护程序之_也需要找到^衡点?br minmax_bound="true" />
10. 能力大Q责任越?/strong>
译注QSlashdot是一个资讯科技|站?br minmax_bound="true" />
本文出处Q伯乐在U?- 职场博客
本文链接Q?a minmax_bound="true">http://www.jobbole.com/entry.php/297
]]>
]]>
文章说的很好?保存到自q博客上面记录下来,随时提醒下自׃要沉q于机器的世界里面?br />
]]>