Linux开发:别瞎造轮子,学会站在巨人的肩膀上

最近在适配Ti Am62x平台，在Uboot下实现只有按下指定的键才能进入uboot的命令行和生成uboot的版本号以方便传输给内核。以前的代码，改来改去，非常不友好，这次借助AI，了解了u-boot的对应机制后，几乎不用修改代码，就实现了功能，所以就有了此篇文章。

我们在实现需求时，是要自己造轮子，还是要在前人的肩膀上，进行二次开发？

在一般的Linux系统开发过程中，十有八九都是增删改的需求，很少有从零写一个全新系统的情况。

就拿最常见的u-boot来说，经常会进行一些小修改

• • 比如产品要求，给uboot加个功能，即按下指定按键就能停止autoboot，方便后续进入uboot命令行调试；
• • 又或者领导要求，给uboot加个自定义版本号，方便后续排查问题，

这两个需求都很常见，想一想，怎么实现？

• • 实现autoboot停止方案，是不是想着怎样得到键值？怎样进行判断？怎样进行处理？怎样进行防抖？
• • 实现版本号，是不是想着怎样生成版本信息？怎样引脚版本信息？怎样编辑版本信息？怎样立即更新版本？
• 
  其实uboot本身就有成熟的相关机制，不用瞎折腾，直接配置或照猫画虎就行，但前提是你得知道、了解它们，否则就得造轮子

Linux以及其生态（uboot/kernel/rootfs以及gnu)，虽然发展也没多少年，但每一行代码、每一个模块、每一种机制，都是全世界各个领域的技术大佬，花费几年甚至几十年，一点点精心设计、反复迭代、慢慢优化形成的。背后都藏着他们的经验总结和踩过的坑。只要我们各个击破，掌握其中的脉络，再借助AI，学习深挖其中的要害，就可以站在巨人的肩膀上做上。

但实际上，在很多场景下，初学者（甚至干了很多年但不懂原理的老程序员），遇到修改、增加、删除功能的需求，第一反应不是去研究现有代码/机制，而是想着快速实现，重新造轮子。深究下来，无非两个原因，说出来可能都有共鸣。

• • 第一个，就是对Linux生态代码和底层机制理解不够深，自身知识储备不到位。比如给uboot加“按下指定键停止autoboot”的功能，其实u-boot代码已经设计了对应的机制，如果理解到位，根本不需要修改代码，运用现有代码或机制的逻辑，经过简单的配置，就可以实现此功能；或者让加自定义版本号，如果不知道uboot已有的版本信息机制，不知道u-boot代码里版本号是在哪里定义、编译时如何生效的，没办法，只能想着自己从零写一套，觉得这样更简单，其实反而绕了大弯，不仅耗时，写出来的代码还容易出bug，稳定性根本比不上现成的框架。
• • 第二个，就是有点强迫症，总想用自己的架构、自己的思路来实现。觉得别人写的代码不够优雅，不符合自己的编程习惯，非要推翻重来，哪怕别人的代码已经经过千锤百炼，在无数个项目里验证过，稳定得不行，也非要自己造一个。比如加停止autoboot的功能，明明uboot里已有现成的按键检测框架和autoboot控制接口；又如加自定义版本号，明明uboot有成熟的版本管理机制，非要自己重新写版本解析、重新控制编译流程，最后不仅耗时耗力，还可能因为考虑不周全，导致功能异常，甚至影响uboot正常启动。

其实完全没有必要，完全可以站在巨人的肩膀上，运用现有代码或机制的逻辑，经过简单的配置，实现功能。真没必要这么折腾，也不需要折腾。做开发，核心是解决问题、提高效率，不是炫技，怎么简单、怎么稳定就怎么来。最好的办法，就是学会站在巨人的肩膀上，也就是好好研究现有代码的逻辑，顺着大神们设计的思路来，稍微做些配置、改几行关键代码，照猫画虎，就能轻松实现需求，既省时又稳当，不管是停止autoboot还是加自定义版本号，抑或是其他，都是这个道理。

甚至退一步说，就算要做的项目脱离了Linux生态，比如自建一套嵌入式系统，也不用完全从零开始。同样可以把Linux里成熟的机制、逻辑移植过去，稍微适配一下自己的生态，就能达到事半功倍的效果，既稳定又高效，何乐而不为？

写在最后：做Linux开发，不是说不能造轮子，而是要分情况。在现有成熟框架能满足需求的情况下，别盲目造轮子，多借鉴、多利用现有资源，不管是uboot的停止autoboot功能，还是自定义版本号，都能借助现成机制快速实现，把精力放在核心功能的优化上，这才是最聪明的做法。毕竟，巨人已经给搭好了梯子，何必非要自己再搭一个呢？省时、省力、不出错，才是开发的核心追求。