网络安全检测|网络安全服务|网络安全扫描-香港墨客投资移动版

　　把可能涉及项目的整个团队当成一个共同体，而不仅仅是自己一个人。相比于自己写一次文档的局部视野，可以从更全局的视野来看长远收益。对于多团队合作的需求，如果不记录，看似一个不重要的参数，可能会涉及大量团队的沟通与协作的成本。虽然在维护他人项目的时候，可以看代码或注释来了解整个项目。但是一些复杂的项目，较复杂的逻辑，很难从代码中看出来整体结构，这时候文档的重要性就显示出来了。

　　文档的维护确实需要成本，但这是一个短期的成本。长期来看，有了文档，可以避免以后更多的沟通交流成本，避免花更多时间看一个陌生的逻辑的时间。相比编码完成之后推倒重来，文档的修改成本并不高。

　　面对短期与长期的天平的两端，你愿意把砝码放在哪一端?人生是一场马拉松，虽然不写文档会有短期内的轻松。但是从长远角度来说，目光长远，从更宽广的视角，拥有长远战略眼光，其实更重要。

　　另外，有人认为文档确实应该写，但是仅限于复杂的项目，简单的项目没必要写，其实简单的项目正是训练习惯的一个好机会。如果从来没有写文档的习惯，那么在Own大型项目的时候，就会发现非常不习惯写文档，在时间紧张，功能复杂，涉及团队非常多的项目时，重压之下，动作就容易变形。想要保证动作连贯行云流水，就要在平时养成好习惯。

　　维护文档的同时，也要维护文档索引

　　如果是单独一个项目的文档，其结构比较单一，即使迭代多个版本，其整体结构也比较清晰。但如果是一个团队大家一起记录，对于一个新主题页面的添加，不同的人会添加到不同的层级，下次在查找的时候非常困难。此时索引的重要性就很明显了，即文档的添加，不仅仅是单独一篇文档的添加，还需要有相应索引的维护。

　　这其实涉及到现代电子文档存储的一个问题，种类多，分类灵活，层级变幻无穷。随着团队规模的扩大，项目的增加，无序状态会持续导致熵加。想要更整洁，索引必不可少。

　　编码时间占比应低于30%

　　一个项目从需求评审、技术方案调研、书写文档、编写代码、测试、上线。纯粹编码的时间占比并不大。特别是在设计完美，一气呵成写完代码的情况下。如果编码时间占比很大，大概率是因为在编码的过程中写了一半、突然不知道后面怎么写了，或者写完之后，才发现设计有严重缺陷，需要推倒重来。

　　代码需要别人能看懂，而不仅仅能正常运行

　　上学时期，一个课程设计的项目，只要能正常运行即可。至于老师能不能看懂我们变量命名是什么意思，并不重要。因为这个项目，以后再也不会有人关注了。但是在企业项目中，一个项目不仅仅是要自己维护，还涉及到团队内其他同学来维护。因此代码的要求就不仅仅是能运行了，还要能让别人看懂。

　　先写注释，再写代码

　　注释不是补出来的，而是在编码的时候就应该写好的。

　　代码和注释是密不可分的统一体，类似知行合一的思想，知和行是密切结合在一起的，两者不可分割。几秒钟打几个字写一些注释，会为以后查看节省更多的时间。有人可能说我能看懂就行，以后看不懂也是别人看不懂，和我没关系。即使只从自己的角度来看，这个还真不一定，不信可以看看自己2个月之前写的代码。况且从更大的共同体利益来看，写注释并不是为了自己，而是为了整体团体的利益。如果刚开始不习惯写代码的同时写注释，可以在写代码之前先写注释。

　　外交无小事，对外的接口，变量的更改，要尽早同步

　　对外的接口协议，要慎重，确定之后不应该修改了。但是如果因为早期考虑不全面，必须修改，那就尽早修改。虽然自己全局搜索替换成本很低，但是如果涉及合作方的修改，特别是在测试后期，沟通成本可能要再高一个量级。周知上下游，越早改，大家的相对成本越低。

　　模块、函数遵循单一目的的原则

　　每个函数只做一件事，每个模块功能尽量单一。每个模块对外暴露相应的接口，做到“高内聚，低耦合”。说起来似乎很简单，但是如果在需求第一个版本就写出高耦合的代码，就会导致后续维护不可控，出现一个类上千行的现象。后期想要再改，成本呈指数级上升。每个函数，尽量不超过30行。每个类，尽量不超过900行。

　　命名要表里如一，见名知意