程序员英文打字速度多少程序员每天的代码量多大

打字速度还有代码量个人觉得只能说明一部分

首先打的多了自然会熟练 速度和量都会上去。

但是 这和代码质量是不能一概而论的

真正牛掰的程序员 你看他写了几行代码

实现同样的功能。你会看到他每一个变量的位置，每一行代码都是有思想的，

写出来的程序是饱满健壮的。

你阅读完了是会学到很多经验，能感受到程序的神奇。

当然 多敲 多思考是提升质量的必要条件

其他的还是要多总结，举一反三出来的东西才是经验。

希望能帮助到你

很难，尤其是对中国人

精通一门编程语言需要10-20年，而很多的编程语言本身设计的局限性比较大，或者过于复杂，导致学编程的人根本没法完全的掌握。

编程的难点，

1 英文字母，这个很致命，因为我们看中文是从小看，可以做到一目十行，但是看英文，我们的阅读水平明显下降。这样很影响我们对于代码的理解和编程速度。

2 标点符号的过分使用，英语对于标点的热爱远超中文，导致我们在编程中不得不频繁的切换。

3 思维逻辑的西方化，编程语言都是西方人设计的，所以思维逻辑上符合西方人的理解方式

中国人的思维逻辑和他们完全不同

4 编程语言普遍太老，目前的最流行的几十种编程语言的出生时间，最年轻的GO（谷歌的）也有10年了，设计思想，语言习惯等等，都有明显的时代特征，很多的设计理念，思想，语法结构都显得多余。

综上，编程语言本身的问题太多，导致了中国人学习起来困难。

同意楼上的说法。

盲打也不必学，你多写代码，久而久之就自然学会了。

其实程序员不是打字员。程序员的真正价值在于思考，而不是疯狂地敲击键盘。通常他们花在思考上的时间都比打字的多。你应该把注意力多放在编程本身。

一、先列三个常见的开发场景：

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%不相似，于是在公共函数里面简单写几个ifelse做个区隔就可以。没想到，越随着版本迭代，这些功能渐渐越变越不一样了，但是这个代码已经几经人手了，而且这是一个公共函数，谁也不知道牵扯多少，所以谁也不敢大改，发现问题了就加一个ifelse判断。

没想到啊没想到，这个本来当初公共的函数，现在变成了系统最大的毒瘤，最复杂的地方，谁也不敢动，除非实在万不得已，手起刀落。

所以，我平时告诫程序员，纯技术的、纯通用的，你们可以尝试搞搞抽象公共函数，对于业务的，你们还是简单粗暴的根据Leader们做的代码模板代码框架，乖乖的复制、修改、填肉吧。

你们啊，先从做模板做代码片段开始吧，咱们放到咱们内部代码片段开源库里，看谁的代码片段被别人复制的多，说明你的代码抽象设计能力越好了。那时候，我就大胆放心让你撒丫子跑了。在没有学会跑之前，给老子乖乖的复制、修改、填肉吧。

CSDN 编者按 Malcolm Gladwell在《离群索居》（ Outliers）一书中曾言 ，要真正掌握某件事情，需要10000小时的练习。 而本文作者Greg Bulmash拥有40多年的编程经验 ，写了10000个小时的代码，却没能成为一名高级程序员。 为何一万小时定律会失败呢他分享了自己的一些看法 。 或许他的经验能够对你有所帮助，一起来看看吧。

原文链接：

本文由CSDN翻译，转载需注明来源出处。

译者 | 章雨铭 责编 | 屠敏

出品 | CSDN（ID：CSDNnews）

Malcolm Gladwell在《离群索居》（ Outliers ）一书中说，要真正掌握某件事情，需要10000小时的练习。其实，10000只是一个粗略的数字，而且这句话的含义也被过度简化了。我已经断断续续进行了40多年的编程。可能已经写了10000个小时的代码，但我甚至还未能成为一个优秀的程序员，更别提成为大师级的程序员了。

我认为有以下几个原因。首先，在这10000小时中，我主要学习了4种不同的编程语言，以及其他一些辅助语言。我从一种语言换到另一种语言时，发现它们有的概念可以互通，有的完全不同。而有趣的是，在这种语言中没有意义的概念可能用来构建它。

例如，JavaScript没有本地链接列表实现，但如果在V8 GitHub库的src目录下搜索 "链表"，会发现有76个commit提到了它。即使它们在语言本身中没有用C的链接列表，但会在引擎下使用C的链接列表。

每种语言都有自己的语法和特殊的实现方式，这些是必须要学习的，而不仅仅只是学习其概念。一种语言的最佳实践方式对于另一种语言来说可能不是最好的。在编译语言上我从来没有花过很多时间，几乎总是使用解释型语言，如BASIC、PHP、JavaScript、Python。我学习过C#和Java，用Rust做过Hello World，但在Linux中从源码编译对我来说十分困难，所以我通常只是下载源码，按照教程中的指示 *** 作，然后祈祷代码能够运行。

除了学习这些语言，我还学习了服务器技术和系统架构的基本概念，不是从编程的角度，而是从网络管理员或者说系统管理员的角度。而且无论是建立一个大型网站，在Flash中创建矢量图并将其渲染成位图，还是学习通过AWS解决方案架构师助理认证，我都已经做了很多次。但是很多东西我已经忘记了。我已经学会了这些语言的框架和库，如JavaScript的React和JQuery以及PHP的Laravel然后也忘记了许多，因为我为完成一个项目学习了它们，然后就没有再使用它们。

