`

五年程序员人生的点点滴滴

阅读更多

      和大家一样,我也是一名普通的程序员,很快工作五年了。现在依然记得大学时软件工程老师曾说过的一句话,大概是这样的:“工作五年之后,就基本可以分出大家的区别了”,这句话大概有两层意思,第一,大家都基本确定了自己的工作或职业方向;第二,一个人的能力如何基本已经确定了。先抛开这句话的真理性,至少它本身是有些道理的,当然随着时间的迁移,当初的五年时间对于现在可能已经不太准确了。但这句话一直陪伴着我,每过一段时间,我就会想起这句话,因为自己很想知道五年之后自己是什么样子,总告诫自己一定要找准方向,要努力学习,让自己在合适的时间能有质的飞跃,能够在同行同辈之中脱颖而出,在工作或事业上形成一个转折点。愿望总是美好的,而正因为有了美好的愿望,人类才能够不断向前走。

      读高二时开始接触电脑(那时用计算机这词也太过专业了吧),偶尔跟着同学去网吧泡泡江湖,论坛形式的游戏,那时要是能打到只凶猛的老虎那可真是令人羡慕忌妒恨啊…。也是那时第一次听了刘若英的《后来》,而且网吧经常放这首歌,直到现在,一听到《后来》就会勾起我的回忆,那感觉挺好!江湖,很侠气的词儿,估计现在的年轻人都不知道曾经有款如此简单低级的游戏了,呵!从那时起,我算是真正的接触了电脑,接着学聊Q、听音乐、玩CS…。还好自己一向比较能克制自己,以致于最终基本不影响考大学。
      报考大学的时候,许多人都是糊里糊涂的报,专业名看起来顺眼就基本差不多了。但那时我却有着明确的报考方向,那就是计算机专业,在那时我似乎就已经知道编程是怎么回事儿了,虽然我真的是没接触过。

      上了大学,读的是自己喜欢的计算机科学与技术专业。
      入门的编程语言是C语言,接触了之后挺喜欢它,那时觉得它简单易学,似乎能够解决好多问题。
      第二门编程语言是Java,经过一段时间的学习发现,Java代码之优雅、结构清晰等优点深深的吸引着我。
      C++自学过一个月左右,ASP了解了一些,C语言和Java都开过课程,那时Java在我心中绝对是第一语言。
      大三第二学期开始接触J2EE,后来基本上每天都会学习相关的技术知识。在老师和师兄的明师指路之下,开始自学了HTML、JavaScript、CSS、XML、DTD、XML Schema、MySQL、Jsp、JSTL、Sitemesh、Spring、Struts、Hibernate、EJB、CVS、Jcreator、MyEclipse等技术与工具。毕业设计与几个同学开发了一个小系统,毕业设计文档还把软件工程的几个步骤给整了一遍,结果还像模像样搞得挺自满的。
      就这样,我带着一颗对编程的热情与好奇心,慢慢的踏上了程序员之路。

      工作后,先后从事了金融行业、电信行业,工作内容经历了写代码(SSH、JSF、ExtJs、单点登录、Eclipse插件开发、GWT开发…)、Linux日常命令使用、安装配置Linux、基于Linux安装MySQL/Oracle及维护、应用系统部署及维护、技术沟通、需求调研、技术管理、工作分配与进度跟踪、项目管理、招聘等(不分先后),一路走来,真是五花八门啊,相信大多数前辈和同辈们都是如此走过来的吧!

      软件这个行业,都说是业务是灵魂,技术是手段,技术不太重要,业务才是最重要的。也许,这就是软件行业在浮躁而极富特色的中国被糟蹋的结果吧。
      但我个人始终认为,作为一家软件企业,技术永远是最重要的,技术才是软件企业真正的灵魂,我反对那些不重视技术的软件企业(虽然你们也是受害者,但却是你们把中国程序员给害的)。

下面总结点自己的工作经验:
1、没有解决不了的技术问题,关键是时间与方法
2、不要说没时间,时间真的是挤出来的
3、Bug是永远改不完的,关键是要修复严重的、影响业务的、显眼的Bug
4、随着项目的开发,接触项目的人越来越多,项目代码越来越乱,风格五花八门,潜在的Bug越来越多,以致于谁都不想去维护了
5、很多程序员写代码不负责任,写代码的水平暂且不说,更令人发指的是,代码测试都没过自己那一关,总想留着让别人去测试,那个汗…
6、喜欢技术的程序员太少了,都想着三五年后转管理,赶紧摆脱技术圈
7、浮躁,简单的注释、命名、代码风格、代码重构、代码测试、业务理解都没做好,就想着做有挑战性的工作、想着转管理,怀着这种心态的兄弟们,你们真能把其他事做好?
8、项目经理很多,但大多经验不足,基本工作是了解需求并做初步分析,简单的工作计划,工作分配,进度跟踪,对系统发表几个观点、提几个问题。这些是必要的,但我觉得有很大的不足,项目经理应该更多的参与到项目的整个过程当中。让程序员开发系统,永远是从实现功能的角度去思考问题,这一点恰恰是开发系统的重伤,因为客户关注的是业务流程。程序员总把问题复杂化,如系统功能强大、支持N多种场景、界面内容丰富等等。没错,作为程序员,我们更多的是想展现并充分发挥自己的能力,但客户想要的确是简单易用、清晰而实用的系统。所以我想说的是,程序员重在功能实现,而客户关注的是结果,项目经理应该多从客户或使用者的角度去参与项目,这样做出来的系统才能够符合客户的要求,程序员才能少加班,因为业务流程清晰、简化实现,从而减少返工的确能够节省很多时间。

      技术,将会一直陪伴着我,无论将来我处在哪个岗位上,因为我学习技术的出发点是兴趣,有时候自己想想甚至不知道为什么,反正就是喜欢。

      程序员之路才刚刚起步,路还很远,但绝没有捷径,只有脚踏实地,一步一个脚印,程序员人生才会更美好!

      写文章对我来说挺难的,想当年读高中的时候,还曾经语文考了倒数第一,所幸的是仅此一次。那时每次写作文的时候,我只写议论文,而且只会“总-分-总”,什么名言警句、典故之类的,都是瞎编,纯粹就为了凑篇幅。所以,这篇文章也花了几个小时的时间,时间虽长,内容却有限,但总而言之总结能令人反思与进步!

89
42
分享到:
评论
101 楼 小烈2011 2013-05-27  
zhanjia 写道
lgcpeter 写道
引用
但我个人始终认为,作为一家软件企业,技术永远是最重要的,技术才是软件企业真正的灵魂,我反对那些不重视技术的软件企业(虽然你们也是受害者,但却是你们把中国程序员给害的)。

不真正潜心做几年业务开发,也许体会不出业务的重要性要远远高于技术。
引用
Bug是永远改不完的,关键是要修复严重的、影响业务的、显眼的Bug

不赞同这一点,写程序过程中应该就能控制Bug。即使有Bug改一个少一个。



1、首先表明一点,技术和业务都很重要,而且IT的不同行业、不同企业的重视程度也都不尽相同。
我说的技术和软件企业可能与你们理解的有点不同,我澄清一下:
1)技术
不只是简单的写写代码,需要从架构、开发模式与方法、实现思路与方法、性能、分布式、集群等方面考虑,写代码只是最终的实现。
如微博,这个业务相对技术来说就简单多了,技术构架、技术选型无疑是最重要了;
像Oracle、Google这类那更是毫无疑问;
那就说说比较接近我们的一些应用吧,如仓库管理系统、旅游网站、工单类的系统、移动的计费系统等,像前三类业务复杂吗,细细想想不复杂吧,计费系统就复杂些,但计费系统也是一点一点的做起来的。

2)软件企业
我偏向于指那些以开发软件为主的企业,这类企业如果软件能做好,相信路会走得更远。

当然,我的观点并不以国情为出发点,因为大道理在中国通常是行不通的,我只是单纯从技术和软件行业的角度发表观点。

中国的软件行业本身就特殊,本来客户需要懂的业务,可能连他自己都不懂。软件本身就需要客户参与,但实际上客户参与得特别少。本来通过沟通引导,需求和业务流程应该可以非常清晰,但这在中国很难而不是做不到,成本也很高。
业务很重要,但由于客户或企业的急功近利、无知、不负责任、只想忽悠领导赚钱、形式的做项目与汇报、无理智的否定技术的重要性,技术的重要性无疑下了几层几狱,业务的重要性也被提到天堂去了


2、我想表达的意思是
1)是软件都会有Bug,这是公认的吧,像Windows、Oracle等等不都有许多Bug
2)既然有Bug,我们就应该分清急缓,先解决紧急、重要、影响业务的。至于有些Bug,改一个少一个,也有些是改一个多出一两个。Bug当然是要控制的


说得不对的地方大家赶紧拍砖吧








中国的软件行业本身就特殊,本来客户需要懂的业务,可能连他自己都不懂。软件本身就需要客户参与,但实际上客户参与得特别少。本来通过沟通引导,需求和业务流程应该可以非常清晰,但这在中国很难而不是做不到,成本也很高。
业务很重要,但由于客户或企业的急功近利、无知、不负责任、只想忽悠领导赚钱、形式的做项目与汇报、无理智的否定技术的重要性,技术的重要性无疑下了几层几狱,业务的重要性也被提到天堂去了
===========================

对上面这段话,深有体会啊,有时客户的很多需求都是华而不实,只是为了向领导汇报时够华丽,够酷炫,结果苦了最终用系统的人,更苦了码农
100 楼 xu3352 2012-06-25  
同感,总结得很不错啊........
99 楼 yq81862 2012-05-23  
好文章啊!
现在真是对技术有兴趣的程序员太少,而且负责人的程序员更少。
像lz这样的,应该在工资之外在加5k用来奖励这种思想和态度。
98 楼 Roney_wei 2012-05-23  
快点买房要小孩
wangchangbing 写道
同5年 感慨很多 最想快点买房要小孩

哈哈



有了技术,快点买房要小孩 [ 这个不是问题
97 楼 changer0702 2012-05-23  
我大学学习经历和楼上差不多,觉得JAVA语言代码整齐、优雅,出自兴趣学了不少JAVA编程方面的技术,楼上体的那些技术名词我都不陌生,但这些技术都只停留在会使用的阶段。现在在读研究生,做的还是工程性质的活,发现自己技术水平一直没有长进,有时候会觉得很迷茫,不知道如何提升自己。
96 楼 kaway 2012-05-23  
跟住兴趣走 我中意!
95 楼 飞扬云 2012-05-22  
坚持信念,永不放弃!
94 楼 黑色牧马 2012-05-21  
嗯,写得很不错的,支持,技术才是程序员的核心
93 楼 hubowei1 2012-05-21  
蛮不错的 加油

我也2年多一点的工作经验。
92 楼 hetaohappy1 2012-05-20  
潜心研究技术,可现实是你根本没有时间好好来研究技术,上面都是要结果,结果出来越快越好,不管里面的代码质量
91 楼 zhanjia 2012-05-20  
lgcpeter 写道
引用
但我个人始终认为,作为一家软件企业,技术永远是最重要的,技术才是软件企业真正的灵魂,我反对那些不重视技术的软件企业(虽然你们也是受害者,但却是你们把中国程序员给害的)。

不真正潜心做几年业务开发,也许体会不出业务的重要性要远远高于技术。
引用
Bug是永远改不完的,关键是要修复严重的、影响业务的、显眼的Bug

不赞同这一点,写程序过程中应该就能控制Bug。即使有Bug改一个少一个。



1、首先表明一点,技术和业务都很重要,而且IT的不同行业、不同企业的重视程度也都不尽相同。
我说的技术和软件企业可能与你们理解的有点不同,我澄清一下:
1)技术
不只是简单的写写代码,需要从架构、开发模式与方法、实现思路与方法、性能、分布式、集群等方面考虑,写代码只是最终的实现。
如微博,这个业务相对技术来说就简单多了,技术构架、技术选型无疑是最重要了;
像Oracle、Google这类那更是毫无疑问;
那就说说比较接近我们的一些应用吧,如仓库管理系统、旅游网站、工单类的系统、移动的计费系统等,像前三类业务复杂吗,细细想想不复杂吧,计费系统就复杂些,但计费系统也是一点一点的做起来的。

2)软件企业
我偏向于指那些以开发软件为主的企业,这类企业如果软件能做好,相信路会走得更远。

当然,我的观点并不以国情为出发点,因为大道理在中国通常是行不通的,我只是单纯从技术和软件行业的角度发表观点。

中国的软件行业本身就特殊,本来客户需要懂的业务,可能连他自己都不懂。软件本身就需要客户参与,但实际上客户参与得特别少。本来通过沟通引导,需求和业务流程应该可以非常清晰,但这在中国很难而不是做不到,成本也很高。
业务很重要,但由于客户或企业的急功近利、无知、不负责任、只想忽悠领导赚钱、形式的做项目与汇报、无理智的否定技术的重要性,技术的重要性无疑下了几层几狱,业务的重要性也被提到天堂去了


2、我想表达的意思是
1)是软件都会有Bug,这是公认的吧,像Windows、Oracle等等不都有许多Bug
2)既然有Bug,我们就应该分清急缓,先解决紧急、重要、影响业务的。至于有些Bug,改一个少一个,也有些是改一个多出一两个。Bug当然是要控制的


说得不对的地方大家赶紧拍砖吧
90 楼 ciro 2012-05-19  
对于刚转行做程序员,任重而道远,楼主的文章给了我一些启发,谢了
89 楼 SoCoolMan 2012-05-19  
我也认为 技术是核心 只有技术好 才会给你的公司节约各种成本,这样资本家才高兴。
88 楼 wy152150 2012-05-19  
顶一个,加油
87 楼 chenhaohbu 2012-05-19  
能静下心写写心得体会,就是在不断进步……
86 楼 lgcpeter 2012-05-19  
引用
但我个人始终认为,作为一家软件企业,技术永远是最重要的,技术才是软件企业真正的灵魂,我反对那些不重视技术的软件企业(虽然你们也是受害者,但却是你们把中国程序员给害的)。

不真正潜心做几年业务开发,也许体会不出业务的重要性要远远高于技术。
引用
Bug是永远改不完的,关键是要修复严重的、影响业务的、显眼的Bug

不赞同这一点,写程序过程中应该就能控制Bug。即使有Bug改一个少一个。

85 楼 xucaishen 2012-05-19  
同感。。。努力。。。
84 楼 lenka_xiu 2012-05-19  
写的很好
java女程序媛
工作不到一年
还没毕业的
对技术很有兴趣的
飘过
83 楼 zone8089653 2012-05-19  
没办法 在天朝想一直做技术咋生活 程序员也要买房买车啊
82 楼 王da萌 2012-05-19  
兴趣是培养的,希望自己以后的路是越走越宽,我们女孩也可以做好的。

相关推荐

Global site tag (gtag.js) - Google Analytics