大厂程序员编程遇到的坑，真让人防不胜防（中级篇）

1.方案不论证，直接使用

 

 

遇到一个问题时，以自己的思路找出一个解决方案，接下来直接去实现他。并不会去考虑该方案的实现效率和实现危机。方案本身看似没有问题，但是在最初只是为了解决该问题，从问题本身衍生出的扩展逻辑，其实你并没有很好的关注到。作为专业的程序员，你的职责不是找出问题的一个解决方案，而是找出问题的最简单的解决方案。我所说的“简单的解决方案”是指这个解决方案必须是准确的，性能足够好，还要易扩展、易理解和易维护。

 

 

2.从不愿意花时间搜索问题

 

 

很多情况下，搜索自己遇到的问题，是可以很容易找到最优解的，你的问题在别人那里可能已经被解决，并提出了各种各样的解决方案，这个方案可能比你理解的更全面，更彻底。因此，在遇到问题的情况下，首先百度一下，也是一种很不错的解决问题方式。但是，这里的误区在于，你直接copy别人的代码，而不去思考为什么这样写的情况，可能会导致你只会成为一个问题的搬运工。对你的成长并没有什么好处。

 

3.从不重构代码

 

 

从学习编程的第一节课，就会遇到一个标准的编程思想：高内聚和低耦合。这个思想不仅仅是编程的核心，也是整个编程生涯中，最重要的一句话。在一个应用中，一个功能应该只在一个地方处理，这通常就是一个对象的职责，这个对象应该只向其他需要用到它的对象暴露必须的接口。这无关乎机密，而是为了降低一个应用中的不同部分之间的相互依赖。敏捷开发过程中，效率带来的，往往无法兼顾这样的问题。因此，后续带来的就是所谓的重构代码问题。因此，问题的关键在于，从一开始就要以高内聚和低耦合的思维去编程，而不是为了省事事后重构，业务的复杂性加上“骑驴找驴”的线上特性，使得重构难度将大大的增加。

 

4.做一些多余的计划方案

 

 

解决问题时设计的方案，可能会多方面的去考虑实现的稳定性，可读性，以及后续的业务扩展，但是这样就会有多余的“万一”场景出现在你的代码里，这样做会大大的降低业务开发的效率。在这里，针对这一点，要强烈的提出一点，任何代码的实现都是以业务驱动的。离开了业务形态，你的代码就没有任何用处。过多的兼顾只会降低代码的性能，大大增加了业务的复杂性。这样的形式在开发中是绝对不可取的。

 

 

5.精通算法，并不等于自己编程能力强

 

 

面试的过程通常要经过所谓的算法关，利用算法去实现各种各样的高性能的最优解。但是这些算法在现实中并不一定会用到，大部分情况下，都是简单的逻辑去处理复杂的事情，毕竟从可读性上来讲，性能并不一定到达最优解的情况，一般只需要次优解即可。而通过各种高大上的算法去解决问题的情况，会使得代码的维护和可读性的难度大大的增加。因此，判定自己的编程能力的高低，是自己的代码具有很高的可维护性，可读性，和稳定性。

 

 

6.代码的实现要符合既定的逻辑

 

 

代码管理是一项很重要的内容，从最基本的代码格式，到文件命名，再到文件包分类，最终的配置文件分离都是编程过程中，特别需要注意的点。需要经常更新的值，就放在配置文件中，BO层文件，就放到BO文件夹里，这样一目了然的文件目录，会让你的代码风格变得更加可控。在合作开发中，你的代码将更加符合别人的阅读习惯。

7.大量的代码注释

 

 

为了别人读懂你的代码，而过多的增加注释，这种方式是绝对不可取的。最好的代码可读性是一目了然的，通过函数名去给与代码天然的注释，而不是依靠自己的注释去告诉大家这段代码实现的意义。由于对于显而易见的代码，更不要去增加多余的注释，这样反而会吸引人的目光，降低读写的效率。

 

 

8.代码没有测试

自我测试是一个很好的过程，你写过的每一个代码，为了保证能够主流程的通畅，自测的过程是必不可少的。不要觉得这件事麻烦，在自测的同时，也是代码稳定性的一种验证，可能在细节处理上很难发现的坑，在测试过程中就会体现。如果你是一个新手，代码的自测环节将会是你最基础的一个步骤。