有两位Google Maps API的初学者向我请教他们按照最简单例子写的程序为什么不能正常的运行。
其中一位用GTalk跟我交流，我仔细了看了他的代码，没看出问题，把代码保存在本地，打开Firefox的错误控制台，用Firefox打开他的页面。出错的那一行被清晰的显示出来，我再仔细端详那句话，原来有两个应该是英文逗号的地方，写上了中文逗号。
另一位，在我的论坛跟我交流他的Google Maps API中遇到的问题，我看他代码的时候也没有马上发现问题。然而，同样在用Firefox打开后，问题很明显的找到了，原来是一个方法openInfoWindow被他写成OpenInfoWindow了。
在我帮助别人解决的程序调试问题中，这是非常常见的。人人都可能打出中文逗号，人人都可能把大小写写错。但是在我帮助他们解决问题以后，他们总是感慨的说，谢谢我解决了这个问题，这个问题困扰了他们几个小时，甚至是几天。
这其实并不是只有初学者才会遇到的问题，我还帮助过些有非常丰富经验的工程师解决问题，有时候问题仅仅出自某个参数没有传递进来，或者是拼接字符串的时候少些了一个冒号，或者是拼接地址的时候漏掉了http:。我甚至帮助一些人调试一些我根本不懂的语言的程序，因为多半出现的问题，都和语言特性无关，不是程序员写错了字符，就是写错了逻辑，或者是错误理解了一个函数。
出问题是正常的，写程序是一个复杂的边思考边打字的过程，笔误和一时糊涂都是难以避免的。程序员一般把这种问题叫做低级问题，因为这类问题跟你的智商完全无关，任何人都可能犯。
但是，问题在于，有时候即使是很优秀的程序员，也会被一个低级错误困扰，可能会几天都解决不了。所以，关键在于，如何找到问题。
遇到问题的时候：
1，不要怨天怨地。出了问题，当然有可能是系统的bug，API的问题，但是那些几率往往比你犯低级错误的几率要低多了，先从自己身上找原因，是不是自己写错了。
2，要掌握工具。最低限度你要会写Log，最好是Log和调试器结合。好 的工具可以大大的提高效率。以前有人跟我说，Dll不能调试，我发现可以；有人说多线程不能调试，我发现可以；有人说COM不能调试，我发现可以；有人说 IE插件不能调试，我发现可以；有人说OE插件不能调试，我发现也可以。当然，你确实会遇到不能调试的时候，当年我们做东芝芯片的嵌入程序，一个组都没有 一个仿真器和调试器，但是至少可以用Log嘛，无非是麻烦点。
3，分析问题要有逻辑。遇到问题可以先把所有的可能性都列出来，然后一个一个分析，肯定能找到原因的。
4，要学会隔离问题。问题涉及到的代码越多，越难以理解，问题越难以解决。遇到这样的情况，可以利用Log或者调试器，一行代码一行代码的给它们洗清嫌疑，这样很快你就可以找到出问题的地方。如果代码特别长，程序特别复杂，可以用二分法来做，效率很高。
5，千万不要懒惰，不要事事求别人。一次复杂的调试过程就像一部侦探剧，如果你有非常好的逻辑性，那这部剧的主角就是福尔摩斯，剧情一定非常精彩。我说这个是有巨大风险的，说真的我帮人调东西挺上瘾的，很有意思。但是我还是要告诉大家，一次高难度的调试之后，你的满足感绝对不亚于写了一个伟大的程序。
要想不遇到问题，写代码的时候：
1，要对写出来的代码负责。我很佩服那些写代码写100行都不执行一次的 高手，如果他们最后不被低级错误困扰的话我就更加的佩服了。我写程序几乎是写一行两行就要执行一次，每句话我都要确保执行效果跟我的预期一致。没错这样写的时候 可能慢一些，但是调试的时候很轻松，我可以很简单的确定哪些代码绝对没有问题。所以我写代码整体速度比一般人高。很多人学习新东西的时候喜欢把例子抄一遍，运行一下，改改，再运行。我喜欢一句一句的抄例子，抄一句两句执行一次，这样可以把例子透彻的理解，而且很难会遇到出现了问题找不到原因的时候。
2，函数体功能块不要过长。我认为我的智商并不高，我很难接受一个程序的一个函数体或者一个功能块超越3屏（当然逻辑真的有那么复杂除外，你会发现越是简单的逻辑越是容易被人写的冗长）。很多人对面向对象耳熟能详，对封装继承看起来驾轻就熟。但是动不动就写出来个函数体超长的程序。这就像写本书从头到尾不点句号一样，会累死读者的。自己看的时候，估计也会被累的喘不过来气。这是我对基础教育的微词所在，他们连教会学生写函数都没教会，虽然表面上他们连面向对象这么高深的东西都教。
3，缩进要对。这点很重要，虽然大部分语言不是像Python那样用缩进来决定逻辑块的位置，但是人看到缩进的时候，总是会以为这些缩进位置跟逻辑相关。尤其是在有大量的ifelse或者for循环等等的嵌套逻辑的时候，如果缩进错了，可能会直接让人把程序的逻辑读错。所以我拿到别人的代码，第一件事情就是整理缩进。我见过一些比较优秀的页面工程师，他们会在div结束的位置用注释写上这个div的id，这样层级关系就一目了然了。
4，不断重构。随着程序的不断修改，有些部分会不断的增长，原来看着清晰的架构可能因为问题的复杂而慢慢模糊，也可能被修正bug的权宜之计弄的面目全非。不信你找一个经过多次修改的程序看看，是不是满目疮痍，是不是都很难认出是你自己的作品了。这在多人参与的项目中更加严重，每个人有不同的代码风格，经过多次杂交后，你肯定认不出你的代码是骡子是马，还是四不像了。随着程序的慢慢成长，原来有些函数体会慢慢膨胀，需要拆分；有些原来简单的功能块四处都需要，应该被提炼成函数或者方法，等等。现在不重构，未来等到代码复杂到无法控制的时候，重构的工作就会变得更加困难。我见过最强的案例是，一个几千行的电子辞典配套联机软件，经过无数次的改版，变成了一个几乎无法维护的主窗体的cpp有1万8千行的怪物。最后经过复杂的重构，才变成一个出新版本只需要新增一个驱动程序的可以维护的几千行的程序。
郝培强：银杏技术咨询创始合伙人，网名Tinyfool，技术方向是全文检索，搜索引擎优化，网站架构设计等。 银杏技术咨询的主要业务是帮助客户的网站改进技术，提高网站性能和反应速度，解决门槛性技术问题，从而提高用户满意度。
【CSDN独家专访】有的时候我们对一款产品表现出难以名状的喜爱之情，往往我们就会想像做出这样功能的程序员他应该是多么的伟大，是什么样的天才，对他就如同造物主一般的崇拜，所以很多人会把成为一个程序员作为自己的理想，然而很少有人会知道，在这样一款产品的背后，其实还有一个更加强健的团队在护送着他前行。
而这个团队的领军人物就是产品经理。近日，我们都很熟悉的暴风影音发布了它最新的3.1版本，这距离上次的3.0版仅过了45天。暴风影音做为一个日使用量在千万级别之上的客户端软件，产品里的任何一个角落有瑕疵，任何一个细节有Bug，被用户识别到的几率非常大，这和普通的应用软件是不能比的。所以需要做大量的用户反馈，数据分析，数据挖掘的工作，来提升软件本身的性能，那么，如果作为暴风影音的产品经理，他的身上又发生着什么样的故事呢？我们带着这样的好奇心采访了暴风影音的产品经理王志鹏。
王志鹏是一个很健谈的人，但在倾听的时候却很真诚。“也许这就是做一名产品经理所必备的基本素质。”王志鹏对我们的赞赏这样回答道，“判断自己适不适合做一名产品经理，你需要为自己做一个这样的测试，如果有十个人分别提出了十种功能改进的方案，那么你是否能够发自内心的把这十套方案都耐心、认真的听完，并且能够真正领会到他们的意图，即使这其中有不切实际的方案、有令人哭笑不得的方案，但是如果你是有兴趣去做这件事，而且付出的都不会成为你的心理负担，那么你就具备了成为一名产品经理的基本素质”。
在做产品经理之前王志鹏也是一名技术人员，他也很喜欢做技术，那么是什么让他实现了从一名技术人员到一名产品经理这样的一次转型呢？“其实我很早就立志我要做技术开发，大学毕业以后我在一家公司做ERP软件，由于ERP软件的特殊性，是需要跟很多的业务部门进行沟通来了解他们的运作状况之后才能够编写软件代码的，所以渐渐的我发现，我的编程技术或者说是一些技巧并不是最好的，但我是最懂得我们业务人员需求，最懂得他们要什么的人。”也许就是这样的一段时间，让王志鹏考虑了自己的特长可能会在这里有更好的发挥。
也许就是凭着良好的沟通和理解能力，不久，王志鹏就被一家知名的国际软件厂商看中收入麾下，并担任项目管理的工作。“这段时间里我主要是在做项目甲方和乙方之间的桥梁，做时间、人员和资源方面的协调分配”王志鹏说，“在这段时间里我已经不做具体代码的编写工作了，这也让我有机会在抽离了具体的代码编写工作之后看清楚了一名技术人员在项目实施过程中会出现的问题，更重要的是让我深刻的体验到了这样的一家国际软件厂商他在软件产品生产的过程中积累下来的流程和规则，在这样的流程和规则下运作的软件生产活动，不管是谁都可以很好的完成高质量的产品”。也正是在这里，王志鹏完成了他的转型。
“其实在这个转变的过程中，我也有过挫败感的时候。”王志鹏说，“曾经我认为从一个技术人员转型到产品经理是容易的，其实不然。在有过失败之后，我开始反思我这样的想法，非常幸运的是我找到了出口”。从王志鹏感悟中我们找到了转型过程中最核心的三点：
1、敬畏之心。无论是技术人员面对产品经理还是产品经理面对技术人员，大家一定要抱有敬畏之心，要尊重和重视别人的意见，不要认为自己就是正确的，一个人提出任何一种想法一定是经过了思考的，不能单纯的认为这个想法“幼稚”、“不可能”，更多要想的是为什么他会有这种想法。
2、主动沟通。技术人员和产品经理其实各自运行的是两套逻辑。技术人员在考虑问题的时候最先是从后台着眼，继而考虑架构然后开始编写代码的过程；而产品经理在考虑问题的时候首先是从用户开始，继而是用户体验、完全以市场驱动为主导。这样两种完全不同的思考方式造就了不同的工作习惯。
程序员完全可以只考虑自己技术实现的这一部分，做到精美、高效那他就是一个合格的技术人员，而产品经理需要的是Open的方式，需要和不同的人沟通他们各自的感受，因为代码的对和错有明显的界限，而用户体验没有对和错，只有好和更好，而自己的习惯并不能代表大家习惯，所以要通过主动的沟通和倾听来知道各种各样的体验是怎样的。
3、大量阅读。不仅仅要阅读相关专业类书籍更要有广泛阅读的习惯。因为这样能够培养人文的思维习惯，这也是单一研究理工科类的技术人员所欠缺的，编程需要逻辑思维的缜密，而阅读能够让你看事情的时候更换另一种逻辑，也让你的思维变得更加全面。
获得成功是每个人都需要的，但是成功并没有一条可以遵循的路线可以走。并不是说程序员到了一个规定的阶段就一定需要转型，一定需要专向产品经理，或者一定需要出去创业。“我并不赞同每个技术人员都要考虑自己该如何转型，真正要考虑的是看请自己突出的特点在哪里。”王志鹏说，“在我们的工作过程中，并不是像升学考试一样，要一张桌子四条腿一样长，所谓的全面发展，如果数学能考120分，语文能考60分，而继续学数学就能考130分，同样的力气学语文可能可以靠90分，那毫不犹豫的应该去学语文；但是在工作中，如果我写代码能得80分的认可，做管理、做沟通能得60分的认可，而继续努力写代码就能到95分，继续努力尝试管理和沟通能得到80分，那么，奉劝大家还是要继续向95分的代码去努力。因为这就是你的特长，如果为了全面而放弃了你的特长，将是一个巨大的浪费。”
王志鹏的经验令我觉得这应该就是社会分工的规律所在，每个人都有自己的角色，要认清的是自己的核心竞争力，而在这里木桶效应是失效的。如果要打破这种规律的话，那可能会付出很大的代价 。
最近评论