很容易写出烂代码，但即使写成一坨狗屎，也是可用的。你同意这个观点吗？刚入行的程序员经常会听到一些意见，你应该关注需求文档/功能设计/架构设计/理解原则（ABCD）。写代码只是把想法翻译成编程语言，是个没什么技术含量的事情。当时听到这个观点，会有一种近乎冷漠的不屑：你们是一群不明白代码质量重要性的蠢货。再这样下去，迟早要踩坑的。但是过了几个月，他们好像也没怎么踩坑。而且随着编程技术的不断发展，越来越多的我原以为是傻子的人加入了程序员这个行业。语言越来越高级，包装越来越完善。各种技术正在帮助程序员提高生产代码的效率。靠着层层封装，程序员真的不需要懂一点点技术细节，只要把需求里的内容慢慢翻译就可以了。很多程序员不知道如何组织代码，如何提高运行效率，不知道底层的原理是什么。他们写的是我脑子里烂成一堆狗屎的代码。但是那段狗屎代码工作正常。虽然我觉得他们写的代码很狗血，但是站在不接触代码的人（比如你老板）的角度来看，代码已经编译，测试，运行了一个月没有任何问题。你还想要什么？所以，即使你心有不甘，你也必须承认，别人写的代码能正常运行，没有错误，那是牛逼。糟糕的代码就是糟糕的代码，但有几次编写糟糕代码的人离开了，事情似乎又发生了变化。当我想修改功能的时候，发现程序里满是看不懂的逻辑。修改后莫名其妙的bug接连出现。接手项目的人开始漫无目的地加班。我开始喜欢跟别人的祖先打招呼了。总结几类经常被骂的烂代码：?意思不明、能力差的程序员，往往写出意思不明的代码，自己也不知道自己在干什么。就像这样：voidSave(void){intx;for(x=0;x<100;x++){//防止保存失败，保存100Flash_Write();}}对于这种程序员，我一般建议他们切换事业。?不会说人类语言是新手最常遇到的问题。直接表现就是自己写了很简单的代码，别人却看不懂。比如下面这段话：很多程序员喜欢简单的东西：简单的函数名，简单的变量名，只用几个词在代码中一遍又一遍地命名；可以缩写，可以省略，可以合并则合并。这类人写的代码里全是g/s/gos/of/mss之类的世界上没人看得懂的缩写，或者一长串不知道自己在干什么的连续调用。也有很多程序员喜欢复杂，各种宏定义，位运算等炒作，生怕别人一下子看懂了代码，会显得自己水平不够。简单来说，他们的代码是写给机器看的，不是给人看的。?组织不当组织不当是高级的坏代码。写了一些代码之后，程序员有了基本的代码风格，但是对更大的项目没有足够的把握，不知道如何解决代码。耦合、分层和组织。这种反模式的现象是，在项目中经常看到一段代码被抄袭、抄袭；一大堆代码放在一个文件里；一个函数有数百或数千行；或者一个简单的函数，他一圈又一圈地调整了几十个函数，在一个很难找到的小角落默默地调用了一些关键逻辑。这类代码大多比较复杂，难以修改，经常一改就崩溃；另一方面，创建这些代码的人倾向于修改代码并且害怕创建代码。他们宁愿把原来复杂的代码一步步做出来，并且不愿意重新组织代码。当你面对一个几千行的类，问你为什么不提取XX的逻辑时，他们会说：“但是，那又多了一个类。”?假设和缺乏抽象相比前面的例子，假设这个反模式出现的频率更高，花样更多，作案者更难自己意识到问题。例如：当文件路径改变时，代码会变成这样：当加载的内容更丰富时，又会变成这样：后面可能又变成这样：这种程序员往往是最多的项目组中高效的开发人员高大上的人，但是大量的业务开发工作让他们无法做多余的思考。他们的口头禅是：“我每天都得做XX需求”或者“先把需求做完再考虑其他的”。这种反模式的后果往往是代码难以重用。当面临deadline时，程序员急于将需求落实到代码中，这往往是一个循环：写代码的时候没有时间考虑重用，代码很难重用，导致需要继续写将来有很多代码。大量的代码一点一点积累，带来了组织和风格一致性等问题，最终形成了新功能基本靠抄袭的遗留系统。?还有吗？坏代码有很多种，沿着功能-性能-可读-可测试-可扩展的路线，你可以看到很多不可思议的例子。那么什么是坏代码呢？个人认为糟糕的代码包括几个层次：?如果只是一个人维护的代码，满足功能和性能要求就足够了。?如果在团队中工作，必须易于理解和测试，允许其他人修改自己的代码。同时，代码越靠近系统底层，可扩展性越重要。因此，当团队中底层代码难以阅读，耦合上层逻辑，难以测试，或者对使用场景做太多假设，难以复用，即使功能是完成了，还是一堆狗屎一样的代码。?足够的代码相反，如果一个项目的代码难以阅读，是否可以说这是糟糕的代码？很难定义，可能不是很好，但它很糟糕吗？如果这个项目从头到尾只有一个人维护，而且那个人维护的很好，那么看起来就是“代码够用”了。一开始，很多项目可能只是一个人负责的小项目。大家关心的重点是代码能否顺利实现功能，按时完成项目。过了一段时间，其他人参与的时候，发现代码有问题，看不懂，也不敢动。需求方又催促上线，怎么办？不得不小心只改逻辑不改结构，然后在注释里写这样的实现很丑，理解了内部逻辑后再重构。过了一段时间，我也有类似的需求，想复用里面的逻辑。才发现原来代码针对各种具体场景都有专门的逻辑，复用很麻烦。为了赶进度，只好抄代码改了。问题解决了，问题翻倍了。几乎所有糟糕的代码都是从“足够的代码”演变而来的。代码没变，只是代码的使用场景变了。如果原来的好代码不符合新的场景，那么就变成了坏代码。重构不是万能的程序员喜欢对程序员撒的谎之一是：现在工期比较紧，X个月后项目工期会松一些再重构。不可否认，重构是在某些（极其有限的）场景下解决问题的手段之一，但写了很多代码后发现，重构往往是程序开发过程中最复杂的工作。花费一个月编写的错误代码将需要更长的时间和更高的风险来重构。经历过几次难以忍受的大规模重构。每次重构前，我都找群里的高手，开了无数次分析会，把群里所有的需求都悬起来了才敢开工。嚎叫无处不在，几乎每天都会出现很多意想不到的问题，上线几乎肯定会出好几个问题。从技术上讲，重构复杂代码时，要做三件事：理解旧代码、分解旧代码、构建新代码。然而，要重构的旧代码往往难以理解；模块之间过度耦合会牵一发而动全身，影响范围难以控制；旧代码不易测试，因此无法保证新代码的正确性。重构后能提高多少效率？可以降低多少风险？很难回答，糟糕的代码本身并不是可以轻易标准化的东西。综上所述，不写代码的人认为应该重构。重构很简单，无论是新人还是老手，都有责任去做重构。资深编码员认为他们迟早应该重构。重构很难，现在好了。不要让这件事落在我身上。写代码的新手庆幸没有bug，不知道怎么重构。☉写好代码难，写不好代码难。写出好的代码有很多先决条件：?了解要开发的功能需求。?了解程序的运作方式。?进行合理的抽象。?组织复杂的逻辑。?正确估计自己的开发效率。?持续练习。写出好的代码有很多方法论，但我认为写出好的代码的核心是听起来很low的“持续练习”。很多程序员写了几年代码也没有多大进步，代码还是烂到让人不忍直视。主要有两个原因：1.环境是最重要的因素之一。很难理解什么是好的代码，大多数知道的人都会选择跟风。2、还有个人性格等主观因素，看不清楚，不清楚。写出烂代码的程序员其实都是容易相处的人。工作几年的人很难说服他们提高代码质量。你只会反复听到：“那有什么用？”或“以前就是这样做的？”那么招聘的时候要从源头着手，提高代码质量如何呢？前段时间面试的时候，我发现一个现象：一个人工作几年，做过很多项目，带过一个团队，发表过一些文章，并不一定代表他写的代码好；相反，一个代码写得好的人，其他能力一般不会太差。悲观的结论说了这么多，其实只有两个结论。作为程序员：?不要指望别人写出高质量的代码?不要以为自己写的就是高质量的代码
