为什么有时候即使是代码作者本身也不愿意对自己的代码进行review？
从自身实践出发，我认为可能有以下一些原因：
1.代码风格很差—-没有良好的命名风格，名字不能达到见名知其意的效果。命名规范可以参考谷歌C++编程规范。
2.在开发前期准备中，没有做好调研，导致逻辑混乱，条理不清，进一步引发的问题是，软件结构的设计不合理。—-用更简洁的说法，就是没有遵循“自顶向下，逐步求精”的软件设计方法。自顶向下，在我看来就是根据业务设计出最简洁的逻辑结构，串联起各个模块之间的线索是数据流向。如果采用并发模型，那么具体如何实现并发，需要在这个环节考虑，线程是临时的还是长期的等。逐步求精的过程，在面向对象的思想指导下，就是一个根据设计好的逻辑结构，对每个模块中涉及到的抽象实体或者具象实体进行划分的过程。更加具体的说，这就是一个类设计的过程，类之间的数据传递最好使用方法调用、参数传递的方式进行，尽量避免以下这种情况：
class A
{
public:
int m_ia{0};
}
class B
{
void myfunction
{
A a;
std::cout << a.m_ia <你可能不会特意去写出这样的代码，毕竟一般情况下数据成员都是私有的，但是当你的类是一个单例，而数据成员非常多时，这种情况就极有可能发生了。但，最好不要这样做，因为，这可能造成你的代码不易读。另一个逐步求精的点，你在设计类的时候可能会根据业务可能会发生的变化，考虑使用什么样的设计模式方便服务的扩展。类的功能要尽可能单一，但这不是说这个类只做一件事情，而是它对应的就是一个抽象类型，而不会杂糅有其它的业务实体的功能。
3.在编码过程中，我们可能会使用大量的第三方库，由于种种原因你可能并没有去研究过源代码，库所提供的方法的运行机理、运行的顺序关系、方法的功能、数据成员的含义等，你可能都没有去了解。这就导致了，你或许是百度Ctrl C 然后Ctrl V到了你自己的工程，要么是从你公司现有的代码中完成了这个操作。但是如果可以最好不要这样做，因为这可能导致如果你的程序出现了问题，问题卡在第三方库那里。你甚至都无从下手，因为你对它完全不了解，不知道它出的问题原因是什么。
4.代码没有良好的注释。好的代码，代码即注释，但这有一个大前提，就是你的命名风格是一个所有人都认可的共识性的规则，并且你的每一个名字都能起的恰如其分（例如，你用中文拼音的缩写，或者有道随便查了个单词就起名了，那么你的同事看到这些缩写的时候，他能知道你想表达的意思吗？毕竟自然语言是那么的博大精深）。所以，优秀的代码，必然是良好的命名风格+良好的注释。关键部分的注释要有。
5.代码的终级目的是计算。第4条里说重要节点上必须要有注释，那么关键计算结果必须要用宏开关打印调试版的日志，如果可以，最好能给出预期的结果应该是什么，或者应该怎么去判断它是否合理，这样，当你的代码出现问题时，可以迅速沿着你的数据流向判断处代码的那个处理环节可能出错了。
6.不要炫技。技术的根本目的是为了更快更好的将用自然语言描述的逻辑业务转变为计算机能理解的电路处理流程。在处理业务时，要选择最合适的技术，不要为了炫技而使业务流程变得复杂臃肿。
7.C++程序员，效率是一个永恒的话题。在使用任何技术时，你必须要清楚的知道，这样做给你带来的效率上的收益是多少，在设计阶段，有没有可能让效率上再提升一些。所以涉及到第三方库的使用，在正式应用到项目上的时候，你得先有一些关于性能的测试数据，包括是在什么条件下进行的测试。
8.没有完善的设计文档。上述7条中，有大部分都应该形成可供查阅的文档，文档不需要采用华丽的语言，但是，一定要是逻辑清晰，层次分明的。最终需要达到的目的是，通过阅读文档，能完全理解你的程序作了什么事情，怎么做的，数据流是怎么样的，记住，即使是并发结构，数据流也有明确的走向，只不过，这个走向根据业务的不同可能比串行结构更加复杂一些。文档中需要对你使用了哪些第三方库，第三方库的版本是什么有个交代（这是在整个工程完结之后的补充），这样，文档+代码，可以让你的程序更加易懂易维护。
