昨天下午部门的日会的CodeReview期间出了一个很有意思的事。

    大家对一个上传Excel的功能提出了异议。

   这个函数是解析Excel对必填和部分业务规则做一些校验，有问题的数据标示一下保存回Excel返给用户，把通过较验的数据保存到数据库中。

  大家质疑的点是以上的逻辑是混在一起的，程序员的理由是一次要处理的Excel可能会有5万行，逻辑混在解析动作一起处理的话，解析中这一次遍历就可以处理完所有的逻辑，如果把解析部分和业务验证拆开的话，可能会对这5万行做二次遍历。

     在大家争论的时候，我又想到了立足点的问题。他从性能考虑有问题吗？其实，我认为也是没有问题的，但是造成的结果确实有点问题。把解析Excel和格式验证、业务验证堆到一起 势必会给后续维护的人造成很大的困扰，很难看懂、也很难改。

  但是，既然他从性能考虑是没有问题的，那问题出在哪呢？还是立足点的问题，我们的设计一定要基于某些基本原则，从某一点出发衍生出整套设计。系 统的设计首先应该回归到本质，那就是解决了什么问题，怎么才能优雅的解决；解决某些问题是系统被设计出来的源头，没有待解决的问题，系统根本不会有被设计的需求，就更谈不上怎么设计了。所以所有设计倾向一定要考虑，如何不在业务问题上妥协和怎么拓展；其次就是可维护性，可维护性意味着可以方便的转交给其他人、易懂、易改，这里面隐含了许多条件，比如要有合理的拆分、必要的提炼、一定程度的职责划分等等。以上的两个方面都考虑到了以后再说性能也不晚，因为有了上面的条件才能保证系统有合理的生存空间和优化的可能性，这时再说性能就合理了。

      把性能放到前面考虑会把所有的问题交织在一起，如何解决问题、可维护和性能交织在一起以后会互相影响。程序员会因为可能猜测的性能问题而要求整体方案妥协，影响对实际业务的问题解决，进而可能可维护性根本不在考虑的范围内了。但是初期猜测的性能问题可能根本就不是问题，而只是一种猜测或者某种写法的理由。出现所有逻辑混杂在一起的代码，虽然是基于性能考虑而诞生的代码，但是一旦出现性能问题反而基本不具备或 者很难进行优化，因为很难看懂、看懂也很难改。

       每个程序员都希望自己能有成长、技术可以进步、设计能力很强，去承担更重要的职责，但是能力肯定不是一夜之间具备的，如何才能一点点的积累到能力呢？日常的开发中我们要不断的寻觅技术点，设计从何而来，我们只是按照思维的惯性一行一行的码代码，每码一行就浪费了一行的机会，为什么会出现混杂在一起的代码呢？因为按部就班的思维方式就是那么一步一步的去做一件事，是不需要考虑如何抽象、如何提炼的，所以大部分项目最多的，也是最难维护的就是流水的代码，只是有时我们会给它冠于某种理由，听起来很合理。但是转念想，不就是流水的代码吗！有什么出奇的。设计就来源于我们在日常工作中对每一行代码的斤斤计较和孜孜不倦的追求更好的方式。把解析和校验分开以后是不是就做了抽象和提炼的工作，锻炼了这方面的能力，但是确实有可能会二次遍历，只是有可能，如果我们想办法解决了二次遍历，找到一种快速处理的办法，是不是就锻炼了我们的数据结构和算法的思维呢！日积月累你怎么会不成长呢。

    思考的立足于何处，就会引导着后续的一系列动作走向何处，并最终产生一个那样的结果。

   文艺点     一生二、二生三、三生万物    所以一是多么重要啊！！！

软件设计中的立足点