合并显而易见的代码
所谓显而易见的代码，就是看上去和别处相同的代码。
在这个例子中，就是View‘中初始页面显示的内容与未来刷新的内容重复；Controller中初始显示的运算和刷新的相同。
Controller好办，如此：
- print?private void PrepareAssignItemsData(int sprintID)
- {
- var sprint = ...
- var team = ...
- var overTimes = ...;
- var itemsTreeInSprint = ...
- ViewBag.AssignItemsViewModel = ...
- ViewBag.ViewModel = ...
- }
- public ActionResult AssignItems(int sprintID)
- {
- PrepareAssignItemsData(sprintID);
- return View("~/Areas/SFC/Views/Items/ItemTree.cshtml");
- }
- public ActionResult AjaxRefreshAssignItemsLeftPad(int sprintID)
- {
- PrepareAssignItemsData(sprintID);
- return View("~/Areas/Agile/Views/PlanningMeetings/AjaxRefreshAssignItemsLeftPad.cshtml");
- }
而cshtml页面中，只需要添加一个在页面初始化时自动刷新的函数，就能把<div id = "leftpad">变成空的，由刷新页面来填充。代码变成：
- [html] view plaincopyprint?<script type = "text/javascript">
- $(document).ready(function () {
- refreshLeft();
- });
- function refreshLeft() {
- $("#refreshLeft").click();
- };
- </script>
- <div style = "display: no1ne">
- @SFCUI.Link("refresh", "/Agile/PlanningMeetings/AjaxRefreshAssignItemsLeftPad?sprintID=" + assignItemsViewModel.Sprint.ID, ajaxUpdateTargetID: "leftpad", ajaxOnSuccess: "refreshAll", id: "refreshLeft")
- </div>
- <div id = "leftpad">
- </div>
$(document).ready是多出来的代码，负责第一次初始化时填充<div id = "leftpad>的内容。
封装多余的技术代码
何为多余的技术代码？之前在AjaxValue系列中曾经提到过接口封装的两个原则：
最小信息原则：方法接口应只传递最必须的业务信息。
包括两个层面：
1. 技术数据不要传递
2. 业务数据不能重复
现在，先从业务角度分析，这个函数接口设计中，到底哪些信息是必须的；让我们来用这一原则，把上面最后的一段cshtml代码，变成一行代码。
1. 如果要刷新，应该调用什么函数（一般是一个JS函数，提供给左边的红框，红框运行成功，就调用这个JS函数）
2. 用于刷新页面的Ajax Url（上述JS函数被调用后，应该到哪个Url获取刷新内容）
3. 刷新成功后，要继续执行什么操作（另外一个JS函数，比如刷新的内容“错过了document.Ready”要重新套用一下——尝试了live功能，不知道为什么无效；或者要串联刷新多个区域，本例中没有）
没了（后面还会看到一些，不过是为了别的功能）。有几个东西是多余的：
1. $(document).ready.....，因为每个AjaxPageLoad都执行，所以是固定的，不用作为参数传入接口。
2. function refreshLeft() ...{ $"#refreshLeft")....，因为这个按钮是多余的，并不需要人手去点击，只是函数实现中的一个步骤而已。换言之这个按钮叫什么都无所谓，只要ready / function / SFCUI.Link(id: ...)中出现的值相同就行，无需人工指定。
3. <div id = "leftpad"></div>也是多余的！因为既然在这里写下那一行代码，就在代码处LoadPage，至于Load到什么东西里边，ID叫什么，都无所谓。
所以，接口调用应该是：
- print?@SFCUI.AjaxLoadPage("/Agile/PlanningMeetings/AjaxRefreshAssignItemsLeftPad?sprintID=" + assignItemsViewModel.Sprint.ID, refreshFunction: "refreshLeft", ajaxOnSuccess: "refreshAll")
这句话是一个helper，将负责生产前面代码中提到的<script>及其中的两个函数ready和refreshLeft、中间的<div>@SFCUI.Link中的Ajax调用</div>、最后的<div id = "leftpad">
下面是Helper的源代码，里边多了一些参数，最后解释：
- print?public const string AJAX_LOAD_PAGE_CLASS = "ajaxloadpage";
- private static Random _rand = new Random();
- public static MvcHtmlString AjaxLoadPage(string pageLink, string refreshFunction = null, string ajaxOnSuccess = null, string style = null, int timeout = 0)
- {
- int id = _rand.Next();
- string html = SFCUI.Link("refresh", "/SFC/Ajax/AjaxLoadPage?pageLink=" + HttpUtility.UrlEncode(pageLink), ajaxUpdateTargetID: id.ToString() + "Body", ajaxOnSuccess: ajaxOnSuccess, cssClass: "hide " + AJAX_LOAD_PAGE_CLASS + " ", id: id.ToString()).ToString();
- TagBuilder script = new TagBuilder("script");
- script.MergeAttribute("type", "text/javascript");
- script.InnerHtml = "$(document).ready(function () { setTimeout(function () { $(\"#" + id.ToString() + "\").click(); }, " + timeout + "); });";
- if (refreshFunction != null)
- script.InnerHtml += "function " + refreshFunction + "() { $(\"#" + id.ToString() + "\").click(); };";
- html += script.ToString();
- TagBuilder pageContainer = new TagBuilder("div");
- pageContainer.MergeAttribute("id", id.ToString() + "Body");
- pageContainer.MergeAttribute("style", style);
- html += pageContainer.ToString();
- return new MvcHtmlString(html);
- }
1. 先看突然跳出来的int id = _rand.next()
之前提到，我们有很多“随便”的变量，比如那个"refreshLeft"，叫什么都行，外界不关心。但是如果设为常数，则如果在同一个页面上放两个LoadPage的时候，会打架，所以用个Random生成ID。为什么用static 的呢？因为Random的生成机制，是利用调用时的系统时间作为“种子”，从种子产生下一个随机数。如果调用时间间隔为“0”，就会产生出相同的种子进而相同的随机数。static就没有这个问题了，大家用一个，顺着排。
总之，随机的id代替了"refreshLeft"这个本来需要传进来的“变量”。
2. TagBuilder script则直接在代码上方产生一段script，免去了编写script的工作。
为什么要判断refreshFunction为NULL的情况呢？因为有一种场景不会重复刷新。
在我的项目中，菜单极其复杂，产生菜单的时间，甚至比页面本身都长。但我们也不像牺牲强大的菜单换取性能，怎么办呢？子菜单延时产生！
由于人们在页面出现后的1～5秒内都不会操作菜单（要离开这个页面时才会操作），所以我们设置所有繁重的子菜单都使用AjaxLoadPage加载，而且注意最后一个参数timeout，它们多数在1000毫秒后才加载，那时候页面早就爽快地展示在用户面前了。
这种场景，不会有人刷新菜单了，所以就不用RefreshFunction这个参数。
3. TagBuilder pageContainer 代替了原来最后的<div id = "leftpad">，它的id也是随机生成的，但是由于1、2、3中保持了id的互相照应，虽然外界看不到，但是内部却顺畅运行。
4. 最后多了个style，是我们加载菜单时的需要，这里就不多说了。
尾声
合并显而易见的代码是初级程序员的基本功，也是产品代码的基本要求；封装多余的技术代码难度较大，但是只要用心，上述提到的原则也没有做不到的。
为什么要费劲封装呢？散装的代码对程序员要求低，只要好好测试，功能相同，也不会出现缺陷，不也一样吗？
在16年的IT从业中我发现，所有最后开发面临崩溃的软件，很少有受到单个技术难题或缺陷困扰的，多数都百病缠身；而百病缠身的主要问题，是可维护性差；而可维护性差的主要原因，是代码臃肿重复，尤其是似重复而不重复。
封装后，则：
1. 总是使用同一段代码，易于维护。
2. 总是重复使用，代码的质量有保障。
3. 一个地方发现缺陷，修改代码后可以同时避免多个地方的缺陷。
4. 在无需深入到技术层面的时候，可以方便地在业务层面阅读代码。
5. 把时间花费在深究代码的封装上，比重复码字要有趣得多。
……
在之前的IT职业生涯的“危险职业”系列中有很多人提到：“我一直在做重复劳动，没有积累，是不是很危险？怎么办？”其实万事万物看似重复，其实不重复。本人从事Web编程只有一年多（其中只有6个月的编程量超过总工作量的50%），Jquery上上个月刚大致弄明白，但是我相信很多Web编程很久的程序员都不会封装这些代码的，而是“重复地”拷贝粘贴代码。
所以实际上，没有重复的工作，只有重复的工作心态。
之后我会写一篇关于“重复劳动中如何提高”的IT职业生涯系列文章。
本文转自火星人陈勇 51CTO博客，原文链接:http://blog.51cto.com/cheny/1101508
