其他
码农在工作中的必备能力
但是人类世界的需求又是如此复杂，更要命的是需求是用自然语言描述的， 这就和计算机之间形成了一个巨大的鸿沟。
很明显，这个鸿沟需要苦逼的码农去填充。
码农得理解人类需求， 学会计算机的思考方式， 理解计算机的指令， 然后努力的把翻译工作做好。
例如： 经理给你一个模块的需求以后， 你得站在计算机的角度， 把它用现有的数据结构或者自定义数据结构， 再加上一般不那么复杂的算法，用计算机语言把它描述出来， 这是基本功， 和具体语言无关， 和框架无关。
这个思维习惯养不成， 做不了码农。
参见我之前写的文章《学会编程，而不是学会Java》
公司调来大批检修工人反复检修，又请了许多专家来察看，可怎么也找不到问题出在哪儿，更谈不上维修了。福特公司的领导真是火冒三丈，别说停一天，就是停一分钟，对福特来讲也是巨大的经济损失。
这时有人提议去请著名的物理学家、电机专家斯坦门茨帮助，大家一听有理，急忙派专人把斯坦门茨请来。
斯坦门茨仔细检查了电机，然后用粉笔在电机外壳画了一条线，对工作人员说：“打开电机，在记号处把里面的线圈减少16圈。”人们照办了，令人惊异的是，故障竟然排除了！生产立刻恢复了！
福特公司经理问斯坦门茨要多少酬金，斯坦门茨说：“不多，只需要1万美元。”1万美元？就只简简单单画了一条线！当时福特公司最著名的薪酬口号就是“月薪5美元”，这在当时是很高的工资待遇。 1条线，1万美元，一个普通职员100多年的收入总和！斯坦门茨看大家迷惑不解，转身开了个清单：画一条线，1美元；知道在哪儿画线，9999美元。
在软件开发领域， 也经常会遇到类似的情况： 软件出了Bug , 大家花费了巨大的精力，日夜奋战，最后发现只是有个文件打开后忘记关闭了 。只需要一行代码就能修复！
所以能迅速定位问题的人才是牛人。
码农定位问题有这么几种办法， 一是查看错误日志，推断错误的可能， 这是最直观也是最直接的了。
只不过很多情况下， 真正的凶手并不在凶杀案的现场， 这时候就需要进行分析了， 可以一步一步的调试代码， 找到真凶， 也可以在代码中输出日志查看运行时行为， 但无论哪种方法都是费时费力。
更悲惨的是， 不少问题是生产环境出现的 ，根本没法调试。
好的码农能够把软件在脑海里建立一个运行的模型，设置输入输出， 仰起头在脑海里模拟运行一下， 很快就能找到问题所在。 参见文章《不加断点的程序员是好程序员》
可是有的人试了好多关键词都不能找到理想的内容。而有的人几乎是一击而中， 无往而不利。
这背后就是对问题本质的理解是否到位。
学会选择最合适的关键字进行搜索， 也是码农很重要的能力，多多练习吧。
所以想编程如飞的话，还是赶快搞定一个IDE吧。
而是在一次次的迭代， 一次次的重构下慢慢的浮现的。
所以重构就显得非常重要， 如果你没有掌握这个技能， 赶紧去看看 Martin Flower的那本经典的书吧：《重构：改善既有代码的设计》
写单元测试主要是保证自己写的业务模块是按照预期来工作的。
此外，这些测试也会成为一种“文档”，用来描述软件的行为， 永不过时。
更重要的是，这些测试将会成为负责任的哨兵： 将来你改动代码的时候， 运行这些测试将会告诉你是不是对原来的逻辑造成的损害，这种回归测试的功能是价值无限的。
现在的软件开发都是团队合作， 甚至是分布式合作， 所以一个SCM系统几乎是团队的必备。
日常的工作都是从SCM中check out 代码开始， 所以熟练掌握至少一个SCM是码农的基本能力， 如果还不会的话， 赶紧到github上开个免费账号，学习一下吧。
这个过程如果是手工的， 那就太无趣了。
这个过程当然应该是自动化的，码农至少应该学会像Ant, Maven这样的工具和像Jekins这样的平台， 帮助我们完成软件的构建。
热门文章：