现在的位置: 首页 > 综合 > 正文

剑法三套,程序员也能挣大钱(二)

2013年12月04日 ⁄ 综合 ⁄ 共 5255字 ⁄ 字号 评论关闭

原文地址:http://www.chinavim.org/%E5%89%91%E6%B3%95%E4%B8%89%E5%A5%97%EF%BC%8C%E7%A8%8B%E5%BA%8F%E5%91%98%E4%B9%9F%E8%83%BD%E6%8C%A3%E5%A4%A7%E9%92%B1%EF%BC%88%E4%BA%8C%EF%BC%89.html

(本文共分三部分,现在打开的是《第二部分》,欢迎阅读《第一部分》和《第三部分》)

3 设计,方法为指导

3.1 阶段释义
老李:老张,你负责的这个模块,要有分布式事务处理能力,还要能与客户的OA系统通信,从OA中获取客户资料的数据。
老张:好的。我将用EJB来实现分布式事务处理,然后开发一个专门的接口,用来与OA通信。
老张毕业五年,是项目组的开发经理,负责完成子系统的设计,并指导其他成员完成编码。老张从老李处获得关于所开发的产品的需求情况,然后进行设计和分析,用UML建出模型,并生成框架代码,由小王等去实现。
老张属于第二阶段中人,通常工作了三年以上。此阶段中人,已经完成了一定程度的技术积累。对《设计模式》、《J2EE核心模式》、《UML》等烂熟于胸,张口就是IOC(控制反转),有事没事也要说说AOP,最差也得是Factory、Delegate吧,你要是说不知道什么是Facade,都不好意思跟人打招呼……
与第一阶段“我能——I can do it”不同,本阶段的人,特点是“我知道它能——I know It can do”,对,就是“知道它能”,至于如何去“能”,就不需要关心了。例如老张,他只需要把EJB接口定义清楚,知道有了这个接口就能完成相应的功能,至于小王如何去实现这个接口,是写了三个类还是五个类,就不关心了。
从技术角度,追求的不再是纯粹的技巧,而是方法这个层次,努力寻求正确的做事方法。即关心“怎样才能盖出好房子”,而不是“如何把石头从货车里搬运到工地上”。用流行的话说,就是“只要方法正确,结果就会正确”。
当然,达到这个阶段的人,技巧本身,通常也是很厉害的。举个例子吧,小王要用一个开源的XML文件比较工具,并编了个测试程序,比较a.xml和b.xml的区别,却怎么着都得不到正确的结果。后来老张来了,牛人根本不看JavaDoc,而是拿着XOP提供的命令行比较了a.xml和b.xml,发现结果是正确的,然后直接打开与命令行对应的main(),检查与options对应的API,发现小王少调用了一个API,加上这个API后测试程序就通过了。在这件事中,老张根本不熟悉XOP的API,但他掌握了查找API的方法,那就是:组件或工具,都有其外在特性,通过组件或工具提供的命令行能做到的事,也一定能通过它提供的API来完成。如果不知道如何去调用API,对于开源软件,看它的source
code或samples中的main()即可;对于非开源软件,看StackTrace;如果都看不出来,就放弃该软件,选择别家的吧。
此阶段中人,也需要编写程序,但编写的是与业务和框架相关的核心类。所用的语句通常朴实无华,用最简单的语句完成最复杂的功能是他们的习惯。例如,求b和c中的较大值,通常不会写成
result=(b>c)?b:c
而是写成
if (b>c)
result=b;
else
result=c;

因为后者更容易懂,而前者,相对生僻一些。开发经理的工作,是把产品的需求,转变为编码人员能理解的接口或类,并保证团队的所有成员在理解上的一致性、无二义性,在这个前题下,简单而又精确的语句是必然的首选。所以,如果你的经理编写的程序,在你看来很“幼稚可笑”时,千万不要洋洋得意。
舍小巧而用大巧,舍弃繁花似锦的编程细节,换取简单稳定的框架结构,换取无二义性的交流效果……独孤剑圣四十岁前,以玄铁重剑纵横天下,剑法古拙,大巧不工,就是此境界(孤独大侠也走过弯路,30岁时用紫薇软剑,可能是追求剑招的繁复和剑法的华丽,失去控制,最终误伤义士)
3.2 应该做的事该阶段的人,该做可做的事非常多。须知一个完整的软件产品的开发过程,编码仅仅是其中的一个环节而已。作为开发经理,老张的典型工作如下:
首先充分理解需求,挑选其中20%左右的功能,结合非功能性需求,设计出系统的结构(Architecture Design)。通过边界类、控制类、实体类的应用,分析清楚Use Case中的交互流程,然后用一系列接口来表达这个流程,最后运行各种设计模式或技巧,实现这些接口,建出UML模型,并生成代码框架。
除了开发经理外,你还有可能是项目经理,在中国公司,项目经理和开发经理可能都是你。学习先进的开发方法是你的必修课,什么用例驱动开发、测试驱动开发,不管用不用,你都得知道个大概;选择正确的开发模型也很重要,何时选用瀑布模型,何时选用迭代模型,一定不能含糊。
遵守公司的开发流程,为SQA(Software Quality Assurance)提供必需的文档和数据也是你的本职工作。如果你所在的公司尚无规范的开发流程,那么,你要帮助公司来建立。完整的开发流程贯穿整个产品生命周期,你有可能只与其中几个阶段有关。但只要与你有关,那就要尽力去配合。
该阶段的人,通常在公司中是中层干部,执行能力是一个最主要的考核指标。你的领导,可能根本不懂编程,而项目组里的小伙子们,可能无法领会领导的意图,这时,你就是中间人,好比足球场上的中场,你的沟通能力和执行能力,将决定产品开发阶段的成败。
3.3 不应该做的事

