自我提升（思想设计篇）——二维分解

前言：作为一个程序员，应该不断的学习新技术的同时，更应该注重自己的思维方式和程序设计。

写代码，常说“高内聚，低耦合”。万变不离其宗，写好代码的关键之一，便是这里的高内聚，低耦合。而，如何做到这两点呢？其实，与之对应的方法便是：分解，设计（也可以说是组合）。

之前我一直做的是一维分解，直白点，就是横向分解。横向分解可以这样理解，就是分模块，分业务。按业务模块进行分解。举个例子，一个地图界面，有一个需求：导航到车。那么这个需求，其实包含的业务是：定位人的位置，添加车的mark，导航功能。所以，可以比较简单的进行模块分解，分解为定位模块，添加mark模块，导航模块。（当然，这里是举个例子，其实可能根本就不需要分模块）

那代码怎么实现呢？其实也很简单，就是写3个方法，分别对应3个模块。（如果方法中代码特别多，可以考虑用一个类来装）。这里讲的就是最简单的一维分解，根据业务模块进行分解。要做到这一点，其实并不难，只需要对业务准确理解，把代码写在一起，稍微封装一下，就ok了。一般写了个一年半载的程序员都能做到，只是做得好不好的问题，分的准不准确的问题。

那么纵向分解又是怎么样呢？纵向分解，可以说是看一个程序员能不能走得更远，能不能走向架构师的一道坎。我老大，就跟我说过，很多，应该说大多数程序员都是”死“在了这里。说纵向分解之前，先说一说大多数程序员写代码和思考的方式：

从技术到业务。说得可能有点抽象，同样举个例子：需求是 ， 展示所有车站。ok，拿到这个需求之后，我们的思维是，嗯，我会用listview（当然可能是其他的列表什么的），嗯，所以，我就用一个列表的方式来展示所有车站。这样思考有错吗？乍一看没错呀，满足了需求，可以完成呀。但是，这样思考真的错了。错在本末倒置。

正确的考虑应该是：我要用一种方式展示所有的车站，然后分析这个”所有的车站“，有什么特点（这里叫细化需求），怎么实现这些小需求（这叫详细设计），然后发现列表的形式最能满足我的需求（优先满足业务需求），且开销比较（学习成本低，使用难度小）。ok，所以，我实现这个需求的技术就是listview。

这样写，应该能理解吧。ok，上面两种思维模式，总结一下就是。一个是从技术到业务，一个是从业务到技术。前者我们可以说是螺丝钉，因为，哪里需要，他就去那里顶。后者，是上层思想的一种体现，以业务为导向，合理调度资源去实现业务。

说了半天，好像和纵向分解，没什么关系呀？那么，回到正题。

纵向分解，其实是技术分解

第一步分解，已经完成的情况下，到了第二步分解，技术分解。正如上述所说的，先把业务需求细化之后，那么对应的详细设计就浮出水面了，这个时候，就是实现技术代码的时候了。但是，在实现技术代码的过程中，我们会发现，有一些技术，是可以抽出去的，因为这些技术，是通用的。然后，我们就把这部分代码，提取出去，给大家共用。说到这里，大家应该就能想到一个东西“util”，没错，工具类，不过，如果接触过分层的同学，应该还能想到一个东西“common”，公共类，或者叫底层类。道理是说清楚了，那么问题来了，怎样去写这个“util”或者这个“common”呢？（别以为这个简单，如果简单，你就不会认为那些框架牛逼了，那些牛逼的框架，就是这样写出来的，技术分解，满足某个需求）。说实话，我现在的水平，离着这个技术分解还有一段路要走。说到这里，顺带提一下，张洪祥写的okhttputil，就是类似这样写出来的。

那么，我怎么去学会纵向分解呢？抱歉，没有速成法则，只有先迈出第一步，改变思维，强迫自己写代码时，先不准思考技术，只思考业务。先完成业务代码，然后补全技术代码。只有在长期的这样练习之后，慢慢去体悟，去总结，才能一步步做到技术分解。

后序：下一次写一篇关于技术的文章，http协议相关的东西，cookie和session。就是关于Android运用到的网络相关的吧，毕竟，思想再牛逼也得，技术支持才行