你适合当程序员吗？
我是一个热爱写程序的家伙。我的第一台电脑，是13岁时买的Apple II，在那之前，我已经开始到同学家用「小教授二号」学写程序了。高中时我当电脑社社长，带队参加教育部办的全国程序大赛，幸运拿到冠军，大学、研究所念的也是相关科系。工作20年来，一直从事软件相关领域，即使担任主管职务，也一直对技术充满热情。
写程序写了这么多年，多少有些体会。我把自己对写程序这份工作的心得写下来，希望能给从事相关领域或有志于写程序的人参考。
Photo credit: gags9999@flickr CC BY 2.0
我适合当程序员吗？
程序员，也叫软件工程师、程序设计师，叫软件工程师、程序员。我觉得「程序员」三个字简洁有力，所以就用这个词。
如果你正从事这份工作，恭禧你！这是个热门行业，在可预见的将来，也不会消失。不过也别高兴太早，这一行的技术汰旧换新非常快，必须不断努力学习才行。
一点天份
打开一个空白档案，必须创造出程序。与所有创造性的工作一样，写程序需要某种程度的天份。程序员生产力好坏差别很大，倒不是说一天能写多少行程序（这可能是最没参考价值的数字了），而是品质有天壤之别。天份很高的程序员，一个抵十个，没天份又不努力的，一天制造的问题可能多于解决的问题，生产力是负的。具体来说，逻辑推理、抽象思考、创造力、理解力，这些都是相关能力。
当程序员不一定要有多高天份，毕竟像Linus Torvalds（Linux创始者）那样的天才很罕见，但一点天份还是必需的。如果你发现自己写程序、看程序、解bug都很痛苦，半年一年了也不见改善，也许这份工作不太适合你。
一些热情
如果你对写程序充满热情，又有一定的天份，那再好不过。最起码，你有时会沉浸在写程序或解bug的情境中（英文有个词叫“flow”，心流）、不想被中断，这样就够了。如果你从未出现过这种情境，那么你可能不会热爱这份工作。不过没关系，世界上不热爱自己工作的人其实不少。如果你能做好这份工作，眼前又没有更好的选择，继续做下去也没问题。
很多努力
努力是一定要的。当一名好的程序员，要学习的东西太多了，而且不努力很快就会被淘汰（虽然很多工作都是这样），这是入这行前应该要有的体认。
程序员基本能力
什么？写程序也有职业道德？有的，而且还很重要。我说写程序是一门良心事业，因为通常你写的程序只要符合规格、能正确执行，就可以交差了，而你的主管或同事很难一眼看出程序码品质有问题，例如：在特定条件下会爆掉、滥用复制贴上、采用一些肮脏写法、程序可读性很差、模组之间纠结在一起，等等。
你焊接过电路板吗？要是电路板绕线一团乱、零件歪七扭八、接脚没焊好，你能交差吗？但是写程序可以。因为程序码是一种抽象产品，没有「外观」可以观察。如果你的团队要求code review，这个问题可以得到某种程度的改善，但仍不能彻底解决。程序员的纪律和职业道德很重要。
程序语言
程序语言的学习，是程序员最最基本的能力，而且应该至少精通一两种语言。随着程序经验的累积，学习不同程序语言的速度会越来越快，例如从几个月缩短到几周。当然精通一门程序语言，不是几星期、甚至几个月就能达成的，但迅速接手并维护既有程序码，是对合格程序员的基本要求。
通常第一种程序语言学最久，因为很多观念也是第一次学，例如变数、回圈、阵列、递回、I/O、网络、多执行绪、物件导向、regular expression、functional programming……。等到学第二种、第三种程序语言，新的观念越来越少，主要在学语言本身，速度就会变快很多。
数据结构及演算法
如果你是本科系毕业，数据结构及演算法应该是必修课。如果没学过，建议花点时间学一下。倒不需要买一本厚厚的书折磨自己，但基本的概念一定要有，例如：
数据结构
阵列（array）、序列（list）、堆栈（stack）、队列（queue）
树（tree）、二叉树（binary tree）、哈希表（hash table）
指针（pointer）：这也许不算数据结构，许多高阶语言也不让你用pointer，但是对记忆体、指标要有概念，这是程序员与非程序员的区别之一
演算法
对以上数据结构的各项操作
排序（sort）：至少搞懂3、4种基本的排序演算法，例如bubble sort、quick sort、merge sort等
搜寻（search）：depth-first-search、breadth-first-search、binary search等
其它：迭代（iteration）、递回（recursive）、分治法（divide and conquer）、时间/空间复杂度的基本概念（big O）等
网络上资源很多，Google一下、多写一些程序练习，弄懂以上基本概念，应该就够用了。
网络协定
TCP/IP、HTTP、DNS等这些都是基本的网络协定。不需要到专家程度，但身为一个程序员，除非你的工作与网络完全无关（这种工作应该越来越少了），否则对这些网络协定的运作应该要有起码的了解。例如你能讲清楚，从你在浏览器输入一行网址到看到网页内容，在网络上发生了哪些事？以前我在Yahoo面试前端工程师的时候，喜欢问一个问题：请解释cookie是怎么运作的，结果不少人答不出来。
当然现在的程序开发环境很方便了，各种library一大堆，我们通常不需要自己实做这些底层的东西。但不懂这些东西运作的基本原理，会让你在debug时被卡住，因为整个网络系统的运行，都是建立在这些基础架构之上。这些网络协定，再过很多年还是会继续存在，花一点时间搞懂这些，我认为很值得。
除错能力
讲除错能力不太准确，因为除错不是单一能力，而是结合了经验、对程序的了解、对系统架构的了解、抽丝剥茧的能力、直觉，以及各种hands-on能力的综合，就像当侦探一样。台语有句话叫「医生怕治咳，师傅怕抓漏」，差不多就是这个意思。
我在Yahoo工作期间，最刺激的事莫过于排全球on-call了。所谓on-call，就是全球Yahoo网站出包时，你要在最短时间内找出问题并修复，那真是超级debug。拜托，Yahoo网站那么复杂、程序码又那么多，出问题的模组又不是我写的，美国同事都下班了，谁知道怎么解决？对不起，那是你家的事，排了on-call你就得想办法解决。功能上的问题还有迹可寻，最棘手的是像系统过载这类问题，爬log、写script、trial-and-error，总之想方设法揪出元凶。
程序员应该具备良好的除错能力，不管程序谁写的。另外，修bug也是一门学问，是采用锯箭法、贴狗皮膏药，还是找到病灶、解决问题背后的问题，就看程序员功力了。
写出可读、易维护的代码
这个要求听起来很合理，不是吗？其实这是最难的。写程序这么多年，看过多少代码，我跟你说，这个世界上的烂code占绝大多数，好code只占一小小部份。我自己也不断在这条路上努力着，到现在也不敢说自己写的code多好。
为什么这件事这么难？我想了一下，大概有以下几个原因：
可读性高的代码，通常是用很好的解法，解决了真正的问题
例如牛顿的F=ma、爱因斯坦的E=mc 2，这是神人等级的功力（只是举例说明，写程序不需要到这样）
你需要彻底了解问题（problem domain）
你需要考虑过至少几种合理的解法（solution domain）
你需要对程序语言、程序库、既有程序架构和可运用工具很娴熟
你要能以简驭繁，而这代表你掌握了更高的东西
你写程序必须很有纪律，例如：
Bingo! 找到一段code了，看我的copy& paste
可以work就很好啦、这么漂亮的解法……
好累，我不行了，先commit code再说
不急着马上写code，先想清楚问题、解法、架构
恰到好处的注解，少了不行、过犹不及
用心想过的命名（程序界有句名言: There are only two hard things in Computer Science: cacheinvalidation and naming things .）
压抑copy & paste及产出一堆烂code的冲动：
在commit code之前，自己再好好review一次（我个人经验，通常这个步骤可以改进程序好几个地方）
越容易维护、扩展的代码，代表它的复杂度越低
当你轻易多用了一个外部组件、增加了一个external dependency，你就把它的复杂度整个带进来了，所以要很小心
降低软件复杂度是软件工程的最大挑战，软件复杂度就像软件的熵（我的第一篇英文blog “Software complexity is software entropy”，就是讲这件事）
必须做到low coupling、high cohesion，而这两件事都很难
低复杂度的软件系统，代表里面各个模组的复杂度都必须更低
现实环境的因素，导致好的程序码不易产生
专案时程的压力
程序员经验的限制
团队未采用一些最佳实务
有决策权的人对软件开发不够了解
代码品质的重要性，每个人都知道，连路人甲都知道。现实的难处在于：第一版的代码，只要能work，品质好坏是很难看出来的；它们的差别，要到系统后续的运行、维护及扩展才能看出来，然而此时木已成舟，程序只能修修补补继续用下去，最多小幅重构（refactor），直到软件生命周期的结束。
写出好的代码，时间会花比较久、会导致专案时程延后吗？其实并不会，这是能力限定，不是时间限定。写出第一个版本，花的时间都差不多。但后续版本就差很多了，写得越好的代码越好改。你如果改过那种high coupling的系统，你就知道我说的意思了，那真是人仰马翻，超high的。这种代码要是装在箱子里，箱子上会标示「易碎/FRAGILE」。
Photo credit: Hsing Wei@flickr CC BY 2.0
写出好的代码并不容易。假如我们从1分到10分给程序码打分数，10分真的很难很难，我自己也做不到。但一般人经过努力，达到6、7分应该是没问题的。如果你想看书，我在这里推荐一本：Code Complete 2nd Edition。教人写程序的书中，这是我看过最好的一本了，只是内容比较多，需要时间消化。如果还有兴趣多看，我个人觉得Martin Fowler也写了不少好书。
程序员进阶能力
具备以上的程序员基本能力，我想就足以胜任大部份「单兵程序员」的工作了。如果想在技术上更上一层楼，以下是几个我认为比较重要的进阶能力，提供给大家参考。
作业系统
大学修的那么多课里面，我感觉对工作最有用的就是「作业系统」这门课了。对作业系统（OS，operating system）的了解，是资深程序员应该具备的。例如：
Hardware: CPU, memory, I/O devices
Process, multi-thread, scheduling
Inter-process communication: signal,socket, pipe, named pipe, shared memory, message queue…
Synchronization, deadlock, mutex, semaphore
File system, cache, virtual memory, pagefault…
Real-time system, distributed system
作业系统本身就是一支超大型程序，有着无数前人的心血。加上作业系统的基本概念，几十年不变，所以花点时间弄清楚这些观念，我认为很值得。
数据库
不是每个程序员的工作都会使用到数据库，而且现在不少人用NoSQL存数据。尽管如此，我认为关连式数据库（relational database）还是很重要，不管是MySQL、PostgreSQL、MS SQL或Oracle都好，资深程序员应该至少对其中一种有相当的了解。
题外话，多年程序写下来，我对ORM（object-relational mapping）抱着存疑的态度。网络上有篇文章：Object-RelationalMapping is the Vietnam of Computer Science，应该是反ORM的代表作之一，有兴趣的人可以看看。还有一篇有名的文章：The Law of Leaky Abstractions，讲的是每一层抽象化都或多或少会有漏洞。从leakyabstraction角度来看，SQL已经是一层有洞的abstraction了，而ORM洞更大！
网络安全
网络安全（network security）平时很容易被忽略，因为它费事费工，没有立即效益。但是对网络安全的轻忽，一旦出事，经常导致企业或政府重大损失。这让我想起以前当社区管委会主委的时候，按消防法规要搞什么社区消防编组、演训，还要指派防火管理人，真的很麻烦。安全这种事情就是这样。
有些网络安全议题，是属于系统管理者的范畴，例如DoS (denial of service)、DNS spoofing、man in themiddle；有些则是程序员的责任区，例如SQL injection、cross-site scripting、cross- site request forgery等等。此外像验证使用者身份的流程、储存/传送使用者敏感数据的方式，也都与安全有关。资深程序员对网络安全议题及常见攻击手法，应该要有足够的认识与敏感度，并在开发过程中合理采取预防措施。
程序语言的多样性
程序语言是程序员吃饭的家伙，除了每天工作上用到的，资深程序员也应该接触一些不同的程序语言。例如：
函数程序语言
函数程序语言（functional programming language）是另一种风格的程序语言，可以挑一个好好学一下。我个人推荐Haskell，但F#、Scala、OCaml、LISP、R、Erlang、Clojure这些也都不错，各有拥护者。
实际工作上，不见得有机会使用这些函数程序语言，但好好学一种，可以拓宽自己程序设计的思路。而且现在很多程序语言，包括C++（C++ 11之后）、C#、Java（Java 8之后）、JavaScript、Python、Ruby、Swift等等，都具备一定的functional programming能力，可以运用在工作上。
组合语言
除非是用C加assembly写硬件相关或compiler/toolchain的人，组合语言在实际工作中很少用到。但我觉得应该了解一下，因为这是软件的最底层，再往下就是硬件了。我中学时候写过6502、8088，大学上过一堂MIPS组合语言的课，其实还蛮有趣的。写过组合语言，会让你对电脑如何执行程序更有「感觉」。
但是组合语言不用太认真学，因为真的很少用。学个概念、最多写几个小练习即可。
Shell Script
如果你工作中有用到Linux/Unix相关的OS，我建议应该要学一种shell script，例如bash。如果你是ops/service engineer或系统管理者，这应该是必备能力了，不过资深程序员最好也能懂这些。就像vi一样，有些东西已经很古老了，但网络世界就这么运作着。没办法在terminal环境工作的人，很多问题处理起来就显得笨手笨脚。
与技术无关的
除了专业技术能力，我再补充一些非关技术的心得。
克制砍掉重练的冲动
在开发过程中，程序员很容易对既有程序码产生一种「这谁写的？砍掉重练比较快」的冲动，包括我自己在内。我想可能的原因有：
砍掉重练其实比较容易（拆掉旧屋盖新屋很快，保留这面墙、那扇窗的反而更困难）
在自己的地盘当山大王很开心（人都喜欢按照自己的意思来）
在系统发展的过程中，很多需求后来才出现，使当初的架构显得捉襟见肘，但在当时其实是很合理的设计
上线多年来，程序员处理了很多状况、修复很多bug，因此程序显得没那么干净优雅
写程序比读程序容易
文人相轻
（排除以上各种因素之后）当初的程序码真的写很烂
不管怎样，砍掉重练（rewrite）的代价，通常比乍看之下高许多，而且日后维护你的程序码的人，心里可能同样嘀咕「这谁写的，砍掉重练比较快」。Joel Spolsky在2000年写的一篇“Things You Should Never Do, Part I”，今日读来依然犀利。
小幅重构（refactor）是没问题的，而且可以经常做。
理解不同人的立场
当我们在某一方面懂得比别人多时，容易产生一种傲慢，技术人员也是。在专案开发的过程中，除了技术团队，还有产品/专案经理、主管、客户、使用者等不同角色的人介入。在技术方面懂得比别人多，并不妨碍我们理解他人的立场。当我们能站在别人的角度看问题，常常一下子就能了解为什么事情会这样。例如：需求改来改去、一开始不讲清楚、进度卡在别的team上面、「请你用最快方式完成」、「先支援这件紧急要求」、没人把我讲的话当一回事……
做到理解他人或是同理心（empathy），其实并不容易，因为每个人都有自己的立场，而人们倾向站在自己的立场看问题。我费了很大功夫，一直在努力修正自己技术傲慢的心态。如果你技术很厉害，又能做到理解别人，那真的很不简单，你所在的团队运作一定更为顺畅。
参与社群，吸收新知，写点东西
不管公司大小，资深程序员若只把触角局限在公司内部，会越来越封闭。接触外面的社群、吸收专业领域的新知、写点东西累积自己的专业credit，会让自己成长得更快。现在参与社群的管道很多了，从专业聚会研讨、开源码专案到各种社团，五花八门，不过还是得衡量一下自己能投入的时间。单身的人比较有空，有家庭有小孩就只能斟酌参与了。
吸收新知是为了让自己保持在敏锐状态，不要变成灭绝的恐龙，但也不用太过焦虑。软件领域变化快速，各种语言、框架、技术不断冒出来，要追新知永远追不完。如果你时间充裕，可以到处追新知，那很好。若你时间有限，我的经验是：等到很多人都在谈论的时候再去了解一下，也就够了。跟工作有关的，根据自己在团队中的角色，适度学习即可。
另外，我建议有几年工作经验的程序员，都应该考虑写点技术文章，累积自己的专业credit。这种事情没有看起来那么可怕，一回生二回熟，包括找主题、写文章，多试几次就会上手。也不用给自己太大压力，一、两个月写一篇都可以，长短不拘，日积月累，会有收获的。
程序员之后
写程序能够写几年？每个人情况不同，但无论如何，大多数人不会写一辈子。
当了单兵程序员若干时日之后，最常见的角色转换就是先成为Tech Lead带组员（不同公司对这个角色有不同安排方式），此时除了写程序，还要负责带团队、对外沟通、掌控时程、照顾组员、处理突发状况等等。如果公司够大，公司可能还会提供更多资深技术职位，例如Architect角色。
技术职之外，有的人会走管理职，有的人走专案管理或产品经理，甚至业务、行销都有；如果喜欢走技术，有的人会跳槽到条件更好、发挥空间更大的公司，其实选择不少。如果有心创业或加入创业团队，扎实的技术底子也会令你如虎添翼。
结语
最近学程序设计忽然变得很流行，「一小时学程序」、小学生学程序，好像程序人人都能写似的。当然练习写几行小程序是没问题，透过这些训练逻辑能力也很好，但真实世界的程序，复杂度远远超出这些沙盒小练习。事实上，随着电脑及网络技术的发展，现在的软件开发比起一、二十年前更复杂了，有时我都很佩服现在刚出校门的学弟妹们，要学的东西这么多，他们是怎么办到的。
洋洋洒洒写了一大篇，其实很多也只能点到为止。希望这篇文章，对大家有一点帮助！
|
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
收藏
淘帖
顶
踩
