当我们开发一个功能时，应该如何具体的开展工作。通常对于经验较浅，对编码活动认识不足的新人来说，容易草率开始，想到哪里写到哪里，简直抑制不住内心敲打键盘的冲动。但事实告诉我们，做事情要讲究方式方法，谋定而后动，不打无准备的仗，所谓：磨刀不误砍柴工，下笔如有神。
以往我们会把这个过程以程序设计文档的形式体现，不过对于快速迭代的项目而言，其实可以把它作为一个可选项。大多数的现实场景里，我们面临着需求的频繁修改，几个版本迭代之后，同一个功能也许已经面目全非，更有甚者直接被废弃掉了，对于游戏类型的项目而言，更是需要快速试错。
所以在平衡开发效率与质量的情形下，完全拘泥于某种形式与套路是不合适的。比如对于一些短平快的项目，更是看菜吃饭。这种情况下，对一些入行者造成很多误解和错觉（特别是大学时期也没有得到规范的编程训练的同学而言），意识里对编码作为一项非常严谨的活动认识不足。
程序设计过程
可以分解为以下几部分，形式不必一定落实到纸面上，讲究的是一种思考方式。
-
- 结构拓扑图：熟悉业务之后，描绘整体逻辑控制流的轮廓。
- 数据模型：是最重要的工作。编码行为本质就是对数据的增删改查而已，数据模型决定了架构的方式。
- 流程拓扑图（UML图）。
- 预实现 （伪代码（接口定义）+ 注释）。
- 自我测试。
- 其他：控制台设计。
- 命令输入功能
- Log打印功能
预实现
-
- 构建逻辑流程的空间结构：定义数据源，逻辑脚本文件和整理文件目录等等。
- 定义接口，用文字描述逻辑流程中每一关键步骤的含义，这个过程同时完成了对代码的注释。
自我测试
应用软件开发，确保开发过程高效高质，首要考虑的两个维度：一，面向维护 二，面向测试。做为程序开发人员至少应该做到逻辑性测试的高通过率。另外如果不是往技术专家向发展，那么应该在功能性测试上做更多的积累，关注产品功能的合理性，更优的用户操作体验，或者更优的视觉听觉反馈等。
-
- 写好测试单元（用例）
- 定义与实现各种测试API（构造假数据来访问正式API接口）
- 模拟假数据（包括各种边界条件）
- 写出必要且详细的日志，这是最通用高效的方式。也许有人会反过来理解，觉得断点调试更优。但是又如何对生产环境的问题做断点呢。
- 输入模拟（用户操作）
- 图形化（控制台_输入设计（按钮，输入框等））
- 动作（定义一些独特的动作类型，3次点击，划圈==）
- 输出结果（反馈展示）
- 美术向 直接看画面表现结果
- 逻辑向 执行流程和数据 通过控制台Log
- 更进一步：性能
- Profile工具分析痛点情景
- 打印一段代码的运行消耗时间
PS：单元测试3原则
-
- Arrange：准备对象，创建对象并进行必要的设置
- Act：操作对象
- Assert：断言某件事情是预期的
