1三法则

三法则是一个代码重构的经验法则，用来决定什么时候应该用新的代码/程序/方法来替换一段复制的代码。

它规定，允许你复制粘贴一次代码，但当同一代码复制三次时，应提取到一个新的程序中。主要的概念是使代码/程序/方法能够在项目中通用，这样它就可以在很多地方重复的使用。

2稳定才是王道

在结构和编码方式上保持一致。这可以帮助你提高代码的可读性和可维护性。

尝试并提出一致性的编码标准，这有助于保持一致性，最好精确到你的变量的命名习惯。另一个重要的是代码程序的结构，它应该是显而易见的，开发人员需要做出一些改变或添加一些新的东西。

3减少嵌套

If中的if可能会使代码结构变得很乱，而且很快就很难读懂。有时你可能无法绕过这个问题，但一定要看看你的代码结构。对于 else if 来说也是一样的，要尽可能避免if嵌套，因为这有时会使代码更难读。

卫语句（又称提前返回/提前退出）是帮助解决这一问题的有效方法！卫语句只是用于检查先决条件，可以是一个返回语句，也可以是一个异常。

没有使用卫语句示例：

if (account != null)

{

    if (order != null)

    {

        if (order.term == Term.Annually)

        {

            // term annually

        }

        else if (order.term == Term.Monthly)

        {

            // term monthly

        }

        else

        {

            throw new InvalidEnumArgumentException(nameof(term));

        }

    }

    else

    {

        throw new ArgumentNullException(nameof(subscription));

    }

}

使用卫语句示例：

if (account == null)

{

        throw new ArgumentNullException(nameof(account));

}

if (order == null)

{

    throw new ArgumentNullException(nameof(order));

}

if (order.term == Term.Annually)

{

    // term annually (return here)

}

if (order.term == Term.Monthly)

{

    // term monthly (return here)

}

throw new InvalidEnumArgumentException(nameof(order.term));

4从全局出发去考虑

对项目整体有个认知是非常重要的，这能使小细节更容易跟进。一旦你了解了项目的整体结构，小细节就不需要再去花太多时间去研究。

5花点时间思考下命名的问题

在编码中给变量、方法或对象命名是困扰我们的事情之一，这可以是给一个类、方法甚至是一个变量命名。一个优秀的开发者会花时间考虑相关的变量名，因为他们知道这有助于提高可读性！

6技术负债是不好的

要求高点可以帮助解决这个问题。尽量一次写好你的代码逻辑，否则你就得反复的去重构。

技术债务是软件开发中的一个概念，它反映了由于现在选择一种简单的（有限的）解决方案，而不是使用会花费较长时间的更好的方法而导致的额外返工的成本。

7过高的评估

根据您所处部门的不同，您未必喜欢这一点。但优秀的开发人员往往会高估任务，因为他们知道事情大概要花多长时间，然后会给预期再增加一个缓冲的时间，这样可以帮助你把事情做好。

这可以真正帮助你解决上面的观点—— "技术债务是不好的"。如果你低估或预估了一个比较理想的时间，实际上可能会无法完成，甚至会遗留一些技术债务。因为你的期望只是尽快的完成并能够使其正常运行，而不是使代码干净且易于维护。

8文档和注释

文档和注释有助于帮助自己或者他人更容易的理解和使用。你会听到一些有经验的人在说，我们能不能把这个过程记录下来，或者代码审查失败，因为接口没有相关注释等。

9敢于删除不好的或没用的代码

你经常会看到很多不太自信的开发人员将大量代码注释掉并留在那里。版本控制是有目的！优秀的开发人员不会回避删除应用程序中没用的代码。

10花时间检查编写的代码

优秀的开发人员将花费更多的时间在代码审查上，并且知道代码审查的重要性。

尽早的发现BUG；

提高开发人员的技能，并让团队其他成员也养成这样的习惯；

知识分享；

一致的设计和实现。

我见过的最好的代码评审过程是：

1个风险不大的小任务应该由1个开发人员进行审查；

中型/大型更改或有风险的更改应由3位开发人员进行审核，其中一位是其办团队中的高级开发人员；

一个风险极高的修改或是正在开发的新功能，应该举行一个会议，3个开发人员至少有一个是首席开发人员，然后一起去看每一行，并提出建议。

11编写测试用例

您会注意到，经验更丰富，实力更强的开发人员会花更多时间编写好测试用例。良好的测试用例可以帮助您更有信心地扩展或修改程序代码，并有助于减少bug的产生。

12花时间去设计

在深入研究代码或写代码之前，请先进行仔细考虑，然后将其分解为小块。这有助于帮你如何将所有东西组合在一起，并为创建更简洁的代码做更多准备。

13要注重技术实现原理而不是语法

这是个大问题!他们喜欢学习基础知识大于注重语法。这可以帮助他们更有效的发现问题，也可以帮助他们更明白的google问题。

14让谷歌成为你的好朋友

他们是Googling的专家，能更好的找到解决问题的方法。因为上面提到他们更专注于基础知识而不是语法，所以他们知道该搜索哪些谷歌术语，如果你执着于学习语法，这是很难做到的！

15先实现功能再优化

一些初级开发人员，似乎一开始就花了很多时间让编写的代码看起来很漂亮，这样如果最后发现它们无法正常工作就陷入尴尬。优秀的开发人员会在早些时候只实现功能，这样把细节处理好之前可以尽早的发现问题，有利于保证项目更加顺利的进行。

16风险管理和解决问题

高级开发人员可以把控风险，通过设计模式的应用提炼出复杂的问题，并且根据过去的经验，可以独立解决不同的问题。

17多问

优秀的开发人员想了解的多一点。即使听起来很简单，他们也不介意提出问题。这些可能是与技术或业务相关的问题。了解业务需求有助于他们编写更好的代码！他们对自己的能力充满信心，因此不怕问问题。

18尽可能地将逻辑从数据库中分离出来

这一点要看你构建的应用类型，只有在不会影响性能的情况下才可以。

他们知道要把数据库查询控制在简单的CRUD操作中。

Create, read (aka retrieve), update, and delete

然后，业务逻辑层应该将这些内容整合在一起。这有助于开发人员知道在哪里寻找业务逻辑。如果在数据库查询和代码中有逻辑，这很快就会变得混乱。

19保持代码简洁

他们知道保持代码简单是最好的方法。即使这意味着有时要多写代码。您将看到许多初级开发人员编写如下所示的代码：

return dir.Keys.Any(k => k >= limit) ? dir.First(x => x.Key >= limit).Value : dir[dir.Keys.Max()];

这通常是可行的，但是阅读起来非常困难！

总结

这就是我看到的优秀的开发人员每天都会做的事情。您会发现其中许多与实际编码无关，而与过程以及它们如何处理任务有关......

...END...