做开发十年,我总结一些开发经验
流程管理与规范
如果你的团队没有一个斗战胜佛,那么最好三个臭皮匠商量出一个规范出来。
怎么说呢,产品和开发讨论出方案的可行性,产品发布按照节奏,有质量跟踪,专门的用户反馈,知道今天干啥,明天要干啥。
需求、开发要互相反馈
库、框架、架构的选型
库、框架的选择
- 我的产品要做什么
- 我需要用到哪些技术,用到什么程度
- 在心里或者文档上清清楚楚描述出我的技术、功能需求
- 拿着需求(拿在心里),去搜索别人的使用案例
- 或者问问别人用的啥
- 大框架、大库很能打但是团队hold的住吗?
- 小库简单,功能够用吗?这些都是要问的问题,选择合适自己的
- 团队技术学习成本、库能够做的事、坑多不多、文档多不多社区活不活跃都是参考标的
架构选型
架构我不懂,但是参考竞品是一个很好的思路
怎么说呢,就是最好拿到行业老大、老二的产品,看看他们都怎么架构,他们的痛点基本也是我们将要踩得坑
bug之战
开发完成后,开发者对各个模块的质量应该心里有个大致的数。
什么是质量——可维护性、拓展性、算法效率、bug崩溃率
bug分三种:
- 对api的熟悉程度不够,如jdk、java机制、sdk等。java内存释放不是绝对的,相互指向无法释放
- 粗心大意,空指针、野指针
- 逻辑上的问题,逻辑情况没考虑全面
注意这三点,大部分问题都会少犯一点
简单的自省标准
我后面的时间是越来用于修改以前的错误,还是做新的功能。如果老是承担过去,那么就要问问自己的代码质量了
代码风格
什么叫好的代码风格呢?就是别人接受你的摊子的时候,没一边读你代码,一边骂你祖宗十八代
注释
emmm,好吧,我不是大牛,我不能做到代码就是最好的注释
。那么,就好好的写好注释吧。
清晰的注释可以:
- 自己以后能看得懂自己代码
- 别人接受摊子的时候少骂娘
典型的,如果涉及的类的逻辑有点多,最好按照1 2 3 4 5 6
一一列出来,写清楚,把逻辑说明白了。想象一个新同事刚加入项目组,怎样让他快速看明白我们的代码
一些公共工具类,里面的参数必要的最好解释清楚,这些参数干嘛用的
代码组织结构
如果按照功能划分,公共工具类一块,配置类一块,公共常量一块,公共异常一块,他们又都可以放在common包下面
按照每一个功能模块,每一个大功能用一个大包,子功能用一个小包
为什么这么分呢?我觉得,写代码的时候大家肯定按照功能块分工的。每一个功能模块一个package,大家互相不干扰是最好的。然后一些公共工具类很可能是leader写的,毕竟是团队最能打的
命名风格
怎么说呢?如果洋里洋气就都洋气一点,国产特色就大家都国产一点,总之高大上也罢,土里土气也好,商量个合适的风格出来,大家保持一致
开发效率
开发效率和很多相关,程序员的技术熟练度,工具趁手与否都有关系
可以从下面几点考虑提升效率,
- 构建公用工具类,大家都用
- 使用名声好的开源包
- 快速找出问题,主要是try-catch,打log的相关配置、操作有关。就我个人而言,目前就是一手debugger和单元测试或者直接蒙一个地方
小结
主要涉及到项目的质量管控方面的一些忠告