本文主要是介绍代码之丑 & 10x程序员工作法 心得，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

代码之丑（2022.1.28）

      前段时间收听了极客时间里名为“代码之丑”的专栏，结合自身情况，总结了自己的想法。
      我知道妄想通过一则专栏就彻底避免“丑代码”是不切实际的，但是留存在脑海中的印象总会在写到“丑代码”时蹦出来，一次两次三次，总有一天会养成习惯，我需要的不是立刻将所有丑代码牢记于心，而是总结自己的体会，在之后写代码时，能意识到自己写了丑代码，及时更改就可以了。

1、命名

      代码之丑的开篇就是介绍代码命名中的“丑”，原文令我印象深刻的点是：取名要考虑动词名词的结合，某些情况下，对于多个同义词，要挑选语义最贴切的英文单词。
      我的英文水平是短板，在工作中，遇到翻译的问题，都是使用翻译工具，遇到多个同义词的情况，会选择最好看，最顺眼的单词，同时对方法的取名，完全没有考虑过动词+名词的这种组合，在工作中，也曾有同事对我命名的类提出过疑问，但同事没有深究，我也就没有反思，而这二者恰恰是原文作者指出的“丑代码”。
      在读完前两章后，我有意识的在编写工作代码时对命名进行了思考，同时对之前写的老代码进行了命名的检查，发现了很多的问题。
      我的代码中，存在：命名不够简洁明了（存在超长名字）、命名不够准确（使用了定义非常宽泛的词语）、命名存在语法错误（动词名词完全没有深究过，有些名字完全是chnglish，实际理解起来非常奇怪），这是我需要改进的点，且不只是类名、方法名，在参数的取名上，也要保证简洁、意思清晰、力求不存在语法或拼写的错误。

2、大类

      在阅读公司之前的老代码时，我发现公司原先就存在很多的大类，包括后续同事创建的类，也存在很多的大类，但他们建立的大类其实是一种伪大类，比如建立一个实体类时，如果一个参数需要抽出一个新的实体类来定义，有些同事会选择直接在当前实体类中建立一个内部类，但这样就会造成当前实体类非常的“大”，在lombok注解省去了所有get、set方法的情况下，依旧需要向下划动屏幕才能看完整个实体类，我认为这也是一种“丑代码”，对于这种情况，我认为应该严格的将类区分开来，即使存在包含的情况，也不要写到同一个实体类中，我有犯过这种错误，之后会牢记这点，在以后的代码生涯中避免。

3、长函数、长参数列表

      原作者提出过一个问题，多长的代码算长代码？我自己没有答案，我写代码，向来只考虑完成需求，有时几十上百行的代码反而会让我在敲完最后一个字符时有一种成就感，但是回想从前，维护这样的代码确实是一件头疼的事。
      当一段时间后，新需求来临，也许我自己回头读这段代码都会有些力不从心，更别提看我代码的同事，原文作者给出一个指标，20行代码，意思是任何需求，在20行内完成，多余的代码要么抽取函数，要么想办法简化，作者有一句话令我印象深刻，当我们对长代码的容忍度过高，相应的很多丑代码我们也就不会觉得是丑代码，而当我们对代码的行数有了一个硬性的规定，也许在我们简化代码的同时，就会发现自己写的丑代码，这是我自己需要注意的点，我觉得作者提出的20行，就是一个很好的规定，今后我一定遵守。
      对于长参数，我自认为做的还不错，封装Dto是我习惯进行的操作。

4、重复代码

      重复的代码带来的最大的问题是新需求的变动，牵一发而动全身，其实没有收听代码之丑前，我也一直知道重复代码是编程中不好的习惯，只是有时会忽略，将可以抽成函数的重复的代码抽成函数，是一个好习惯，我会努力培养。

5、final修饰符

      可变的参数是一种丑代码，这是我之前完全没有想到的，作者用于举例的代码，参数都由final修饰，初见我就有疑问，直到作者指出可变的参数也是一种丑代码我才释然，确实，绝大部分的参数在传参之后，并不会二次改动，对于这些参数使用final修饰是没有问题的，今后我会注意。

6、拓展性

      这点在工作中十分重要，需求总是在增加，如果每次增加简单的需求就需要动代码，会增加很多的工作量，在设计之初尽量的考虑拓展性，是十分必要的，但这点很难做到，我只能保证今后努力。

这篇关于代码之丑 & 10x程序员工作法 心得的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！