我的代码人生5_2
9670 2016-05-18 12:12:30 继续2002-2010的介绍:
技术路线:从单一的采用pb进行开发,到pb全套解决方案,再到java转型,中间穿插着学习并利用flex、C#、C++进行项目开发;从单一的sqlserver数据库,到sybase、oracle、mysql、sqlanywhere、hsql、sqllite等多数据库的开发,形成了自己的技术学习路线,大大的提高了自己的技术水平,打下来一定的技术基础,在2011能在一周时间内通过培训顺利通过上海商派的ecos的php认证。说到技术方面的心得,我主要提几点:良好的代码习惯、钻研的精神、聪明的头脑。
良好的代码习惯:虽然我们大家都知道这个道理,但能长期坚持下来的并不多,在多年的项目开发过程中,遇到了各型各色的程序员,有技术一流的,有速度一流的,当然也有bug不断的,但真正能做到养成良好代码习惯并不多,我一开始也是认为并功能完成能用就行了,有必要花大力气弄这些东西吗?不过在吃了几次亏之后,我才真正知道这点的重要性。举几个例子吧:有位动手能力不错的同事做了一个项目,后面需要3、4个测试人员给他测试,旧的bug没有改完,新的bug就又出现了,弄的整个项目组怨声载道,叫苦连天;其实这位同事在设计、美工方面很有想法,钻研技术的能力也很高,就是不好的代码习惯拉低了他的水平,最关键的是他已经形成了坏的习惯,想修改就比较难了;我也曾经在早期的一个项目中由于良好的代码习惯,造成项目一出问题,就东怀疑西怀疑,无法定位问题根源,只能变通解决,造成问题一出再出,差点搅黄了项目不说,还让自己对项目开发产生了恐惧感(一提到这个项目的问题就不知所措)。我不断在研究什么是良好的代码习惯:每写一句代码,脑子要思维定式的问问自己是否是最佳的代码【如果不是,就需要查资料问别人,达到自己认可,日积月累慢慢就会自我感觉良好】;每写一个函数,就要想想这个函数是否符合面向对象开发规范【自从采用面向对象的分析、设计、开发后,很多疑难杂症都有治疗方案了,治不治得好就看你的水平了】;每写一个逻辑,要在头脑中验算几遍是否可行【复杂的逻辑要多动手,勾画出逻辑的关键】;每一次函数、逻辑调用,要考虑是否存在失败的情况,如何应对【这是很多程序员的通病,只管成功不管失败,结果失败来临时,束手无策】;每一个页面要从左上角到右下角,把涉及的逻辑考虑完善,主要逻辑一定要自己亲自测试一遍,条件允许的话所有的逻辑尽量都要自己能控制到【很多情况下,功能做完了,由于一点的小bug造成用户对软件质量产生质疑,节省一点时间结果得不偿失】。啰里啰嗦说了这么多,其实核心只有一个,细节决定成败,只有注重了细节,才能经得起风吹雨打,如果平时不注重细节,一段发现问题,不能及时定位,因小失大,后悔莫及。
钻研的精神:你选择了开发,注定你就不能轻松的生活,技术不断更新换代,客户需求千变万化,你要生存就需要不断学习新的技术【在你所的技术没有落后的情况下,你可以选择跳槽或不做这个客户项目,但在技术已经落后新技术已经在风口,你不转型你就会被淘汰】。不过选择了这个职业,也不用过于担心技术的更替,因为万变不离其宗,只要你在某个技术领域站稳脚跟,再学习新技术的时候,应该能很快入手,如果想熟练运用新技术就需要时间的积累了。不过为了你能站稳脚跟,你就要钻研的精神,遇到问题不是得过且过,而是要寻根追源,不是要死记硬背,而是要融会贯通。不要去试图记忆哪些枯燥无悔的语法、函数,而是要有钻研的精神,采用封装的方法,告诉自己下次遇到这些问题时我是不是能很快找到解决之道,如果不是就需要钻研如何找到解决之道,是通过函数封装还是将这些容易忘记的语法、函数放在哪个自己容易找到的地方【我一般是两个渠道:网上在线分类登记、本机分类保存文档】。
聪明的头脑:头脑不灵活的人是做不了开发的,我总是对单位刚入职的人说:你如果遇到一个问题不能从1想到2,再从2想到3,你就要考虑自己是否适合这个行业。因为这个行业技术玩头脑的,一项技术你从入门到融会贯通,一项业务你从一窍不通到成为行业专家,没有相对聪明的头脑是不可能完成这些。也不是说你在这个行业生存不下去,而是你要升到一定高度太过困难了,可能找一个更适合你的职业对你的一生更好。这里说的聪明,不是会写几个算法,会脑子急转弯,而是根据用户一个想法可以快速形成一个相对可行的设计方案,根据用户一个修改意见可以快速把影响的地方考虑清楚并形成初步想法的大智慧、大聪明。并且再把用户凌乱不堪的思路、想法形成行之有效的设计方案、系统原型的过程中,也是需要头脑风暴,项目组献计献策的,没有一个聪明的头脑,客户凭什么为你做出的东西买单。
立足之本:我们在不考虑你是否适合这个行业的大前提下【建议你觉得自己不适合这个行业,就及早抽身免得埋没了自己其他方面的才华】,如何你想在这个行业多少有点作为,我想提出我的两点看法:精湛的技术、独当一面的能力。这么多年在我遇到的同事中,真正能快速在单位立足的无外乎这两种,要么你有精湛的技术,让领导欣赏你的技术觉得你可以有培养的前途;要么你能在某一方面【纵向:需求、分析、设计、开发、测试、实施;横向:A领域、B业务、C项目、D系统】能快速的独挡一面,往往这个方面比技术层面更容易上手,也更能快速提升你的能力,一旦你能做到独当一面我想你在技术层面应该也不至于过差。
模型的封装:就是将A项目、B项目。。。中感觉以后在新项目中有可能用到的模型进行统一的封装,在以后做新项目的时候,可以迅速把封装的模型用于新项目的开发,大大缩短项目开发的周期。我在自己的两个技术转型期【pb、java】都是由于平时注意进行模型的封装,我在利用这两种技术进行开发的新项目的时候,就可以把主要精力放在新项目的独特性方面,其他的就是一些体力活,这样新项目不但能很快完成,我们也有足够的精力把新项目中独特的地方整理出来进行统一的封装。这里面我举一个自身的例子:曾经有一个项目是省、市、区县三级使用的多级C/S系统,大概有200多个单位在用,接到这个项目后,由于以前采用pb已经开发过六个系统了,已经在多级部署、上传下载、系统登录、树形控件、综合查询、权限分配等方面积累了一些通用的模型,这样一个庞大的系统,就花费了项目组2个人3周【不含礼拜天,前面已提到过一般不加班】的时间就完成了全部开发,这里面平时模型的封装起到了很大的作用。由于在pb、java中进行了大量的模型封装,这样在学习其他语言如flex、c++、php进行项目开发的时候,除了找一些入门的文章进行学习外,就可以根据其他语言的模型封装进行模型封装练习,既可以提高学习的效率又可以了解不同语言之间的共性与差异。
项目的目标:用户往往做一个项目,就是一个念头或者说几张零碎的卡片,如何将这些念头、卡片转化为一个实际运行的项目,这里面详细的工作我就不多说了,真正成功的项目不多【项目完成不算真正成功,只有客户、自己满意才算】,往往是客户不停的变换需求、项目的功能一加再加,项目严重偏离目标。我现在开发项目,对项目组的成员的最重要的要求就是首先确定项目的目标,列出1、2、3来,和用户确认,并在设计过程中,时刻依照项目目标设计功能,如果一个功能偏离目标就毫不犹豫的舍弃,一个功能虽然工作量稍大但对目标是很好的补充的话就好不犹豫的坚持,如果对目标有一点补充但功能过于庞大就需要大家讨论后再决定。一个项目没有严格的目标的话,小的时候1、2天就可以开发完,大的时候1、2年也无法结束,所以一定要明确项目的目标,这是项目成功的最必要的条件。
领导的意见:我们在开发项目的时候,经常会请一些领导进行业务指导,其实初衷是好的,防止项目偏离方向。但是这与领导的能力、性格有很大关系,领导能力高会对项目进行很好的补充,性格好提出的东西进行讨论后再确定进度,但在遇到能力有限、性格又比较特别的领导时,项目就有崩溃的危险。有什么好办法做到两全其美,保证项目不产生崩溃?首先,请领导指导尤其是前期这个大方向是没错的,省得项目开发出来了,这不行哪不行再返工可不是个小事情了;第二,领导的意见一定要弄清楚领导的真实想法,不要以偏概全,能达成共识更好,不能也要征求其他相关领导、专家的意见,形成一个相对妥协的方案,再通过一些其他手段【如:拖字诀-领导容易实现的意见尽快实现,不容易实现的先拖一拖】解决;
拳头产品:在开发项目过程中,要有一些拳头的产品,往往这些产品不一定是技术多么先进,开发周期多么长,而是这些产品对单位的整个产品线会产生深远影响,我们要多参与拳头产品的开发过程,因为只有参与到拳头产品中,你在单位的地位才能水涨船高,如果你在单位没有参与几个拳头产品,你的辛苦付出产生的经济效益将会缩水不少,同时在暴风雨来临时,你也没有可以遮风挡雨的地方。可是如何参与到拳头产品中,这就需要你在干好本职工作之余,多花一些心思【如:以参考学习的名义熟悉拳头产品--大多公司是不反对员工学习的】接触拳头产品,时机成熟提一些建设性意见或接一些力所能及的任务,潜移默化的你就参与到拳头产品中了。
先进的技术:搞技术的多少都对技术有些沉迷,谁也不想每天只是代码的搬运工,这就需要我们经常研究一些前沿或者说超前的技术,保持大家的饥渴感,当然有客户愿意为这些买单那就更好了。只有不断的接触、研究先进的技术,你才能不断保持对技术的新鲜感,不至于在技术日新月异的当前社会迷失自己。