一次不太愉快的软件开发

整体的开发感受是：缺乏一个合理的、完整的软件开发流程或规范。

• 合理是指：大多需求都是由领导拍脑门、飞书、现场沟通传达。尤其在面临这种前路未知、需求多变的任务时，由于背景知识的缺乏， 沟通会更加吃力。最大的缺点是难以记录，不利于软件的维护、更新等。需要加什么功能，改什么功能，为什么这么做，无从查起。

• 完整是指：什么时候开会和立项，什么时候讨论，怎么样算完成，软件如何发布，如何维护，这些东西没有任何规范。一个软件的生命周期，从需求分析到维护，这些都没有。整体感受和学生时代的大作业没啥区别。

• 沟通效率很低。

  • 逐字、逐标点符号对文档十分没有必要，应该关注大纲。需要知道目标是什么，有哪些场景即可
  • 以为刷新一下就实现的东西，说快速让我实现一下。但需要很复杂的数据传输与解析，脑子幻想的东西实现起来也许很费力
  • 一开始不要讨论代码，浪费时间。一开始的讨论都是基于颅内 debug，到后面会发现之前讨论的代码很可能无法实现，或者说并不是最优的实现方式。代码写到那里，自然而然的会发现更好、更便捷的实现方法，回过头来发现前期的讨论除了浪费时间和耽误进度外，没有任何价值。

• 应用场景，用户需求没有任何调研。

  • 未调研用户的需求，并没有得到他们的反馈。只是在满足领导想象出来的需求。假设有 50 人用软件，领导说你软件写的不行，不符合他的要求，一直提需求导致软件迟迟没有发布，项目一直 delay，自己很着急，老板很失望。我想写小而美的软件，后面慢慢添加功能；领导希望一次性支持全部功能，这仿佛真的很难实现。比如今天 AI 组又提了一个新需求，超出了我们最开始的规划，真的很难一次性实现全部需求。
  • 其实呢，也许你的软件 20 人用着是满意的，20 人用着是觉得凑合的，9人觉得还需要改进，只有领导觉得这里不行，应该这样显示；那里不行，应该加个隐藏按钮。但也许 30 人觉得那个隐藏按钮多此一举，10个人觉得千万不要加隐藏按钮，只满足一个人的需求是没有意义的。换句话说，领导该把控大的方向，而不是纠结是否添加一个隐藏按钮。

• 临时添加功能过于繁琐。

  • 想临时看一下峰值内存、想临时加一下 unknown 函数调用、想取消 unknown 的函数调用、想随便生成一个表看看界面什么样子。这些至少还是能应付的，改几行代码去应付即可，只不过累一些。而这些繁琐的临时需求，会发现写完之后不在需要，只会一点一点的消耗耐心，浪费宝贵的积极性。
  • 后续再安排新任务时，会下意识的质疑任务的合理性，以及是否有必要去实现，产生一点排斥心理。

• 需求不明确

  • 当软件过于庞大，输入、功能、需求、应用场景其中之一发生严重变化时，这绝对不是改几行代码能搞定的。只有两条路可走：继续维护屎山代码，或者重写代码。
  • 所以一开始，最好讨论清楚目标是什么，功能是什么，支持的用户范围，最重要的是：做到什么程度就到此为止，哪些功能不需要实现，哪些用户不需要支持。等一切都清晰后，再开始去写代码。一开始被领导叫去写代码，还被要求实现很多的功能。后面和老板讨论后发现一些功能不用实现，一些功能需要改。看着手里的屎山代码，我选择了重写。
  • 如果功能发生大的变化，一定是前期的目标出了问题。作为领导，应该只要求大的方向，而不该关注和过分追求细节：比如按钮在哪个位置，信息如何提示给用户，文件命名等。比如文件名是日期+版本号，还是版本号+日期。小细节前期讨论会很浪费精力，后期修改又会更浪费时间、消耗耐心、浪费经历，十分没有必要。

如果某天我当了领导，我大概率会说：先调研，有无现有的高性能实现方案，是写异步函数还是同步函数。然后写技术方案，和我沟通后我确定做的方向与内容，细节你们决定。

如何维护？

• 需要修复一些紧急的 bug，立刻发布
• 大家提了一些共性的需求，库会周期性发布，一次性多实现几个功能
• 个别需求不考虑实现

提问和发布暂定使用 gitlab，将软件管理起来。第一次管理软件的维护和发布，处于探索阶段，还需要学习。功能实现或紧急 bug 修复后，关闭对应的 issue。