事件原因
一位新浪程序员小姐姐半夜被投诉电话吵醒，开始了寻找bug的必经之路~~~
检查代码半天，发现问题的原因是一个莫名其妙的if代码块。 这个逻辑他看了半天也没明白，感觉奇怪~~~
在这种被逼的情况下，他只能半夜打电话询问是哪位朋友提交了这段代码。 经过沟通，他发现这么奇怪的逻辑是之前产品提出的特殊要求……
针对这样的情况，让我们看看网友们有何感想！
网友一
程序员最讨厌的事情：别人不写文档，别人不写注释； 自己写文档，自己写评论！
学姐有话要说：你看，因为程序员不喜欢写注释，半夜就被电话吵醒了！
网友二
我会写笔记，我会写下理论基础（产品的要求）。 是为了未来打败产品。
学姐有话要说：别这么暴力，解释对你我他都方便！
网友三
呵呵，如果程序员明明不测试逻辑程序员下载网站文件要钱吗，为什么测试去了，详细开发文档的人为什么去了，这盆产品不记。 除非有反馈说产品需要硬装。
学长有话要说： 说得有道理，但其实这个环节还是有点偏，这个过程中哪个环节做得不是很到位，需要反思！
网友四
你这么急着在半夜给朋友打电话吗？
师姐有话要说：这应该不算异常，很常见~~~
网友五
我一般不写。 如果其他人要求，我认为不合理的我会添加评论。
学长有话要说：最好养成写注释的习惯，尤其是这些容易引起误解的代码程序员下载网站文件要钱吗，更应该多加注释。
网友六
它运行速度太快，产品需要休眠几秒钟。
学长有话要说：收到后你想说如果用户想降低产品流畅度加钱，你就缩短睡眠秒数，然后告诉用户你已经优化了提高效率的计划？
有时候写一些代码注释看似浪费时间，说不定可以节省代码维护时间呢！ 当人们不断追问这段代码的含义，甚至是凌晨被电话吵醒时，能够深刻感受到这句话是非常有道理的。
另外，通过这个例子，和姐姐一起看看开发过程中的一些问题吧！
01
产品的需求不是在产品文档中生成的，而是口头传达给程序员的。 程序员只能通过看代码来抱怨，而不能通过文档来抱怨！
02
程序员的代码没有写注释，这也导致其他程序员无法理解逻辑，不得不打电话给提交代码的人。
03
测试人员并没有认真测试和验证这个新需求，危害上线后的用户反馈和投诉导致了这一系列现象。
希望你毕业后能有一个良好的习惯和对发展流程的认识。
