Google，GitHub，StackOverflow
1.不是所有的程序员都不重复造轮子的：
有些程序员就是喜欢自己造轮子。高手和菜鸟是不是都适宜这种想法姑且不论。但很多C++团队都喜欢自己写自己的字符串策略，自己的内存分配策略，抱有坚决不用STL的态度，可以说是现在很多遗留的C++项目看起来好像另一种语言写的一样的一个主要原因。之前某大牛还在微博上抱怨过，为什么公司那么喜欢重复造轮，否则他第一天就可以上班了。其实，现在应该每一种轮子，都可以在开源社区找到，而且是合法的。但不是每个人都可以造出大项目来，因为一个轮子本身就不一定好用，很多个轮子说不定要翻车。
2.最近到到新公司，接手一个很烂的项目，发现许多问题：不是所有的程序员都不重复造轮子的，有些轮子必须要重造，否则很难维护
假设，你决定留下来处理这个烂摊子，提供以下建议供参考：
第一，你应该得到足够的职位或授权，一个程序员是没有足够的能力处理这个问题的。不在其位，不谋其政，如果你连项目经理或架构师都不是，连技术高层的认可都没有，那么还是走为上。
第二，建立共识，你的观察和意见是否能够得到领导和团队成员的认可？在团队目前共识中，你列的这24个问题是项目最重要，最急迫的问题吗？是不是还有更重要的问题，你暂时还没有接触到？你的问题描述客观吗？还是过分夸大，和带着情绪？很多词看起来都不是平心静气的说的。你看到的问题领导和团队成员看到了吗？他们认可吗？解决这24个问题能提高你们的生产效率，或节省经费吗？能缩短问题解决的时间，提高客户满意度吗？能减少加班吗？如果你这24个问题并不是项目目前的项目的核心问题，解决了，又能如何呢？谁会分配资源给你来解决问题，谁会配合你解决问题？如果没有共识，或者无法建立共识，那么要么忍，要么滚。
第三，产品是过程的产物，你们目前的系统也是过程长时间运行的产物。IT系统成功的三大要素是：过程，人和技术。想不触动软件开发过程，仅仅从软件技术上解决问题是没有办法解决的。
3.拙见
见困难就跑的，还真不如代码写差点迎难而上的。水平高新老划断找好边界逐步重构，再不济你想重写都可以。先从最容易不出问题，最容易引起同组程序员共鸣的地方开始修改，每改好一点都是对工程的改进。如果遇到项目大改版什么的，这个是重构最好的时机，有足够的测试资源帮助你进行重构。如果你的方案有足够优秀的理由，自然会得到其他人支持。最后要注意一点，没有看懂前，不要因为烂就重构，里面可能是老架构不适应新需求，导致代码上有一定妥协。PS.这个事情应该是技术负责人去推进的。但是作为一个新人，可以找时机提方案，在领导的允许范围内主动承担改进任务。你们领导也会一定程度为你提供资源和时间做这件事情。
4:
找轮子本身其实是一件不容易的事情。而我对上面问题的解决方法是：找轮子的任务不要交给新人，而是要由经验丰富，信息检索能力强的编程人员负责，最好是项目的构架人员。团队成员找到的轮子最好也由构架人员拍板，用还是不用。对于团队新人，最重要的任务还是编程基本功、文档阅读能力以及如何用好已经拍板的轮子。