开源代码只是心里安慰，开源软件如何选择？
大家好，欢迎来到停止重构的频道。
本期我们聊一个比较开放的话题，也是项目中经常遇到的问题。
在实际项目当中，由于开发成本、上线周期等因素，不可避免地需要使用开源软件。
开源软件意味着源码公开。
但是，使用开源软件是否意味着易维护呢？
是否选择一个功能差不多的开源软件，再根据实际需要改动一下，成本就会大幅下降呢？
关于问题的答案，欢迎大家把自己的实践经历写在评论区。
而我们的实践结论是：不一定，特别是当项目需要持续维护升级的时候。
我们按这样的顺序阐明我们的观点：
1、 开源软件维护的真正难点在哪
2、 开源代码为什么难以理解
3、 开源代码改起来为什么尴尬
4、 如何选择开源软件
开源软件维护的真正难点在哪
实际上，绝大部分的开源软件都是不易维护的，除非只有几百或几千行代码。
开源软件虽然是代码公开的，但是维护开源软件的难点正是源代码的理解上。
无论是修改开源软件自身的bug，还是对开源软件追加功能，都是建立在代码理解的基础上的。
对于不能理解和掌控的源码，其实等于没有源码。
不能理解和掌控源码，就必定会出现修改一个bug出现十个bug，追加一个功能瘫痪几个功能的情况。
对于这些黑盒一样的源码，是无法较为准确地评估成本的，往往忙了很久，天天加班也只会跟计划越走越远。
即使很幸运地理解到源码的结构、脉络，也能顺利的添加功能，但是随着版本迭代，势必会越来越乱，维护难度会越来越高。
开源代码为什么难以理解
那为什么开源代码难以理解呢？
其实不仅是开源代码难以理解，别人写的代码、甚至是自己几周前写的代码往往都是难以理解的。
这跟是否有注释、文档是否完备、选用什么基础框架都关系不大，因为代码编写是非常开放。现有代码里有很多个if/else、有很多层函数/类调用、甚至有很多极具个性的算法。
理解现有代码，无疑是理解一张蜘蛛网。
值得注意的是，理解代码，并不是仅仅看懂了代码，理解代码意味着掌控了它，真正理解、掌控开源代码，也意味着需要花费很多不可评估的试错成本。
在之前讨论前端、后端架构时，我们都十分强调规整化的重要性，也提出了顶层架构的概念。
规整化是从根本上缓解现有代码理解困难的问题，如果可以拥有十分明确且简明的编码规则，千人一面地写代码，那么就可以大幅减少代码理解的成本，这会一连让开发效率、沟通成本、bug响应时间、维护升级成本大幅减少。
这并不是任何一个基础框架可以保证的，这也是为什么同是使用vue、SpringBoot 有的项目质量很高，有的项目大幅延期、成本超支的原因。
开源代码改起来为什么尴尬
在我们看来，开源软件的源码，很多时候只是心理安慰。
即使掌控了开源代码，在出现bug时，只能避开，而不能直接修改。我们经常翻看vue、springboot、FFmpeg的源码，也发现了一些bug，但从来都是绕开这些bug，而不直接修改源码。
因为修改这些源码会陷入十分尴尬的地步，开源软件的升级将会变得非常困难，不升级又可能存在一些埋得很深的BUG，如内存泄漏等。而且别忘了，开发团队的人是流动的，这会让升级难上加难。
如何选择开源软件
但是说了这么多，开源软件是不可能不选用的。
大部分情况下，不可能去开发一个十分成熟的组件，如文本编辑器、播放器等 ；不可能去开发一个基础框架，如Vue、SpringBoot等；不可能去开发一个不熟悉领域的软件，如编解码处理的FFmpeg等；大多数情况下会直接选用一些十分成熟的业务系统，如商城系统、cms等。
在选择开源软件之前，我们需要抱的是使用的心态，而非抱着不行可以改的心态。
所以流行度、文档完备程度是首要指标。
需要特别说明的是：流行度并不是听说某个大厂在用、听谁谁谁也在用就是流行的，而是网上能搜索到很多使用问题的答案。
有时候，开源软件的功能契合度并不是100%的，特别是业务系统，如商城系统等。对于这些软件，最好还是获取他们的技术支持，而不是瞎评估工作量。
单靠几张架构图、几篇文档，即使比较熟悉使用的基础框架如SpringCloud，工作量也是评估不出来的，往往就是你以为1天，最后花了大半个月。
如果没有技术支持，那就需要详细评估软件架构是否便于维护，而且这时候，软件架构的质量比功能满足程度还要重要。
当然软件架构是很难通过“看”就能看出个好坏的，我们的习惯是先尝试修改一个比较典型的功能，如果这个功能修改起来特别麻烦，那就不要用了。
总结
开源软件往往都只是看起来可维护罢了，毕竟软件是人写的，必须由人参与的劳动，产出的质量就会存在很大的差距。
所以我们在讨论大型网站架构时，总是提到规则、规整化、顶层架构，而非讨论哪个技术、框架、工具的使用。
因为并没有任何的框架、工具能保证最终的质量，软件质量是项目过程决定的。
项目过程并不是八仙过海各显神通，而是一个团队统一按照明确且简明的规则完成任务，项目周期、项目成本、软件质量就会自然提升。