注重逻辑:成为一名职业程序员
好,再前进一点点,你就要成为一名职业程序员了,让我们继续来完成这个任务吧!我们在前一节提到过,“你发现一些个别的demo是极品,它所展现的程序逻辑结构是你设计不出来的,你现在有点更关心它的程序设计构架,甚于对你原始目的(某种相关的技术/技巧)的关注”,其实你是在关注这个demo程序作者的思维逻辑,所有程序的本质就是逻辑。技术你已经较好地掌握了,但只有完成逻辑能力的提高,你才能成为一名职业程序员。打一个比方吧,你会十八般武艺,刀枪棍棒都很精通,但就是力气不够, ?所以永远都上不了战场,这个力气对程序员而言就是逻辑能力(其本质是一个人的数学修养,注意,不是数学知识)。逻辑能力也是逐步提高的,开始时你一定是用直观的逻辑能力来编程的,怎么想就怎么编,不对就再改,在改进中提高自己的逻辑能力,从直观逻辑能力提高到抽象逻辑能力,这是很正常的。提前说一句吧,到达逻辑能力的至高境界,其表现是用数学语言来描述问题和问题的解决办法,高度抽象!好,说回来吧,你要提高逻辑能力,最快的办法就是读别人写的结构优秀的程序。优秀的代码是百读不厌的(这句话是我抄来的),暂时放放对其中某种技术和技巧的关注吧,你要推导和学习的是这些好程序的逻辑结构,它们是被精心设计出来的。你可以先捂住这个demo程序,自己设计一个功能相同的程序结构,然后比较一下demo的程序结构,如果差距较大,那你就不应简单地改进一下,而是要把demo作者设计的过程在心里复原一遍,做到这一点也许有点困难,但这种事干的多了,你就会越干越快,越来越得心应手,你的逻辑能力飞速提升,你能看得上的逻辑结构优秀的程序开始不多了,下一步就是练习。从工作中开始吧,如果你有空闲,你需要做至少两类练习,一类是算法练习,所有的经典算法都是经典的逻辑,题目有的是,像个好学生一样吧,每年的国内国际编程竞赛都有逻辑要求非常高的题,你可以只选一两道难题来做做。当你可以把复杂的单递归程序(只有A调A)变成非递归程序时,已经不错了,如果你能看得懂双递归程序(A调A、A调B、B调A、B调B都有),我为你鼓掌!你不必往下看了,我有点不好意思啦――班门弄斧,你快滚蛋吧!另一类是把以前和当前你工作中你不满意的程序推倒重新设计一遍,这非常重要,省时省力,因为你熟悉需求,技术上也没问题,目的就是改进程序的逻辑结构,很划算哦,唯一要克服的就是:你对推翻以前工作中那点小小成就的心理障碍,如果你真想优秀,说句粗话:这点心理障碍算个屁,一遍遍反复地推倒已有的成果只能使自己快速进步,放手干吧,没什么好可惜的,马恩早就在《共.产.党宣言》里说过了: ?在这个过程中,你失去的只有锁链(禁锢你思想的锁链)。
让我们来总结一下,经过自我否定后,再生的你尽管对过去的“业绩”还有一些眷恋,但已是一个初步具备职业水准的程序员了,掌握了相应的技术和技巧,具备了较高的抽象逻辑思维能力,最主要的特征是:能自觉地自我否定,不断地追求更高水平的逻辑能力。
在这个过程中,如果你能注意以下一些小的方面,你前进的步伐也许会快一些。
从编译原理的角度来理解你工作中使用的高级语言,如果你做到这一点,至少有两个好处,第一个好处是避免一大堆低水平重复出现的编译错误。一名优秀的Coder平均在一个工作日中应该完成200行以上的源码,其编译错误应该控制在5个以下,要知道这200行源码不是一次完成的,所以大多数情况下你都要追求一次编译通过,而一名职业水准的程序员,应该进一步做到即使用purify这类的工具来检查源码,也不会存在严重的内存泄露。第二个好处是可以提高源码的可读性和效率。规范地编写你的代码使你自己的逻辑清晰,因为你明白多加几个括号和空行、多换行对齐、多注释,编译器是会自动识别的,不影响程序执行的效率,反过来,控制好递归调用和循环内的if语句才是提高程序效率的关键,要全力避免递归,但要深刻理解递归,能通过自己建立堆栈来把递归程序转换成非递归程序,要求还是较高的哦!
避免思维陷阱,只要你是人就一定有自己的思维惯性,这一定又会表现在你的程序逻辑中,有时你就是从这个惯性中跳不出来(谁都有这个时候),但要心里有数才行,所以你需要帮助,如果你有几个水平相若或更高的职业伙伴,太好了,当遇到花30分钟还打不下的bug时,就别浪费时间了,找他们吧,最要紧的是能思路清晰明确地表述你的问题,通常你自己在这个过程中或者伙伴中就有人把问题解决了,又快又好。另外,有几个可以良性竞争的职业伙伴是人生的一件幸事,1+1>2,大家各有所长,你最好做到及时公开你的成果,技不压身嘛,IT发展的这么快,你再优秀,那点东东也没有什么值得隐藏的,所以你可以技术或水平不够高,但千万不可以让真正具有职业水准的选手鄙视你的职业品质和行为。
有自己debug的特点,下面的说法作者不敢太肯定, ?只是经验之谈。即使在VC这种高度完善的开放环境下,你仍然应该要求自己仅凭打印语句就能debug。这也有两点好处,第一个好处是,遇到bug你会认真想问题所在,而不是用debug工具一步步简单地追踪卡在哪儿了,你定位bug范围的方式是从大到小、从粗到精,这是一种自顶向下的思维方式,而用工具追踪,容易形成自底向上的思维方式,这不算好,你应该先看到森林,再看到树木。我反复提及:程序就是逻辑过程,大多数程序从main函数开始,是由数据结构和功能子程序组成的一个树形结构的逻辑过程(要认清即使是面向对象的程序语言也是一样的),它的执行过程是深度优先的,但你定位bug应该是广度优先的,好好想想这一点,嗯?第二个好处是强迫你思考并记住而不是用工具看到调用过程,你大脑的抽象逻辑思维能力和胳膊上肌肉的力量一样,都是练出来的,如果你的bug是程序结构上的逻辑错误引起的,这一点就非常重要了,顺便说一句,最难打的bug就是程序逻辑结构错误导致的bug。你要是真正明明白白地认识到这儿了,那我就没什么东西可以告诉你了。总之,程序员的职业水准:生产效率和程序质量,主要是取决于源码中bug的数量和debug的速度,而不是取决于编写源码的速度。给你一个我自己定义的考查一个职业程序员的指标:一个合格水准的职业程序员,编程的时间如果算一份的话, ?其累计debug的时间不能超过一份,真正职业高手累计debug的时间应该控制在0.5份以下,如何?你关上门悄悄问问自己,你花费在编程和debug上的时间比例是多少?如果你把程序员作为自己一生的职业,那么就永远都要牢记一点:追求做一个0 bug的优秀程序员!这是任何一个想成为职业程序员的人的理想,请相信:坚忍不拔地追求实现这个理想将让你出类拔萃!
做好程序的单元测试,这是另一项考查你是否是一名具有合格职业水准的程序员的一个必要指标。其实在你拿到需求的时候就要准备单元测试用例了,并且这些用例将直接影响你的详细设计(有关软件设计本来是该放在第四节讲的)。我们还是打比方吧,当你拿到一个需求时,除了分析它静态的功能外,还应明确它动态的操作/执行过程,把这个动态过程明确地用流程图画出来,比如分为A~Z的26步,其中A又可以进一步分解为A1~A5的5步,直到不能再分解为止。又比如说A3步不可分解了,那么你应该把A3步的正常操作和所有五花八门的异常操作都列出来,确保正常的操作肯定正确,异常的操作起码程序不退出才行。这样你就要写好多好多的测试用例,说句老实话,我也从来不写!但我一般会列一个提纲,比如A3步有正常的操作a、b、c、d、e共5项,异常的操作有f、g、h、i、j、k、l、m、n共9项,你在进行单元测试时都应该跑一遍,这样的程序都还不敢说质量如何好,但起码可以说较稳定吧!如果要想在进行单元测试时干得快、效率高,那么在进行详细设计时,你就应该把A3步中对所有正常操作和异常操作的判断都设计好,在编程实现A3步时,使得程序的结构合理高效,对不对?所以,如果你在工作中是割裂地看待软件工程中从需求、分析、设计、编程、测试等各个环节,恐怕水平很有限喔!但如果你在分析需求时就能看到测试的问题,并改进设计和实现,为此做好相应的准备工作,嘿嘿,整个软件开发过程你的效率会高很多,通常你在一个开发团队中就会高度自信的,你已越过当一名偏颇、露骨的高手的境界,成为一个平静的高手,这可是The best in the best!,用周星星的话说:是高手之高高手,因为别人看不出你高在哪儿,没见你有什么高招或特拚命干,但反正你就是干得又快又好、又省力。关于进行单元测试还有很多复杂的方法,在此本文只提到了最基本的一点,目的是让你在工作上考虑周全、安排有序,其它的自己琢磨吧,没有人能替你吃饱饭!
如果你是用C++编程,我再简单谈谈有关内层释放的一个小技巧,就是对所有你编写的类,在构造和析构函数中加打印语句,统计每个类在运行程序时构造和析构的地方,如果是配对的,那么起码没有对象类一级的内层在程序运行结束时没有释放,然后你就可以把打印语句删掉了,招数虽土,但管用!
还有其它一些好习惯,在这里我随笔写一些,你要是有不同看法也请一笑过之吧。编程时应该对齐缩进,一个缩进用一个tab键,一般是4个空格,严格遵守开发团队的编程规范也是非常重要的。 ?一个子程序不应超过30行(不算空行),其内多重循环不应超过3层,否则都应该分裂成两个子程序,个别算法程序可以长一些,但也不宜超过200行。通常一个类的所有成员函数总和不宜超过1500行,多了就应该考虑分解成两个类(这个工作最好在设计时就完成)。每完成一小段程序,比如15~30行,就立即编译运行,不要假装高手,先敲它一大堆程序,再编译运行,妄想一次成功,体验一种假爽的、虚荣的快感,或炫耀给别人看,这么做只能证明自己是一个不折不扣的傻瓜,装酷而已。因为只要有一次不成功,你就会花费大量的时间来调程序,别人的进度在这时就远远地超过你了,平常心是道,还是修炼真功夫吧!孙子兵法里关于这一点有明确的阐述,我就不引用了,但建议你真的不要这么干,除非你确实就是这样总是一次就成功的天才,那你还看这篇文章干什么呢?我又不是写给你们这些天才们看的。再就是有学会买好书、读好书,关于计算机和软件方面的书太多了,时间有限,比如有一个叫侯捷的家伙,几乎写的每本书都不错,张国峰的C++编程也不错,这只是我的个人意见啊,好书多着呢,列出来比这篇文章长好多倍,我就不多说了。还有一招,要是你运气好,能搞到一些著名软件系统的源码,好好读读吧,在此我只能告诉你,Linux操作系统的一些源码不错,是开放的,你可以合法地搞到,其它的不要说是我建议你侵犯知识版权啊!
天生神力:成为系统分析员
本来就论述如何成为一名职业程序员而言,本文已基本完成任务了,但《菜根谭》有言: ?竭世机枢,似一滴投于巨壑,穷诸玄辩,若一毫置于太虚。既已乘兴到此,何妨多置一毫于太虚呢,作者不才,干脆尽兴写算了。
你要是运气好,直接进入了一个严格规范生产的软件企业就业,刚开始就应该是按别人做好的软件设计来实现编程,你可以有机会直接学习软件设计,当你积累的足够多了,能够对其中的一些设计提出好的改进建议,而且干得又快又好,就会渐渐地展露头角,我相信你终有一天成为一名软件设计人员(注意,不是软件产品设计人员),步入系统分析员的行列,但这还需其它的一些条件和自我修炼。如果你在一个不规范的软件企业工作,那也不错,你很可能直接就有机会进行软件设计,然后开发、测试,甚至还不得不自己定义需求,把软件开发过程的各个环节走一个遍,当然这样对你的要求更高,而且你也不容易得到及时有益的指点,在正态分布的情况下,你应该是成长的很慢。但不管就业的单位如何,如果你决心要成为顶尖软件职业选手,通常什么客观困难都阻挡不了你,然而你个人的因素可能会阻止你的前进。下面提出的观点纯属一己之见,伤人自尊之处作者在此提前道歉,并建议你除非对本文有强烈的兴趣,否则就请直接看第五节或放下别看了。丑话已说在前头了,在各种软件开发组织的发展过程中的事实也证明,只有少数程序员能成为系统分析员,我想这一点不是我杜撰的吧,因此你要是在看接下来的部分时感到气愤难当,那也实在没着,纯属活该,因为作者只是在说明自己的观点而已,你最多可以呲之以鼻,表示一下你的轻蔑好了, ?但没有任何理由可以骂人!
作者自己没有到微软面试过,但身处软件行业,关于微软的许多东东当然还是有耳闻的,据说微软招聘一名程序员要过五个已经成为微软程序员的面试关,而且是一票否决制,又据说大多数面试题并非编程,而是一些有关逻辑和智力的题,作者私下也做过许多流传的微软面试题,并对此做法深以为然。程序的本质就是逻辑,所以几十年前就有人提出编程是一门艺术,而艺术是要靠天份的,这一点少有人反对。一个人的逻辑能力可以不断提高,但其能到达的终极逻辑能力的层次必定为其天生智力所限制,这一点就让人不易接受了。好笑啊!人们可以公开承认自己没有某种或全部的艺术天份,但要说自己逻辑天份不够,换句话说承认自己笨、IQ不够高,往往是要怒发冲冠的,其实这又有什么区别呢?话都说到这儿了,再次建议你如果不够自信,就跳过这一节吧,直接看第五节,好吗?
好了,把话题说回来,你已经成为一门合格的职业程序员了,如果要想成为从事软件系统设计的职业系统分析员,第一件事就是悄悄找一个标准智商测试的网站或其它渠道,严格认真的测一测自己的智商,如果IQ低于130 (正常智商是110),就请别费劲了,打消掉成为系统分析员的念头吧!好!好! ?先请你冷静一下,好好想想,其实微软面试时就是在测你的智商和逻辑数学素质呢,这就是本节的标题为“天生神力”的原因,因为设计就是从无到有地进行创造,无论是软件还是其它行业都一样,可以有借鉴的,没有现成的,设计就是创造!如果你IQ在130以上,又决心要当一名职业软件系统分析员,其实你不过是要准备好吃更大的苦而已,有什么好虚荣的呢?
修炼还是从基本功开始的,过程和成为一名职业程序员差不多。必须使用设计工具这一点是不用多说的。在工作中,你基本上遇到的是两类方式的设计,一个是结构化设计,另一个是面向对象设计,就个人经验而言,面向对象的设计更好。如果你工作中不得不采用结构化的设计,你必须熟练地掌握数据流图和控制流图的分析和设计,一般来讲,如果你把一个软件中用到的数据模型设计好了,针对功能化的流程,不难设计出数据流图,但下一步设计控制流图才是挑战,如果你按照需求走不通设计好的控制流图,那么你或别人在按照这个设计编程实现时,必定也走不通, ?没有奇迹会发生,还是在设计阶段严格要求吧,又有一点需要牢记:返工是最慢的。当你在进行控制流图的设计时,也不要妄想得到需求人员提供给你明确的指点,通常他们要是能够把需求的功能和操作次序写完整的话,你应该就感恩戴德了,从需求中整理出功能、操作的拓扑次序和条件是你作为系统分析员的职责。看看,要是没有一点图论的基础和拓扑学的入门知识,你是当不好一个职业系统分析员的,即使你天赋不错,必要的数学和逻辑素质仍然不可或缺。也不用气馁,永远没有最好的设计,只有更好的设计,反复地进行设计迭代,勇于推翻旧的设计,你将快速进步。如果你在工作中是采用面向对象进行设计的,那就更有利了,有关面向对象设计的书太多了,不用作者在此多费口舌,建议精读一本经典的书,比如北大邵维忠等编译的《面向对象的分析》,有些方法和技巧可能过时,但其逻辑的基本原理是非常正确的,其本质是,你在逻辑上是如何认识这个世界的,你就是如何设计软件体系结构的,然后读读其它书,触类旁通,自己创造机会多实践,成功自然会到来的,总之,不管是结构化设计还是面向对象设计,评价一下自己的软件系统设计方案吧,有好多指标呢,比如是否均匀和平衡?局部独立性强不强?有没有歧异的结构?有没有层次太多或太少?有没有某个层次太大、太广?是不是逻辑结构先复杂了再化简的?还是只会设计简单的,复杂不起来(这一点是笨哦,如果出现多次,请你不要意气用事,转行吧)?最重要的一点,是否容易理解、实现和改进?你自己会得出评价的。如果有机会看到别人的设计,一定不要错过学习的机会,自己推导一遍,认真比较比较,获益会较多。
走到这一步,你就应该关注设计模式了,首先还是学习,这方面的好书有的是, ?但一般在工作中用到的设计模式较为单一,应该多尝试一下其它的设计模式。其次必须要明白设计模式不是设计思路,也不能代替设计思路,比方你要从A到B修一条路,设计模式只是让你选择,是修水泥的还是柏油的?是高架路还是普通的,但线路必须你自己定,而线路就是设计思路,模式对思路是有影响,但不能代替,所以如果你的智商高达250,我相信你直接用汇编语言也能写出面向对象的程序来。第三在此有一个陷阱,很多系统分析员生搬硬套设计模式,全然不懂如何融会贯通,在你的一项具体工作中,往往是以一种设计模式为主,其它模式为辅的,思维不拘泥于形式才是关键,而且也为你到达更高的软件设计的境界做好准备。
唉!都不知该怎么向下写好了,因为已达到作者水平的极限了,我胡乱说一点,你凑合看吧。软件设计最终的层次是:以无法为有法、以无限为有限,这句话是李小龙说的,不是我说的。再拾人牙慧一把,类比一个故事吧,金大侠在《倚天屠龙记》里讲到张无忌初学太极,学会的标志是把刚学的招数全忘了,记住的是太极的道理和精神,和李小龙有些相似喔,软件设计也一样,忘记所有的设计模式,随心所欲进行设计才是至高境界,所以你能到达多高的软件设计的境界最终将取决于你的哲学素质,这一点实在是不好写啊,你自己领悟吧!作者只有祝福了!
职业人的终极目标:全面修炼,成为Leader
这一节更不好写,涉及到太多其它非技术方面的因素,特别是个人人生观和世界观的修炼,如果本帖的点击率超过作者私下期望的一个数值,那我就争取尽力厚着脸皮再补上吧。我只说一句,虽然大家都知道软件开发是一个团队性的工作,但追求参与一个大型软件系统的成功开发,是一名软件人员的本能,就像拿破仑说的不想当元帅的士兵不是好士兵,所以不追求实现大系统的软件人员,也不是一个好的职业软件人员,但你只有成为Leader,领导一个优秀的软件开发团队,才有机会实现这个终极职业目标,对不对?
好吧,不管你现在的感受如何,我都谢谢你能读到这里!我不习惯假歉虚,就不说什么作者水平有限,本文抛砖引玉,欢迎大家批评斧正之类的客套话了,虽然作者水平确实有限。所以我认为你尽管有权砸砖,但实在没必要搞回帖、或回骂、或顶之类的玩意儿,我只是尽兴写一点多年从事软件开发工作的体验,因此接下来我就高挂免战牌,不回复任何回帖了。再次谢谢你能有耐心读到这里!希望本文对你有所裨益,祝你成功!再见!