技术债务与工程能力：ChatGPT的启示-优快云博客

闲聊技术债务到工程能力

闲聊技术债务到工程能力

技术债

最近互联网公司不太平，阿里、滴滴、腾讯视频相继发生系统崩溃事件。11月12日，阿里系多款APP出现无法访问或服务异常情况。11月27日，上海、北京、广州等多地用户反馈，滴滴出行APP无法使用，地图无法加载。12月3日晚，腾讯视频出现网络故障，VIP用户看不了会员视频¹。这几家"大厂"的崩溃事件影响着实不小，都在热搜榜上有名。

看到这些新闻，我脑中第一个跳出来的词竟然是"屎山"。后来在网上遇到"技术债"(technical debt)这个概念之后，我觉得大家可能就在经历典型的"欠债"和"还债"过程。

欠债

"技术债"不是个新概念，早在1992年被提出，在2016年的Dagstuhl研讨会上给出定义。
技术债务类似金融中的债务，这个术语描述了未来的成本，产生此"费用"的原因是目前选择了一个简单的解决方案而非使用需要花更长时间才能完成的更好的做法²。
常见的技术债包括以下几种³：

缺乏文档和注释，初期可能因为时间紧迫而省略，但随着项目发展，新成员的加入和代码修改的增多，缺乏文档和注释会导致代码难以理解。
负面影响：阅读和理解代码的难度增加，团队合作效率降低，维护成本上升。
忽略单元测试，初期为了加速开发可能会忽略单元测试，但随着代码量增加，缺乏测试会导致在修改或添加新功能时出现更多的错误。
负面影响：错误引入的风险增加，维护和调试变得更加困难，项目稳定性下降。
代码复制粘贴，为了快速解决问题可能会直接复制粘贴代码，导致相同的功能在不同地方有多份实现。
负面影响：修改和维护成本上升，逻辑分歧的风险增加，项目变得难以扩展和维护。
缺乏面向对象设计原则，如封装、继承、多态。
随时间增长：开发人员可能在快速开发中忽略面向对象的设计原则，导致代码不够灵活和可维护。
负面影响：难以适应变化，项目变得脆弱，增加新功能的难度。
缺少编码标准可能导致不同团队成员采用不同的编码风格，使得整个项目的代码风格不一致。
负面影响：降低代码的可读性和可维护性，团队协作效率下降。

为了赶上发布时间点而现场提交代码处理问题的行为，让我欠下了"技术债"。这些技术债如果不加以处理，就会像雪球一样越滚越大。最终可能导致"屎山"的出现，还会经常出现崩溃的情况。

还债

首先明确一点，技术债务是还不"清"的！随着产品的开发，只要有新的问题等待解决，这里面就留给了技术债存在的空间。就像国家和政府的债务也一样，是不会清零的。但还债是一个"一直在路上"的行为，也是一个逐步的过程，通常需要综合考虑团队的资源、时间和业务优先级。
知道了技术债的类型，就有了以下一些常见的还债策略：
制定计划：确定还债的优先级和计划。识别最紧急、最影响业务的技术债务，然后逐步解决。
重构：进行代码重构，改进代码结构、提高可读性、降低复杂度。重构有助于提高代码质量，减少潜在的错误，并使未来的开发更加高效。
自动化测试：增加或完善自动化测试套件。良好的测试覆盖可以保证代码质量，减少在修改代码时引入新错误的风险。
技术栈升级：将过时的技术栈或依赖项升级到最新的版本。这有助于提高系统的稳定性、安全性，并能够利用新特性实现性能优化。
文档和注释：补充缺失的文档和注释，确保代码的逻辑清晰，新的开发人员能够轻松理解和维护代码。
技术债务冲刺：将一段时间内的工作集中在还债上，形成技术债务冲刺。这个可以周期性的进行，也可以在功能刚刚发布，新的功能还没有提上日程的时候进行。
持续集成和持续交付：实施持续集成和持续交付流程，确保代码的频繁集成和发布，以减少集成时可能出现的问题。
培训和知识分享：对团队进行培训，分享最佳实践和新技术。提高团队成员的技术水平，有助于减少未来的技术债务。
监控和性能优化：加强系统的监控和性能分析，识别并解决潜在的性能瓶颈和问题。
代码审查：实施明确要求的代码审查，确保团队成员之间对代码质量的共识，发现并解决潜在的问题。这个在有些team中不被看重，老板也不觉得这是个工作量，更不会要求严格执行。被code review的人对待别人给出的comments嘻嘻哈哈，一句"下次注意、下次改"就过去了，这样的代码审查就形同虚设了。
还可以根据项目产品的特点引入"敏捷开发实践"，以更灵活、高效地开发和交付软件。这些策略都能够用于减少技术债务和还债的过程中。

