悟鸣的技术博客

57岁的程序员陶建辉曾因错过即时通讯风口而遗憾，2007年他早于微信团队开发出免费短信应用"和信"，却因市场环境不成熟而失败。如今，他创立的涛思数据迎来AI新机遇，推出工业数据管理平台IDMP，主打"无问智推"功能，利用大模型自动分析工业数据，无需人工提问。陶建辉认为AI消除了行业知识壁垒，让基础软件公司能直达终端用户，这次他决心全速抓住从百亿到千亿规模的市场机会。

然而，让人感到困惑的是，现在越来越多的小公司也开始大量采用关注数据结构和算法的面试题，这让一些人产生了疑问，因为他们认为 “Leetcode能力” 并不能准确衡量他们的工作实力。在使用 Leetcode 刷题过程中，我学到的很多内容都源于对他人代码的仔细研究，并将他们的建议融入我的工作。在大规模使用的情况下，数据结构和算法的有效实现对于应用程序的性能和稳定性影响深远。在我成功刷完了 Leetcode 上 400 道题之后，我获得了一些宝贵的经验，这些经验对我在软件开发方面的理解和方法产生了深远的影响。

原文链接：https://cerebralab.com/Imaginary_Problems_Are_the_Root_of_Bad_Software网友评论：https://news.ycombinator.com/item?原文作者：George译者：明明如月学长任何的工具使用情况、团队沟通的质量、开发者的投入水平以及采取的测试手段等，都可能成为低质量软件的诱因。我认为，导致低质量软件的根源是：虚构问题。

高质量的文章通常具备以下特点：另外，通常来说很多知识付费平台的热门专栏、很多知名开源项目的官方文档、很多大厂的技术公众号的文章质量也非常高。《对抗软件复杂度的战争》，就是一篇不错的高质量文章案例。大家可以大致浏览一下，该文图文并茂；引用文章众多，论证充分；能够结合源码和经典的理论；能够引发读者的思考。本文主要结合自己的写作经历，从战略和战术两个层面讲述如何写出高质量的文章，希望对大家写作有帮助。如果你有不同的看法、有补充的建议，欢迎在评论区和我交流。

最近在代码审查时，会发现一些校招新同学会把一些步骤当做 Service 的方法，在 Facade 层对这些步骤进行编排来完成一个完整的功能。这显然是不太正常的。Facade 层通常作为前端或者其他服务调用的入口，主要负责参数校验、构造底层服务所需的参数、结果转换等。不应该将单个业务功能拆分到 Service 中，在 Facade 中对这些方法进行编排，最终完成一个业务功能。Facade 作为门面，本身不应该有业务逻辑，业务逻辑应该放在 Service 层。Service 的每个方法应该能够独立完成一

一、背景前一段时间听到周围有人认为：“函数名起的困惑无所谓，反正别人使用接口的时候也会看下源码的”，让我非常吃惊。我一直也是认为，好的代码应该是看到函数名就应该知道含义，看到参数和返回值就应该可以放心使用，而不是非要去读源码才不会误用。今天重读《代码整洁之道》，看到书中提到：函数名称应该表达其行为。如果你必须查看函数的实现（或文档）才知道它是做什么的，就应该换个更好的函数名或者重新设计功能代码或者起个更贴切的名称。（原文翻译有些生硬，这里自己改了一下）二、示例比如只想查询用户的姓名、年