敏捷的编码

62 篇文章 1 订阅
62 篇文章 1 订阅

代码要清晰表达意图,项目是增量式开发,写程序也应该增量式编程。

代码要清晰地表达意图

要编写清晰地而不是讨巧的代码,向代码阅读者明确表明你的意图,可读性差的代码一点都不聪明(让自己或者团队任何人,可以读懂自己一年前写的代码,而且只读一遍就知道它的运行机制)

代码沟通

用注释沟通,使用细心选择的、有意义的命名。用注释描述代码意图和约束。注释不能替代优秀的代码

动态评估取舍

动态评估权衡,考虑性能、便利性、生产力、成本和上市时间。如果性能够了,就应该把注意力放在其他因素上,不要为了感觉上的性能提升或者设计的优雅,从而将设计复杂化。

增量式编程

在很短的编辑/构建/测试循环中编写代码,这要比花费长时间仅仅做编写代码的工作好得多,可以创建更加清晰、简单、易于维护的代码。

保持简单

开发可以工作的、最简单的解决方案,除非有不可辩驳的原因,否则不要使用模式、原则和高难度技术之类的东西。

当你觉得所编写的代码中没有一行多余的,并且仍能交付全部功能时,这种感觉就对了。这样的代码容易理解和改正。

编写内聚的代码

让类的功能尽量集中,让组件尽量小,要避免创建很大的类或组件,也不要创建无所不包的大杂烩类。

告知,不要询问

不要抢别的对象或者组件的工作,告诉它做什么,然后盯着你自己的职责就好了。

根据契约进行替换

通过替换遵循接口契约的类,来添加并改进功能特性,要多使用委托而不是继承。

记录问题解决日志

对解决的问题可以记录以下条目:

问题发生日期

问题简述

解决方案详细描述

引用文章或者网址

任何代码片段,设置或对话框截图

警告就是错误

嵌入带有警告的代码,就跟嵌入有错误或者没有通过测试的代码一样,都是极差的做法。

对问题各个击破

在解决问题时,要将问题域和周边隔离开,特别是大型应用中

报告所有的异常

处理或向上传播所有的异常,不要讲他们压制不管,就算是临时这样做也不行,在写代码时要估计到会发生的问题。

提供有用的错误信息

提供更易于查找错误细节的方式,发生问题时,要展示出尽量多的支持细节,不过别人用户陷入其中。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

蜗牛慢慢向上爬

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值