… 我确实记得在职业生涯早期为一家小型工程/制造原型公司工作的时候，他们自己做软件，有一位资深开发人员英语说得不是很好，但他一直坚持认为“业务层”应该放在上面。他真的说得对。我无法想象这样简单而表达不准确的句子中蕴含了多少智慧和经验。其实其他都不重要。在我看来，函数式与命令式只是一个次要的问题，基本上是个分散注意力的东西。
源讨论简化你的代码：函数式核心，命令式外壳原帖 213 条评论 · 导入时统计把你的经验，加入这段讨论。
> 即使是大公司，在编写好代码方面仍然在抓瞎 可能有很多原因，但我经常看到的是，一旦代码库被破坏，之后就会一落千丈。 添加功能通常需要更多的临时解决方案。另一种选择是修复混乱，但这并不是当前任务的一部分。
完整原文这些是非常棒且简洁的，你和你队友的。 我仍然会在这内部争论，但一个客观的指标是，我较长的假期进行得有多顺利： 我唯一没有接到任何紧急电话的时候，是我给队友留下了一组大型且非常具体的shell脚本和/或可执行文件，这些脚本/可执行文件只做一件事。没有配置文件，没有参数/选项（或者极其有限），每个文件的名称都像run-config-a-for-client-x-with-dataset-3.ps1，这些文件处理了我预计他们需要完成的一个任务。只需双击这个文件，当你得到新数据集时，或者克隆/重命名它并修改第8行，如果你需要为新客户运行它，就是这样。 查看这些脚本/程序的内容看起来与我所学过的所有DRY或其他类似原则相反（除了KISS和其他类似简单的原则） 但结果自己说明了一切。进一步来说…
完整原文> 越具体，越脆弱。越通用，越稳定。不同的关注点以不同的速度演变/衰退，因此不要在不同层之间耦合。注意语法/音系（结构）变化缓慢，而词汇（功能、服务）变化更快。 ... > 在不同层之间耦合会带来麻烦（例如，用“直观”的名称编码业务逻辑，反映临时的理解）。当需求变化（功能、法规）时，库维护者会引入破坏性更改或新的处理器架构出现时，我们稳定的根基，与快速变化的部分纠缠在一起，仍然会破裂！ https://alexalejandre.com/programming/coupling-language-and-...
完整原文"通用核心，具体外壳。" 你的建议与"功能核心，命令外壳"相反。FCIS原则中的IS是通用的，为了简单，因为通常很难测试（它涉及资源和外部依赖）。因此，通过保持简单，它更容易进行单元测试。 另一方面，FC是业务逻辑所在的地方，可以复杂且具体。之所以想要这个"功能"（其实只是另一个名称，指"由小块组合而成"），是因为它可以不依赖外部环境来测试其有效性。 因此，IS可以让你避开外部依赖的技术细节，比如数据库有什么奇特之处，我们是通过网络发送数据还是写入文件，或者用户是用西班牙语还是英语输入命令，显示绿色方块还是蓝色三角形来表示报告已准备好等等。 另一方面，FC处理的是…
完整原文> 正确的哲学是"通用核心，具体外壳。" > 其他一切都无关紧要。在我看来，功能与命令式只是次要的问题，基本上是种干扰。 我对此感到矛盾。这确实是提高质量的更快方式。 另一方面，如果更多的开发人员知道这一点，当我为客户创建系统时，我就不会那么快了。我只会是一个"普通的1倍开发人员"。 我喜欢在没有AI辅助的情况下，比使用Claude代码的开发人员在他们的$FRAMEWORK上更快地在我的业务应用程序中实现功能。
完整原文非功能核心往往会变成一个充满错误的混乱局面，外壳中需要有各种变通方法来弥补这些错误，然后就需要了解核心的性质才能正确使用外壳等等。功能核心则非常容易进行单元测试。当功能核心做得正确时，编写测试几乎变得微不足道。命令式外壳则成为次要问题，因为错误的影响范围被限制在核心的一次使用中。当然，命令式外壳应尽可能保持简洁。
完整原文在我的想法中，以及它描述的通用和具体是相反的。核心处理一个具体、纯粹的问题。核心是通用的（你是通过HTTP、数据库、文件系统等获取数据）然后这些变得与核心问题无关
完整原文我甚至会说，大公司在这方面比小公司更难应对。需要了解如何正确构建事物的人数比小公司多，小公司可能只需要一个有知识的工程师就足够了。人太多反而会把汤（或炖菜）搞砸了。而如今有太多人在“做饭”。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。