今天哈哈，加班了，本来一切都想的很美好，已经做完的功能，好像完全没有什么问题，在测试环境也测试的好好的，就等着上线之后，简单测一把之后就可以溜之大吉。可是令人想不到的是，测试环境没有什么问题，到了正式环境就出了各种各样的问题，有的是测试环境没有测出来之前遗留的bug，当然不是我写的bug，还有就是数据的问题，测试环境的数据覆盖比较少，而生产环境数据量大，导致出现了各种奇怪的问题。
当然问题很简单，花了一段时间就解完了。当然其中有个bug令我记忆深刻，在之前的老代码中，总会出现对原始数据进行修改，好像有强迫症一样，数字已经表达不了的含义，非得用中文来凑，好像数据比较难以记忆。当然本来代码是可以运行的，当时的我由于需要这个字段，但是这个字段生生的被改成了汉字，而我又真的不想每次用汉字来进行判断。于是我做了一个决定，就是改他的代码，说实在的，他的代码里各种复制粘贴，一个文件有几千行代码，大约有一半的代码都是重复和注释的，其实我真的搞不懂为什么修改了之后，要将原来的代码进行注释，我们不是有强大的代码管理工具git吗？难道说还怕代码丢失了不成。
当然改动也是很漫长的，主要是代码里还用了mixin，导致有一部分的修改没有覆盖到，导致这次的代码出现的bug，说真的代码还是要养成好的习惯，
首先，对于后端返回的字段尽量不要改动，可以新增字段，如果修改了字段，那么对于后来者的修改将是毁灭性的，因为他要将原有的推到重来，我这里还只是将文字和数字一一对应，要是多几个条件转换，那么也只有干瞪眼了。
其次，虽然说复制粘贴很简单，但是对于某些代码，可以封装成方法，这样可以减少代码量，当然封装也需要考虑到复用性，不要参杂过多的固定参数，比如在我遇到的代码中，有一个特定场景产生的数据，比如列表里的某一行，或者树的某一个节点，这里封装了一个方法，调用了后端的接口，然后进行后端数据的操作转换，到这里一切本来很完美了，但是这里封装的时候，还对树节点或者行进行了操作，导致后面需要用到这个方法的时候，如果没有树节点，我根本就没办法复用，导致我不得不重新写个方法去获取数据。
当然这也只是冰山一角，每个人写代码都有自己的风格，比如有人喜欢驼峰，有人喜欢下划线，有人喜欢中划线，无可厚非，但是请不要在同一套代码里混用，说真的有时候真的挺头疼的，导致最后我都不知道我应该怎么去写代码。当然如果公司有代码规范条例还好，如果没有那么自己要养成习惯，不要说为了写代码而写代码，要不停的成长，要学会用尽可能优美的方式解决问题，那么也许你会收获良多。
网友评论