随着自己的能力的不断的增长，主要是自己的视野和格局在不断的增长。让自己，觉的现在的代码越来越垃圾了，急需重构代码。项目中的冗余代码越来越多，这是为什么呢？这是因为，之前开发规范的问题。没有一个很好的规范，导致了各种问题，当然也埋下了很多的坑！
这么说，一个六个人的团队，未必就会比一个人的做的好！因为，In China 很多的时候，我们往往只相信自己的能力，并不相信别人。总觉的被人是傻逼。一般的只要不是大公司，小公司也包括中型的公司，新人到了公司之后，缺少代码规范的训练。因为，似乎每个人都很忙，他们不知道，现在的很忙，导致了以后会更忙。新人，必须要代码规范。但是，很多初级的程序员，往往没有这种意识！需要我们来督促！
说说，今天！ 今天上午发了包，下午有点自己的时间，可以让自己来重构自己的代码！说真的我很庆幸现在自己的状态，因为，我算是 天时 地利 人和。 我很是庆幸，比如我的哥们，小强，他作为一个新人刚到公司，看到公司垃圾的代码，但是，他不可以重构，因为，作为新人，到了公司没有什么话语权。这个社会就是这个样子的，新人要有新人的样子。就像PM 很多都是傻逼，娜姐除外。说白了，很多人根本就是看不起程序员，我们一般是比较理想化的人，活在自己的世界里面，感觉自己的世界里面，自己似乎可以做所有的事情！说白了，我就是自己的神。总之，我现在重构我的代码，没有意思的顾虑，就是只要自己有时间就好了！花点精力来做这件事情。我觉的代码就像自己的老婆一样，如果，你都不花心思来整理，还有谁会对你的代码上心呢？所以，代码可以变的更好，实现 可修改，可维护，可增量！
这个世界上的事情，需求是不断的改变的。假如 需求是死的，那么的你活着还有什么意思！
我们就生活在不断变化 的世界里面
下面说说我的重构代码的感悟：
1 命名规范
这个问题，真是很蛋疼呢？说白了，很多人写代码就是瞎鸡巴写，根本就不在谁来维护代码，只要代码实现了就好，什么有道词典，百度呀，google 翻译呀，瞎鸡巴乱搞，很快他们就实现了功能，老板很开心，因为，很快就看到了产品，在老板的心里面，产品的代码应该是整整齐齐的。但是，在程序猿的心里面代码是乱七八糟的，我说的是大多数的。作为，刚到公司的人急于表现自己的能力，想让自己的能力得到老板的肯定。然后，就瞎鸡巴揽活，拿到需求之后，看到产品原型图，就瞎鸡巴写，写了之后发现有问题，就开始瞎鸡巴改！真是蛋疼的狠！最后，发现 坑越来越多，自己的坑越来越多，这是一个量变促进质变的过程。到了最后，发现自己真的是改不动bug了！然后，递交了辞职信！ 这尼玛就是坑货， 新来的人 又开始了死循环！
解决：
命名规范的问题，每种语言都有自己的特性，但是命名确实大同小异。你需要根据自己的习惯总结一套自己的命名规范。不是每个人都有这种意识，很庆幸，我有这种意识！这个东西，CTO 产品经理 可以制订一份文档，来规范用到的英文。没有在文档汇总的，程序员可以 google,添加到文档中！
命名的规范有很多，我就不介绍了，你们随便找找吧！
2 Utils
为什么要提取Utils
今天，我的项目中用到了ImageLoader. DisPalyOptions 很多地方都初始化了，将近 100 多个地方都用自己重新定义了一下！这样的重复代码， 根本原因，我们开发的时候，很多的时候只会粘贴复制。粘贴复制到了 代码的重复！
我的原则： 重复的地方超过了3次以上，立马听一下工作开始重构代码，或者提取到工具类！
我这里建立 了一个ImageLoaderUtils， 来处理 不同的DisplayOptions, displayImage().
但是，这么做有什么好处呢？
我有一个问题，加入有一天，我不想用ImageLoader了，我想换一种 图片加载工具，比如 Passco 实现图片的加载。但是，现在的代码修改起来，代价太大了。因为内部代码跟ImageLoader 的耦合度太大了，属于低内聚，高耦合。就是，所有用到ImageLoader的地方都要修改。这样很不好。
这个时候，我体会到了解释器设计模式的用处。
提取工具类是一个非常好的习惯。因为，可以消重。消除重复代码的原则：拆分和抽取。就是 大事化小，小事化了，了事化无。
用了ImageLoaderUtils 之后，我可以在这个累的基础之上去使用适配器模式，做不同的 图片加载工具的 adapter. 我只需要链接不同的 图片加载的特性。然后，抽取一个 BaseImageLodaerUtil 设置几个抽象的方法，然后，让子类实现以下，就可以了！具体的需要思考。
这就是我今天的收获！
No comments:
Post a Comment