不要降低代码质量

　　为了快速交付，所以没有全盘理解架构，但绝不能以降低代码质量为条件。下面是一些你可能因为只考虑快速交付而引发的代码质量问题。
　　因为修改代码涉及到很多的依赖，所以新增代码相对而言风险较小。例如，有 5 个用例都调用了某个方法。为了改进某个用例，你需要修改这个方法的实现。简单的做法就是复制这个方法，重命名，然后在改进的用例中调用新方法。千万不要这么做。代码冗余是非常有害的。尝试对方法进行包装或者重写，甚至是直接修改，然后重新测试所有用例，通常停下来想一想，然后亲手去实施，是一个比较好的方式。
　　另一个例子是将“private”方法改为“public”，使得别的类也可以调用。尽量不要将非必须的部分暴露出来。假如为了更好的设计需要重构，就应当着手去做。
　　大部分应用都有确定的结构和模式来实施。修复或增强程序时，确认你没有偏离这样的模式。若对约定不确定，请其他的高级开发者来审核你的变更。若你必须做一些违背约定的实施，尽量放置于一个规模较小的类中（一个 200 行代码的类中的私有函数应当不会影响应用的整体设计）
不要停止深入理解项目架构
　　按照文章列出的方式，假设你能够在对项目了解较少的情况下进行交付并以此持续下去，可能你会停止对项目架构的深入了解。这样从长远角度来说对你的职业生涯没有帮助。当你的经验增加时，你应当承担比较大的模块任务。如构建一个完整的新特性或者修改项目的一些基础设计等较大的改进。当你能够做这些改进时，你对项目的整体架构应该相当了解。文中列举的方法是让你在短的时间内提升自己，而不是阻止你完整理解整个项目。
结论
　　整篇文章集中在对项目进行必要了解的前提下进行快速交付。你可以在不降低代码质量的前提下这么做。
　　若修复一个 bug，迅速定 位并修复。有必要可以使用运行时分析工具。若新增一个特写，可以寻找相似特写，理解流程（有必要使用工具）并编写。
　　或许这些听起来很简单，但是实用吗？当然。但前提是你有良好的 java 技术以及对框架足够了解才能先修改代码，然后对变更影响进行分析。对变更影响的分析比实施变更需要更多的技巧。你可能需要高级开发人员协助你分析变更影响。
　　大约有 50% 的 IT 可操作预算用于简单的 bug 修复和功能增强。根据文中的建议，对于维护活动中的经费的节省应当还是很有帮助的。
　
报名方式： 
方式一:如果你对西安甲骨文九州实训基地的课程、学费、就业等有任何疑问,可以拨打我们的咨询电话一八六二九四六五八五四 方式二:如果你拨打电话不方便也可以选择网上咨询,或网上报名。登录西安甲骨文九州实训基地网站http://www.x***/android.html?lpx在线咨询。