枫芸志

关于开发的一点思考总结

代码开发模式

• 对于需求相对明确的，可提高每个环节的质量减少多次迭代成本
• 对于需求不太明确性的，可采用快速迭代型开发，通过多次优化完成开发需求

代码开发流程

• 需求确定、需求验证：可白板模拟点击进行验证
• 技术方案设计：数据存储结构设计、实现方案设计、代码结构设计
• 功能设计、编码开发
• 功能测试、集成测试、回归测试
• 功能验证、用户验证
• 发布




代码规范

• 合理定义变量、函数，规范命名、意义明确
• 代码缩进、空格、换行、大小写合理易于阅读
• 适当增加复杂、意义不明显代码上的注释方便理解
• 规范类、数据库设计，以便后续维护扩展

代码的可扩展性

• 避免硬编码参数配置值，改为配置文件、数据库、设置界面等方式便于参数修改
• 功能上进行合理性扩展联想，在设计上做合理的预留和拓展性兼容考虑

代码的性能优化

• 优化算法提高代码性能
• 采用中间变量、Cache存储中间结果避免重复计算，避免重复计算
• 利用变量、内存Cache、数据库Cache等多层缓存优化性能
• 建立数据库索引、优化数据库查询提高数据查询性能
• 数据量大的情况下，可用分库分表进行数据存储
• 请求和计算大的情况下，可以对数据库服务器、请求处理服务器、计算服务器等做负载均衡

代码的安全考虑

• 将用户进行分组并赋予不同的权限便于用户权限管理
• 对所有用户请求和操作做登录信息认证和权限认证
• 对所有资源访问做权限认证
• 防范各类安全注入

代码的容错性

• 检查边界条件
• 检查“零”值、无效值
• 检查异常访问、无效请求
• 适当增加异常处理和错误提示方便纠错

代码的可维护性

• 采用团队的最佳程序设计实践和代码书写规范
• 每个函数只实现一个明确的功能
• 避免重复代码，如代码结构不清晰时考虑重构
• 可以先写测试用例再写代码，测试驱动型开发，编写的代码应该可测试
• 将重复代码降低到最低程度，采用类继承设计、函数抽象等方式
• 采用接口继承，规范类设计
• 适当增加关键性调试、检测代码方便查错

代码维护的成本

• 对于不明确的需求尽量在开发最开始就做到清晰确定，避免后续的返工修改
• 对于Bug确定问题的根源后，再来考虑解决方案，有理有据并能清楚认知到各个方案的优劣做出取舍
• Bug越到后面修复成本越高，设计》开发》发布后修复
• 后期修复设计重新Investigate，花费调查成本、修复和测试成本，成本大大增加

代码的维护

• 确定问题后，明确根源来自于代码漏洞还是设计缺陷，再进行处理或修复
• 举一反三，确定当前问题在现有的其他场景下是否同样存在，是否可以统一修复
• 未来考虑，如何在未来编码中避免此类漏洞，如只是代码性是否可以通过编码检查来预防，设计性的是否可以增加需求验证实践来减少

Bug管理

• 使用统一的Bug管理系统进行Bug管理
• 详细描述Bug相关的重现步骤、影响范围、分析结果和修复方案，并附所有相关文档，便于后续跟踪
• 明确Bug处理流程：
  • 未发布产品Bug：可只分Active、Resolved、Close
  • 线上产品Bug：Triage、重现、调查分析、修复、测试、发布、线上测试

代码交付物的管理

• 采用版本控制服务器对代码进行管理，并在每次Check in时添加明确的修改说明便于跟踪
• 有多个大项目或大版本同时开发时，可采用多个分支进行管理，开发完成后合并回主分支
• 对相关设计文档、需求文档、测试文档进行统一集中式管理，方便查阅



本博客所有文章如无特别注明均为原创。
复制或转载请以超链接形式注明转自枫芸志，原文地址《关于开发的一点思考总结》
标签： 笔记
分享：