Ⅰ net程序员怎么提升自己的技术能力
一、先列三个常见的开发场景：
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们做的代码模板代码框架，乖乖的复制、修改、填肉吧。
你们啊，先从做模板做代码片段开始吧，咱们放到咱们内部代码片段开源库里，看谁的代码片段被别人复制的多，说明你的代码抽象设计能力越好了。那时候，我就大胆放心让你撒丫子跑了。在没有学会跑之前，给老子乖乖的复制、修改、填肉吧。
Ⅱ 开源如何提升编程技能
开源是很多程序员都会面临的问题，很多人会相信接触的开源源技术越多对自己的编程技术提升越快，写出来的代码也更好。开源可提高编程技能之间有什么相关性或因果关系吗？
阅读代码能让你变得更优秀
我在编程生涯的早期就明白我阅读的代码越多，我的代码就能变得更好。我知道，当我不得不维护其他人的代码时，简单和干净的代码几乎总是比花哨或复杂的代码好——即使有注释。然而另一方面，当我花足够的时间去理解复杂代码的时候，我常常能够学到新的技巧。不论怎么样，都能让我有所提高。
这使得我在那些没有代码审查的地方一再争取。而当没有足够的时间来正式执行“代码审查”的时候，我会自己浏览存储库和阅读代码。当然，那时我还被受限于来自于小团队的公司资源。
超越语法
在你不得不全力对付任意编程语言的语法时，也就是学习如何充分利用该语言最琐碎的时刻。一门语言的语法往往是非常静态的，并且如果你出错了，你的编译器会向你控诉。更深层次的课程涉及到什么语言最适合解决什么样的问题（“合适的工具做合适的工作”），以及如何用那种语言编写代码以便于使它高效和可维护。
学习新语言有许多方法：课程，教程，导师，书籍以及等等。我通常会结合这些选项来学习一门新的语言。我注意到，当涉及到非语法元素的时候，这些方法常常非常相似。
阅读来自于其他人的实际部署代码会让你收获更多。不仅仅是常规的结构化学习，你还需要学习模式和实践方法。语言中所谓“正确”的做事方式并不总是效果最佳的方式。你会经历边缘情况，一次性事务以及意想不到的集成。你也会找到这些问题的解决方案，有好有坏，但如果你认真思考的话，那么这正是出来“推荐做法”的地方。今天的模式就是明天的反面模式。
你可能对有些事情，例如“总是注释”，“逗号放到最后”，“缩进x个空格”有着自己的想法，当然你是对的。我对提到的这些及编码的其他方面也有着自己的感受。
有时候当我阅读其他人的代码时，如果看到他们做错了，我会生气。但是随着我代码阅读量的增加，我开始懂得，总会有一些情形常见于别人的代码，但我在我自己的代码中却未曾遇到过的，并且我的方法没有必要那样执拗。我不仅改变了我的一些观点，而且懂得更加灵活。
开源无处不在
随着开源运动的发展，可供阅读和学习的代码数量也大幅度增长。例如Gitlab，GitHub和到BitBucket这些网站就允许我们获取全功能的应用程序，不仅可以阅读代码，还可以摆弄。很少有我想要学习的东西是不能在开源代码中获取的。
我以前学习新的编程语言，会把重点放在诸如目录结构和命名约定这些简单的事情上。但是，现在，我会找一些不同的开源项目，然后可以开始拼凑常用的方法。我很少强调以前那些类型的东西了。
可用的代码是如此之多，但质量却良莠不齐。当我们想要学习的时候，常常搞不清楚哪个好哪个不好。那就保持阅读代码吧，慢慢地你会学会如何区分。阅读“坏”的代码可以帮助你理解为什么它是“坏”的。关键是不要害怕尝试任何你觉得看上去正确的东西，并且当你走错路的时候能够承认错误，并改正问题，然后继续前行。
坏的代码就坏的，是这样的吗？
有人会说“坏的代码比好的代码要更多更明显”。sub-reddit致力于坏的代码。
在这些年里，我写了很多好的代码和坏的代码。当我看到我以前写的代码时，我的第一想法就是我怎么会写这样的垃圾代码。这实际上意味着我还在学习中。如果我看到我以前的代码，觉得它看上去非常伟大，那么说明我并没有提高。
那么，我们怎么才能从坏的代码中学到东西呢？
你阅读的坏代码越多，那么你就越擅长发现坏的代码
当你在学习和搜索例子的时候，你会发现和使用大量不能工作的代码。请记住，仅仅因为它不适合你的情况，并不能说明它就是坏的代码。学习如何让它工作能够使得你变得更优秀。
你怎么知道它是坏的代码？
人们喜欢批评。阅读评论，如果你看到很多“WTF（什么玩意）”，那么可能你看到的正是坏的代码，试着指出为什么不好的原因。不要只留下“这代码真烂”这样的评论。不要装得你好像懂得坏代码的所有需求，要知道，总有一个它之所以被这样写的正当理由。如果你知道它为什么是坏代码的原因，那么不妨留下一个有建设性的评论。或者??
让它变成好的代码
放一个能让代码变得更好的pull请求。修正语法，使用更好的方法，添加注释或修改缩进：这些都是改进代码的伟大方式。加一个为什么你推荐改变代码的解释。
昆明北大青鸟java培训专家认认为，当我帮助别人学习的时候能学到更多。如果我认为我理解了一个新的主题，那么我会找个人来试着向他解释，这能让我更深刻地理解和记住它，并且让我快速发现我是否写了坏的代码。
回报
记住开放源代码在你参与进去的时候效果最佳。代码更改在大多数项目中都是受欢迎的，但是有很多出力的方法。
测试开源代码和文件错误报告；帮助完成文档集；写教程和如何做的例子；参加对话——或者仅仅只是帮助传播。每一件事都能带来改变，并且越多的人参与进来越好！