如何让程序代码自我改善

A. 程序员如何提高自己的编程技巧

可读性：函数命名随意，实现逻辑混乱，代码格式不统一。。。
可靠性：程序运行很难稳定，bug百出。。。
维护性：代码逻辑没有层次，混成一团，很难维护改进
移植性、重用性：许多人写的代码，只能各自使用，很少有能共享的功能性代码
高效性：很少从算法、资源占用、执行效率等角度去考虑，经常导致服务器负载过重
那么我们改进时，就可以从以上几点出发。
总结了一下自己以前的经验，主要有以下几点：
提高自己的程序语言基础。对于许多新手程序员来说，只是简单的学会了该语言，知道一些简单的用法。但是实际编程的时候，许多写法、用法不标准。举一个很常见的例子：许多人刚刚学c++,java等面向对象编程的语言时，虽然知道了类、知道了类一般都有“多态”的特性，但是他们还是经常会用“类型判断”去判断某个对象是属于哪个类的实例、然后强制转换、再调用方法。却完全忽略可以用多态来避免这种丑陋的实现！
熟悉语言规范。如果不知道自己所学的语言还有规范，那么建议你现在去查找。说个简单的规范，Java的类名要取得有意义、首字母要大写。再比如：一个函数只实现一个功能。再比如一个复杂的：连续的if else条件判断最好不要超过10个。
培养自己严谨的逻辑思维能力。我们写程序，至少都会在脑海里走一遍程序的流程。如果流程走通最后却出现bug，那么就是流程的某个细节我们没有考虑到！有的时候，我们总是自认为自己已经考虑的非常全面了，其实不然。同样举一个例子：对一个集合，写个for循环按照一定的条件删除里面的元素。其实这里面隐藏了一个“集合在动态变化”的陷阱。比如说，将第一个元素删除了，如果集合的数据结构是将第二个元素移动到第一个元素上，那么，第二个元素就遍历不到了。所以，有时候，我们看似很简单，觉得逻辑非常正确的代码，可能就潜伏着陷阱。
熟悉所用语言的API。学一门语言，其实不只是学语法，学语义。更重要的是学基本的API类库。因为你实际编程的时候，自己所写的代码其实很少，大部分都是用的别人的API，将许多API的功能穿起来，才是自己实现的功能。用好的API，能增加代码质量、提高代码可读性、减少代码bug、减少工作量。就比如说堆栈这个数据结构，程序员基本都知道，但是大部分人可能都不能实现一个正确的堆栈API。
熟悉了解一些数据结构、算法。平常写程序时，或多或少都要接触一些常用的数据结构，比如说链表、map等，了解它们的原理对于那些没学过数据结构的人来说很重要。很多时候，一个简单的功能被实现的超级复杂的原因就是没有使用简单清晰的数据结构。
掌握一些编程思想、设计模式，这会让你的代码更加具有结构性、条理更加清晰！比如说，面向接口的编程思想，能让你的代码易于修改、易于扩展。如果更进一步，站在架构的角度去考虑。
多看高手代码，读一些优秀的开源代码，看一些经典的书籍。比如说《Effective C++》、《Effective Java》、lucene的源码。这些会让你提升巨大，只有了解到高手眼中的世界，才能有成为高手的可能！
代码重构。多回顾之前写的代码，进行一个系统性的整理。因为我们起初开发，不是面面都能想到，许多新东西是不可避免的，这就意味着可能会导致一些逻辑混乱。在开发完成后，多回顾回顾，寻找能改进之处，这也是一种进步。
即时缺少高屋建瓴的能力，我们也应该多从全局的角度去考虑整个工程的代码的层次、模块、架构等问题点。可以尝试着进行功能点拆分、接口交互设计等工作。
为自己的代码添加测试用例。可能因为懒惰，许多程序员基本都不会为自己的代码添加测试用例，这其实是一个不好的习惯。即时是有测试人员的团队，添加测试用例对你的好处也是显而易见的。
至于从团队的角度，可以考虑建立以下几点：完整的规范、执行流程、review机制和辅助工具。由于本篇文章主要针对的是个人，就不展开。工具方面，可以考虑开源的ReviewBoard。
个人的代码质量提上来，团队的水平才能提上来，公司的效率才能提升。其实最主要的是，个人的层次、境界才能提升！

B. 作为一名普通的程序员，需要怎么给自己找一条后路呢

作为一名程序员，在未来可能会面临技术淘汰、公司倒闭、经济不景气等风险。因此，找到一条后路是非常必要的。

以下是一些可以帮助程序员找到后路的建议：

1.不断学习新技能：随着技术的不断发展，新技能的学习变得非常重要。程序员应该不断关注行业的动态，并且学习新的编程语言、开发工具和技术。

2.建立广泛的人脉：建立广泛的人脉可以帮助程序员在职场上更好地生存。这些人脉可以包括同事、老板、行业专家和其他程序员。

3.做好个人品牌建设：通过博客、社交媒体和GitHub等平台，程孝祥序员可以建立自己的个人品牌，提高自己的知名度和可见祥凯度。这可以帮助程序员在找工作或者自主创业时更有优势。

