尝试完成分配给我的一个需求，度过了糟糕的一天。了解了需求的逻辑，再对应到代码中去看，需求中只要添加一个地方，但小小的改动牵扯了一大片的逻辑。
当开始接需求时候，我的吐槽也开始了。
需求文档很重要
不熟悉每个字段的含义，对待许多个条件的判断便无从下手。
以往接手的项目后端都会提供接口文档，标明字段的含义和包含的值。
看这这份文档，再结合对应代码逻辑的判断，便很快的进入熟悉的状态，一个需求过后一部分功能就都很熟悉了。
但到了这里工作，文档竟然不完善，也没有人能完全把字段都说清楚，这就对阅读逻辑增加了不少的难度，看了一天下来也是一脸懵逼。
他们之前在做项目时，加一个简单的功能，只是返回一个字段而已，靠口口相传字段的含义完成需求，懒得花时间去写一个字段的含义到文档中，因为太简单，脑瓜子记得很清楚，便选择忽略记在文档的必要性。
经过长年累月的迭代，字段越来越多，新的记得清楚，旧的早已淡忘，由于忽视了记录，便忘记了很久之前的字段含义。更要命的是人员在流动，写字段的人走了，接手的人成了接盘的侠，可以想象接盘侠是何等的抓耳挠腮却无计可施，
望着一行行代码，陷入了深深的烦恼中。
所以在做项目中，写文档至关重要。没有文档的记录，看代码，只能抓瞎。
加注释有指导意义
项目代码经过几个人的手，迭代了多个需求，代码的可读性已经变得非常的差。
一个文件总共有4千行代码，查看一个判断，要从开始的200行，拉到中间的2000行，还要反复的拉上落下来确定逻辑的正确性，这简直就是浪费时间。
一个判断能超出一屏之外，还有很长，左右滑动记住来字段的名字，简直就是反人类。就不能折行显示，一眼扫下来全部在视线内，不至于手滑的疼痛。
洋洋洒洒写了很多行代码，竟然没有一句注释，这留给后来人简直就是噩梦，要一行一行的读，多个判断交织在一起，压根都不知道是做什么用的。顺手加行注释的事，就是没人去做
不要求每一行都加上，至少也要在一大块写点注释。功在当代，利在千秋呀！
代码规范很重要
代码风格一点都不统一，大家都按照自己的喜好来写代码，有人喜欢加分号，有人不喜欢；有人喜欢等号两边空格，有人就喜欢不加空格；有人的缩进是4个，有人的缩进是2个；有人用N年前的技术手段，有人喜欢用最新的技术方案。这样的代码一眼就能看出来是经历了多人之手，风格完全不一致。
这里没有代码规范一说，有检测代码的工具，却是摆设，没人使用，因为太严格，很多人不适应，随弃。
代码风格的好处是统一组员参差不齐的风格，使之很多人写出来就跟出自一人之手一样。
所加入的团队没有做好接口文档、注释、代码风格统一，接手的人处在泥塘中苦苦挣扎着。
