@DevWiki
2015-07-02T21:15:58.000000Z
字数 1773
阅读 940
高效程序员的45个习惯
更多内容详见:高效程序员的45个习惯
coding feedback 编写能产生反馈的代码
1.为了应对代码的变化,你需要持续获得代码的健康状态的反馈:它是在做你期望的事情吗?
2.用代码来测试变量的具体值(以及跟踪运行了多少个测试),已经是非常普遍的做法.
3.对于测试我们要做到:
4.只要有了单元测试,就要他们自动运行.也就是每次编译或者构建代码的时候就运行一次测试.
5.单元测试的理由:
6.单元测试是优质股,只得投资.
7.人们不编写单元测试的很多借口都是因为代码中的设计缺陷
8.单元测试只有在达到一定的覆盖率时才能真正地发挥作用.
9.不是测试越多质量就越高,测试必须要有效.
Write tests before writeing code 编码之前先写测试
1.如果要让你的产品尽可能的好,自己要先积极地使用它.
2.对于我们自己写的接口,在说服其他人使用之前,先得让自己切实地使用它们.
3.你会发现,因为你自己要使用它们,所以能设计一个更有用,更一致的接口.
4.学会使用TDD---Test Driven Development,测试驱动开发.TDD有机会让你在编写代码之前,可以深思熟虑将如何使用它.这迫使你去思考它的可用性和便利性,并让你的设计更加注重实效.
5.设计不是开始编码的时候就结束了.你需要在设计的生命周期中持续地添加测试,添加代码,并重新设计代码.
6.任何一个设计都可以被改进.
7.单纯的单元测试是无法保证好的设计,但它们会对设计有帮助.
1.同一段代码可能在不同的机器上运行就会有不同的结果.
2.测试团队应该在项目所支持的所有平台上进行测试.
3.在保持可以发布中学过,用一个持续集成工具,周期性地从源代码控制系统中取得代码,并运行代码.如果测试失败了,就会通知相关的开发人员.要在多个平台上测试,你只要为每个平台设置持续集成系统就行了.
4.要积极地寻找问题,而不是等问题来找你.
5.硬件比开发人员的时间便宜.
6.软件在很多平台上出现bug很可能只是因为栈布局的差异,机器字大小的端的不同导致.
1.关键的业务逻辑必须要独立进行严格的测试,并且最后需要通过用户的审批.
2.使用集成测试框架,可以更容易地让用户验证是否为他们需要的业务.
3.让你的客户单独验证核心的业务逻辑,要让它们像一般的测试一样可以自动运行.
4.使用客户的业务逻辑,但不要陷入无边无际的文档写作之中.
Focus on where you're going 专注于你的方向
1.判断工作进度最好的是看实际花费的时间,而不是估计的时间.
2.时间表很难真实地反应工作的完成状况,因此它不可以用来进行项目计划,评估或表现评估.
3.我们不应该去计算工作量完成的百分比,而应该测定还剩下多少工作量没有完成.
4.在你最后真正完成一项任务时,要清楚知道完成这个任务真正花费的时间,并在下一次评估任务时作为参考.
5.如果能一直让下一步工作是可见的,会有助于进度的度量.最好的做法就是使用待办事项.(bakclog)通过待办事项就可以随时知道下一步最重要的任务是什么.
6.不要用不巧当的度量来欺骗自己或者团队
7.10分钟作为一个时间单位,它的颗粒度实在太细了.一周或者一个月的时间单元,它的颗粒度太粗了.一般以一天或者半天作为时间单位.
8.一周工作40小时,不是说你就有40小时的编码时间.
It is a bug! 这是一个bug.
1.每一个抱怨的背后都隐藏一个事实,找出真相,修复真正的问题.
2.没有愚蠢的用户,只有愚蠢的自大的开发人员.
3.当除了问题,你要尽可能地提供详细的信息.
4.不管是产品的bug,还是文档的bug,或者是对用户社区理解的bug,他都是团队的问题,而不是用户的问题.
5.我们花费了很大精力从单元测试之类的代码中获得反馈,但却容易忽略最终用户的反馈.
6.不仅需要和真实的用户进行交谈,还需要耐心地倾听.
7.如果代码解决不了问题,也许可以考虑通过修改文档或者培训来弥补.