第三部分，未来职业生涯规划、家庭环境分析、例如经济状况，家人期望等。感谢您阅读《大项目、小项目都是程序员成熟之道[2]》内容，职场资讯网小编向您推荐一些职业规划知识，欢迎参考，希望能帮到你。
而我今天说的项目大小是从软件项目本身来确定的，与客户对项目大小的定义没有什么太大的关系。我认为项目大小可以从以下几个维度去考虑：资金、开发人月、项目复杂度。
1、 资金
我认为在当今物价状态下，5万以上50万以下为小项目。50万以上为大项目，500万以上为特大项目。
2、 开发人月
同理，2.5个人月到25个人月以下为小项目。25个人月以上为大项目。
3、 项目复杂度
软件项目的复杂度还可以用软件的用户使用人数、数据库中表的数量、表的记录数来衡量：
软件使用人数：10-1000人为小项目，1000人以上为大项目。
数据库表的数量：20-100张为小项目，100张以上为大项目。
表中的记录数：10万-1000万为小项目，1000万以上为大项目。
此外，项目运行能够给客户带来的收益大小、项目的业务逻辑的复杂度都可以成为项目大小考量的内容。
如果项目都不能达到小项目的水平，我们这里就不把它看作项目了，因为低于小项目的项目很多是个人编程，这与项目众人参与的特点有点不符。
所以我对程序员的建议是：
1、 要主动参加项目
无论大项目还是小项目程序员都要努力参加进去，因为只有做了项目自己的能力才能提高。不要静静待在那里，等待别人挑选，而是积极主动表示加入项目的愿望。在我负责过的项目过程中，我对主动要求加入项目的程序员往往给与更多的机会，因为这样的程序员具有主动性，工作更好开展。一个项目的出现就是一个机会的出现，把握项目就是把握机会。机不可失，时不在来。
2、 不要放过小项目
程序员不要以小而不为，只有做过若干个小的项目后，程序员才能去做大项目。那些想一步就做大项目的程序员，往往会失去小项目锻炼的机会，往往参加到大项目后，感到力不从心。项目虽小也同样可以锻炼人，程序员可以有更多机会体验项目负责人的脚色。学会从整体角度上来看待编程。
3、 要积极准备参加大项目
对于已参加过小项目的程序员，一定要把握机会，积极准备参加大项目，项目越大，越锻炼人。在大项目中要学会摆正自己的位置、虚心向团队其他成员学习。要在平时没有项目的时候，要多做些技术准备，多关注可能的大项目开发内容。在项目开发中，则可以把重点放在体会不同功能模块之间的关系上。学会从关联的角度上看待编程。
根据我的经验，我认为程序员要经过5-6个小项目的锻炼才能入门，而经历了3个以上的大项目的程序员才开始成熟。当然我们不能排除程序员的天才成分，有的程序员会再很短的时间达到一个很高的水平。但是，绝大多数程序员成长是必须通过项目来催化的，尤其是大的项目催化更加重要。说白了，项目如同阳光，程序员如同禾苗，关系就是那么简单。
延伸阅读
今天，根据自己的体会，我来谈谈项目经理的初始化阶段。
新人工作一段时间后，或长或短，可能一至两年后，有可能出任项目经理。此时，考验你能力的时候真正来临。项目分很多类，如基础研究项目，大型综合性项目。这里我们选取小的商业应用型项目为例。
刚开始，我们是没什么经验的，好在有热情。但这是项目，是一个讲究人与人之间配合的技巧性的活，光靠热情是难以持久的。退一步说，你是能力很强的聪慧之人，什么都拿得起放得下，那你充其量只是个精兵，而不是一个好的管理者。管理者的目标让整个组织的效率更高，管理者是没有那么多时间老是冲锋在前的，请深刻体会这一点。 因此我们得掌握一些基本的技术，讲究一些策略，力求避免未做勇士，先做烈士。
需要先补的课程是，项目的三要素：时间、成本、范围。
第一：时间
如果三峡项目做得很漂亮，质量很高，专家也很满意，惟一不足的是项目比预期推迟了两年半，那么这个项目的考评可能从A+会直降到C-甚至D-。因为这样一个大项目群，耽误一天便产生数以亿计的成本损耗。我们的项目虽然小，但道理是相通的。所以在执行项目之前。项目的时间至关重要。
客户有个时间表，老板有个预期的时间表，每个项目成员都有个时间表，作为项目经理，必须把这些协调起来，达成一个各方满意的结果、按照利益相关方的优先级别排序。这里有个分析的小技巧：请注意，老板说是下月底完工，你得有两手准备。一方面：alpha版一定要在下月上旬先给老板看下，给他一个初步印象，避免到时心里落差过大，情绪失控，万一有错，也来得及修正。另一方面，不要做得太细太完善，既浪费时间，又不给领导提意见的空间，领导只会怪你不会做事。于是，你得留一些简单的易于完成的小破绽给领导。是不是很委琐？！我相信这 样做，对项目组有利。当然，看具体的人，看性格。
第二：成本
项目花下去多少成本，预算时要心中有数。多大的西瓜多大的秤。这个成本包括时间成本、人力成本、费用成本等。在项目中间要勤计算挣值 。这是一个很关键的指标。投入与产出必须有一定的正相关系数关系。人有多大胆，地有多大产的教训在我身上太深刻了，记住，什么事都不要拍脑门，项目中没有任何板上钉钉的事，特别在公开会议上，要控制自己的情绪和言行。 有时候，一时不必要的斗气，让项目成员苦不堪言。
第三：范围
有了时间、成本的到位分析。范围就是一件简单的事了，简单的说，范围就是项目需要完成的程度。时间长、成本允许，可以内外兼修，各环节都做得漂亮，各方满意，自己也挺有成就。这是理想中的理想，基本上在实际中属于空想的范畴。所以，如何控制好范围，而又保持好项目成员的积极性，是一门学问，水很深哪！项目经理的一个基本观念是：项目是独立核算的，项目的考评是本项目完成到什么程度，而不是为了别的项目组或者为了下一次项目做了多少。如果这个项目可能为了别的项目组做出一些牺牲或额外努力，请尽量避免！如果必须得做，也需要在项目组 会议上言明，为自己项目组争取既得的回报，不一定非得物质的，比如领导的心知肚明，客户的理解和感激等，这些会帮你加分。千万不要偷偷摸摸的干，把项目成员的暗中努力不当回事，我是雷锋我怕谁已经不能用来唬人了，这是个讲究科学、兼顾效益的商业社会。
有人会问，在这三者冲突的情况下，如何取舍。建议很明确：先砍功能，也就是范围，把一些能推到项目二期的先往后推，向范围要时间。所以，在项目开始之前，要给项目孵出20%左右的可压缩时间，这个只有项目经理自己清楚，不必言明。
最不可取的就是项目经理挥刀自宫，让整个项目组在低成本下高速运行，这样的项目最后成败我们先不说，在项目成员的眼中，你基本上与黄世仁无异，甚至不用等到项目结束，就已经牺牲了。所以在第一次项目中一定不要让项目成员感觉跟你就是为了体验雪山草地，他们配合你，一是出于利益，二才是看你这个人值不值得跟。都看着你呢。所以，遇到不顺事先忍着，抓重点，回头再总结。这就是前文所说的做人、做事的原则：为什么级别的事情，就得付出什么级别的代价！
其实，第一次，不要将成败看的太重，教训要自己书写。有人说，哪怕只打一次仗，一个兵才会淬火成为真正的军人。谁没有第一次呢？做人，要经得起失败，但得明明白白地失败。
有人说 程序员的人生有三重境界。第一重、见山是山，见水是水。刚入门的程序员基本只能看到表面的东西，由于各种原因，没法了解更深入。第二重、见山不是山，见 水不是水。成长并有经验后，看到的表面现象渐渐有头脑中成型，犹如行军详细地图已经了然于胸。第三重、见山亦是山，见水亦是水。大悟之后，举重若轻，外松内紧，处事看似笨拙，实则暗藏玄机，惜语如金，然字字珠矶。此时，胸中亦有各种框图，然表面内敛以藏拙，见人说人话，见鬼与鬼语，谓之通灵也。
要想修炼到气定神闲的第三重境界，那就用心和智慧体验吧！
职业规划是对职业生涯乃至人生计划的过程，职业生涯规划的好坏可能将影响整个生命历程。感谢您阅读《项目经理眼中的合格程序员》内容，职场资讯网小编向您推荐一些职业规划知识，欢迎参考，希望能帮到你。
一、合作与团队精神及计划性
服从分配的工作，并在保证质量的前提下尽快完成任务。如果接到的新任务没有给出工作量估计，首先估计出完成任务所需要的工作量，并有责任向领导说明其估计的合理性，如果接到的新任务已经给出工作量，除非能提出充分的理由，否则必须接受该工作量估计。提前完成任务时，应该及时通知上级。在同时承担几个模块任务时应能根据优先级的变化及时调整自己的工作时间分配。
二、需求理解能力
在开发过程中，要在需求细节不明的情况下，有责任设法搞清楚，积极学习编程思想和方法，并在设计、编码工作中自觉应用，对有一些复杂程度的设计，主动申请设计审查。并能在开发用户界面之前，尽可能使用界面原型方法获取用户的确认。
三、测试意识
在工作负担允许的情况下，采用测试驱动的编码方式，及时把完成编码的部分提交测试，并及时排错。不断通过自己的测试来驱动程序质量的提升。
四、规范化，标准化的代码编写习惯
良好的文档是正规研发流程中非常重要的环节，作为代码程序员，25％的工作时间写技术文档是很正常的。缺乏文档，一个软件系统就缺乏生命力，在未来的查错，升级以及模块的复用时就都会遇到极大的麻烦。
对正规的企业，会有完整的编码规定，代码的变量命名，代码内注释格式，甚至嵌套中行缩进的长度和函数间的空行数字都有明确规定，良好的编写习惯，不但有助于代码的移植和纠错，也有助于不同技术人员之间的协作。代码具有良好的可读性，是程序员基本的素质需求。
五、总结与全局观
以项目全局为重，采取尽可能简捷的解决方案，把完美方案的设想提交设计人员，有问题时首先向同事们征求解决办法，不鼓励花大量时间解决难题，并鼓励给同事提供技术支持。项目结束，做出个人小结，以利个人和集体的改进。
1.从程序员到PM,是一条脱变的路，事实上程序员走的路最终不应该是项目经理。首先有一点需要明白的就是，一定规模的项目中，项目经理不需要太懂技术，他可以是一知半解。项目经理的任务不是在技术方面，技术相关的应该交给SA去做。项目经理更多地是做管理，沟通等工作，你如果可以的话到书店查看一下关于项目管理的书籍，你就会明白。当然对于小项目来说，有可能是PM,SA是同一个人，而这样的项目经理更多只是SA加上一些管理工作。要做项目经理，你就首先告诉自己不再去碰技术细节了。程序员并不是一个培养项目经理的好环境。所以没有什么从Coder到什么developer再到SA然后是PM的路，这是一条比较悲哀的路。在大公司，SA下一个目标不是PM,而consultant,然后是seniorconsultant,PM走的是另一条路，所需要的技能不是技术，技术给PM带来的能力提升是很少的。在项目中你最后能分清楚PM与SA的关系及各自在项目中的分工与用途。
2.其实我蛮同意gzlucky（Lucky）的看法的，确实是我们公司不少项经理就是不很能跟得上现在的一些技术，因为很多人都快年近四十，儿子都上高中了，要他们再学新技术真的难度比较大，他们的工作基本上就是天天找手下的程序员，布置这个任务，询问那个任务做的怎么样了。不过我的头倒是和我一样编程，他手下写代码的就我一个人，他自己也会ASP和JSP,但是可能对。NET不熟，就由我来主负责了。我觉得项目经理还是像他这样的好，自己也能懂不少技术，可以服人。但是我的头儿好像在沟通这一块不是非常出色，当然也有可能是俺太内向，不太与他沟通，所以他也只是在交待任务后就不再多询问，而不像别的项目经理天天追程序员后头问。我想问问各位，你们看哪种项目经理才是比较好的，像我的头儿这样的，还是像某些喜欢追程序员后面问进展的。
3.原来在一个小公司做过半年的DM,一年的PM,后来为了让自己的技术更扎实一些，离开了原来公司，现在在大公司做程序员，开始后悔了，在大公司里很难接触管理方面的东西，也很难晋升，个人认为在小公司做DM,PM,有经验后直接找大公司的PM,这样也是一条路。
或者考PMP之类的证书，然后直接找管理的工作。
希望过来人能给予更好的意见和建议，我也现在想往管理层发展。
技术很硬了再去做PM,这种想法是错误的，我就犯了这个错，边搞好技术（为了生计）边学管理知识（为了将来）,慢慢向管理发展，不能等。有句话说的好，机会是属于那些有准备的人的。利用业余时间多学些管理方面的东西，所谓人的差异在业余时间。
要走向管理层，英语一定要学好。
沟通很重要，要做好管理者，先学会做人。多跟下属沟通，多为下属着想，而不要去巴解讨好上司。体谅下属，把项目计划做的尽量合理，不要让下属加班，给下属发展和晋升的空间，这样才能是下属有干劲，才能把项目做好，你才有更高的升迁机会。
只有把自己知道的不断的让你得力下属知道，只有提拔起一些得力的下属来，你才有时间和精力去向上爬，不然你抱着不放，就没有升迁的机会。
管理不是喝酒抽烟那么简单，那只是过去的那种不思上进，耽误自己前程。
吃尽苦中苦，方为人上人。
做PM不是混，是要把项目做好，这跟做人是一个道理，这也就是为什么做管理要先学会做人的道理。
pm的整个工作重点是什么？如果做为一个PM,技术不高怎么对付组里的牛人
我们经常会因为公司里的顶尖人才、个性化太强，不能与其他人合作而感到棘手，要解决这一问题其实也是有法可寻的。
一、在肯定其价值和优势的前提下，明确地制定改进的目标；
二、顶尖人才能够面对中肯的，明确及一对一的批评作正面反应，所以要加强与他沟通的力度；
三、可以根据具体情况调整考核目标，加强与其他员工合作的内容；
四、把顶尖人才调到相对能独立发挥其才能的岗位，减少与别人发生矛盾的机会。
工作渐渐展开之后，就是平静如水的生活，每天上班，吃饭，睡觉，日子也过得很快。刚开始，由于懂得东西少，所以每次任务下来后，都是积极的去完成，因为害怕自己做不完。但是渐渐的，当自己清楚该怎么做的时候，人会产生疲倦，因为每天都做一些差不多的劳动。慢慢的，做事情就喜欢拖拉了。当分配一个任务后，自己先估量一下这个工作自己大概需要多久，一般老板给的时间会多很多。所以喜欢把工作先放着，去看看网页，逛逛论坛什么的，等到剩下的时间差不多了，需要开始工作了，就懒洋洋的进入工作状态，但是往往完成工作质量都不怎么好，很多提交后会有些BUG。不过我也没怎么在意。因为和老板关系好嘛，像我这样，再怎么说也属于元老级别的。就这样慢慢的工作了几年。因为小公司什么都要做，技术也积累了很多。包括各种主流数据库的用法，。NET，CSS,JAVASCRIPT,PHP,JAVA,perl,FLASH, 等等，其间，自己独立开发项目的时候，总想找出一种架构，加快自己下一个项目的开发进度。但是每次开发完后，发现上次设计的架构真垃圾。开发过很多项目，每次都想了一些新的架构方法。到现在沉淀下来的还值得用的架构思想也没多少。记得在做JSP的时候，感觉JSP里面服务端代码和HTML混在一起，很难看。不如。NET的事件驱动好用。就去写个模块，让JSP也实现事件驱动的模式。结果写到后来，也没得到什么好处，并且感觉有点不伦不类，后来项目慢慢做大了，才渐渐明白面向对象的用意。当一个项目很小，逻辑很简单的时候，用面向对象的方法设计用处不大，反倒是组件用处更大。因为项目小，基本上都是建几张表，改改HTML的工作。但是项目一大，逻辑变复杂了，如果你要理清楚逻辑，这里就需要一种方法论。我一开始写算法的那种方法有点不适用了。原来那种是从顶层开始，向下细分。是一种至上而下的设计方法。而面向对象不是，它是一种由点及面的设计方法。面向对象是先找出一个个对象点，然后再找出每个点之间的关系。在实际的项目中，你很难从上至下的设计。因为项目需求往往刚开始很不全面，很多项目后来改得都是面目全非。从上至下的设计不适合这种平凡的修改。并且当需求很大时，他涉及东西太多，你也很难从一个俯视的角度去全面的看这个系统。所以从上至下的设计不能满足要求。打个比方，记得一个项目已经做了80%，结果客户觉得用得不方便，要改一下。很多原来做的功能都不需要，并且提了几个新功能。但这几个功能也只是对原来的功能稍加改动。但是逻辑上看却是大相径庭。人脑不是电脑，如果想着这个代码，去改那个代码，势必到后来让自己也搞糊涂了。所以需要抽象出几个对象出来，是按照客户的思维方式。然后抽象出来的对象里面包含原来的功能。这样做起来就事半功倍。
在工作的磨练中，慢慢的发现了普通的程序员与优秀的程序员的一些差别：
1, 普通的程序员遇到问题喜欢张口就问别人，问之前没经过大脑想想。这是一个不好的习惯。其一，自己都没仔细想想，就算别人帮你把问题解决了，你自己不多久就会忘记。下次遇到，照样是不会。因为这个问题你没有经过大脑。其二，能够回答你问题的人，多半是有一定经验了。他们或许很会安排好自己的事情，管理好自己的时间。如果时常去打断他们，他们会觉得你很烦。
优秀的程序员多半会先到网上查找一下相关问题，看看网上有没有相关解决方法。经过一翻查找，他会把这个问题记得比较牢。
2，在一个项目的合作开发中，普通程序员往往只了解自己开发那方面的东西。项目做完后往往对整个项目有哪些功能都不太清楚。可能会有人抱怨，自己工作都做不完，哪有时间去了解整个系统。但现实多半是，花大量的时间去网上闲逛，却不愿花时间去增进知识。 如果总认为项目的设计是设计者的工作，自己没必要去了解。那么这样的程序员只能是手工劳动者。
优秀的程序员会对整个项目有认识，对一些自己感兴趣的功能会去做一下了解，更优秀一点的，会去对整个项目的架构设计做一下了解。自问如果他是项目设计者该怎么做？ 去学习项目设计的优秀之处，去发现设计的不足之处。触类旁通，把优秀的地方用在自己将来的工作当中。
3，普通程序员往往有很大的惰性。不能自觉的去学习知识，增进能力。所以每天耗费大量的时间在一些消遣状态中。所以时间往往白白的浪费掉。
优秀的程序员往往会安排好自己的工作和学习。在工作中学习，在学习中工作。能够感觉到自己每天都向着自己的目标在前进，状态佳，动力足。他们因为每天工作情绪很高，所以研究的东西也多，时间比较宝贵。因此他们会善于利用一些工具来操作自己的电脑，大大来的减少琐碎的电脑操作时间。更有胜者，会开发一些符合自己的操作习惯的小程序，来提高自己的效率。说不定这些小程序放到网上共享，可能还会有意想不到的收获。
我现在做项目管理，看着手下的程序员，时常也让我想起原来做程序员时候的坏毛病。比如，上班迟到啊，工作时间上网闲逛啊，交上来的程序BUG成堆啊！看到这些，我时常都是会心的笑笑，可以理解！ 不过我也时常提醒他们，如果你们想将来成为IT界的精英，而不是等到30岁感觉自己无路可走，那么请你们珍惜自己的时间。如果你们自己都不珍惜自己的时间，那么别人更不会去珍惜你的时间。
今天花了两个多小时，写了一篇短篇自叙。感觉值得，把自己五年多的光阴回顾了一遍。从前的故事历历在目。写下来过五年后再来回顾一下，说不定会是另一番感受。
感觉有些是企业环境因素，不是项目经理能力范围，以项目经理的实践经历来评估。但感觉有点抽象，没有深入探讨，与实际中应用对比起来。
1级：具备项目管理的一些基本知识，有一定的计划、控制意识，但还没有全面掌握PMBOK知识。
这一类人，在实际中较多，基本上靠自己的经验和意识在管理项目，对于系统学习项目管理体系知识还有些抗拒，认为过于理论化，实则是还没有意识到项目管理的重要性。典型的一种例子，在项目计划中，只注重开发任务，对于项目干系人的沟通计划、项目实施得不太关注。这类角色，实际还不太具备项目经理的能力，顶多是开发小组组长，但实际还是不少人担任项目经理，如果项目技术性较强，这类人可以担当，如果项目业务类较强，项目实施涉及较多干系人，则通常项目会搞得很糟。
2级：全面掌握项目管理知识领域知识，并能结合实际运用，有一定的沟通协作能力。
与第1级相比，2级的PM意识到项目管理的重要性，主动学习相关的知识，并在实践中应用。意识到沟通、计划的重要性。
已经可以单独承担6-12人月的项目。可以管理10人左右的项目团队。
3级：可以管理项目群，相当我们说的部门经理或者高级项目经理了。一般会管理几个项目的项目群。
与2级相比，这一类具有更好的沟通能力，以及教练指导能力、授权能力，以及团队建设能力。一般可以管理的团队规模在20-50人。
4级：可以管理一个团队规模在100人以上、项目规模几百人月以上的大型项目，也就是我们说的项目总监。
与3级相比，4级因为管理团队规模较大，会在市场战略分析、管理标准化和规范化（如开发过程体系、绩效考核体体系、人员培训计划）多下功夫，与公司高层、外部客户的沟通协作能力也很强。已经开始上升到高层管理角色了。
5级：应该是大型公司的GM、CTO级别了，不过这个层次的主要工作好象不是项目管理了，是企业管理了，一般已是公司总裁级别，或者是事业部负责人。严格意义上，这类角色已经是不是在管理项目，他们是在管理企业，我之所以列在这里，是从职业通道上，很多做到4级的项目总监，有希望再上一层，走到这一级。所以我将题目由项目经理的能力成熟度探讨扩展为项目经理的能力成熟度与职业阶梯探讨。
本人普通院校，非计算机专业本科毕业。从毕业到现在也工作有五年了。回忆起程序人生，也颇有一翻滋味。
本人是从大三上学期开始学习计算机的，因为那时电脑突然一下比较普及，本人家里也有能力买台电脑。买了电脑后，最先看的是C语言的数据结构。用电脑调试书里面的各种程序，那时第一次看数据结构，我接近全力去看，但是没看懂多少东西。只是把书里面的代码敲了一遍，运行后看看是否和书里面说的结果是一样。但很多时候，第一次都是没通过调试的，发现不是这里抄错了，就是那里抄错了。通过不断的查找，最后才能运行正确，那时心里就会才生少许的成就感，感觉自己写的程序调通了（虽然只是照着抄了一遍）。看完数据结构（其实有很多东西还是不懂），我去找了本计算机组成原理来看。结果看得自己更加模糊。因为这本书里没有代码，只有一些抽象概念，当时好像只记得CPU有几个寄存器寻址，还有些补码，反码什么的。那个书又厚，硬着头皮翻了一遍后就没看了。接着买了本操作系统原理来看。也是很难看，都是些概念的东西，又没代码调试。比如什么GDT，虚拟内存分段，分页，实模式，保护模式，中断等等。也是硬着头皮翻一遍，能懂多少是多少。看完后，接着就看那个编译原理，因为网上都说懂编译原理的人都很牛，我也希望变成牛人所以也去搞了本回来看。结果发现，能懂编译原理的人，确实比较牛。里面涉及到自动机的概念。属于用计算机来做人工自能的范畴。我也很想成为牛人，硬着头皮看，结果还是有心无力。经过这样一个过程，虽说很多都不懂，但却使我对编程从一无所知到有了一种模糊的认识。大概懂得了什么叫做内存分配，还有程序的那些字母符号是怎么被计算机执行的。这时回头把原来的数据结构翻出来再读一遍，突然发现这本书比起其他三本都容易，也很好懂。明白了什么叫做算法，并且可以尝试去实现自己想的一些算法。当时的自豪感油然而生。感觉电脑可以按照我的想法去工作了，非常兴奋。虽然那时我并不懂得多少C语言，对指针也只大概知道是什么东西，实际中还是不会应用。但至少可以利用我所知道的，来实现我所想到的。在当时一股冲动之下，写了几个自己记忆由心的算法：
1，从1到100，每数到7的时候，把该数字提出来，剩下的数字继续循环，问最后剩下的一个数字是多少。我记得好像是50。
2，任意输入数字，和+ - * / （ ）几个符号组成一个算术表达式，计算出值是多少。
3，记得看过计算机组成原理里面有个磁盘调度算法，用的是现在电梯常用的电梯算法。感觉这个算法很好，就去用C语言实现了一遍。
刚开始写程序，都是一个main函数全部搞定。慢慢的，在算法实现的过程中发现，如果一个算法太大，一路写下去，代码会很长，并且很容易想了前面就忘后面该怎么写，或者写到后面，忘了前面写的是什么。 这时，就产生了一种想法，就是刚开始设计算法的时候，想好哪几步，然后每一步用一个函数代替。main函数中只是分步函数的流程控制。这样main函数的代码就大大的减少，逻辑变得非常清晰。然后可以像填空一样把每个分部函数完成。接着在子函数里面还可以分成子函数，分到后来，发现很多函数可以被其他的函数调用。达到重用的目的。记得当时发现这个方法后，也是异常的兴奋。这种方法居然被自己想到了，感觉自己真是个人才。因为自己是非计算机专业，想找编程的工作，起码要有一个东西证明自己是学过计算机的。所以在这期间报考了那个高级程序员（高程），因为要考试，所以学习了一些汇编之类乱七八糟的东西。考试好像分为笔试和上机，但是现在已经忘记是哪一个没过了。郁闷！没过之后，不甘心，就去报了个计算机等级考试（3级，互联网技术），结果不出意外，将证书收入囊中（不过现在想想，一点都没用上。拿回来后，从来都没给人看过，现在都不知道放到哪里去了）。
搞完这些，自己大三也差不多结束了。自己也知道到了大四要开始找工作，所以不能自己专门去研究什么算法。那个东西当不了饭吃。所以要搞一些比较流行的东西，起码需要混到一个工作。所以那时就搞了一本C#入门经典。因为那时听说。NET比较流行，好找工作。并且对于一个新的东西，我比较喜欢找一些名字上有入门两个字的书（这样的书里面一般都会很详细的告诉你如何搭建调试环境）。因为程序这个东西，你首先要能够搭建一个调试环境，光靠看是看不出什么东西来的。后来感觉这本书还不错，不枉费我100块大洋。从中学到了一些。NET的基本用法。并且对面向对象讲得比较详细。面向对象那一章我也很认真的反复看了好几遍，因为那时03年面向对象非常热门，网络上面到处是面向对象几个字，感觉编程高手都是会面向对象。我也想成为高手，所以我就抱着一种不搞懂不罢休的气势去看。结果，只是记住了面向对象的语法。书中和网上举得例子也很简单，多半是些动物是抽象类，然后，分什么鸡，鸭，鹅之类的去继承，然后动物都有吃饭的接口，鸭子有游泳的接口， 此类等等的例子。看了半天，也没弄明白这些对于我写程序有多大的作用。后来，从书上抄了一份网站购物车的程序，认识到了WEB的开发流程，感觉自己也可以上路了。因为当时才大四上学期，也没有到处发简历。只是在网上留意一些招聘信息。当时也是在CSDN里面，看到一个本地的公司在招人的帖子，公司很小，刚起步。我想应该不会要求很多，我也就去应聘试试，希望自己能够应聘上，这样至少能够证明自己有资格成为程序员。应聘的时候，老板问了一些问题，多半是WEB开发方面的技术问题。由于那时我对WEB只是刚刚接触，懂的不多。好像当时有一半以上都没回答上来。走的时候，我把我从书上抄的那份程序放到电脑里运行出来给他看了看。大言不惭的说者是我写的。他看了看，点了点头，然后就回去等消息。我是星期五去面试的，星期天公司打电话让我星期一去上班。听到这个消息后，心里莫名的激动。请同寝室的哥们大吃了一顿。大家也都为我能这么早找到工作感到高兴。后来，就是白天到公司实习，晚上回寝室睡觉。工作后慢慢的，那种兴奋感就消失了，取而代之的是工作压力，由于做WEB开发，服务端的C#还好说一点，但是前台用到很多的是HTML和JAVASCRIPT，当时对这个知道的很少，只能一边翻书，一边做事。要达到老板的要求，每天都八点左右才能搞完下班。
1、源代码控制（Source Control）
你有源代码控制系统吗？如果没有，那就是个大问题了。你得赶紧添置一个。没有源代码控制，你就跟玩俄式轮盘一样：你不能恢复已做出的更改，你没有源代码的备份，你没有历史记录，这样你也几乎不可能建立合适的持续集成的服务装置。
2、持续集成（Continuous Integration）
你有一个持续集成的服务器装置吗？设想一下：生成器是根据导入的代码进行编译，如果你每次导入的代码，都让生成器来编译，这就足以使整个过程变得复杂了，更不用说有很多人导入各种各样的代码。但是，持续集成装置将自动地编译你的软件项目，并且能给你编译的结果。你甚至能添加Unit Tests、Coding Standards Tests等等。但是为了让你更容易明白还是不要搞的太复杂。
3、软件缺陷跟踪系统（Bug Tracking System）
如果没有软件缺陷跟踪系统你就无法方便地衡量软件的质量。在任何时候你都应该能够看到哪些功能模块正在被构建、被测试、被通过以及哪些模块出现问题了等等。如果你还在依靠excel表或是笔记做这项工作，那么赶快投资一点钱添置一个（程序）错误跟踪系统吧！
4、补丁系统（Patching System）
这里我并不是要谈论installer的问题，我要说的是你需要一个补丁系统。你肯定不想经常重装你的testers.
5、删减未测试的功能模块（Disable Untested Features）
删减你的软件中所有未完整地经过软件缺陷测试以及未被使用者认可的功能模块。如果你的软件陷入困境，你很可能会觉得其中还有90%-95%的功能模块能够执行，而实际上却只有80%.
或许上面写的比较偏激，但真的是很普遍，我想告诉你们，你们虽然只是负责一个模块，但无论如何，请要知道你的项目到底是什么，如何运转，哪些地方好，哪些地方不好，因为这是对你自己的一个提升，也是对公司的一个负责。说到负责，我不得不说责任感，很多人就是缺少了责任感，以为完成了任务就可以了，但你要知道，你的公司或许等的不是你的完成呢？
请您拿到项目需求的时候，分析一下您要做的东西，用你敏捷的思维想一下，该如何去做，还请您多想想下一步，如果扩展了，我要改哪些地方，最重要的是，请您想想，这个任务对公司是否有利，或许你会说你只是个程序员，我没有权利去改变任务，没有错，你是个程序员，首先请你完成你的任务，在完成任务的同时，想想任务的完成对公司的运营是否起到反作用，因为有时你会比你的老板更了解项目对公司的利弊。如果你真的觉得不太好，不要怕，提出你的观点，但一定要想好你观点的描述，尽可能的表达清楚，让你的老板知道你的意思，因为老板他不一定懂技术，所以一定要白话一点。如果你的观点是正确的，你们老板也听明白你的意思了，那样你们老板会更加的器重你，而不会不可理喻的让你完成他所要的东西了。毕竟这是对他好的建议，也是对公司发展好的建议，如果你的观点不好，那样老板也会给你一定的提点，何乐而不为呢？
下班后，请你抽空想想公司的发展吧，因为你是公司中的一员，公司发展前景好也代表着你的发展前景好，如果你的想法给公司带来了好的前景，那也是对你能力的一种肯定。
最后说说面试，我也经历过很多面试，同样也面试过很多人，刚开始也会为工作着急，到处找面经，但最好的面经是无法从其他地方找来的，因为面试是一个展示自己的机会，而不是一再的ctrl+v 。刚开始我也会紧张，但马上，我调整了自己，每次面试就当自己一种磨练，一种交流、沟通、展示的机会，随后的几次面试都比较成功，再随后的几年，我回到了老公司进行面试，显然他们对我的能力已经是一个肯定了，最后我还是没有选择他们，因为我回去面试只是为了看看公司的发展进行的如何了，因为这一切也有着自己的一份努力。最好玩的是一次邮件面试，对方给了很多题目，大多是网上都有的，我也没有baidu，用自己的想法回答了所有的问题，并提出了很多意见，没想到对方回错了邮件，把他给人事的邮件发给了我，貌似是说面试还可以，就是工资高了点之类的话，我也懒得继续往下看，回信给对方，发错邮件了。过后不久收到对方的面试通知，更确切的说是offer，不过在他电话中我直接给回绝了，因为我已经在一家自己喜欢的地方就职了。
我爱我的公司，我爱我的程序，我也爱我的老婆和家人，因为他们给了我快乐，也给了我支持，让我能更全身心的去投入到代码之美中，我更相信公司能异军突起，成为IT界的领军人物，因为我看到了一群为公司孜孜不倦，辛苦能力的同事，我很爱这种氛围，我相信我们的努力一定会给自己带来收获，就算没有收获，我也没有任何怨言，因为我沉醉了，因为我快乐，因为我是个快乐的程序员。
4、对代码的信任
作为项目管理者，你怎么相信他们的代码。有些程序员，你可以对他们说：我星期五就要结果.--星期五到了，你收到了这样的Email:代码我都已经检查过了，现在就等着测试了。你很放心，只会有很少的瑕疵在质量确保的团队被查到。当然，还有些轻率的例子，一些程序员在邮件里是这样说的：我还没弄完，星期一上午我会最先完成它.你不太确信这东西，发现很多Bug,很长时间基本上不能用。又得花上几个星期清理代码中的Bug.
关键：你对一个开发人员越有信心，他离成为一个伟大的程序员的距离就越近。想象你是你的管理者，如果他并不担心你的代码，会给你多少信心和勇气！
5、对方案的信任
和对代码的信任是一回事--如果你手上有伟大的程序员，你就会对解决方案有信心。这些程序员同时也是伟大的建筑师。他们剖析整个问题，指出问题需要怎样去解决。这就不只是用伟大的代码编程的问题了，很大程度取决于你怎样构筑解决方案。这是关键，而且会让你在软件世界里出类拔萃。
6、满足客户需求
一天下来，你写出了最棒的代码、用了最好的框架和最好的解决方案，但这真的能迎合用户的需求吗？恐怕根本不是那么回事儿。你搞砸了。尽管现在多次失手，一个伟大的程序员还是会正中靶心，找出客户需要的，给用户逐步展示他们所需要的无bug的最终版本。需求正中靶心的同时，用户满意了。
7、不断升级
伟大的程序员会积极主动地把自己的技术升级。他们对知识的态度就像饿猫见着了牛奶，他们从不用上级催促给自己设定目标、不用经理要求他们完成任务，因为他们自己就已经安排OK了。
他们发现自己想要参加的大会就会给公司写Email本人非常想参加今年的Tech-Ed大会。我将用心研习，并对作出贡献。我预计这可节省金钱/其他原因.如果可行，不知公司是否帮我支付此行？如果我收到这样的邮件，我不仅会帮他支付参会费用，他的路费我也会全程买单。
伟大的程序员们永远会关注例如。net用户组或Java用户组的所有用户群体。他们参加本地的技术会议，并从中汲取知识。你会看所有最新博客和最新的杂志吗？现在列出你最喜欢的前5个开发博客。你能做到吗？你应该像参加基督教青年会那样轻松做到。做到这些，可以很好的帮助你延伸你的思路！你将会不断获得更好的点子！你会得到更好的回报！
我和大部人从事IT的人一样，毕业后第一份工作刚开始也是从事软件开发，说得简单点就是程序员，因为刚从学校出来，对这个行业都不懂，但是听社会上工作一两年的人都说，做it要有职业规划。要先做程序员，到转到管理，于是我心里在想，所以我也有一个想法，就是以后要转向做管理。
后来我自己也从项目Leader,做到项目经理。
以前做程序员的时候，认为做项目经理或者项目主管只要在这方面做的时间长，经验丰富，别人遇到问题能解决就可以了，可是真正当我一步一步走上时，我才发现，原来并不这么简单。
刚做项目管理的时候，真的不知道要做些什么，因为我服务的公司不是一个很正规的公司，所以这方面的培训，也没有说教你说做项目主管应该做些什么，或者做项目经理应该做什么，后来我只有从网上找，朋友问，但是这些旁听来的消息，也不知道是真是假，半信半疑。
后来我也卖了一些这方面的书来看，想从中取经。
现在想想刚开始那段时间还真有一点难受，甚至有一段时间我在心里就想不做这个项目主管，让我做个程序员就可以了。
后来慢慢的，我们老总也给我很多帮助，也感谢公司里。net团队和flex团队的两位资深项目经理，他们也不断给我鼓励，给我帮助，让我慢慢的找到正确的路，让我慢慢知道项目经理应该做些什么，怎么样才算是一个好的项目经理。
现在回想起来，做一个项目经理应该具备以下能力：
1.用一句比较常用的话来说：上得了厅堂，下得了厨房。因为做项目经理的时候，难免会与客户打交道，也有可能与合作伙伴打交道。有的人出了公司，见了客户就发虚，底气不足，说话都很抖，让人爱给看扁了。有的甚至一见面就是哦,晕倒,哇靠之类的词就出来了，这样有个客户都会被你吓跑。有的也会很私文，气势都被对方压倒。我本人是07年毕业，到现在才两年多的时间，到现在为止面试的人员差不多有近百了，里面有研究生，有工作很多年的，我记得有一个工作九年的项目经理，能说会道，我和他面谈也很顺利，到面试完后，我才给他说，其实我是07年毕业的，他说真的看不出来。所以作为项目经理，在和自己组员打交道可以 随便点，但是和客户谈话，要注意分寸，有进有退，保持立场。
2.做事要目标明确，抓信问题的关键。不管和客户打交道，还是和程序员打交道，都要能快速的找到问题的关键。很多程序员遇到一个问题，不知道如何下手，其实只要点博一下，找到问题的关键所在，就能很快找到解决问题的办法。在有些场合要与客户谈判或者协商事情的时候，更要注意，更要能够快速找到关键的那一点，比如说人有时候都喜欢来两套，桌面上一套，桌面下一套，有些事在办公室谈不好，说不定到酒桌上就能谈好，但是要看对人，才能使对招，只有这样才能事半功倍。
3.项目经理要有推动力，也就是说你在你的团队，或者在你的谈判中，要能起到推动作用，把事情不断往前推进。让事情向前发展。这就和开会一样，一般来说开会都是遇到什么问题，需要开会来讨论，大家提会提出一些解决问题的办法，大家提出办法后，大家都在那里争论分析几种方法的优缺点，每种情况都有可能失败，都有可能带来损失，大家都不愿承担责任，如果让这种情况一直下去，我敢说他们会讨论几天都可以，这时就需要一个决策者来下结论，决定采用哪一种方法，然后快速的执行下去，而不是在那里无休止的分析。
4.要能承担压力。人遇到压力的时候，都会焦虑，而且有压力的情况下，思路可能会变得不清晰，有时候还会进到死胡同。这时候就需要一个临乱不乱的人，来支撑场面。如果头都乱了，那下面的人一定会乱。我个人认为我本人这一点是没有做好，以前有时候，项目收尾的时候，面对各种压力，比如客户的压力，程序员本身也有压力，还要面对老板的压力，要做到临乱不乱还是有一点难。
5.要有良好的回报心态。不管是在哪一个行来，不管在哪一个公司，也不管在哪一个职位，都要有一个良好的习惯，那就是回报.回报的意思，就是说你要向你直接领导报告你的实时情况，让你的领导随时能够了解你的进度情况，这样就算出了什么事，你的领导多少会有所准备。但是这都是在你回报的情况属实的情况下，我遇到的一个程序员就是每天给你回报说OK,可是真正当项目测试的时候，才发现什么都不OK,让我一点准备都没有。所以回报也一点属实。
以上是我自己的一点心得体会。其中也有些是我没有做好的，我也会在后面的工作中学习，改进，也提升自己。
第二个提法，我觉得目前女性就业困难，关键还在女性自己。
目前大学里面有句话：干得好不如嫁得好！,我想大家都听说过。其实是人就有惰性，也有一些劣根性，都想找一些活少拿钱多的工作，舒舒服服地赚钱，这种思想，其实不管男人女人都有。我自己也有，呵呵。
关键是，社会是公平的，一分贡献，一分收获，哪有那么多不劳而获的事情。但现在的女生，我觉得普遍有点问题，都想走捷径，都想一次革命成功，目前大学校园中，傍大款的不少，很多女生一门心思嫁个好老公，认为这辈子就有靠了，不需要奋斗了。
因此，在求职市场上，很多女生不是找不到工作，是根本没有一心一意地去找，因为对女生而言，通常都有第二选择，可以靠家里，靠男朋友，等等。这种求职态度上的不坚决，其实无形中，已经给自己关闭了很多企业的大门。有个现象，同等条件的两名女生都面试，一名犹犹豫豫的，一名态度极其坚决，一定要拿到这份工作，通常都是后者获胜，因为企业认为这个人既然这么需要这份工作，那不管能力怎么样，进来后起码会拼命做事。
那我们再来比较男生和女生，就可以看出显著差异了，其实男生有时候也想靠，但是没得靠啊，反而，还有个女生在靠自己，自己还要撑起一片家庭，那么，你说男生求职拼命不？
但我还是得说，前面女生的这种思维是严重错误的，夫妻也是经济共同体，双方需要共同完成家庭建设，这样的家庭才稳定。一个女性，如果觉得职场艰难，就打退堂鼓，那，不管是不是程序员，其实我觉得她什么职位都找不到的。
这样还有潜在的恶果，现在有很多闪婚族，出了校门就结婚，我认为和女性的这种依赖思想有一定关系，但这样的婚姻，是不是稳定呢？
其实我不讲，大家都应该清楚，女性凭借个人的外貌实现魅力，男人更多的是凭个人的内涵和事业的成就实现魅力，这就决定了，一个女人，魅力最大的时候，是18~28这个年龄段，而男人恰好相反，一个男人最有魅力的时候，是35~45岁这个年龄段。这中间有落差。
一个女性，如果坚持以漂亮为本钱，早早地就嫁人，在家里相夫教子，那么，在她30多岁，年华老去的时候，情况就比较危险了。首先，男方逐渐进入事业巅峰，很多更为年轻漂亮的女性，会青睐这种男人，男人面临的诱惑在加大，其次，这个家庭，十几年其实都是男方一点点赚出来的，女方是享受者，不是建设者，在这个家庭里面渐渐就没有发言权，经济基础决定上层建筑，不要说对方爱你就会一辈子听你话，很多事会变的。
如果此时女性再不注意，试图通过控制经济等手段压制男人不会变心，或者采用跟踪，哭闹等极端方法，往往适得其反，最终导致男人离他而去。一旦出现这个问题，女性的问题就比较危险了，十几年没有上过班，自己的专业能力，恐怕仅仅剩下一张文凭了，知识都还给老师了，那她在社会上可以说没有任何竞争力可言。那么，她以后靠什么生存？
相关文章
最新更新