4.考虑转行：如果程序员发现自己的技能在行业中逐渐被淘汰，或者自己的工作面临很大风巧宴搏险，那么可以考虑转行到其他领域。这需要程序员具备开放的心态和勇气，但也可能会开启一条新的、更有前途的职业道路。

综上所述，作为一名程序员，需要不断学习新技能、建立广泛的人脉，做好个人品牌建设，不行就要提前考虑转行。

C. Java程序员如何自我提升

1.专注于一个工作，对于程序员来讲，专注于某一个开发工作是非常重要的，如果同时处理几个任务，你只会为此耗费精力，这样只会导致工作效率降低，所以作为java开发应该专心做好一个工作，再去做下一个。
2.建立条理工作系统，对于程序员来讲，工作如果没有条理，那将是多么可怕的一件事，会直接影响工作效率。一名优秀的程序员一旦投入工作当中，他们会变得非常专注和条理。
3.不要使用过多工具，在开发工作过程当中，编程工具肯定会用到，但如果使用过多，只会起到适得其反的效果。
4.要迅速做出判断，作为java程序员要果断做出抉择，不然真的会影响到工作效率。
5.学会发现和解决问题，可以这样说，问题是好的学习机会，只有在工作当中不断发现、分析和解决问题，才可以成为公司真正的骨干，同时也更快成长。从入门到高手这一过程，这一阶段对个人成长是很有帮助的。
6.经常思考总结，古人云：”学而不思则罔“，只学习不思考会导致难以把握事情的本质，这样的学习过程可以更好地版主自己清楚地了解工作进度，减少压力和提高工作表现。

D. java程序员如何提高自己技术能力呢

一个java程序员不思进取，那么等待他的就只有淘汰。时代在进步，java更是在不断地发展，一个java程序员必须不断的提高自己各个方面的能力，才能更得上时代的进步，java的发展，保持自己的核心竞争力。那么沙河计算机学校介绍java程序员如何提高自慧消段己技术能力呢?

1.规范java代码编写

一个java程序员是离不开代码的，代码就是他最好的伙伴。代码前誉是有自己编写规范的，作为java程序员你不断要遵守，并且还得有意识的规范自己编写代码，一旦养成良好的习惯，这会让你受益良多。

比如，现在好多公司会要求你在编写代码时严格按照规范来，对java代码内注释格式、Java代码的变量命名等等都有严格的规定，这样不仅利于程序员之间的交流协助，还方便修改跟移植java代码。

2.练习编写文档

作为一个java程序员，你总是希望每次上级安排给你的任务，都配有相应的文档，这样你会省去很多的功夫。其实，这种想法在一定程桥氏度上限制着你的发展。

你要知道，一个高级的java程序员每天至少会花上30%的时间来写技术文档。这也是你不管从事多久的java行业，却依然还是个初级java程序员的重大因素，所以，多多练习编写文档吧，这对你未来的发展会有莫大的好处。

3.测试常践行

一个java程序员如果觉得把自己编写的程序交上去，自己完全不需要测试，然后会有专职的程序测试员会进行相应的测试，然后测出问题自己再去解决。那么这种思想也是存在误差的。

你要知道防微杜渐，而不是在问题出来以后你再解决，你应该在你编写的每段代码，每个子模块完成后进行认真的测试，有问题及时解决，这会为后面省下好多的功夫，大大提升效益，也不会到时候有特别重大的失误。

E. 如何提升程序员的代码编写能力

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

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们做的代码模板代码框架，乖乖的复制、修改、填肉吧。

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

F. 如何提升程序员的代码编写能力

在我身边的程序员中，无论是现在的同事还是过去的同事，普遍缺乏文档编写能力或能力严重不足，甚至有些编程能力很强的程序员也不能写出一篇可读性较强的设计说明书、产品手册等项目必备文档。其实，文档编写能力是成为优秀程序员和项目经理必须具备的能力，想要和更多人人进行交流只能通过你的文字来传达你的思想。该如何才能提高文档编写能力呢，可以采用了以下几种方法，只要坚持不懈的做下去，相信会有提高。 1、尝试编写个人简历和经历，用文字来认识自己是不错的方法。要想别人认识你，首先自己要认识自己。 2、养成良好的程序注释习惯，而且要用准确的语句描述注释的内容，从写注释的一句话开始锻炼文字表达能力。准确而简明的注释有助本人和他人阅读你的程序代码，语义不清或者错误的注释反而浪费了自己和他人的时间。 3、从编写较简单的文档（如：《XXX系统使用说明》）开始，锻炼文档编写的组织能力和文字表达能力 4、写博客。其实这也是我写博客的原因之一，想通过多写文章，用文字来准确的表达日常自己的所思所想来提高文档能力。还可以通过他人的评论和建议来改正不足之处。 6、阅读一些写作技巧方面的文章提升技术文档编写能力也是显而易见的。 当然，要切实提高文档编写能力，需要勤于学习、勤于思考、勤于实践、长期积累，毕竟丰富知识和阅历才是写好文档的基础。