1、尽量少编程。除了“核心接口、类和算法”,不要与其它代码纠缠,那会使你忽视宏观上的问题。而且,你也不一定比小伙子们编得快。只有当小伙子们遇上困难时,你才去协助他们解决问题。
2、不轻言放弃。该阶段的人,工作压力巨大,即使他看上去什么事也没干,他承受的压力也不是编码人员所能体会的。在压力面前,容易失去理智,如果不注意控制自己的情绪,可能会发生一些不愉快的事。
现在的你,可以说是“到哪都能找到工作”了。当与公司、同事发生一些摩擦时,可能会“一怒而去”,这是最要不得的。因为你现在追求的,已不是“能找到工作”了,而是“能找到体现自己价值的工作”,千里马尚且需要伯乐来发现,换家公司就一定能受重用了?而且,不管你是否意识到,你已经学习了许多行业相关的知识,这些知识,在更换公司后,未必能用上,到新公司后,还得从头学习——人生有几次重来的机会?
3、戒骄戒躁。你现在已经是“有本事”的人了,加上工作压力,难免有点脾气。但是切记,你还没有功行圆满,还要“多长本事,少长脾气”。因为你的局限性,与你的优点一样明显。技术等级的提升,应该是让你眼界更开阔,并看到了更大的差距,而不是固步自封。
4、不要迷信新技术。新技术的采用是有一定的风险的。因为技术本身,可能还不成熟。追捧新的框架可能是你的爱好。没关系,作为爱好,是可以的,但不一定要把爱好带到工作中来。老板关心的是你开发出来的东西能否买个好价钱,不是看你用了多少新的Framework。你的用户关心的,是产品的易用性、稳定性,用起来是否顺手,用户同样不会关心你用了Tomcat还是Jetty,甚至连J2EE和.Net都不关心——如果他不需要为此购买新的硬件或者重新培训操作员。
5、多看人文方面的书和文章。此时的你,在技术方面已经有一定的造诣了。但是不是就大功告成了呢?回答当然是“不”,你还需要补充人文方面的知识,即进行感性思维训练。为什么?往下看。
3.4 局限性你的局限性,与优点一样明显。如果让你列举自己的优点,你可能会说:
n 我精通设计模式,能做出重用性很好的软件
n 我对软件工程很有经验,能做一个好的项目经理
n 我熟悉建模工具、开发环境等,能提高开发效率
n ……

是的,这些都是了不起的能力,但是:
1、 你们公司不是研究所,不卖设计模式,也不是咨询公司,不卖软件工程经验,更不是培训机构,不对外提供“建模工具、开发环境”培训
2、 你知道软件是如何被开发出来的,但很少考虑是否应该开发这个产品;
3、 你不知道用户会怎样使用你开发的产品,你不知道用户喜欢什么、抱怨什么;
4、 你不知道这个产品为公司赢得了多少利润;
5、 ……

一句话,你懂技术,但客户要的,并不是技术。摩托罗拉有世界上最好的射频工程师,但为什么手机就是卖不过诺基亚呢?因为诺基亚喜欢听客户的意见,而摩托罗拉喜欢听工程师的意见。
你说:“我热爱技术,喜欢钻研技术,至于客户在想啥,那不是我要考虑的问题——我甚至不知道客户是谁”。是的,达到你今天的这个境界非常不容易,许多人工作十年也未必能象你这样优秀,你是公司的骨干,是同事的偶像,但是……但是……《武状元苏乞儿》中有一段经典对白:
洪日庆:先别走!行行出状元!如果我没看错,你会是乞丐中的霸主!
苏 灿:乞丐中的霸主?!那是什么?
洪日庆:嗯……还是乞丐!

没错,乞丐中的霸主也是乞丐。你再优秀,也只是公司的中层干部,是干活的人中的霸主——还是个干活的:
n 客户给老板发工资
n 老板给你发工资
n 你不认识客户,客户同样也不认识你
n 既然你不认识客户,那就不知道客户喜欢什么、讨厌什么
n 如果有一天,你的产品让客户不满意(这个概率还是很大的)
n 客户很生气,后果很严重
n 老板请你喝咖啡,并建议你去度假,顺便提醒你从外面把门关好

再来看看圈子里:
n 没有技术,但手里有一堆客户的公司,比比皆是,他们活得很滋润。
n 没有客户,但手里有一堆技术牛人的公司,很少见——都倒闭了。

现在,你知道局限性在哪里了吧?
“正因为你技术太强了,所以只能当乞丐中的霸主,技术恰好就是你的枷锁”
说件真实的事吧。
某天,我奉命与一个合作伙伴交流我们的平台产品,目的是让对方了解我们的平台并在平台上做二次开发。交流进行得很顺利,对方也跟我们签合同了。后来,市场人员去合作伙伴处了解反馈意见,对方说:“你们那个xxxx太厉害了,问什么都难不倒”。回来后,领导就不允许我参加交流了。原因是:“你可能泄密了”。
作为技术人员,我希望充分介绍自己产品的优势,并能应付合作伙伴提出来的各种应用场景和问题。但是,从领导的角度来看,“如何满足应用场景、如何解决问题”本身,就是商业机密,是不能乱说的。举这个例子的目的,就是说明技术人员看问题的局限性。
想要达到更高的层次,就要跳出技术看问题,多了解市场,了解客户。假设孤独剑圣陶醉于玄铁重剑的威力,天天带着到处乱跑,那么他就不是剑圣,而是搬运工了。搬运工最多只能当个中层经理,当不了高层领导。
如果想进入领导班子,与老板一起玩游戏,那就赶快升级吧。
3.5 进阶指南

1、 跳出技术看技术
达到这个阶段的人,在技术上已经“很深入”,眼中所见,尽是技术。但你们公司不是卖技术的,你们卖的是产品,是服务。所以,把你的目光从技术中解脱出来,去思考一下产品和市场层面的问题。例如:
n 市场上有同类竞争的产品吗?
n 当前已有的产品,客户有什么不满意的?
n 我做的产品应该具有什么样的特色?有什么卖点?

所谓“一招鲜,吃遍天”。只要你知道客户想要啥,并能有针对性地开发产品,客户一定会情不自禁地给你钱。客户都给你钱了,老板还好意思不给你个CTO的头衔玩玩?
2、 了解业务
计算机技术必须为具体的行业服务,每个行业都有自己的特定背景和业务知识。技术人员应抓住机会,了解这些知识。我曾在某个电信软件公司任职三年,号称是项目经理,开发电信网管产品。那时我整天的工作就是研究各种框架,讨论各种设计模式,我眼中所见心中所想,尽是WEB、Struts、HTML等一大堆计算机名词。如果你问我“为什么这玩意是个网管软件,而不是淘宝易趣阿里巴巴?”我一定回答不出来。
一个公司里面,真正值钱的东西,不是技术,而是业务知识,技术是实现业务的一种手段,是为业务服务的,主从关系,不可搞错。
3、 加强非技术性的功夫
学书法时,老师曾说过“三分书内功夫,七分书外功夫”。这句话我一直不理解(事实上,到今天依然不理解),但把这句话用于计算机技术,却是明白的。三分书内功夫,是计算机技术,七分书外功夫,就是非技术性的产品和市场了。
可以通过看些“不务正业”的书,来提高自己的感性思维能力,可以多看看市面上流行的《比尔盖茨传奇》《数字化生活》《把信寄给加西亚》等,象《谁动了我的奶酪》这种只会抱怨不会解决问题的书,就不用看了。
3.6 阶段小结
适用人群:工作三年以上,上限不封顶
输 入:软件需求(请注意用词的区别:软件需求,而不是客户需求,你所得到到软件需求,是由别人收集来的,并不一定能代表客户,如果“别人”的水平一般,错误理解了客户的意图,那么你就等着跟他一块倒霉吧)
输 出:设计好的类、接口和算法
阶段目标:我知道它能——I know it can work
技术特点:注重方法,不关注编程语言细节
胜任职位:高级软件工程师、开发经理、系统架构师等
升级秘笈:换位思维,跳出技术看问题
参考薪水:¥6000以上,¥15000以下(仅供参考)

(本文共分三部分,现在打开的是《第二部分》,欢迎阅读《第一部分》和《第三部分》)

【上篇】
【下篇】

抱歉!评论已关闭.