宁波网站推广优化外包,做彩票网站是违法的吗,惠州抖音seo策划,软件定制公司请您在阅读本文之前#xff0c;先了解《高效程序员的45个习惯》-之一。
每一期都会涉及15个话题#xff0c;用3期来列出这45个习惯#xff0c;每次不贪多#xff0c;贪精#xff0c;大家如果有空#xff0c;一定要细细品味这15个习惯。
注意#xff1a;每一个好的习…请您在阅读本文之前先了解《高效程序员的45个习惯》-之一。
每一期都会涉及15个话题用3期来列出这45个习惯每次不贪多贪精大家如果有空一定要细细品味这15个习惯。
注意每一个好的习惯开头都会相应有一个唱反调的句子哦。 1 做事
“出了问题第一重要的是确定元凶找到那个人一旦证实了是他的错误就可以保证这样的问题永远也不会再发生了。”
指责不会修复bug把矛头对准问题的解决办法而不是人。这是真正有用处的正面效应。
也许你不相信但确实有些人常常不把解决问题放在最高优先级上。也许你也没有。先自我反省一下当有问题出现时“第一”反应究竟是什么
一个重大的错误应该被当作是一次学习而不是指责他人的机会。
团队成员们在一起工作应互相帮助而不是互相指责。
如果你没有犯过任何错误就说明你可能没有努力去工作。 2 欲诉则不达
“你不需要真正地理解那块代码它只要能够工作就可以了。哦它需要一个小小的调整。只要在结果中再加上几行代码它就可以工作了。干吧就把那几行代码加进去它应该可以工作。”
拙劣的代码工人会这样不假思索地改完代码然后快速转向下一个问题而优秀的程序员会挖掘更深一层尽力去理解为什么这里需要加1更重要的是他会想明白会产生什么其他影响。
千里之堤溃于蚁穴大灾难是逐步演化而来的。一次又一次的快速修复每一次都不探究问题的根源久而久之就形成了一个危险的沼泽地最终会吞噬整个项目的生命。
如果有一位团队成员宣布有一块代码其他人都很难看懂这就意味着任何人包括原作者都很难维护它。请让它变得简单些。 3 对事不对人
“当L先生在做一个新方案介绍时下面有人会说‘这样设计很蠢都没有考虑线程安全’这也暗示着L先生很蠢。”
事实上最适合并且最有效的表达方式应该是“谢谢L先生。但是我想知道如果两个用户同时登录会发生什么情况”
尽力贡献自己的好想法如果你的想法没有被采纳也无需生气不要因为只是想体现自己的想法而对拟定的好思路画蛇添足。 4 排除万难奋勇前进
“老鼠们打算在猫的脖子上系一个铃铛这样猫巡逻靠近时就能预先得到警报。每只老鼠都点头认为这是一个绝妙的想法。这时一个年老的老鼠站出来说道’那么谁愿意挺身而出去系铃铛呢’毫无疑问没有一只老鼠站出来。当然这个绝妙的计划也就这样泡汤了。”
有时绝妙的计划会因为勇气不足而最终失败。尽管前方很危险但你必须有勇气向前冲锋做你认为对的事情。
当你勇敢地站出来时如果受到了缺乏背景知识的抉择者的抵制你需要用他们能够听懂的话语表达。“更清晰的代码”是无法打动生意人的。节约资金、获得更好的投资回报避免诉讼以及增加用户利益会让论点更有说服力。 5 跟踪变化
“软件技术的变化如此之快势不可挡这是它的本性。继续用你熟悉的语言做你的老本行吧你不可能跟上技术变化的脚步。”
如果只是掌握了工作中需要的技术并不够。那样的工作也许几年之后就不再有了—它会被外包或者会过时那么你就将会出局。
迭代和增量式的学习了解最新行情参加本地的用户组活动参加研讨会议如饥似渴地阅读。 6 对团队投资
“不要和别人分享你的知识—自己留着。你是因为这些知识才成为团队中的佼佼者只要自己聪明就可以了不用管其他失败者。”
团队中的开发者们各有不同的能力、经验和技术。每个人都各有所长。不同才能和背景的人混在一起是一个非常理想的学习环境。
一个学习型的团队才是较好的团队。
每周要求团队中的一个人主持讲座。他会给大家介绍一些概念演示工具或者做团队感兴趣的任何一件事。你可以挑一本书给大家说说其中一些特别内容、项目或者实践无论什么主题都可以。 7 懂得丢弃
“那就是你一贯的工作方法并且是有原因的。这个方法也很好地为你所用。开始你就掌握了这个方法很明显它是最好的方法。真的从那以后就不要再改变了。”
打破旧习惯很难更难的是自己还没有意识到这个问题。丢弃的第一步就是要意识到你还在使用过时的方法这也是最难的部分。另一个难点就是要做到真正的丢弃旧习惯。 毕竟汽车要比马车车厢强多了。
不是完全忘记旧的习惯而是只在使用适当的技术时才使用它。 8 打破砂锅问到底
“接受别人给你的解释别人告诉你问题出在了什么地方你就去看什么地方。不需要再浪费时间去追根究底”
要不停的问“为什么”。不能只满足于别人告诉你的表面现象要不停的提问直到你明白问题的根源。
问“为什么”但是要问到点子上。
当你问“为什么”的时候也许你会被反问“为什么你问这个问题”。在提问之前想好你提问的理由这会有助于你问出恰当的问题。 9 把握开发节奏
“我们很长时间没有进行代码复审所以这周会复审所有的代码。”
在许多不成功的项目中基本上都是随意安排工作计划没有任何规律。那么样的随机安排很难处理。你根本不知道明天将会发生什么。
但是敏捷项目会有一个节奏和循环让开发变得更加轻松。Scrum约定了30天之内不应该发生需求变化这样可以确保团队有一个良性的开发节奏。Scrum是一种迭代式增量软件开发过程通常用于敏捷软件开发。包括了一系列实践和预定义角色的过程骨架。
站立会议最好每天在固定的时间和地点举行比如说上午10点左右。要养成这样的习惯在那时就准备好一切参加站立会议。 10 让客户做决定
“开发者兼具创新和智慧最了解应用程序。因此所有关键决定都应该由开发者定夺。每次业务人员介入的时候都会弄得一团糟他们无法理解我们做事的逻辑。”
在设计方面做决定的时候必须有开发者参与。可是在一个项目中他们不应该做所有的决定特别是业务方面的决定。
记录客户做出的决定并注明原因。好记性不如烂笔头。 11 让设计指导而不是操纵开发
“设计文档应该尽可能详细这样低级的代码工人只要敲入代码就可以了。编写代码的时候无论你发现什么绝不能偏离了设计文档。”
设计满足实现即可不必过于详细。
即使之前已经提交了设计文档也还会有一些意料之外的情况出现。时刻谨记此阶段提出的设计只是基于你目前对需求的理解而已。一旦开始了编码一切都会改变。设计及其代码实现会不停地发展和变化。
设计可以分为两层战略和战术。前期的设计属于战略通常只有在没有深入理解需求的时候需要这样的设计。更确切的说它应该只描述总体战略不应深入到具体的细节。 12 合理地使用技术
“你开始了一个新的项目在你面前有一长串关于新技术和应用框架的列表。这些都是好东西你真的需要使用列表中所有的技术。想一想你的简历上将留下漂亮的一笔用那些伟大的框架你的新应用将具有极高的技术含量。”
这个技术框架真能解决这个问题么如果需要先做一个小的原型
你将会被它拴住么一些技术是贼船一旦你使用了它就会被它套牢再也不可能回头了。我们需要考虑它是开放技术还是专利技术
维护成本是多少维护成本昂贵。我们听说有个项目的合同是支持一个规则引擎引擎一年的维护费用是5万美元但是这个数据库只有30条规则
不需开发你能下载到的东西。
新技术就应该像是新的工具可以帮助你更好地工作它自己不应该成为你的工作。 13 保持可发布
“我们刚试用的时候发现了一个问题你需要立即修复它放下你手头的工作去修复那个刚发现的问题。不用告诉其他任何人—赶快让它工作就行了。”
已提交的代码应该随时可以行动。
在本地运行测试检出最新的代码提交代码。 14 提早集成频繁集成
“只要没有到开发的末尾阶段就不要过早地浪费时间去想如何集成你的代码至少也要等开发差不多的时候才可以考虑它。”
敏捷的一个主要特点就是持续开发而不是三天打鱼两天晒网地工作。特别是在几个人一起开发同一个功能时更应该频繁地集成代码。
绝不要做大爆炸似的集成。
代码集成是主要的风险来源。要想规避这个风险只有提早集成持续而有规律地进行集成。 15 提早实现自动化部署
“没问题可以手动安装产品尤其是给质量保证人员安装。”
系统能在你的机器上运行或者能在开发者和测试人员的机器上运行当然很好但是它同时也需要能够部署在用户的机器上。
质量保证人员应该测试部署过程。
从第一天起就开始交付一开始就实现自动化部署应用。
如果维护安装脚本变得很困难那很可能是一个早期警告预示着—很高的维护成本。