即使写了10000小时的代码，也不意味着你能够轻易地在不同语言之间转换。当你真的进行转换的时候，你会发现10000小时没有那样神奇的魔力，因为另一个不可避免的原因：记忆衰退。正如我所说的，如果我停止使用一种语言，甚至只是停止使用它的一个功能一段时间，我就会像忘记 "高中西班牙语 "一样忘记它。我在高中时读完了西班牙语3级，在大学时考过了西班牙语4级，并获得了A。而现在，我可能只记得不到10%的内容。

例如，我几乎完全忘记了怎样使用常规动词连接过去式，更不用说不规则动词了。但是因为我以前练习的足够多，我知道自己的不足之处，所以我可能比刚开始学习的人更快地恢复以前的知识。但可能需要几个月的强化练习才能全部恢复。

十年前，我精通PHP，在一个定制的MVC框架中工作（由其他人创建），使用Doxygen来映射类的继承层次，并使用JQuery来构建前端的交互性。但我在7年前没用过PHP了，转而使用Node。现在，我需要花5分钟并且改正了一些语法错误，才在刚才提到的PHP副本中正确地写出一个Hello World。

去年12月时，我为freeCodeCamp的前端库认证建立了五个React项目，但在那之后，我就没有再编码React项目了。过去了两个月，当我开始准备面试的时候，我觉得我就像是React新手。如果我看到自己写的代码，能够很快理解。但是因为很多东西都只是我准备的辅助工具，很多我都忘光了，所以我需要回到文档中去开始一个新的React项目再开始工作。和新手相比，我只是走得更快。

这就是新手和已经入门了的区别。一万个小时可以让你成为一个小提琴大师。但是如果你每隔500小时就换一次乐器，并想要成为整个交响乐团的主角，那你不一定能够更胜一筹。所以为了强化和拓展你的技能，练习不仅要广泛，而且要持续。

10000小时是什么样的概念？是5年每周工作40小时，两年休息1周（假期、病假和休假都在这2周内）。你会发现有的工作招聘时要求在一个3年的框架内有5年的经验。5年似乎是成为专家所需的标准时间。因为对框架的无知和这种简化的标准，就会产生逻辑上的矛盾，一言以蔽之。

一个专业的开发人员，有多少的工作时间是花在电子邮件和会议上的？又有多少时间在真正编码和思考编码问题？当我在微软写文档的时候，我的经理说，不管怎么算，你一天中大概只有一半的时间花在实际的生产工作上。其余的时间会花在一些琐事上，比如回复电子邮件、开会、进度/状态报告、在IM上回答随机问题或者和别人闲聊

所以我只有20%的时间是在写代码，因为其他80%的时间是在写文档和教程，这意味着我平均每天只写了一个小时的代码。在使用浏览器中的开发工具进行调试方面，我曾经是个天才，因为我在这方面经验丰富，还经常为新版本进行更新。但是，虽然当时所有的开发控制台的快捷键，我都烂熟于心，但在我离开微软的7年后，我基本上已经把它们忘得一干二净了。

事实上，自从我进入开发人员关系部后，我每天花了10-20%的时间写代码，其余的时间写教程，为会议讲座和网络研讨会制作文件，制定建立和培养开发人员社区的战略，制定展示新功能的最佳方法，以及处理各种人——产品经理、内部工程师、外部开发人员、产品营销经理、需求生成和社交媒体经理、律师、公关和公司政策执行者的问题。

最后要记住的是，你不会花整整一万个小时学习新东西。如果你在学习小提琴，你可能会花上几百个小时来学习一些初级的作品。在你学习新东西之前，你已经掌握了一些初级的东西，并且在反复练习直至完美的过程中，

学到很多，并且将你学到的这些用于学习新事物。所以这一万个小时中的大部分时间都是强化的。

在编程中，这就像多次编写相同的To Do单页应用程序。前几次你可以参考教程，但最终你必须能够在没有任何参考的情况下写出它。这就像一边看着乐谱一边慢慢演奏《欢乐颂》，然后记住如何演奏，然后准备在演奏会上演奏。

但是，当你需要在截止日期前交付一个项目时，你有多长时间来进行强化练习？在许多公司，不会给你提供扩展技能和强化编码的时间，需要你利用额外的时间来完成。一些公司会给你10%的时间或20%的时间来做独立的项目，但很少有公司希望你把这些时间花在单纯的练习上。

新的框架、新的最佳实践方法、新的语言、新的模式产生的速度不断加快，在这种情况下，仅仅是在新的方面取得合格的成绩，都会像和职业选手一样演奏《欢乐颂》的困难。

你需要平衡强化和 探索 的时间，特别是当你每天编码的时间少于50%的时候。你必须不断地通过练习来进行强化，建立心理肌肉记忆，直到你能在睡梦中解决它们。小提琴几百年来都没有实质性的变化，但编程却在不断变化。成为一个特定语言的大师级程序员意味着要坚持更长的时间。你不得不在非工作时间进行强化练习，完成任务，努力成为一个优秀的程序员，或者跳槽到另一个能够给你充足时间练习的公司。

哪怕你5年或者10年后都没有成为大师级的程序员，也没有关系，因为好好地做一万个小时比看起来更难完成。

以上就是关于程序员英文打字速度多少程序员每天的代码量多大全部的内容，包括:程序员英文打字速度多少程序员每天的代码量多大、编写程序很难吗、学c++怎么训练代码输入速度等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！