终于明白了什么叫做“算法才是程序的精华”
今天第一次在修正一个BUG的时候用到了算法，当成功解决了一个被认为是不可能实现的

问题时，终于真真切切的明白了什么叫做“算法才是程序的精华”.
   
  我现在的兴奋不可言表，那种感觉比第一次写出程序还要兴奋，我也成功证明了数据结构

并不是一文不值！

------解决方案--------------------
算法就是解决问题的有效办法。
如果问题是1+1是多少，那么int i = 1 + 1;这也是算法。
任何一个程序，都是算法和数据结构的结合体，算法描述了how，数据结构描述了what。
因此，从你第一天写程序起，你就在“用算法”。

因此根本不存在算法是程序精华一说。
------解决方案--------------------
今天你是程序员;
他是算法工程师;
他写程序比不过你.
明天也是这样.
明年也是这样.
20年之后---
你是个被辞退了的老头,
他是个吃香的算法工程师!
程序员常有,
算法工程师不常有,
这就是现实!
没人会雇个老头当程序员,
尤其是只会编程的程序员!
------解决方案--------------------
修BUG就是使用疑似正确的办法解决问题。
如果BUG是 1+1 是 int i = 3;，那么int i = 3 ^ 1;这也是修BUG。
任何一个程序，都是BUG和疑似BUG的结合体，BUG描述了wrong，疑似BUG描述了may。
因此，从你第一天写程序起，你就在修BUG。

因此根本不存在修正BUG一说。

是啊，这是事实，但是这是片面的事实。因为这样的事实更有传播价值，所以你听说来听说去都是这样的故事。如果一个人和你说，一个有BUG的程序解决不了，后来还是找了一个疑似BUG的程序解决了。你会把这个故事再复述给第三个人听么？这就像打开报纸，到处都是杀人放火，男盗女娼的事情，但是新闻联播中100年你也遇不到一起一样。

任何事情都不是绝对的。为什么你相信疑似BUG比BUG质量好，这是因为疑似BUG的平均品质要高出BUG很多，故障率则要比BUG低很多。但是疑似BUG也有跑了2秒钟就奔溃的，你因此得出结论疑似BUG不如BUG，我想这个结论你自己都不信。

修BUG不是图腾，不值得顶礼膜拜。
学习理论知识只是避免制造BUG而已。每个人都应该用自己的丰富经验去解决BUG，而不是祭出一个xx修正BUG的大旗。

我之前讲过，真正的修BUG是循序渐进的，迭代前进的。而不是封闭的，或者跳跃的。

也就是说你每天修改点新的BUG都会觉得提高，而不是突然修改了个什么，然后让之前的全部出错了。每天修改点新的BUG，都会发现更多要修改的BUG，而不是“修改完这个，再修改哪个比较好”。

我说了，你应该在学编程的第一天就知道怎么修BUG，虽然你修BUG的知识还来自编程之外，比如算错乘除运算。此时你就习惯用丰富的经验解决BUG，只是这个丰富的经验是你学生时代背下来的99口诀。

即便你学到很高的层次，还是在用丰富的经验解决BUG，只是这些经验来自你实践那些你已经遇到并掌握的BUG的经验。

将“不用修BUG”也视作修BUG的经典例子就是变量名的拼错修改，或者叫重命名。
给它一个名字而已，其实拼错修改说白了就是“不用任何技巧的修BUG”。事实上，拼错修改是用得最广泛的BUG修改。
因此忘记什么修BUG，你是在解决问题，而不是在秀你的修BUG功夫。如果你学会修什么BUG，无论写什么程序都要拿来套用一番就糟糕了。
因为一个项目中修改了一种精妙的BUG而换了一个场景换了一个需求，却非要再找一个精妙的BUG才罢休那就是刻舟求剑了。

再说拼错修改，也许你学了很多别的修BUG的方法，比如学了命名空间，你有没有意识到，其实命名空间也是拼错修改呢，只是你不再是局部的拼错修改，而是整个项目的拼错修改。如果你把命名空间伪装起来，从高层次上来看，还是拼错修改。

这就是，相对论不是推翻了牛顿力学，而是把牛顿力学包括进来，成为相对论在低速情况下的近似特例。修BUG也是一样，复杂的BUG和简单的BUG是相容的，而不是排斥的。
------解决方案--------------------

探讨

引用:

啥时候我能执着呢？现在我还没能力执着，但也许就没有机会执着了。本人打算再过2个月就退出程序员生涯！继续做销售，有时间就来逛逛，给各位捧捧场！再顶一次楼主。

多谢了前辈，怎么不做这行了？