开发最佳实践及原则

开发最佳实践及原则

工作方法

• 单元测试,重构,迭代,积累分享
• 关键议题,不拘小节 抓住关键议题
• just do it 马上去做,实践是检验真理的标准.别把时间浪费在无休止的争论和想像中.
• 不做重复工作,充分利用已有的资源.在你打算写个功能或算法之前先google下
• 工预善其事,必先利其器. 使用和掌握一些工具最大的提高工作效率
• 万变不离其宗,掌握基础理论非常重要.
• 多些判断力,想清楚什么该做什么不不做.减少不必要的工作.

测试驱动

• 边写代码边测试
• 确保你编写的模块和代码是可进行单元测试的
• 先行测试可保证模块间松散的耦
• 单元测试是最好的文档

设计原则

• 不要过渡设计,没有彻底了解业务逻辑之前,不可能做出完美的设计.好的设计是重构出来的.
• 你要依赖的包或类应该比你本身要更稳定
• 单一职责，一个类只做一件事情
• 保证相同或类似的逻辑只有一个独立的入口.
• 尽量封装你的内部细节，让外界知道的越少越好。如果一个public方法能够解决问题最好。
• 通过分层设计简化你的系统设计.

关于管理

• 团队之间重要的三点就是沟通，沟通，沟通
• 敢于说不，知道什么事情该做，什么事情不该做。
• 重复你说的话给大家打上烙印

代码重构及代码审查

每日构建

编码相关

• 编写优雅的代码: 命名规范,结构清晰.便于维护
• 编写健壮的代码,代码缺陷少,最大限度的减少bug出现几率,而不是丢给测试人员.
• 编写高效的代码,写代码的时候多作些思考.这远比回来优化代码寻找系统瓶颈划算的多.(尤其你的方法或类,用在循环或者调用频次比较多的地方) . 有时候为了优化牺牲优雅的代码结构也是必要的.
• 编写可重用的代码.

注释

• 注释不在多，在于清楚的表达
• 写注释是一个思考的过程,有利于重申你的设计
• 清晰的代码比注释更有效
• 实在不好把握好的变量命名,清晰的注释是好主意
• 不清晰的注释还不如不存在,容易误导大家

写代码时脑子里应该有的几根弦

• 这个类是稳定的么？我一定要依赖它么？
• 这个变量必须是成员变量么？尽可能的使用局部变量
• 这个成员变量可以是静态的么？不要无谓的浪费内存
• 这个变量是只读的么？是只读的话应该加上final （java)或 const (c++)关键字
• 这个类的方法或成员我必须得暴露给外面么？ 尽可能的屏蔽类的内部细节
• 这个方法我是否能够让外部的调用更简单？尽可能的封装复杂的逻辑
• 决不允许存在冗余的代码
• 从源头修复bug,遇到bug多些思考,想想bug出现的原因是粗心还是设计逻辑问题?否则可能会修补了这个bug引出更多的bug.

常见问题

• 方法重载是对基本方法的包装而不是拷贝
• 一个类掺杂着多种业务逻辑(参考单一职责原则)
• 决不要有环形依赖 A→B→A