有人认为,熟悉了设计模式、设计原则,就学会了设计。其实,设计模式和设计原则,只是前人根据设计实践做的总结和提炼,设计,归根到底是要解决问题的,把具体问题的解决办法,经过一定的抽象,变成程序员的语言。
我见过一些人,他们知识渊博、见识广博,甚至理论可以给你阐述得冠冕堂皇,但是到了实际需要解决问题的时候,他们却拿不出巧妙的、优雅的办法,这是典型的象牙塔人。
另一方面,也有一些人看不起学习设计模式的人,他们觉得他们已经掌握了软件设计的奥义,这些对他们来说是毫无意义的词汇,对此大可以一笑置之。
有时候我们反而被设计模式或设计原则粗暴地掌握束缚了手脚,譬如我遇到这样一件事情,某位努力的程序员,设计的代码用遍了组合(例如把User对象放置到Administrator里面),我好奇地问,有一些类和对象之间的关系很明显符合继承的特征,为什么不愿意用它?他说,设计原则告诉我们,要多用组合,少用继承。我想,对这些优秀的模式、原则、方法论,如果不能透彻地掌握,不能根据实际场景合适地运用,是不是反而不如对其不了解来得好呢?
有人觉得学习一种语言就可以了,学习那么多语言没有必要。事实上,多掌握一门合适的计算机语言不仅仅是多掌握一种谋生的工具,如果一种新的语言能够很大程度上改变你对编程、对设计的看法,那么兴许它就值得你去学习。
譬如C语言,可以培养严谨的思维;譬如动态语言,它可以帮助程序员更好地做面向对象的coding;譬如函数式语言,它在工业生产、运算领域有着不可替代的作用。
当然话说回来,所谓术业有专攻,对于某一门计算机语言(包括该语言所需的运行时环境、其中的编译或解释的原理)深入的掌握,是很有必要的。
另外,我们时常看到诸多计算机语言孰优孰劣的争论,计算机语言归根到底是一种工具,工具是随着时代发展升级和变更的,单纯的优劣争论没有太大意义。
中国人为什么要学英语,程序员为什么要学英语,当我把那些方法名、变量名全部取成拼音,一样可以,谁下的这个破规定?
遗憾的是,诸多学习材料、论文、技术资料(尤其是一些刚出不久的技术),都是英语的;另一方面,国际标准、程序员交流的通用方式,都是英文的,我想肯定很难想象,那些有名的framework、lib的源码,如果用拼音来写变量名会成什么样子。
所以,如果你的英语不好(至少读写不好),就不要给自己找借口,英语是一个掌握其他工具的工具,除非你坚信,中文很快就会在计算机界变成世界第一通用的语言。
算法有多重要,这一件事的争议一直都很大。
软件归根到底是用来解决问题的,提到算法就不能不提到数学(这也是为什么很多软件领域的大师都具备相当的数学背景),对于解决问题,这里可以简单归纳成两步:
算法,在这里应该是一个广义的概念(这里的算法并不仅仅指大学里学习的狭义的具体算法),算法是解决上述数学问题的办法。如果工作中你并未意识到它的存在,那只是说明,你抽象出的数学模型比较简单,解决这个模型的办法也很简单,或者有现成的方式可以模仿,或者有现成的框架帮你完成了,以至于你不去关注它、在乎它。
如果你做的事情是充满创新意义的,是别人从没有做过的,这时候算法兴许就成了决定你成败的因素。
在当前中国的环境下,视野广阔和经历丰富的人很好找,但是企业要招到具备上述两点能力来解决问题的人,其实是非常困难的。
唯经验论者的人有很多,他们认为,在软件企业的职位、薪水、甚至决策能力,都取决于经验,一个5年经验的工程师,肯定比3年经验的工程师能找到更好的饭碗:
“我是老员工,我工作5年了,凭什么工作3年的他薪水比我高那么多?!”
实际上,很多因素,包括领域积累(这是业务上的,例如互联网领域、传统软件领域,这和所谓的纯技术没有直接关系)、视野、承受压力的能力等等往往都在很大程度上取决于“经验”的积累,但是,这并不是绝对的。有句话叫做“事业一半是干出来的,一半是总结出来的”,也确实有一些出色的程序员,他们善于总结、善于观察和积累,并且善于不断地思考,这样的程序员就是拥有更多优秀的经验。
另一方面,程序员是要来解决问题的,经验不能代替解决问题,有的人具备更优秀的解决问题的能力,他为什么就不能得到更优厚的薪水?