之前在论坛里看过一些朋友有关高手的总结，大致意思是，他们只是踩过足够多的坑，顺便也解决了足够多的坑而已。 
解决问题固然重要，更重要的是解决问题的思路。世间没有两片一样的叶子，同样问题也是繁杂多样，即便同一个问题，所致原因也不尽相同。
比较幸运的是，往往异常会有日志输出，如果没有，想办法让它有。如果你忽略了日志，还想解决问题，可以把你归类为夜郎自大。
搞懂日志描述的意思，这是最起码的一步，找对方向，才能事半功倍。同时，你的大脑数据库应该在高速检索过往的所有经历，以匹配当前的错误。如果命中，恭喜你即将解决问题。
如果未命中，但问题还是要解决的。犯懒的人基本上就张嘴就来，xxx，来帮我看个问题。此言一出，基本上也就是废了，无半点进取心可言。稍微不甘心的都会用百度找一遍，发现说来说去都是那几句话，相互复制来复制去，幸运的恰好中题，能解决你的问题。
丧气的是试了百度所有搜出来的方案都解决不了，还有一个渠道，google，这对英文不好的朋友是个挑战，满篇的e文，无从下手，装个词典是个不错的选择。
我经常在本子上记一些不认识的单词，希望下次能认出来，然并卵，不经常用总会忘记。
一般而言，你遇到的问题，基本上别人也遇到过，老外也不例外，稍微有点深度的问题，这个时候也会遇到类似的咨询者，类似的解决方案。
有时候更幸运的是，没有一个人有你类似的经历。这个时候你要小心了，要么你看过的方案里稍微留意下已经可以解决了而你错过了。要么真是让你碰上了，组件自身的问题，如此就只能到官网翻阅资料，希望里面能有只言片语提及到，这个几率很低，你确定有如此好的运气？
如上反反复复，难缠的问题，不折腾几遍不虐心几次，基本也解决不了。沉住气，有时候一个难啃的骨头，确实要花上几天时间。
如果经常以上步骤还没解决(当然是时间允许的情况下，如果项目忙的火烧眉毛，你应该在遇到问题的1小时后把问题抛出来，主动暴露风险，不然你就是项目的风险)，可以把问题抛出来讨论，寻求其他思路，或绕过去，或解决掉，让团队的力量来解决。
如果团队力量有限，可以寻求业内专家的意见，渠道很多了，只要肯找。一般的应用开发问题，基本都会在团队内部消化掉。
日复一日，年复一年，张嘴问很容易，解决问题也很快，但要搞清时机，不然你真会错过成为高手的机会。
歪脖贰点零 ∣一个程序员的日常碎碎念
