临沂 企业网站建设,ie9网站后台编辑器,企业网站优化推广,云浮+网站建设请您在阅读本文之前#xff0c;先了解《高效程序员的45个习惯》-之二。
每一期都会涉及15个话题#xff0c;用3期来列出这45个习惯#xff0c;每次不贪多#xff0c;贪精#xff0c;大家如果有空#xff0c;一定要细细品味这15个习惯。
注意#xff1a;每一个好的习…请您在阅读本文之前先了解《高效程序员的45个习惯》-之二。
每一期都会涉及15个话题用3期来列出这45个习惯每次不贪多贪精大家如果有空一定要细细品味这15个习惯。
注意每一个好的习惯开头都会相应有一个唱反调的句子哦。 16 使用演示获得频繁反馈
“客户不停的更改需求导致我们严重地延期。他们一次就应该想清楚所有想要的东西然后把这些需求给我们。”
需求就像是流动着的油墨。你无法冻结需求就像你无法冻结市场、竞争、知识、进化或者成长一样。就算你真的冻结了也很可能是冻结了错的东西。
不一致的术语是导致需求误解的一个主要原因。所以需要维护一份项目术语表。人们应该可以公开访问它一般是在wiki或内部网里。
项目启动了一段时间以后你就应该进入一种舒适的状态团队和客户建立了一种健康的富有创造性的关系。 17 使用短迭代增量发布
“我们为后面的3年制定了漂亮的项目计划列出了所有的任务和可交付的时间表。只要我们那时候发布了产品就可以占领市场”
给我一份详细的长期报告我就会给你一个注定完蛋的项目。
对于大项目最理想的办法就是小步前进这也是敏捷方法的核心。大步跳跃大大地增加了风险小步前进才可以帮助你很好地把握平衡。 18 固定的价格就意味着背叛承诺
“对这个项目我们必须要有固定的报价。虽然我们还不清楚项目的具体情况但仍要有一个报价。”
固定价格的合同会是敏捷团队的一大难题。我们一直在谈论如何用持续、迭代和增量的方式工作。但是现在却有些人跑过来想提早知道它会花费多少时间及多少成本。
软件项目天生就是变化无常的不可重复。如果要提前给出一个固定的价格就几乎肯定不能遵守开发上的承诺。
如果你现在别无选择你不得不提供一个固定价格那么你需要学到真正好的评估技巧。 19 守护天使
“你不必为单元测试花费那么多时间和精力。它只会拖延项目的进度。好歹你也是一个不错的程序员—单元测试只会浪费时间。”
单元测试能及时提供反馈
单元测试让你的代码更加健壮
单元测试时有用的设计工具
单元测试是你自信的后台
单元测试是可信的文档
单元测试是学习工具 20 先用它再实现它
“前进先完成所有的库代码。后面会有大量时间看用户是如何思考的。现在只要把代码扔过墙就可以了我保证它没有问题。”
很多成功的公司都是靠着“吃自己的狗食”活着。也就是说如果要让你的产品尽可能地好自己先要积极地使用它。
编程之前先写测试。
先写测试你就会站在代码用户的角度来思考而不仅仅是一个单纯的实现者这样做是有很大区别的你会发现因为你自己要使用它们所以能设计一个更有用、更一致的接口。 21 不同环境就有不同问题
“只要代码能在你的机器上运行就可以了谁会去关心它是否可以在其他平台上工作你又不用其他平台。”
一位同事的代码失败了最终找到了罪魁祸首一个.NET环境下的API在Windows XP和Windows2003上的行为不同。平台不同造成了结果的不一样。
使用持久集成工具在每一种支持的平台和环境中运行单元测试要积极地寻找问题而不是等问题来找你。 22 自动验收测试
“很好你现在用单元测试来验证代码是否完成了你期望的行为。发给客户吧。我们很快会知道这是否是用户期望的功能。”
关键业务逻辑必须要独立进行严格的测试并且最后需要通过用户的审批。但是你又不可能拉着用户逐一模块确认。所以你需要能自动比较用户期望和实际完成的工作。
FITfit.c2.com即集成测试框架它很实用可以更容易的使用HTML表格定义测试用例并比较测试结果数据。 23 度量真正的进度
“用自己的时间表报告工作进度。我们会用它做项目计划。不用管那些实际的工作时间每周填满40小时就可以了。”
时间表很难真实地反映工作完成状况因此它不可以用来进行计划、评估或表现评估。
你曾经听到开发人员报告一个任务完成了80%么然而过了一天又一天一周又一周那个任务仍然是完成80%。
随意用一个比率进行度量是没有意义的。所以不应该去计算工作量完成的百分比而应该测定还剩下多少工作量没有完成。如果你最初估计这个任务需要40个小时在开发了35个小时之后你认为还需要另外30个小时的工作。那就得到了很重要的度量结果这里诚实非常重要隐瞒真相毫无意义
关注功能而不是日程表。 24 倾听用户的声音
“用户就是会抱怨。这不是你的过错是用户太愚蠢了连使用手册都看不懂。它不是一个bug只是用户不明白如何使用而已。他们本应该知道更多。”
不管它是否是产品的bug还是文档的bug或者是对用户社区理解的bug它都是团队的问题而不是用户的问题。
对于一些软件倒霉的用户必须要配置那些包含了一些魔术数字的模糊系统文件否则系统根本不会运行。系统既没有错误提示消息也不会崩溃只是显示大黑屏和一个斗大的“退出”按钮。
每一个抱怨的背后都隐藏着一个事实。找出真相修复真正的问题。
没有愚蠢的用户只有愚蠢自大的开发人员。
“它就是这样的。”这不是一个好答案。
你的用户有可能会阅读所有的文档记住其中的所有内容。但也可能不会。 25 代码要清晰地表达意图
“可以工作而且易于理解的代码当然好但是让人觉得聪明更加重要。别人给你钱是因为你脑子好使让我们看看你到底有多聪明。”
Hoare说“设计软件有两种方式。一种是设计得尽量简单并且明显没有缺陷。另一种方式是设计得尽量复杂并且没有明显的缺陷。”
Hoare创造了Algol 60编程语言并发明了快速排序算法。于1980年获得图灵奖。
代码阅读的次数要远远超过编写的次数所以在编写的时候值得花点功夫让它读起来更加简单。
当开发人员们像一群旁观者见到UFO一样围在代码四周感到恐惧、困惑与无助时这个代码的质量就可想而知了。
看一个例子
coffeeShop.PlaceOrder(2);//通过阅读代码可以大致明白这是要在咖啡店中下一个订单。但是2代表什么意思 coffeeShop.PlaceOrder(2 /* large cup */); //不妨添加一些注释。但注释有时候是为了帮写得不好的代码补漏。 public enum CoffeeCupSize { Small, Medium, Large } coffeeShop.PlaceOrder(CoffeeCupSize,Large);//如果使用上枚举值代码就一目了然了。
应该让自己或团队的其他任何人可以读懂自己一年前写的代码而且只读一遍就知道它的运行机制。 26 用代码沟通
“精确地解释代码做了什么每行代码都要加注释。不用管为什么要这样编码只要告诉我们做了什么就好了。”
源代码可以读懂不是因为其中的注释而应该是由于它本身优雅而清晰。
要尽量避免使用神秘的变量名。i常用于循环索引变量str常用于表示字符串。如果用str表示循环索引变量可真不是好主意
在代码可以明确传递意图的地方不要使用注释。
解释代码做了什么的注释用处不那么大。相反注释要说明为什么会这样写代码。 27 动态评估取舍
“性能、生产力、优雅、成本以及上市时间在软件开发过程中都是至关重要的因素。每一项都必须达到最理想的状态。”
与其花费时间去提升千分之一的性能表现也许减少开发投入降低成本并尽快让应用程序上市销售更有价值。
如果现在投入额外的资源和精力是为了将来可能得到的好处要确认投入一定要得到回报。大部分情况下是不会有回报的 28 增量式编程
“真正的程序员写起代码来一干就是几个小时根本不停甚至连头都不抬。不要停下来去编译你的代码只要一直往下写就好了”
如果不对自己编写的代码进行测试保证没有问题就不要联系几个小时甚至连续几分钟进行编程。相反应该采用增量式的编程方式。
采用增量式编程和测试会倾向于创建更小的方法和更具内聚性的类。你应该经常评估代码质量并不时的进行许多小调整而不是一次修改许多东西。
在写了几行代码之后你会迫切地希望进行一次构建/测试。在没有得到反馈时你不要走的太远。 29 保持简单
“通过编写史上最复杂的程序你将会得到美誉和认可更不用提保住你的工作了。”
Andy曾经认识一个家伙他对设计模式非常着迷想把它们全都用起来。有一次要写一个大概几百行的代码程序。在被别人发现之前他已经成功将17种设计模式都运用到那可怜的程序中了。—这不应该是编写敏捷代码的方式。
问题在于许多开发人员倾向于将投入的努力与程序复杂性混同起来。如果你看到别人给出的解决方案并评价说“非常简单且易于理解”很有可能你会让设计者不高兴。许多开发人员以自己程序的复杂性为荣如果能听到“Wow这很难一定是花了很多时间和精力才做出来的吧。” 这时他们就会面带自豪的微笑了。其实应当恰恰相反开发人员更应该为自己能够创建出一个简单并且可用的设计而骄傲。
简单不是简陋。 30 编写内聚的代码
“你要编写一些新的代码看看IDE中现在打开的是哪个类就直接加进去吧。如果所有的代码都在一个类或组件里面要找起来是很方便的。”
内聚性用来评估一个组建包、模块或配件中成员的功能相关性。内聚程度高表明各个成员共同完成了一个功能特性或是一组功能特性。内聚程度低的话表明各个成员提供的功能是互不相干的。
类也要遵循内聚性。如果一个类的方法和属性共同完成了一个功能这个类就是内聚的。
不过不要把一些东西分成很多微小的部分而使其失去了实用价值。当你需要一只袜子的时候一盒棉线不能带给你任何帮助。