到这里，让我想起了老板年中的时候为我们确定的下半年工作目标，其中一个是"提升工程能力"。我理解这里的"工程能力"是"软件工程能力"，就是一个个体、团队或组织在软件工程领域中设计、开发、测试、部署和维护软件系统的能力和水平。
而这些还债策略实质上就是提升工程能力的一部分，通过工程能力的提升，团队能够更加有效地应对和解决技术债务，开发出优秀的产品。

工程能力的榜样

2023年最火的应用之一就是OpenAI发布的ChatGPT，很多搞技术的人已经体验过。ChatGPT作为一个产品应用，"工程能力"在其中扮演重要角色，这里举几个例子：
用户体验设计：在网页版ChatGPT的开发中，工程团队需要考虑用户体验的方方面面。这包括页面布局、交互设计、响应速度等。通过良好的用户体验设计，用户可以更方便地使用ChatGPT。这里以temperature值举例：在将提示词给到大模型的时候，需要设置temperature的值，它负责控制 ChatGPT 生成文本的多样性。当 Temperature 的值接近 0 时，模型生成的文本将更加确定和一致，原理上就是模型将更倾向于选择概率最高的内容输出。当 Temperature 的值接近 1 时，模型生成的文本将会更加多样和无序，也就是说模型在选择下一个词或短语时会考虑更多可能性。
比如在写小说的时候，就需要ChatGPT进行比较自由的发挥，temperature值就要调到1.0甚至更大；而在提取文章内容，希望能够忠于原文作者意图的时候，或者在逻辑推理、数学计算的时候，这个temperature的值最好就设置为0.1或者0，不要ChatGPT来发挥。
如果用户没有显式指定temperature的值，系统会默认设置一个预定义的temperature值。这个预定义的值如何选取，就到了体现工程能力的时候了。
可扩展性： OpenAI首席执行官山姆·奥特曼当地时间11月6日在该公司首届开发者大会上宣布，ChatGPT目前拥有1亿周活跃用户⁵。随着用户量的增加，系统需要能够轻松扩展以应对激增的请求。

安全性与隐私保护：在处理用户输入时，工程团队需要考虑到安全性和隐私保护的问题。可能需要实施一系列安全措施，如输入过滤、防御性编程，以及符合法规的隐私政策。
技术支持与文档：为了提供更好的服务，工程团队可能需要建立完善的技术支持体系，包括在线帮助文档、API说明等，以帮助开发者用户更好地使用ChatGPT。

谈到ChatGPT，大家可能会忽视以上几方面的描述，大家关注更多的是它的大语言模型，觉得这个东西牛。它生成的对话结果有时候还真让人觉得超出预期。的确，大语言模型是ChatGPT的灵魂。但在灵魂深处，也依然体现着"工程能力"的影子。

作为OpenAI联合创始人和首席科学家，Ilya在上周的一个采访⁴令我印象深刻。Ilya提到了他的一个同事Alex，Alex非常热爱GPU，可能是当今世界上最擅长在GPU上编程的人之一。他帮助OpenAI能够从GPU里面榨取大量的性能和效率出来，才让他们取得今天的成绩。Ilya也提到，很多很多年以前一直到今天，其实都有很多人在机器学习领域里做研究，都是非常有兴趣去训练自己的超大型神经网络。但是他们却无法训练，主要就是在工程上不支持。
我理解这里面包含着至少两方面内容，在硬件支持上，没有高性能的GPU出现也没有强大的算力平台；另一方面，没有足够的编码能力，即使拿到了最高性能的GPU，依然无法让它发挥出最大的性能优势。

所以，无论ChatGPT模型本身的能力，还是作为一款应用能够以高效、安全、可扩展的方式发挥出最大的价值，我觉得ChatGPT可以作为一个值得学习的体现优秀工程能力的榜样。

小结

在技术创新的道路上，我们往往会积累一些看不见的"技术债"，这些债务既是对简单解决方案的一种妥协，也是对未来成本的一种拖欠。通过典型的欠债和还债过程，我们更深刻地理解了技术债的本质以及它在软件开发中的危害。
ChatGPT作为一个工程能力榜样，不仅在大语言模型的创新上取得了显著成绩，更在用户体验设计、可扩展性、安全性与隐私保护等方面展现了卓越的工程实践。
我们要做的就是从减少技术债出发，认识到工程能力的重要性，开发令用户满意甚至超出用户预期的产品。