人在江湖

  BlogJava :: 首页 :: 联系 :: 聚合  :: 管理
  82 Posts :: 10 Stories :: 169 Comments :: 0 Trackbacks

不确定“再见理想”是“再见了,理想”还是“再次燃起理想”,稀里糊涂地对这句话有感觉。作为程序员,总会有自己的技术价值观和技术理想。工作七年多,开始痒了。

程序员的生活总是喜忧参半,出入体面的写字楼,在小小的cubicle里虐杀脑细胞;偶尔有条件小资一下,常被工作、生活压力逼得点灯熬油;有时候想,这么辛苦,不论做什么行业都会做的好,是不是入错行了?手放在键盘的时候,又享受投入思考的快感。或许注定是个程序员,限于天赋,或许注定是个庸庸碌碌的程序员。

前端时间因为跑到乡下,没法上网,网瘾一上来撞墙流鼻涕,百无聊赖开始勾画价值观和技术理想。人总追求快乐,每天清醒的十六个小时中,——程序员可能有十八个小时,至少有八小时花在工作上,所以,为了过得快乐,工作一定要快乐。如果当前的工作注定没法使你快乐,就赶快结束它。毕竟,多数时候,拼命工作不如拼命找工作来得实在。程序员当然不算光鲜的职业,但确实挺费脑子,如果你智商低于110,换个软件公司也注定痛苦,还是直接换个行业吧。

工作的基本原则是要保持身价,何为身价?不是你现在月薪多少,而是你现在跳槽,能拿多高的offer。这跟很多因素有关,主要因素包括

1.你当前薪水——HR往往参考这个给你定薪水;

2.你的资历——毕业的学校,工作年限,外企工作年限,你当前的title,在当前公司工作了已经几年…

3.你在面试中的表现——能发挥多少技术水平,英语对答如何。

像我这种身价的本来没资格讨论身价,但谁叫这是我的blog,我的地盘听我的呢.挨个乱喷一下。

1. 关于当前薪水

假如你跟我一样笨,没有别的好办法,就只能多投入精力工作。在以前的博客 与神对话 里也提过一个程序员对于产品的价值。每天上班8小时,每天多专注一点,日积月累,做的事情会多很多,对自己的提高也会多很多。加薪或许是水到渠成的事,如果不顺利,要么跟领导谈谈,或者直接闪人。无论如何,不要抱怨。善于抱怨的人表示他还不够强。你需要尊重权利,包括他人的权利和自己的权利

2. 关于资历

如果你毕业于名校,学历又好,一毕业自然就能进大公司。如果你还在江湖三流公司混,就得每天想着早点换工作。工作年限不总算是资历,好公司的工作经历才有用。要记得换工作是有成本的,我工作七年多,现在的工作是第五份工作,所有公司都诟病我不stable,这样的资历很难骗取信任,教训啊!聪明的你肯定想到简历作假,但好公司都有reference check的,我还是劝你别冒险。

3. 面试

千万记住,一定要预先做好充分的准备才能参加面试。对于一个java程序员来说,面试之前要翻一遍类似于Thinking in Java的书,背一遍设计模式,复习sql,复习mvc框架,复习Hibernate,复习Spring, 复习Servlet spec。或许还有其他的,web service之类的。你可以想象,真要复习一遍,起码要三个月,这就是我认为换工作之前至少要预留出来的准备时间。机会有限,侥幸心理出去碰运气纯粹是浪费机会。平时工作总有局限,看书是最有效准备面试的途径。

上面说的都是不登大雅之堂的事情,有热情的程序员总想成长为高手,我当然也有这样的愿望。问题是你认为什么样的人算是高手,每个人心里会有不同的答案,关键是找出你和理想之间的差距并尽量缩短它。高手一定不仅仅是技术超群的,高手必然有高手的胸怀

自己有时候会考虑一些工作和技术上的原则,想到哪儿敲到哪儿吧。

关于工作:

作为程序员,你要关心产品。这没什么可说的,这是职业道德问题。

作为程序员,你要尊重QA。工作越久,就越觉得QA对产品非常重要,程序员很多时候陷在具体的技术问题中,太多精力被牵扯住了。好的QA让程序员心安,能够有助于控制风险. QA应该有做最后决定的权利,所以QA需要对产品有很好的insight. 而且好QA需要明白,测试不是找bug的游戏

关于技术:

effective java 和 Refactor书都是总结各种编程原则的书,那些熟为人知的原则不说,我只说我的理解

static: Joshua在effective java里强调尽量使用static method。这肯定是没错的[这句话说错了,请看下面T.H.E的评论。他说的很有道理。我是做应用的程序员,不暴露API给其他产品,所以一直都觉得IDE里移动static method没成本。但如果写Service层给未知产品用的话,耦合class的确有危险]。太看重这一点,就容易转到一个误区——多使用static field. 而static field有时代表了封装的问题,需要谨慎。

