React实战-历数一个混乱React项目的罪状

最近看到有篇文章讲述的了注释的作用，核心思想是：代码就是一切，好的代码能告诉你所有你想知道的，好的代码不需要注释。对于此类看法，我只能说部分认同，代码毕竟是深入到了细节，只有设计说明与规范的代码相结合，才能尽可能减少注释(weixin公众号：react实战)。

所谓好的代码无非是简单、易懂。软件项目的众多设计中很重要的一点是代码的可读性、可维护性和可扩展性。软件工程学来源于物理工程学，但软件与盖房子存在着本质的区别，软件逻辑复杂，软件开发过程以及维护过程中会对原有代码就行不断的修改，并且修改的人不一定是原始代码的编写者，即使是同一个人，10天之后也会忘却，所以软件结构、命名、注释、文档说明都显得非常重要。

之前无意间误入一个澳洲的初创校园票务互联网公司，尽管公司已经运行了几年，但当我看到他们的代码时，真感觉回到了大学时代，也真明白了互联网公司追求的是尽快完成功能，以金钱换时间。曾试图对项目结构进行调整，无奈别人要的只是完成功能，这种弱智的体力活自然是作罢了，一拍两散，但是项目的混乱程度可以给人以借鉴。

介入两天我曾写过一个建议，指出项目的低价，惹得负责人不高兴了，哎，自知此做法不会讨得好，但作为一个从事软件工程研究十多年的码农，实在不想回到学生时代的编码方式了。

暂列几条罪状吧：

1.函数大小随意，多则上千行，少则几十行。

2.虽然采用React，实际上是用的React，编的是jsp或是asp，React作为javascript的革新之作，居然被这帮人整回了原始社会，更别谈什么组件化、FLUX、Redux、函数式编程等等了。

3.业务模块混乱：目录文件随意，完全看个人喜好，你根本不知道一个业务到底由哪几个文件完成，你得跟着代码一行一行的去看。

4.无层次结构：整个项目没有分层的概念，UI,数据访问，逻辑全在一个文件中。

5.无文档说明：没有任何文档说明，所有需求只是来源于一个人口述，几张PPT。业务逻辑前后台没有一个人说的清楚，难道你们没有听说过UML图吗？来张图不是什么都清楚了？！

6.没有编程规范：命名、逻辑结构、实现方式完全看开发者心情。但是新入者只有吐血的份了。

7.更别说测试什么的吧。

这样的项目也算让我见识了什么叫新瓶装旧酒。人人常说中越反击战是用现代的武器打了一场古代的战争，这个项目就是采用了React，干的却是原始javascript的事。