技术团队要小心，那些技术过早优化的迹象

hi，我是熵减，见字如面。

在软件行业内，有一句关于技术实用性的名言：“过早优化是万恶之源。”

在局部代码层面上的追求先进，是无可厚非的事情。

但是，在一些小公司中，技术过早优化的现象又是很常见的。当小公司为了追求技术的先进性和高效性，往往会采用一些不适合自己的技术方案，导致开发成本增加，维护难度提高，甚至影响业务的稳定性和发展。

所以，公司在做技术选型和决策时，更需要足够的理性和慎重思考。

以下是三个在小公司中，比较场景的追求技术先进性的过早优化的现象：

• 直接上容器k8s
• 多种开发语言
• 自己造基础设施的轮子

直接上容器k8s

容器和k8s是目前非常流行的技术，可以提供高度的可扩展性，可移植性和自动化。然而，对于一些小公司来说，直接上容器k8s可能并不是一个明智的选择。因为容器和k8s的部署和管理需要一定的专业知识和经验，如果没有足够的人力和资源来支持，可能会带来很多问题，比如：

• 容器镜像的制作和维护；
• 容器网络的配置和安全；
• k8s集群的搭建和监控；
• k8s资源的调度和优化；
• k8s服务的发现和负载均衡；

这些问题都需要花费大量的时间和精力来解决，而且可能会影响到业务的正常运行。对于一些小公司来说，可能更适合使用一些简单的虚拟机或云服务来部署应用，这样可以节省成本，降低复杂度，提高稳定性。

多种开发语言

在软件开发中，有很多种不同的编程语言可以选择，每种语言都有自己的优势和特点。有些小公司为了追求技术的多样性和创新性，会使用多种开发语言来开发不同的模块或服务。这样做可能会带来一些好处，比如：

• 提高开发效率和质量；
• 满足不同场景和需求；
• 增加团队的学习和交流；

然而，使用多种开发语言也会带来一些挑战和风险，比如：

• 增加沟通和协作的难度；
• 增加代码库和依赖的管理；
• 增加测试和部署的复杂度；
• 增加维护和更新的成本；

对于一些小公司来说，可能更适合使用一种或少数几种开发语言来保持技术栈的统一和简洁，这样可以减少沟通成本，提高协作效率，降低技术风险。

自己造基础设施的轮子

在软件开发中，有很多基础设施可以支持应用的运行和扩展，比如数据库，缓存，消息队列，日志系统等。有些小公司为了追求技术的自主性和定制性，会自己造一些基础设施的轮子，比如：

• 自己开发或修改数据库引擎；
• 自己实现或封装缓存服务；
• 自己设计或改造消息队列系统；
• 自己搭建或优化日志平台；

这样做可能会带来一些好处，比如：

• 提高系统的性能和稳定性；
• 满足特定的功能和需求；
• 增加系统的可控性和安全性；

然而，自己造基础设施的轮子也会带来一些问题和风险，比如：

• 增加研发和测试的难度；
• 增加运维和监控的压力；
• 增加兼容性和可移植性的问题；
• 增加技术债务和迭代成本；

对于一些小公司来说，可能更适合使用一些成熟的开源或商业产品来作为基础设施，这样可以节省时间和精力，利用社区或厂商提供的支持和服务，避免重复造轮子。

总结

在一些小公司中，做技术决策时，在趋势和习惯的裹挟下，是很容易被所谓的新技术和理想所带偏跑歪。

虽然技术过早优化和先进性，可能会带来一些短期的收益或满足一些个人或团队的兴趣或需求，但是从长远来看，技术过早优化可能会给小公司带来很多问题和风险。

因此，在选择技术方案时，小公司应该根据自己的实际情况和业务目标来做出合理的判断和权衡，并避免盲目地追求技术过早优化。

正所谓，学霸两支笔，差生文具多。用最简单的工具，是可以解决掉大部分的问题的。

技术只是解决问题的工具，技术的先进性和自主型不是业务类公司初期的关键。