exception: 包括Thinking in java的Bruce, Martin Fowler等很多人都对checked exception不感冒。自己也思考了一下,你当然能举出checked exception的应用场景。你可以说某个方法它抛出checked exception是为了让caller处理exception.但你说的是让“这个caller”处理它。从重用的角度说,你并不预知所有被调用的情况,所以不能排除一些情况下这个checked exception并不能得到特别的处理。这个想法更本质的原则是,写底层程序的时候,要装作不知道caller是怎么使用它的,哪怕是你自己调用它。

重复代码:所有程序员都对重复代码表现出深恶痛绝的样子。但我觉得,重复代码不是定性问题,而是个定量问题。可以这样考虑:三行代码反复出现在三个不同的文件里,甚至在不同的package里,这算重复代码么?四行代码呢?十行代码呢?曾经听到一个高手说,编程的核心在于重用。我不反对这个说法,但我更倾向于说,编程的核心在于可维护性。对于重复代码,大段的重复肯定要消灭的,三五行的重复不是不可以存在,但是要尽量把它圈在一个小范围里,比如一个包,或者文件,或者方法里。有时候刻意追求“不重复”,反而让程序变得别扭。

技术存在的价值在于能够解决现实问题。你可以对技术狂热,但不能忘了这个客观事实,技术需要实现商业价值,需要最求投入产出比。最最根本的原则,是pragmatic

posted on 2011-01-30 18:17 人在江湖 阅读(3158) 评论(9)  编辑  收藏 所属分类: life

Feedback

# re: 七年之痒,再见理想 2011-01-31 09:22 T.H.E
"static: Joshua在effective java里强调尽量使用static method。这肯定是没错的。"
哪里有提到尽量使用static method? 还望指正  回复  更多评论
  

# re: 七年之痒,再见理想[未登录] 2011-01-31 09:47 greatghoul
其实有些时候,换工作是情非得以。。。  回复  更多评论
  

# re: 七年之痒,再见理想 2011-01-31 11:56 liujg
看来我只能改行了。。。  回复  更多评论
  

# re: 七年之痒,再见理想[未登录] 2011-01-31 21:44 vcycyv
@T.H.E
呵呵,对不起,是我搞错了。但我的确觉得应该多用static method. non-static和static 混杂在一起往往表示OO的不好。但是可以static的时候不写static不表示OO的好,那只是掩盖了问题。那么不如加上static声明,一方面不需要实例化类就能调用,比较方便。另一方面容易揭示OO的问题,这很实际。这里需要注意的是,一个方法没用使用成员变量,不表示一定应该加static关键字,因为有可能是为了继承和多态的考虑。但我感觉,绝大多数情况是可以安全地加static的,就算最后遇到多态需求可以重构。
你很敏锐,谢谢,如果我的理解有什么错误,请指正。  回复  更多评论
  

# re: 七年之痒,再见理想 2011-02-01 09:23 T.H.E
@vcycyv
存在必合理这点还是需要肯定的. 特别是工具类, 常量一般都是使用static method. 但过多的使用static method会使整个系统内的模块与模块间对实现类强依赖. 这样大大增加了代码的耦合度, 首先破坏了OO设计原则"高内聚, 低耦合".
以上都是从吹nb的层面讨论, 举些实际的例子来看使用interface而不是static method的好处.
系统中一个模块对外暴露出来的功能"接口"(这里指的是广义接口"), 如果是static method, 会造成其他模块对该类强依赖. 一旦内部逻辑或者觉得需要重构(类位置发生变化, 重命名等到), 依赖它的模块全部要重新编译. 小的系统还好大型系统成本太高.
但如果对外暴露的是interface, 通过static的"工厂方法"(这个到是effective java里推荐的呵呵)获得实例, 通过实例的method访问, 灵活度就非常高了. 可以看到开源框架基本上都是暴露interface给用户(osgi的bundle, log4j的log等等), 都是为了降低耦合度.  回复  更多评论
  

# re: 七年之痒,再见理想 2011-02-01 22:12 vcycyv
@T.H.E
"系统中一个模块对外暴露出来的功能"接口"(这里指的是广义接口"), 如果是static method, 会造成其他模块对该类强依赖. 一旦内部逻辑或者觉得需要重构(类位置发生变化, 重命名等到), 依赖它的模块全部要重新编译. 小的系统还好大型系统成本太高. " —— 这是我之前没有考虑过的角度,你说得很有道理,领教了,多谢!
我同意不应该过多地使用static method  回复  更多评论
  

# re: 七年之痒,再见理想 2011-02-02 13:42 xylz
工作也有“七年之痒”?这是程序员之痒还是工作的?显然我还没有达到这个层次。  回复  更多评论
  

# re: 七年之痒,再见理想 2011-02-08 08:38 凌晨风
程序员自我自我价值观太强了  回复  更多评论
  

# re: 七年之痒,再见理想[未登录] 2011-02-22 14:00 Frank
好文章,学习了,一看就是自己的切身经验  回复  更多评论
  


只有注册用户登录后才能发表评论。


网站导航: