重复造轮子 or not

现在网络资源这么多，在做一个东西之前，不免会遇到这样的选择：

• 完全原创----从原理到实现
• 学习原理，自己实现
• copy一些开源的代码

思考下决定原则，其中的依据，从原创到copy，他们的意义是：

• 解决问题，尤其是用很棒的方法和优雅高效编程解决问题是最让人兴奋的事情，这是程序员的原动力，没有这些，一切都是索然无味的。
• 在独立思考和实现过程中，技能知识和理解都在以“学习”所不能代替的方式增长（实际是要比学习好的多的方式增长）。
• 不管原创还是直接copy，都是解决了问题，让项目变得更强大。

而各自的特点：

• 原创原理，大多数是researcher的事情，这个过程过于缓慢，个人觉得在有限budget下是不应该做的
• 完善原理，即便gdc这样非常实战性的会议的paper仍旧很难完全符合项目需求，这就需要深度理解paper要表达的东西，然后根据实际情况去延伸，裁减。这个是较为senior的programmer应该做的事情，这个过程具体情况具体分析，一般也是比较时间长。
• 直接copy代码，很快，但是代码常常是质量不够高，方式和项目不统一，增加项目的复杂度。
• 完善代码，和完善原理比较像，最棒的方式还是把代码的道理抽象出来，把代码重新消化成最符合项目的东西。

ps：关于代码copy的情况，经常会遇到疑问：直接拿来用不就行了么，为何要去重复值造轮子？

game engine的质量要求需要高于普通工业标准，直接拿来的东西如果不符合质量要求（质量不够，不够轻量级，不够效率，契合的不够好。。。）都要进行改造。轮子不需要重新发明，但是需要的话，应该毫不犹豫的重新制造。

所以可以copy来的东西，常常是和其他部分契合的不够好。

实际中的例子就是哪来的库和源代码，有时候是多了太多的保护，考虑了太多的多线程情况，考虑多平台，多操作系统，而我们的情况更加简单，不需要把很多资源和内存花在上面，需要精简代码来达到更好的效率和内存占用。

 

 

那么最后是依据这些基本定理得出在各自空间下做各自的事情：能做多少是多少了

• 解决问题
• 保持质量
• 完美解决----原理的思考和创造，高质量的实现，文档还有和社区的分享交流

纯粹程序员的价值观应该都是在完美解决这一级，自己做个人项目的话都应该这样，做项目的话，作为team的一员，会为了team利益不得已要作各种妥协。