先把问题搞懂，好吗？
作为一名技术人员，我热衷于讨论技术。随着讨论的进行，经常会有如下的对比，例如JVM vs. Net，Java vs. Kotlin，Go vs. Rust，Maven vs. 不知道哪个，等等。随之，我们会经常深陷我们所热衷的那个技术的优缺点的泥潭，讨论了几个小时也不能达成共识。
几年前，我还是一名“解决方案架构师”。这个工作的头衔有好几种，比如，解决方案设计师，解决方案工程师，但目标就只有一个：为某个问题找到“最佳”的解决方案，但在大多数情况下，这个问题却属于业务范畴而非技术。
该工作一般分为以下几个步骤：
讨论问题
评估替代方案
选择最合适的。有时候，这一步需要业务方来拍板。
大多数人都是看到第一步就直接跳开，因为太老套了。但，这里有一些轶事分享给大家，我希望通过它们来强调我的观点。
— 1 —
“我想要一套Drupal”
“我想要一套Drupal”
当时，我在一家公共行政机构工作。请允许我不透露具体是哪一家。他们的流程要求每个项目都应该包含一名解决方案架构师来实现上述工作流。
有一天，一个项目经理要和我开会讨论一个新项目。他描述要解决的业务问题如下：“X部门的IT主管想要一套Drupal。他有很大的政治权力，因此咱们开始搞吧。”
不用说，我对他的做法感到非常惊讶。我尝试和他讨论，到底出了什么问题为什么需要这个，但没有成功。他不想解决根本问题，他只想服从领导的一时兴起。
由于官僚主义的性质，他遵循的流程中需要一名解决方案架构师来验证任何一个解决方案。因此他只需要我做的是：批准领导想要的解决方案。我离开了房间，我也忘了谈话到底是怎么结束的，反正我没有批准任何事。
作为一个附注，在组织中，那些只扮演代理角色的人具有非常低的投资回报率。有些组织往往非常吸引他们。例如，那些没有竞争的组织，不受低投资回报率的任何后果所影响的组织，比如公共行政部门。
— 2 —
需不需要.env文件
需不需要.env文件
最近偶然发现了另一个例子。一位谷歌工程师写了一篇文章[1]，名为《现在请停止使用.env文件！》，在这篇文章中，他解释了.env文件的一些问题以及如何使用配置服务器解决来它们。
作为回应，另一位作者发表了另一篇文章[2]，名为《请继续像往常一样使用.env吧！》。看得出，这位作者的重点是解释.env文件是可以接受的，并描述了使用配置服务器会有各种问题。
最初作者的文章几乎没有详细描述这个问题，也只是某个段落中简要的提了一下。随后，原作者对这位作者回应道：我完全不需要解释配置服务器好不好，他欠我一个道歉！
事实上，这个回应的作者所发表的揭穿真相的帖子并没有获得掌声。
总的来说，人们都太专注于自己最喜欢的解决方案，却都没有很好地解释在他们的环境里他们到底遇到了哪些痛点，并用什么解决方案来解决这些痛点。
PS：原文中的问题是.env文件管理无法扩展。对于谷歌这样规模的组织来说，这确实是个大问题；但对于一个小型组织来说，它们确实挺好用的。
— 3 —
很多问题并不需要微服务来解决
很多问题并不需要微服务来解决
当下很难忽视微服务的热潮，许多人都在热衷评论微服务的优缺点；但很少有人写他们为什么要用微服务。
在之前的文章中，我一直在谨慎地解释为什么微服务在大多数组织中其实是个糟糕的想法。也许我并没有讨论微服务能解决什么问题，所以这里有一个：
成功的组织会不断壮大成长。大多数时候，开发团队会随着IT一起成长，以支持业务增长。在某一点上，团队必须分成几个子团队来处理业务的增长。
这就是问题之所在。现在，许多开发人员必须在相同的代码库上工作。因此，我们一般通过以下方式处理这种复杂性：
不同的开发流程，例如Git流、GitHub流、GitLab流
一个专门负责发布管理的人
我的经验告诉我，这种方法当达到某个极限的时候会触发一些问题，比如当开发人员数量达到大约70人时，我看到了很多有经验的开发团队的同步问题。
当然，这也只是我的个人看法，也许其他人有不同的经历。
无论如何，这是我们需要讨论的核心问题。只有这样，我们才能决定到底什么样的替代方案能够解决开发团队的增长。
— 4 —
技术支持也要对问题产生疑问
技术支持也要对问题产生疑问
即使是技术支持，首先也要讨论问题。支持人员们通常会直接回答用户提问的问题并给出解决方案。我认为这是最糟糕的做法：它可能会完全忽略潜在的真正的问题，提供了一个不合格的解决方案。
下面的片段是一个来自StackOverflow的例子：
我想添加一个从Git中拉取的项目，然后用Maven构建。问题是他们的pom.xml同时使用私有和公共仓库，他们告诉我删除私有仓库来构建，就可以正常工作了。
——如何在构建之前从pom.xml中删除repo[3]
答案聚焦在如何从pom.xml中删除内容，因为这是那个人当时问的问题。但问题有所不同：问题在于如何构建一个引用了无法访问的仓库的项目。删除XML行是众多解决方案中的一种，但我觉得这是最不优雅的一种。
如果是我回答，我可能会建议那个人在Maven设置中配置一个镜像。
— 5 —
五个为什么
五个为什么
为了解决总是不深究问题而是紧盯解决方案的情况，我建议采用“五个为什么”的方法：
“五个为什么”是一种迭代式的疑问技术，用于探索特定问题背后的因果关系。该技术的主要目标是通过重复问五次“为什么？”。第五个为什么的答案应该可以揭示问题的根本原因。
——https://en.wikipedia.org/wiki/Five_whys
恕我直言，一个人可能不需要五个为什么，有几个就够了。通过深入研究问题的方法，你将发现许多上下关系，找出根本原因，那么，你也可能会让一个开明的领导（或业务方）改变他之前的想法。
此外，你可能会注意到，非IT解决方案在某些情况下是最适合的。请记住，最好的代码是无代码。
— 6 —
结论
结论
工程师喜欢谈论他们最心仪的的解决方案。然而，在没有上下文的情况下对解决方案持不同意见是没有任何意义的。不讨论问题就同意解决方案是更糟糕的。
讨论问题本身可以让我们洞察问题的实质。如果你想提升价值，你应该花更多的时间去思考问题是什么。
相关链接：
https://dev.to/gregorygaines/stop-using-env-files-now-kp0
https://dev.to/wiseai/continue-using-env-files-as-usual-2am5
https://www.reddit.com/r/devops/comments/ht3m2u/how_to_remove_repo_from_pomxml_before_building/
推荐阅读：
分布式实验室策划的《Go实战集训营》正式上线了。这门课程通过5天线上集训，4个练习项目，40天课后辅导，和学员一起一步一步基于Go常用框架搭建起一个可以访问MySQL、Redis和第三方服务的Go服务，并进行线上调试，排查问题。培训重实战、重项目、更贴近工作，边学边练，1月7日正式开课。