如何开始一个功能的开发？这个问题估计有很多人思考，但是很难找到一个方法论。就跟老师上课讲结题思路一样，他只存在于那个老师的脑海里。每个老师对于同一个题目的解题思路或多或少都会有不同。开发程序就跟解题一样，解题时，我们会在脑海中思考思路和步骤，会在草稿纸上涂涂画画。在开发之前，我们需要做什么？
明确需求
当需求的提出者，可能是项目负责人，也可能是产品经理，需要你来开发或者几个人一起开发的时候，需要开发者非常理解需求提出者提出的需求。不明确的地方需要通过提问、画业务流程图或者其他方式进行确认。
设计
一种思考和沟通的过程
设计是将思考和沟通的结果转化为实物的过程。 设计是功能、模块、软件开发的前期工作，也是非常重要的工作。一个好的设计是一个功能、模块、软件开发成功的前提。 设计的范围很广。前期在跟用户沟通，确认需求时，需要有原型设计、业务流程设计。通过界面和流程图跟用户沟通需求是最直观方便的。 没有充分沟通的设计在后期会面临很大的推倒、重做的风险。 设计也指在功能开发时，使用什么函数、设计几个类，类的字段有哪些，类和类之间如何交互、使用什么设计模式、数据库如何设计、后期是否支持拓展、选用什么开源组件等等。
寻找参考和灵感
- 产品功能文档、设计文档
从网上查找相关的成熟案例，一些产品官网的设计文档，功能文档等，对于了解要开发的功能有更深入的认识。
- 产品的设计图、在线网站等
可以从国内的花瓣、国外的Pinterest等网站查找相关的web design设计图作为参考。
有些是直接可以在网络上浏览的demo或者网站，直接上去体验并截图作为参考。
消除地图上的战争迷雾
一个功能模块就好像一个战争地图，起初它是全黑的，什么信息都看不到。 思考的过程就是一个探索地图的过程，会逐渐将战争迷雾消除，展示出地图上的信息。 沟通和寻找参考也是打开战争迷雾的手段之一，只有将地图上的迷雾消除的越多，你能获取到的信息也就越多，信息越多，对于做出有效决策帮助就越大。该如何设计就更得心应手。
画业务流程图
可以是手画，也可以使用软件去画，主要就是用来确定需求和进行讨论沟通。
业务流程图除了需要跟用户沟通确认，也需要跟开发人员进行沟通确定，让开发人员理解功能开发的要求和目的。
简单的原型页面和流程图的结合使用，可以大大降低沟通的成本，使参与方都更加理解需要开发的功能形态。
梳理功能点
业务流程确定好之后，就要根据业务流程确定需要实现的功能。
功能分为主要功能和次要功能，主要功能直接服务于业务流程，次要功能服务于主要功能。
页面设计
如果没有条件使用软件进行页面设计，可以去网络上搜索别人的产品或者图片进行参考。在开发数据质量模块的展示功能时，通过Pinterest网站搜索data quality来搜索可用的参考图。这里选择了红色箭头所示的图片。
有条件的也可以使用AI工具进行设计，只需要说出条件，AI就可以给出设计图。
生成的效果图的好坏跟Prompt有关，可以去网上搜索一些别人整理好的Prompt，在自己做些微调。
技术选型
技术选型包括项目架构的设计、技术框架的选择，功能模块的设计和开源组件的选择，有时候需要使用适当的技术，比如多线程、设计模式来完成功能的开发，有时候需要引入一些中间件，这个都是需要经过评估和设计。 当功能点确认完毕后，就要根据功能点来大概思考一下，各个功能点的实现了。 简单的功能实现不成问题。有些功能实现比较困难，需要对相关的技术进行调研和选型。这个过程需要查找很多资料，了解相关技术的一些指标和使用场景，是否适配我们的项目。选择了1-2个候选技术后，就需要搭建简易的demo进行开发测试。 技术选型是否合适直接影响到项目、功能模块的成败。
开发
开发功能是开发人员的具体工作量的体现。而往往是开发人员唯一重视的一环。但这仅仅只是开发环节中最靠后的一环而已。 开发相对来说也是开发人员最拿手的一环，也是耗时最多的一环。但设计和沟通也需要引起大家的重视。
测试
自己对自己开发的功能负责，你就需要进行更多场景和条件下的测试。
评价
这一环非常重要。 前提是软件、功能没有bug。 对于一个功能、一个软件，开发出来就是给人去用的。那么评价一个功能和软件是否足够好的标准就是是否好用。 好用体现在哪些方面：
软件
- 界面主题明确
- 界面设计自带指引
- 性能强，加载快
- 易于上手，不会造成理解困难
- 色调统一，标准一致
代码
- 结构清晰、代码即注释，可维护性强
- 设计合理，可拓展性强
赏心悦目的程序，才能够最小化出现错误的可能性，使程序更具扩展性和可维护性，并且便利团队协作。这是因为“赏心悦目”意味着每一部分的代码都分工清晰明确，不同部分的代码之间耦合（coupling）、依赖（dependency）较小。因此，改动代码时只需要专注于某一部分代码的改动，而不需要来回改动整个代码库以至于出现“牵一发而动全身”的情况。
同时，“赏心悦目”的代码本身就是 “self-documenting” 的；代码的结构就很好地说明了每一部分代码的功能和设计初衷，因而极大地便利了团队成员间的沟通。
优化、重构
将以上的环节再走一遍，或者其中几个环节再走一遍的过程。 将软件版本从v0.1变成v1.0、v2.0的过程。 这是软件变得好用的必经之路。 使用和反馈是优化和重构的触发器。使用过程中出现的问题、用户的反馈都是触发开始优化、重构的信号。 要重视使用的体验和使用者的反馈。
例子
这是我工作中的情况，作为例子来说明一下重构的好处。
- 重构了质量检查模块的业务逻辑，定义了规则和方案域，将原本杂糅一起的SQL拆成了组合式，可拓展性变强，结构更简单。
- 重新设计了质量维度和规则，质检结果重新设计并使用了新的展示方式。
任何一环都很重要
一步错，步步错。 当需求没有经过充分的沟通和明确，之后的开发基于错误的认识去做的，往后的开发都是做的无用功。 技术选择不当，软件的性能、要求达不到技术要求，那就是得推倒重做。 设计是一个思考和沟通的过程，包含了很多的脑力劳动，贯穿于软件开发的整个生命周期。这个无法完全体现在工作量中，但对工作的贡献却非常大。 每一次循环都是一个功能的落地，模块的落地。在这个过程中提升实力，也需要在循环结束后进行复盘。复盘可以帮助我们更好的提升能力。
人是最重要的决定因素
以上的流程或者环节都执行了，最后还是达不到效果。为什么？ 因为软件不是工业化产品，没有标准，没法流水线生产，参与的人对软件质量的走向有决定性影响，这也是软件工程师、设计师工资比工厂工人高的原因。 两个不同的工程师开发同一个功能，其实现肯定不一样。 工程师需要的品质不限于：诚实，谦虚，向上，严谨，敬畏代码，健康的体魄，激情... 厉害的工程师的品质应该是我们追求的目标。 而有一些特点是我们需要去避免的。
没有思考的设计与开发
网上所说的码农就是指这个，机械式的搬砖。
自我陶醉型
呆在技术的舒适圈内，不愿意出来。鄙视一切。技术是盔甲，是盾牌。重视技术，忽视业务。 功能的实现以新技术的使用为导向。 工作是为了学习新技术、炫技，而不是产出合格的功能和产品。
偷工减料型
出bug最多的类型。参数校验可以省，异常处理可以省，分支业务可以省，突出一个惜码如金。