鞠强
这是一篇关于成长的心得。仁者见仁、智者见智,如果诸位读者能够从此文中看出一点东西来,有所感悟,我就满足了。
我是数学系毕业的,大二开始捣鼓计算机(94年),最大的兴趣就是写程序。改游戏、改病毒,这些小东西让人很有成就感。工作后的兴趣经历了一个很大的转变(当然,这个时间相对于多数人而言,迟了些),2000年的时候,我突然发现了我写的程序的价值。当我看到我修改了短短的几行代码的时候,给客户带来了很大的效率提升,降低了成本,那种成就感,远非6年前的认识可比了。
本文并非专门面对计算机入门者,所以内容比较杂。
此段权作前言,现在进入正题。
知识点要连贯,知识面要广
国内的大部分软件企业,从来没有像国外那样,在技术上保持连续性。从微软这条路线来看,从最早的DOS->Win16->Win32->OLE->DCOM,到COM+->.NET,我们很难找到能够完整走完这个历程的人。这种现状,导致大部分的技术人员,对于开发技能,有一个很大的断层:知其然,不知其所以然;碰到非source code的错误,就手足无措;或者代码质量低劣,或者性能有很大瓶颈。
上面的路线演进,可以认为是“工程”方面的,而非我们大学教育中的“科学”。操作系统、数据库、数据结构、离散数学,这些内容非常重要。但是我们要注意的是,你学习了这些,不代表就能写好一个程序,能够解决客户的问题。工程方面的东西,我们多加掌握,熟练应用,配合上述“科学”的内容,才能真正保证程序价值的发挥。
而如何让两者有机的结合起来?我想,不外乎就是兴趣+经验。
在微软平台上开发,很重要的一个资源就是MSDN(Microsoft Software Development Network),里面有how to,有concepts,有topics,可以让我们更好更快的上手。当我们碰到某个代码错误,想找某种解决方案的时候,MSDN是一个非常好的助手。对于初学者,我们可以看里面的how to,step by step的进行学习。
还有一个笨办法,我刚工作时候采用的,就是找一个老版本的SDK说明文档(borland开发工具的帮助里面就有,那个短小精悍,没有msdn的那么复杂),从字母A开始,到字母Z,我当时花了一年半的时间,基本把所有的API都试验了一遍。这么做有个好处,能让你快速的对整个开发有一个概览。以后在学习或者工作中碰到了问题,能让你有一个大概的印象,知道应该怎么做,知道应该用哪个API
对于现在的应用而言,如果是基于.NET的企业级应用开发,我的经验是,Win32 API了解即可(当然,如果对某一方面很熟练的话,还是非常有好处的。如socket、GDI等。);COM/COM+要知道一些,至少要清楚Add/Release Reference的含义;.NET Framework要深入一些。比如可以拿那本《.NET 高级编程》来做练习。这本书1000多页,虽然名之为“高级”,但你可以拿它当字典来用。有兴趣的,可以按照我说的那个笨办法,从第一章开始到最后一章,读一遍之后,自己一个字母一个字母的,把所有的代码写上、调试通过、运行,并反复debug,从中了解语法、语义、一些编程技巧。
对于高质量的代码而言,仔细研读《Essential .NET》这本书是很有必要的。
对于企业级应用开发,还有一点很重要,就是数据库知识。数据库本身的语法很简单,关键是我们写出来的sql要成本低,成本低一般就会带来效率的提升(并非绝对如此)。这部分内容,一需要经验,二需要思想意识的转变。什么思想意识呢?就是要有数字化的观点!
举个例子,客户让你出一份能够适应未来三年需求的存储方案,你该如何考虑?如果没有数字的观点,很可能的结果就是瞎蒙出来的数字。如果有了数字观点,我们很容易提供此方案。
对于存储空间,我们可以仔细分析客户最近2-3年的数据库结构、内容,加以咨询客户,未来3年的应用变化趋势,最终我们能得到这样一份提纲:
|
帐务管理
|
发票管理
|
订单管理
|
用户个数
|
50
|
20
|
100
|
高峰时间段
|
月底3天
|
每日
|
每日
|
每行记录大小(kb)
|
20
|
10
|
200
|
业务发生笔数(每天)
|
30
|
50
|
50
|
高峰期业务发生笔数(每天)
|
100
|
50
|
50
|
假设每个月工作日是22天,那么计算每个月的高峰期业务量、平时业务量,得到一个总数,乘以36个月,就能得到一个统计意义上的3年业务量。再考虑到tempdb、日志、索引,以及raid,我们就能很容易的得到存储空间数字。再通过TPC等要求,得到服务器的其他配置要求。
当你写的代码被别人应用的时候,总会有这样、那样的问题。硬件,可能会和程序不兼容;软件,新操作系统你可能不支持;木马可能让你的B/S代码发生莫名其妙的故障;病毒会导致你的.NET runtime频繁重启;BT/emule让你的应用没有带宽用、socket无法连接,等等……
诸如此类的问题,绝对不是我们在电脑旁边写程序时,就能想到的。那怎么办呢?我们虽然做不到全才,但是要利用好你所处的团队,利用好网络资源。这两点做到了,当你积累了相当的经验,再考虑新的程序的时候,就能有所警觉,让新程序的架构更为合理。(对于架构,牢牢记住这些:伸缩性、扩展性、可靠性,以及安全、性能。)
当你对架构有所了解的时候,你又会发现,细节决定了一切。细节的处理,来自于你的知识面、项目经验,以及大量的思考。无论.NET还是J2EE,无论是C#还是C++,平时多了解一些,总会对你思考整个软件,带来益处的。
软件开发是一项事业
软件是一个非常累的行业,如果想拿高薪、每天八小时工作、周六周日有自己的私人空间,那么在这个行业你几乎找不到合适的切入点。
对于许多新人而言,这个行业充满了诱惑,也有很多挑战。兴趣,也许是选择这个行业的第一前提。当我发现我写的程序能够控制企业的生产设备时,无疑是很兴奋的;当我发现我的代码总是会莫名其妙的crash,无疑又是很沮丧的。很快,我们的兴趣就容易被这些抽风似的问题,磨灭殆尽。
也许可以这么说,兴趣是领我们进门的老师,你能让它跟你越久,你就越能保持前进的动力。如果没有了,这也是一个好事。我在工作后的第三年,突然对所做的一切失去了兴趣。后来想,这说明我已经度过了那个纯粹感性认识的阶段,“可以”朝理性阶段迈进了。
就这个行业本身而言,我们更多的接触客户、更多的接触实际需求,这些带来的冲击,远比一种新技术对我们的影响,要猛烈的多。客户那里有各式各样的硬件环境、网络环境、软件环境,有各种管理模式的应用。接触的久了,我们自然就会思考:
l 我写的代码,该如何改进,才能适应各种环境?
l 应用上采用什么架构,可以满足可预见到的未来的需求?
l 怎么做,能让程序在sqlserver和oracle、db2上都跑的很好?
l 安全上,代码中的sql injection,真是那么容易解决的吗?
l 我的程序能够无缝的在客户那里的.NET Frame1.1/2.0上切换吗?
l 我的程序,如何能在windows 2000上跑的更快?
当我们有了这些思考,实际上,兴趣就又回来了。这些问题毫无疑问,都不简单,但都很有意思。我相信,这是一个良性的循环。兴趣、事业,交替引导着我们前行。
不要急于为自己定位
工作了2、3年之后,我们都会有这个困惑:我以后做什么?继续作程序员?作管理?想的再远一些,30岁之后,我们应该做什么?
这个问题,我曾经问过我的老板,他和我说,你把自己当前的工作做好,好的要做的更好。今后的发展,是和你目前所做的工作、你的视野、你的经验,息息相关的。
功到自然成。
如何看待IT这个行业
我认为IT行业,现在刚刚是起步阶段,这个阶段也许持续20年或者更长。IT的最终目标,应该是作为一种基础服务,沉淀在经济发展大潮下面。如同水、电、煤气一样,我们日常感受不到它们的存在。一旦停电、停水、停气,我们才会感觉到不便,才会发现,整个经济的运转,都离不开这些基础设施。
软件方面,最终也会发展到这么一个阶段。黑客帝国二里面,议会老大和NEO在谈论matrix和“真实”世界,透过繁荣,背后是巨大的能量供应基地、星罗棋布的管道,这一切看起来丑陋的东西,被深深地印藏在背后了。
从目前来看,软件还是在尽量的模拟世界,尽量的从数据中发现我们所生存的这个世界的真相。这首先需要我们把所有能发现的现象,都抽象出来,需要庞杂的数学理论支持,需要硬件的革命性地变化支撑。
但这是一个非常困难的工作,也许几代人的时间我们才能做到。我们目前所做的,正是这伟大变革的第一步。
做好选择:进大公司?进小公司?
每个临近毕业的,致力于搞软件的人都会有这个抉择:进大公司?进小公司?
大公司门槛高,组织结构复杂,层级很多,待遇也许不会太好,高手众多。Freshman也许要适应几年的时间,才能展露头角。
小公司门槛低,结构单一,待遇相对会好。新手很容易抓住机会,在项目中成长起来。
众多走过来的人都有这个经验,大公司里面你会学到很多东西,各方面会正规一些;小公司的生存压力比较大,也许你会成为一个多面手,但成为一个高手,会很困难。道理很简单,一个是发展阶段,一个是生存期,这两种状态决定了公司的运营状态,决定了软件研发的思路,决定了市场思路。
我个人的体会是,开始进入大公司,应该是一个不错的抉择。如果进了小公司,就要考虑如何踏实的把工作做好先,如何能够全面、快速的成长。
作者鞠强,10年的企业管理软件开发经验,目前致力于产品性能、安全方面的研究。我的联系方式是:济南市山大路224号,浪潮通软,邮编250103。联系电话:138 5310 1310,MSN是:juqiang1975@msn.com