㈠ 程序员实际工作中有没有程序员因为有些地方忘了或者是某个功能不知道怎么实现了，边查资料边看教程来完的
所有的知识性工种应该都有这种情况。不只是程序员，科学家，老师……都会的
㈡ 一名小白程序猿怎么快速提升编程能力
一、先列三个常见的开发场景：
1、拿到一个模块详细设计文档，大部分程序员的通常做法就是开始搭建界面代码，然后从第一个按钮点击事件或页面Load事件开始写第一行业务代码。写的差不多了，就运行一下，发现哪里不是自己想的那样，就改改，直到改到是自己预想的那样。
2、做完了一个功能模块或几块相关联的功能模块，输入111asd，发现新建正常、保存正常，就提交给测试人员。测试员用测试用数据、测试场景用例来测试，发现有问题，就登记bug。对于严重的影响下一步测试的BUG，测试员就用内部IM通知这个开发人员。对于不影响继续往下测试的BUG，测试员就登记下来，等程序员有空时处理。
3、程序员一般工作不希望大家打扰，所以开发起来就是开发。等手头开发告一段落，就看看BUG库。发现有与自己有关的BUG，就从第一个BUG开始看起。就开始通过IM和测试员掰扯起来（这不是个BUG啊、业务逻辑不是你想的那样啊、我这里不能重现啊、你给的信息描述不清晰啊），于是IM几来几往，甚至跑过去当面交流一番，甚至会拉扯上产品经理一起讨论，更甚者需要项目经理或产品经理发起一个会议来集体讨论一下
这是不是很熟悉呢看这就是大部分程序员开发的三个步骤：写代码、自测、修复BUG。
二、说好的代码设计、代码测试呢看
代码设计看那不是都有开发平台么，已经固化了啊。那不是维护旧功能做完善修改呢么，又不是写新代码，只能在现有代码基础上修改啊，你又不能大幅重构。
代码测试看你丫需求讨论期、产品设计期、设计评审期那么长，都把研发项目时间占光了，就留下2个星期让我们写代码，我们哪里有时间搞那么深的测试。还想让我们搞结对编程看还想让我们搞测试驱动开发看
而且你看测试，什么功能测试、集成测试、性能测试、安全测试、安装部署测试、升级测试、迁移测试、UAT测试，一大堆测试，测试也需要很多时间。
一个项目，需求讨论、产品范围规划与评审、产品设计与设计评审占了一个半月，开发+自测就一个月，测试占了一个半月，这就4个月了啊。
三、为啥程序员写代码总是写写测测看
刚才大家也都看到了，大部分程序员都是从界面代码开始写起，而且写一写，就运行一下看看。为什么会是这种开发方式看
那是因为大部分程序员缺乏在脑子中的整体建模能力。只能做出来一点，真实的感觉一下，然后再往下。
有些是产品经理的上游就有问题，没给出业务流程图（因为产品经理也没做过业务），也没画清楚产品功能操作流程图。
为啥没给出业务流程图看因为产品经理不熟悉业务，另外，产品经理也没有流程建模能力啊。为啥没画清楚产品功能操作流程图啊看因为不会清晰表达流程啊。
很多产品经理、程序员，都缺乏分类、分层、相关、先后能力，更别说总结、洞察能力。
这是基本训练，是一个做事头脑清醒的人必备的技能，这不是一个程序员或产品经理或测试员的特定技能要求。
我经常看书就梳理书的脉络，每看一本就写一篇总结。我过去闲扯淡还梳理过水浒传、红楼梦的人物关系图呢，其实就在事事上训练自己的关联性、层次性、洞察性。
我经常面试一个人时，我会问这样的问题：逗你把我刚才说的话复述一遍，另外你再回答一下我为什么会这样看地，其实，我就在看一个人的细心记忆、完整梳理、重现能力，我也在看一个人的梳理、总结、洞察能力。
我个人写代码就喜欢先理解业务流，然后理解数据表关系，然后理解产品功能操作流，大致对功能为何这样设计、功能这样操作会取什么表、插入或更新哪些表，哪些表的状态字段是关键。
然后我写代码的时候，就根据我所理解的业务流、功能操作流、数据输入输出流，定义函数，定义函数的输入与输出。
然后，我会给函数的输入值，赋上一些固定值，跑下来看看能否跑通这几个关联函数，看看还需要怎样的新增函数，或者看看函数的输入输出参数是否满足跑通。
剩下的事，就是我填肉写详细逻辑代码了。
当然，大部分人没我这样的逻辑建模能力。怎么阅读理解也想象不出来，也没法定义函数。毕竟有逻辑建模能力的程序员都很少，100个人里有10个，已经是求爷爷告奶奶好幸运了。
那怎么办呢看
我建议是分离分工配合，这就是现实中没办法的办法。让有逻辑建模能力的人来设计函数框架、来设计工具来设计代码模板，然后让没有逻辑建模能力的人来填肉写详细逻辑代码。
我们可以先从最紧要的模块开始这么做。不紧要的模块，还让它放任自流，让熟练手程序员继续涂抹。
我曾经还让有头脑的程序员做榜样，给大家分享他是怎么规划函数的，怎么做维护性代码的代码结构改善的。但是发现效果并不佳，其他人并没有因此能做代码设计。可能逻辑建模能力是个人的基本素质，是从小到大训练成型的，不是你一个大学已经几年的人能够短时间内可以训练的。
所以啊，还是让能走的人先走，让从最紧要的模块开始这么做。
不必担心这样做后，因为过去一件事被分工（一个做代码框架一个填肉）成两个人做了会降低工作效率。我们很多的工作效率低就是因为半瓶子醋搞出来的，来回反复修改。
真是应了刘德华在电影里说的那句话：说你又不听，听又听不懂，听懂了又不做，做又做不好，做不好还不服气。
四、为什么大部分程序员不做代码测试或白盒测试或单元测试呢看
还是因为没有代码设计。因为没有函数啊。所以，一个按钮功能有多复杂，代码就有多长。我见过2000行的函数，我也见过1000多行的存储过程和视图SQL。怎么做白盒测试啊，这些代码都粘在一起呢，要测，就得从头到尾都得测。
所以啊，先学会设计函数，先写好函数，这就求爷爷告奶奶了。很多开发了5年的熟练手程序员，可能都未必会写函数。
函数的输入输出值就很有讲究。很多人都写死了，随着版本迭代，发现过去定义的函数参数不够用了，于是就新增了一个参数。然后，相关性异常就爆发了，其他关联的地方忘改了，到底哪些有关联，怎么查啊，本系统没有，没准其他系统就调用你了，你根本不知道哪个神经人曾经COPY过你的代码修吧修吧就改成了他的功能呢，而且里面的很多代码他看不懂也不敢删，只要他实现的功能正常了他也不管了。于是，你改了你这个函数，他的系统就莫名出错了。
所以，我一般会定义几个对象来做参数。另外，我也很注重函数的日志、函数的异常保护、异常抛出、异常返回。另外，我也很注重参数输入值的合法性校验。
所以啊，应该开发Leader们先制定函数编写规范最佳实践，输入输出参数怎么定义比较好，函数的返回值如何定义比较好，函数的日志记录应该怎么写比较好，函数的异常保护、异常抛出、异常返回如何写比较好。先教会一般程序员，先从会写函数开始啊。
当然，你光有一份规范，程序员们还是不理解、不实际应用啊。所以，还得Leader们做好典型的代码模板，里面是符合函数规范的代码框架，只有这样，一般程序员们才会照猫画虎适应了函数设计的编程习惯。
所以啊，我专门重新定义了leader的明确职责，其中第一个重要职责就是：负责工具/框架/模板/规范的制定，并且负责推广且普及应用落地。
你不明确定义Leader的这个重要职责，你不对这个职责做明确的KPI考核，谁尿你啊。你以为好的工具/框架/模板/规范是靠人们的热情、自发产生的么看我们还没有那么自觉高尚啊。
五、为什么大部分程序员不写注释啊看
我经常说一句话，千万别多写注释。为啥看
因为我们经常遇到的问题不是没有注释，而是更糟的是，注释和事实代码逻辑是不相符的。这就出现常见问题了：残存下来的设计文档是一个逻辑、注释是一个逻辑说明、真实代码逻辑又是一个，钟表多了，你也不知道正确时间了。
所以啊，产品文档、注释、真实代码，三者总是很难一致同步。我为了几百人研发团队能做到这个同步花了大量心血和办法，但我最终也没解决了这个问题，还把Leader们、总监们、我都搞的精疲力尽。
索性回归到一切一切的本源，代码，就是程序员的唯一产出，是最有效的产出。那么，让代码写的不用注释也能看懂，咱得奔着这个目的走啊。
为啥看不懂，不就是意大利面条式代码么，又长又互相交杂。
OK，我就规定了，每个函数不能超过50行。用这一个简单规定和静态代码检查插件，来逼迫大家尝试着写函数。有的函数属于流程函数，是串起其他函数的，有的函数就是详细实现函数，实现一个且唯一一个明确作用的。
有了流程函数和功能函数，而且每个函数不超过50行，这就比过去容易看懂了。
六、为什么大部分程序员不抽象公共函数啊看
我经常说一句话：千万别抽象公共函数啊。为啥看
因为大部分程序员缺乏抽象洞察能力。特别是有些积极热情有余、爱学习爱看书、半瓶子醋晃悠的二杆子，看了几本UML、重构、设计模式、整洁代码之道，就跃跃欲试了，还真敢给你抽象公共函数了。
一开始，他觉得80%相似，20%不相似，于是在公共函数里面简单写几个if..else做个区隔就可以。没想到，越随着版本迭代，这些功能渐渐越变越不一样了，但是这个代码已经几经人手了，而且这是一个公共函数，谁也不知道牵扯多少，所以谁也不敢大改，发现问题了就加一个if..else判断。
没想到啊没想到，这个本来当初公共的函数，现在变成了系统最大的毒瘤，最复杂的地方，谁也不敢动，除非实在万不得已，手起刀落。
所以，我平时告诫程序员，纯技术的、纯通用的，你们可以尝试搞搞抽象公共函数，对于业务的，你们还是简单粗暴的根据Leader们做的代码模板代码框架，乖乖的复制、修改、填肉吧。
你们啊，先从做模板做代码片段开始吧，咱们放到咱们内部代码片段开源库里，看谁的代码片段被别人复制的多，说明你的代码抽象设计能力越好了。那时候，我就大胆放心让你撒丫子跑了。在没有学会跑之前，给老子乖乖的复制、修改、填肉吧。
㈢ 程序员怎么知道用什么方法解决问题
一般程序员开发的版本分为两类，我将之称为：新开发和N次开发。
新开发版本是指之前没有的、本次为了实现需求而专门开发的版本，也就是所谓的第一个版本。对于此类版本，个人的开发经验如下：
(1) 在动手编码之前，我们要理清需求，看一下软件有什么特点、哪些功能的实现比较容易、哪些功能的实现比较困难。“读书百遍，其义自见”，通过多次阅读需求说明之后，我们的头脑中就会形成对于该软件的大致的轮廓。
(2) 在阅读需求的同时，我们要想一下或咨询一下同事，看之前是否有类似的软件版本已经存在了。如果有，我们就可以在已有的版本的基础之上进行修改，节约开发时间，提高开发效率。
(3) 一定要做好软件的详细设计并且评审通过之后再开始编写代码，在详细设计里面，要针对软件需求列出程序的大体流程及相关算法设计等。很多软件后期出现问题，都与前期的详细设计没有做好有关。因此，宁可多花些时间在软件的详细设计上，也不愿后期将程序改过去改过来。
N次开发版本是指在已有的软件版本之上为新增需求而开发的版本。打个比方来说，一栋楼已经有五层了，现在要在上面加一层，那么第六层(新增加的这层)就是N次开发版本。对于此类版本，个人的开发经验如下：
(1) 在添加或修改代码之前，一定要对原程序的流程有一个全面的了解，要搞清楚本次要在哪个地方添加、修改或删除代码。很多开发人员为了赶进度，拿到代码就开始修修补补，那是不对的。
(2) 一定要确保本次修改不会影响之前的老的程序流程，在修改完代码之后，要对之前的重要程序流程进行回归测试。这点很重要，如果新增流程影响到了原有流程，那么要向相关人员提出，大家在一起商量出一个好的解决办法。
(3) 如果发现原程序架构不合理，或原代码的编写不规范，可以考虑对之进行适当的修改(重构)。但在修改之前，要向开发经理提出自己的想法，大家商讨出一个折中的方案。因为原版本已经发布，所以任何对它的修改都要谨慎，千万不可任性。
㈣ 程序员跟你说这个功能不能实现你会怎么办
别不要总听别人说的 看你有没有那个信心去实现了
如果有 那么 你就努力去做到他
如果你感觉也没什么希望 那建议你多听听别人的
因为做软件讲求的是实用
可能你的想法很好 很新颖 但不实用
㈤ 安卓程序员要实现某个功能却不知道用什么代码实现怎么办
美国的程序员交流网站 Stack Overflow 在去年的开发者调查中想要了解，码农们是否都有大学的计算机专业学位。有 26086 名程序员参与了这项调查，其中有近一半受访者的答案是，没有学位。 大量程序员非科班出身的原因有很多方面。一方面，美国大学的学费正日益高涨。私立四年制大学一年学费平均接近 4.5 万美元，其中还没有包括生活费。另一方面，网上课程和培训班吸引了很多人。有志于成为程序员的人士可以在做中学，而不必浪费几年时间去完成大学学业。 关于非科班出身的程序员，有几点建议可供参考： 闭门造车要不得 编程时的闭门造车会带来几方面问题： 没有人给你答疑。编程时你会面临许多疑问，但却无法找到人给你答疑解惑。解决这类问题的过程通常需要求助于高级程序员，或是将自己的代码与别人的去对比。 软件评审。大型软件公司都会设置软件评审环节，即让同事之间互相评审对方的代码。无论是国外还是国内，数据显示，代码评审能多发现 60% 的错误和漏洞。即使你自己干，也需要找人去评阅自己的代码。 与他人一同工作有助于拓展人脉，在职业生涯初期尤其如此。 目前，国内许多众创空间都在面向小团队乃至个人开放申请。这将会是不错的选择。 多读书，尤其是大学专业内容 大学培养人才的重要之处是训练基本功和思维方法，而不是让你实际参与工程项目。如果没有上过大学，那么这些方面很可能会有缺失。你可能知道如何根据架构师的设计文档去写代码，但却不知道算法为什么是这样。在实际面试中，笔者还曾发现，有许多非专业出身的人士甚至都不能准确解释，什么是面向对象的编程。而这本应是 C++ 的基础。 非科班出身的人士需要通过多读书来补充基础知识，无论是离散数学、算法设计，还是软件测试的基本理论。 另一方面，如果你希望通过网上课程或培训班去学习，那么最好从基础开始学，尤其是在没有编程经验的情况下。 如果你是非科班出身，希望自己干，那么应当采用自底向上的模式。这将帮你弄清许多基本概念。一上手就接触庞大的代码将会令人摸不着北。 多练习，多做项目 对新人来说，多参与项目能帮助积累更多经验，有利于未来的职业发展。而如果想要单干，那么所做的项目将成为简历上的主要经历，是对能力的证明。 个人从事项目最好的选择是开发移动应用。相对于大型软件项目，例如系统软件或企业级应用，移动应用的开发相对简单，很容易出成果，而也会有许多用户提供反馈，相当于免费帮你做测试。移动应用开发使用的语言包括 Swift 或 Objective C（iOS 平台）、java（Android 平台），以及 C#和 VB（Windows 平台）等等。此外，Phonegap 等通用型技术也可以考虑。 对个人程序员来说，GitHub 是个好工具。GitHub 上有许多开源项目可以参与，也有许多其他程序员可以提供帮助。你也可以自己创建软件项目。这一切都是免费的。 职业发展的选择 非科班出身程序员在找工作时可能会受到局限，因为大公司的招聘中学历是个门槛。许多知名科技公司用大学学历作为条件去过滤求职者。例如，谷歌在招聘初级工程师时就是这样。 相对来说，一些创业公司更看重个人能力，而非学历。对于需要什么样的程序员，什么样的程序员是够格的，它们有自己的标准。在创业公司里找工作时，你不一定需要有大型软件的成功开发经历，通常只要证明你能开发出用得起来的软件。 如果觉得自己的能力稍弱，那么还可以考虑软件公司中的 QA（质量工程师）职位。QA 的工作通常是统计问题，找出趋势，以及建议如何改进。这也是一项程序员的基础能力。而许多公司对 QA 工程师的招聘门槛要低于软件工程师。 简而言之，大学学位，或者说计算机专业的学位，并不是成为程序员的必要条件。但如果这类人群希望成为程序员，那么将要在学习和实践方面付出更多的努力。 编者按：李玮是科技从业者，在多家网站开设专栏。同时他也是为 TC 中国长期贡献稿件的译者之一。
㈥ 编程程序是怎么实现的
编程的话，我的语言描述就是，
要编一个程序，那么这个程序有它的基本语言。就像我们学习说话，先学会发音，然后组织语言；
学会了基本的语言后，我们就根据需要来编程，在编程过程当中，我们要考虑各种情况，使程序实现我们需要，如果考虑不周到，就会有漏洞，需要补上。所以在编程当中，用到最多的语言就是（如果，或者）这样的词汇。
把各种漏洞都堵上了，电脑执行你的指令，不管你有没有提到其它方面，所有的程序它都要复核一边。所以程序不要太庞大，需要简洁，减少电脑的运行。这个就与你堵漏洞有相反的要求。如果你编写了一个子程序，程序经常要用到这个，那么你要考虑怎么把这个程序精简到最低程度。
因为电脑只能识别这个语言，所以不能够在语法上有错误，它会理解不了。
说到漏洞，比如说，记事本里面查找功能，你要找文字（J3），那么它把（J33），（J32）里面的也找了，如果你在里面替换什么内容的话，就会出现问题。这个问题就是你要考虑的，怎么把漏洞堵上，不发生这样的问题。
所以我认为编程就是你对这个程序的理解程度考验。至于基本语言你学会就好，你要做的就是把你想说的话，翻译成电脑能够听懂的话。要说明，什么不能够做，什么应当做，一一交代清楚，只要说漏了一句，电脑就不按你的思路走了。（电脑不会思考，你要做的就是让电脑按你的思路走。）
㈦ 系统程序员，主要学会那些技能，如何做好一个系统程序员，需要注意事项有哪些
程序员是一种技术工作，在IT的发展中有相当重要的地位，从底层硬件通讯协议的建立， 到数据传输层的处理，到操作系统的建设，到数据库平台的建设，一直到应用层上各种数 据营销平台的搭建，程序员在里面都扮演着举足轻重的角色并为IT事业的发展做出了巨大 的贡献。 中国有很多精于编码的人，但是中国软件行业，尤其是网络应用开发方面误区很大，很难形成有规模的软件开发力量和产品能力，不但比美国差距甚远，和印度相比也是颇有不如。这些问题不是在于中国程序员的智商和工作努力状况，也不是在于国家和民间对开发的投入程度，而是很大程度上，有一些对技术，对程序开发，对项目设计方面的思想误区，这些误区，导致了软件行业的产品化能力不足，缺乏规模化和大型复用系统研发能力，可以说，改变认识误区，是解决软件行业小作坊模式和个体英雄模式所带来的局限性 的重要工作。 中国有很多小朋友，他们18,9岁或21,2岁，通过自学也写了不少代码，他们有的代码写的很漂亮，一些技术细节相当出众，也很有钻研精神，但是他们被一些错误的认识和观点左右，缺乏对系统，对程序的整体理解能力，这些人，一个网上的朋友说得很好，他们实际 上只是一些Coding fans，压根没有资格称为程序员，但是据我所知，不少小网络公司的 CTO就是这样的coding fans,拿着吓人的工资，做着吓人的项目，项目的结局通常也很吓 人。 程序员基本素质: 作一个真正合格的程序员，或者说就是可以真正合格完成一些代码工作的程序员，应该具 有的素质。 1:团队精神和协作能力 把它作为基本素质，并不是不重要，恰恰相反，这是程序员应该具备的最基本的，也是最重要的安身立命之本。把高水平程序员说成独行侠的都是在呓语，任何个人的力量都是有限的，即便如linus这样的天才，也需要通过组成强大的团队来创造奇迹，那些遍布全球的为linux写核心的高手们，没有协作精神是不可想象的。独行侠可以作一些赚钱的小软件发点小财，但是一旦进入一些大系统的研发团队，进入商业化和产品化的开发任务，缺 乏这种素质的人就完全不合格了。 2:文档习惯 说高水平程序员从来不写文档的肯定是乳臭未干的毛孩子，良好的文档是正规研发流程中 非常重要的环节，作为代码程序员，30%的工作时间写技术文档是很正常的，而作为高级 程序员和系统分析员，这个比例还要高很多。 缺乏文档，一个软件系统就缺乏生命力，在未来的查错，升级以及模块的复用时就都会遇 到极大的麻烦。 3:规范化，标准化的代码编写习惯 作为一些外国知名软件公司的规矩，代码的变量命名，代码内注释格式，甚至嵌套中行缩 进的长度和函数间的空行数字都有明确规定，良好的编写习惯，不但有助于代码的移植和 纠错，也有助于不同技术人员之间的协作。 有些coding fans叫嚣高水平程序员写的代码旁人从来看不懂，这种叫嚣只能证明他们自 己压根不配自称程序员。代码具有良好的可读性，是程序员基本的素质需求。 再看看整个linux的搭建，没有规范化和标准化的代码习惯，全球的研发协作是绝对不可 想象的。 4:需求理解能力 程序员需要理解一个模块的需求，很多小朋友写程序往往只关注一个功能需求，他们把性能指标全部归结到硬件，操作系统和开发环境上，而忽视了本身代码的性能考虑，有人曾经放言说写一个广告交换程序很简单，这种人从来不知道在百万甚至千万数量级的访问情况下的性能指标是如何实现的，对于这样的程序员，你给他深蓝那套系统，他也做不出太极链的并访能力。性能需求指标中，稳定性，并访支撑能力以及安全性都很重要，作为程序员需要评估该模块在系统运营中所处的环境，将要受到的负荷压力以及各种潜在的危险和恶意攻击的可能性。就这一点，一个成熟的程序员至少需要2到3年的项目研发和跟踪经 验才有可能有心得。 5:复用性，模块化思维能力 经常可以听到一些程序员有这样的抱怨，写了几年程序，变成了熟练工，每天都是重复写 一些没有任何新意的代码，这其实是中国软件人才最大浪费的地方，一些重复性工作变成 了熟练程序员的主要工作，而这些，其实是完全可以避免的。 复用性设计，模块化思维就是要程序员在完成任何一个功能模块或函数的时候，要多想一些，不要局限在完成当前任务的简单思路上，想想看该模块是否可以脱离这个系统存在，是否可以通过简单的修改参数的方式在其他系统和应用环境下直接引用，这样就能极大避免重复性的开发工作，如果一个软件研发单位和工作组能够在每一次研发过程中都考虑到这些问题，那么程序员就不会在重复性的工作中耽误太多时间，就会有更多时间和精力投 入到创新的代码工作中去。 一些好的程序模块代码，即便是70年代写成的，拿到现在放到一些系统里面作为功能模块 都能适合的很好，而现在我看到的是，很多小公司软件一升级或改进就动辄全部代码重 写，大部分重复性工作无谓的浪费了时间和精力。 程序员应具备的素质中 6:测试习惯 作为一些商业化正规化的开发而言，专职的测试工程师是不可少的，但是并不是说有了专职的测试工程师程序员就可以不进行自测;软件研发作为一项工程而言，一个很重要的特点就是问题发现的越早，解决的代价就越低，程序员在每段代码，每个子模块完成后进行认真的测试，就可以尽量将一些潜在的问题最早的发现和解决，这样对整体系统建设的效 率和可靠性就有了最大的保证。 测试工作实际上需要考虑两方面，一方面是正常调用的测试，也就是看程序是否能在正常调用下完成基本功能，这是最基本的测试职责，可惜在很多公司这成了唯一的测试任务，实际上还差的远那;第二方面就是异常调用的测试，比如高压力负荷下的稳定性测试，用户潜在的异常输入情况下的测试，整体系统局部故障情况下该模块受影响状况的测试，频发的异常请求阻塞资源时的模块稳定测试等等。当然并不是程序员要对自己的每段代码都需要进行这种完整测试，但是程序员必须清醒认识自己的代码任务在整体项目中的地位和各种性能需求，有针对性的进行相关测试并尽早发现和解决问题，当然这需要上面提到的 需求理解能力。 7:学习和总结的能力 程序员是人才很容易被淘汰，很容易落伍的职业，因为一种技术可能仅仅在三两年内具有 领先性，程序员如果想安身立命，就必须不断跟进新的技术，学习新的技能。 善于学习，对于任何职业而言，都是前进所必需的动力，对于程序员，这种要求就更加高 了。 但是学习也要找对目标，一些小coding fans们，他们也津津乐道于他们的学习能力，一会学会了asp，一会儿学会了php，一会儿学会了jsp，他们把这个作为炫耀的资本，盲目的追逐一些肤浅的，表面的东西和名词，做网络程序不懂通讯传输协议，做应用程序不懂中断向量处理，这样的技术人员，不管掌握了多少所谓的新语言，永远不会有质的提 高。 善于总结，也是学习能力的一种体现，每次完成一个研发任务，完成一段代码，都应当有 目的的跟踪该程序的应用状况和用户反馈，随时总结，找到自己的不足，这样逐步提高， 一个程序员才可能成长起来。 一个不具备成长性的程序员，即便眼前看是个高手，建议也不要选用，因为他落伍的时候 马上就到了。 具备以上全部素质的人，应当说是够格的程序员了，请注意以上的各种素质都不是由IQ决 定的，也不是大学某些课本里可以学习到的，需要的仅仅是程序员对自己工作的认识，是 一种意识上的问题。 那么作为高级程序员，以至于系统分析员，也就是对于一个程序项目的设计者而言，除了 应该具备上述全部素质之外，还需要具备以下素质: 第一，需求分析能力 对于程序员而言，理解需求就可以完成合格的代码，但是对于研发项目的组织和管理者， 他们不但要理解客户需求，更多时候还要自行制定一些需求，为什么这么说呢? 一般而言，进行研发任务，也许是客户提出需求，也许是市场和营销部门提出的需求，这时候对于研发部门，他们看到的不是一个完整的需求，通常而言，该需求仅仅是一些功能上的要求，或者更正规些，可能获得一个完整的用户视图;但是这都不够，因为客户由于非技术因素多一些，他们可能很难提出完整和清晰，或者说专业性的性能需求，但是对于项目组织者和规划者，他必须能够清醒认识到这些需求的存在并在完成需求分析报告的时候适当的提出，同时要完整和清晰的体现在设计说明书里面，以便于程序员编码时不会失 去这些准则。 程序设计者必须正确理解用户需求所处的环境，并针对性做出需求的分析，举例而言，同样一个软件通过ASP租用方式发布和通过License方式发布，性能需求可能就是有区别的，前者强调的是更好的支撑能力和稳定性，而后者则可能更强调在各种平台下的普适性和安 装使用的简捷性。 第二，项目设计方法和流程处理能力 程序设计者必须能够掌握不少于两到三种的项目设计方法(比如自顶至下的设计方法，比 如快速原型法等等)，并能够根据项目需求和资源搭配来选择合适的设计方法进行项目的 整体设计。 设计方法上选择不当，就会耽误研发周期，浪费研发资源，甚至影响研发效果。 一个程序设计者还需要把很多功夫用在流程图的设计和处理上，他需要做数据流图以确立 数据词典;他需要加工逻辑流图以形成整体的系统处理流程。 一个流程有问题的系统，就算代码多漂亮，每个模块多精致，也不会成为一个好的系统。 当然，做好流程分析并选择好项目设计方法，都需要在需求分析能力上具有足够的把 握。 第三，复用设计和模块化分解能力 这个似乎又是老调重谈，前面基本素质上不是已经说明了这个问题吗? 作为一个从事模块任务的程序员，他需要对他所面对的特定功能模块的复用性进行考虑，而作为一个系统分析人员，他要面对的问题复杂的多，需要对整体系统按照一种模块化的分析能力分解为很多可复用的功能模块和函数，并针对每一模块形成一个独立的设计需求。举个例子，好比是汽车生产，最早每辆汽车都是独立安装的，每个部件都是量身定做的，但是后来不一样了，机器化大生产了，一个汽车厂开始通过流水线来生产汽车，独立部件开始具有一定的复用性，在后来标准化成为大趋势，不同型号，品牌甚至不同厂商的汽车部件也可以进行方便的换装和升级，这时候，汽车生产的效率达到最大化。软件工程也是同样的道理，一个成熟的软件行业，在一些相关项目和系统中，不同的部件是可以随意换装的，比如微软的许多桌面软件，在很多操作模块(如打开文件，保存文件等等)都是复用的同一套功能模块，而这些接口又通过一些类库提供给了桌面应用程序开发者方便 挂接，这就是复用化的模块设计明显的一个佐证。 将一个大型的，错综复杂的应用系统分解成一些相对独立的，具有高度复用性的，并能仅 仅依靠几个参数完成数据联系的模块组合，是作为高级程序员和系统分析员一项最重要的 工作，合适的项目设计方法，清晰的流程图，是实现这一目标的重要保证。 第四，整体项目评估能力 作为系统设计人员，必须能够从全局出发，对项目又整体的清醒认识，比如公司的资源配置是否合理和到位，比如工程进度安排是否能最大化体现效率又不至于无法按期完成。评估项目整体和各个模块的工作量，评估项目所需的资源，评估项目可能遇到的困难，都需要大量的经验积累，换言之，这是一种不断总结的累计才能达到的境界。在西方一些软件系统设计的带头人都是很年长的，比如4，50岁，甚至更老，他们在编码方面已经远远不如年轻人那样活络，但是就项目评估而言，他们几十年的经验积累就是最重要和宝贵的财富。中国缺这么一代程序员，主要还不是缺那种年纪的程序员，而是那种年纪的程序员基本上都是研究单位作出来的，都不是从专业的产品化软件研发作出来的，他们没有能积累 那种产品化研发的经验，这也是没有办法的事情。 程序员应具备的素质下 第五，团队组织管理能力 完成一个项目工程，需要团队的齐心协力，作为项目设计者或研发的主管人，就应当有能 力最大化发挥团队的整体力量，技术管理由于其专业性质，不大同于一般的人事管理，因 为这里面设计了一些技术性的指标和因素。 首先是工作的量化，没有量化就很难做到合适的绩效考核，而程序量化又不是简单的代码 行数可以计算的，因此要求技术管理人员需要能真正评估一个模块的复杂性和工作量。 其次是对团队协作模式的调整，一般而言，程序开发的协作通常分为小组进行，小组有主 程序员方式的，也有民主方式的，根据程序员之间的能力水平差距，以及根据项目研发的 需求，选择合适的组队方式，并能将责权和成员的工作任务紧密结合，这样才能最大发挥 组队的效率。 一个代码水平高的人，未必能成为一个合格的项目研发主管，这方面的能力欠缺往往是容 易被忽视的。 综上可以看到，作为一个主管研发的负责人，一个项目设计者，所需要具备的素质和能力并不是程序代码编写的能力，当然一般情况下，一个程序员通过不断的总结提高达到了这种素质的时候，他所具有的代码编写能力也已经相当不简单了，但是请注意这里面的因果关系，一个高水平的项目设计者通常已经是代码编写相当优秀的人了，但是并不是一个代码相当优秀的程序员就可以胜任项目设计的工作，这里面存在的也不是智商和课本的问题，还是在于一个程序员在积累经验，逐步提升的时候没有意识到应当思考哪方面的东西，没有有意识的就项目的组织和复用设计进行揣摩，没有经常性的文档习惯和总结习 惯，不改变这些，我们的合格的项目设计者还是非常欠缺。 另外，为防止有无聊的人和我较真，补充一点，本文针对目标是作商业化的软件项目和工程，那些科研机构的编程高手，比如算法高手，比如图象处理高手，他们的工作是研究课题而非直接完成商业软件(当然最终间接成为商业产品，比如微软研究院在作的研究课题)，因此他们强调的素质可能是另外的东西，这些人(专家)，并不能说是程序员，不 能用程序员的标准去衡量。 最后补充一点东西，一个软件项目研发的设计流程是怎样的呢?以通常标准的设计方法为 例，(不过笔者喜欢快速原型法)。 第一个步骤是市场调研，技术和市场要结合才能体现最大价值。 第二个步骤是需求分析，这个阶段需要出三样东西，用户视图，数据词典和用户操作手 册。 用户视图是该软件用户(包括终端用户和管理用户)所能看到的页面样式，这里面包含了 很多操作方面的流程和条件。 数据词典是指明数据逻辑关系并加以整理的东东，完成了数据词典，数据库的设计就完成 了一半多。 用户操作手册是指明了操作流程的说明书。 请注意，用户操作流程和用户视图是由需求决定的，因此应该在软件设计之前完成，完成 这些，就为程序研发提供了约束和准绳，很遗憾太多公司都不是这样做的，因果颠倒，顺 序不分，开发工作和实际需求往往因此产生隔阂脱节的现象。 需求分析，除了以上工作，笔者以为作为项目设计者应当完整的做出项目的性能需求说明 书，因为往往性能需求只有懂技术的人才可能理解，这就需要技术专家和需求方(客户或 公司市场部门)能够有真正的沟通和了解。 第三个步骤是概要设计，将系统功能模块初步划分，并给出合理的研发流程和资源要求。作为快速原型设计方法，完成概要设计就可以进入编码阶段了，通常采用这种方法是因为涉及的研发任务属于新领域，技术主管人员一上来无法给出明确的详细设计说明书，但是并不是说详细设计说明书不重要，事实上快速原型法在完成原型代码后，根据评测结果和 经验教训的总结，还要重新进行详细设计的步骤。 第四个步骤是详细设计，这是考验技术专家设计思维的重要关卡，详细设计说明书应当把具体的模块以最’干净’的方式(黑箱结构)提供给编码者，使得系统整体模块化达到最大;一份好的详细设计说明书，可以使编码的复杂性减低到最低，实际上，严格的讲详细设计说明书应当把每个函数的每个参数的定义都精精细细的提供出来，从需求分析到概要设计到完成详细设计说明书，一个软件项目就应当说完成了一半了。换言之，一个大型软 件系统在完成了一半的时候，其实还没有开始一行代码工作。 那些把作软件的程序员简单理解为写代码的，就从根子上犯了错误了。 第五个步骤是编码，在规范化的研发流程中，编码工作在整个项目流程里最多不会超过1/ 2，通常在1/3的时间，所谓磨刀不误砍柴功，设计过程完成的好，编码效率就会极大提高，编码时不同模块之间的进度协调和协作是最需要小心的，也许一个小模块的问题就可能影响了整体进度，让很多程序员因此被迫停下工作等待，这种问题在很多研发过程中都出现过。编码时的相互沟通和应急的解决手段都是相当重要的，对于程序员而言，bug永远存在，你必须永远面对这个问题，大名鼎鼎的微软，可曾有连续三个月不发补丁的时候 吗?从来没有! 第六个步骤是测试 测试有很多种: 按照测试执行方，可以分为内部测试和外部测试 按照测试范围，可以分为模块测试和整体联调 按照测试条件，可以分为正常操作情况测试和异常情况测试 按照测试的输入范围，可以分为全覆盖测试和抽样测试 以上都很好理解，不再解释。 总之，测试同样是项目研发中一个相当重要的步骤，对于一个大型软件，3个月到1年的外 部测试都是正常的，因为永远都会又不可预料的问题存在。 完成测试后，完成验收并完成最后的一些帮助文档，整体项目才算告一段落，当然日后少 不了升级，修补等等工作，只要不是想通过一锤子买卖骗钱，就要不停的跟踪软件的运营 状况并持续修补升级，知道这个软件被彻底淘汰为止。 写这些步骤算不上卖弄什么，因为实话讲我手边是一本《软件工程》，在大学里这是计算机专业的必修课程，但是我知道很多程序员似乎从来都只是热衷于什么《30天精通VC》之类的，他们有些和我一样游击队出身，没有正规学过这个专业，还有一些则早就在混够学 分后就把这些真正有用的东西还给了老师。 网上现在也很浮躁，一些coding fans乱嚷嚷，混淆视听，实际上真正的技术专家很少在网上乱发帖子的，如笔者这样不知天高地厚的，其实实在是算不上什么高手，只不过看不惯这种对技术，对程序员的误解和胡说，只好挺身而出，做拨乱反正之言，也希望那些还 沉迷于一些错误人士的coding fans们能认真想想，走到正途上，毕竟那些聪明的头脑还 远远没有发挥应有的价值。
㈧ 当作为一个初级程序员，自己的业务能力不够的时候怎么办有些功能业务实现不了怎么办
你只能继续深造加强学习，因为你刚参加工作经验比较少，学的东西和实际结合不进去慢慢的来别着急，多和有经验的交流，就会改变你现有的壮况。
㈨ 程序员的java功能的实现不知道怎么动手，没有思路，怎么办
多写一些算法题，写熟了就好了，理清思路，知道自己要做什么，有时候不知道怎么做，你可以选择反推，从后往前延伸，建议还是多做算法题，可以锻炼编程能力
㈩ 程序员如何提高自己的编程技巧
可读性：函数命名随意，实现逻辑混乱，代码格式不统一。。。
可靠性：程序运行很难稳定，bug百出。。。
维护性：代码逻辑没有层次，混成一团，很难维护改进
移植性、重用性：许多人写的代码，只能各自使用，很少有能共享的功能性代码
高效性：很少从算法、资源占用、执行效率等角度去考虑，经常导致服务器负载过重
那么我们改进时，就可以从以上几点出发。
总结了一下自己以前的经验，主要有以下几点：
提高自己的程序语言基础。对于许多新手程序员来说，只是简单的学会了该语言，知道一些简单的用法。但是实际编程的时候，许多写法、用法不标准。举一个很常见的例子：许多人刚刚学c++,java等面向对象编程的语言时，虽然知道了类、知道了类一般都有“多态”的特性，但是他们还是经常会用“类型判断”去判断某个对象是属于哪个类的实例、然后强制转换、再调用方法。却完全忽略可以用多态来避免这种丑陋的实现！
熟悉语言规范。如果不知道自己所学的语言还有规范，那么建议你现在去查找。说个简单的规范，Java的类名要取得有意义、首字母要大写。再比如：一个函数只实现一个功能。再比如一个复杂的：连续的if else条件判断最好不要超过10个。
培养自己严谨的逻辑思维能力。我们写程序，至少都会在脑海里走一遍程序的流程。如果流程走通最后却出现bug，那么就是流程的某个细节我们没有考虑到！有的时候，我们总是自认为自己已经考虑的非常全面了，其实不然。同样举一个例子：对一个集合，写个for循环按照一定的条件删除里面的元素。其实这里面隐藏了一个“集合在动态变化”的陷阱。比如说，将第一个元素删除了，如果集合的数据结构是将第二个元素移动到第一个元素上，那么，第二个元素就遍历不到了。所以，有时候，我们看似很简单，觉得逻辑非常正确的代码，可能就潜伏着陷阱。
熟悉所用语言的API。学一门语言，其实不只是学语法，学语义。更重要的是学基本的API类库。因为你实际编程的时候，自己所写的代码其实很少，大部分都是用的别人的API，将许多API的功能穿起来，才是自己实现的功能。用好的API，能增加代码质量、提高代码可读性、减少代码bug、减少工作量。就比如说堆栈这个数据结构，程序员基本都知道，但是大部分人可能都不能实现一个正确的堆栈API。
熟悉了解一些数据结构、算法。平常写程序时，或多或少都要接触一些常用的数据结构，比如说链表、map等，了解它们的原理对于那些没学过数据结构的人来说很重要。很多时候，一个简单的功能被实现的超级复杂的原因就是没有使用简单清晰的数据结构。
掌握一些编程思想、设计模式，这会让你的代码更加具有结构性、条理更加清晰！比如说，面向接口的编程思想，能让你的代码易于修改、易于扩展。如果更进一步，站在架构的角度去考虑。
多看高手代码，读一些优秀的开源代码，看一些经典的书籍。比如说《Effective C++》、《Effective Java》、lucene的源码。这些会让你提升巨大，只有了解到高手眼中的世界，才能有成为高手的可能！
代码重构。多回顾之前写的代码，进行一个系统性的整理。因为我们起初开发，不是面面都能想到，许多新东西是不可避免的，这就意味着可能会导致一些逻辑混乱。在开发完成后，多回顾回顾，寻找能改进之处，这也是一种进步。
即时缺少高屋建瓴的能力，我们也应该多从全局的角度去考虑整个工程的代码的层次、模块、架构等问题点。可以尝试着进行功能点拆分、接口交互设计等工作。
为自己的代码添加测试用例。可能因为懒惰，许多程序员基本都不会为自己的代码添加测试用例，这其实是一个不好的习惯。即时是有测试人员的团队，添加测试用例对你的好处也是显而易见的。
至于从团队的角度，可以考虑建立以下几点：完整的规范、执行流程、review机制和辅助工具。由于本篇文章主要针对的是个人，就不展开。工具方面，可以考虑开源的ReviewBoard。
个人的代码质量提上来，团队的水平才能提上来，公司的效率才能提升。其实最主要的是，个人的层次、境界才能提升！