本文是我第一篇博客，可能笔法稚嫩，语序不通。但走出第一步是最重要的。

对两本书内容有所感触，即备受好评的书籍《重构 改善既有代码的设计》与《代码整洁之道》

其中一段话感觉还是比较符合我现在的状况

你当然曾为糟糕的代码所困扰过。那么——为什么要写糟糕的代码？

是想快点完成吗？是要赶时间吗？有可能，或许你觉得你自己要干好所需的时间不够；假使花时间清理代码，老板就会大发雷霆。或许你只是不耐烦再搞这套程序，期望早点结束。或许你看了看自己要承诺要做的其他事，意识到要赶紧弄完手上的工作，好接着做下一件工作。

我们都曾说过有朝一日再回头清理。当然，在那些日子里，我们都没听过勒布朗法则：

稍后等于永不（Later equals never）

作为刚入职的新人，处理项目的总会有些手足无措，对繁复的需求与底层实现支离破碎，可能产生不想继续做下去，想做简单的事情，先抛弃困难的地方，去熟悉简单的事物。总想着稍后稍后，这个需求就会因此荒废。

对于一个新需求，我们老大告诉我一个方法。凡是遇到一个事情，由粗到细，由细到粗进行处理。虽然我现在不能完整掌握，但方法论总是重要的。

由粗到细：指的是，面对一个新事物时从宏观角度进行处理。了解这个工程的具体执行方法。了解这个请求是什么方式不断执行下去的。在找到你所在需求所处流程的位置，着重看细节问题。是那那几个类，那几个文件进行主要执行的。

由细到粗：指的是，了解细节的具体使用方式后，从细节推出去，找到细节的具体问题与需求的解决方法，暂时解决方法后，在慢慢从宏观角度看自己的方案进行有什么缺漏之处。

我解决动态配置附件上传地址时，一开始陷入底层代码中，一层层的嵌套，代码不断向底层推进，就慢慢不了解是如何执行功能的流程。写完代码后，发现数据冗余严重，逻辑多层嵌套。包括错误的想法，试图去为Action执行切面编程，织入自己的逻辑代码。这都不应该交由Action处理，可以在Action方法的调用方法执行后去执行自己的逻辑等等。包括冗余的逻辑可以进行整合，重复的代码逻辑看看是否可以被方法整合。

最后一个重点是我看到的java命名规则

JAVA

类名：帕斯卡命名方式，首字母大写：VeloCityResponseWriter

包含小写：net.oschina.beans.xxx

变量名和方法小写开始的驼峰命名       studentParentName

常量名用全大写：MAX_PARAMETER_COUNT = 100

枚举类名参考普通类名，枚举变量采用全大写 

重点：不用任何带下划线的命名方式，除非变量与枚举类

我们项目中访问具体Action方法：全部小写，英语单词用—连接

例如：Aciton名字 DiskAddress.Action

localhost:8080/G2/disk-addresss.do

href="test-dialog!list.do?data"