非常感谢分享

【评论来自文中主角】

怎么抽象？
有感而发，随便闲谈。

个人觉得关键是要有“随时进行抽象”的习惯。每个人作抽象的过程和方式都不太一样，那是各自的秘诀。

记忆中刚出校门的时候最容易犯的一个错误就是：拿到一个模块，就绞尽脑汁的在编码细节中打转，然后就写出一个长长的极其复杂程序来。状似面条,戏称为面条程序。
然后有人告诉我一句话：“写代码的时候不要简单的为了实现而实现，而要尽可能的把你的代码细节影射到一个相对直观的概念上”。
其实就是说我们定义一个变量，，写一个循环，一个函数等等的时候都要随时问问自己---它有没有简单明确的概念。
如果没有那么是不是就意味着我们要分解一下概念或者更换概念（调整结构，分解函数什么的）。
从那刻开始，才明白编码细节中逐渐有意识的培养自己“随时关注概念，分解概念”的编码习惯。

后来逐渐面对一个相对完整的系统问题时候，发现自己面临了两类问题。
第一类问题和上面提到的类似，仍然是概念的提炼与分解，变更等等，只不过由于站的层面比以前高，所以面临的概念更多，更复杂。
对于这类问题的抽象与分解没有什么准则，注重在于最终评判的时候是否存在大家认为相对复杂的概念。如果有而且无法回避，那要小心了。
过程上重点在于个体思考理解，群体讨论（讨论的基调在于个体思考理解的结果，以及对他人结果的分析理解。切忌不深入理解而讨论，那个容易变成吵-----头脑风暴除外）

第二类问题则完全不同，而是考虑到软件实施过程固有的一些诸如僵化，脆弱等问题（联想一下设计模式的诞生），而蹦出来的一些全新概念。
对于这些全新的概念，懵懵懂懂之间又回到了开始的不断模仿学习的阶段--
掌握脱离框架的底层技术细节、阅读框架、遇到实际问题或者在头脑中模拟一些问题去尝试不依赖框架而是使用原始技术构架自己的解决方式并和依赖框架的解决方式对比思考优缺点
并把自己的思考结果（尤其是自己认为更好的解决方式）去求证（讨论，阅读等等）。如此反复，不断求证，不断超越。（不要耽误工作进度，不然会被老板打PP, :)）

（抱歉在这个模式与框架满天飞的年代，我使用了全新这个词。因为如果个人不把软件实施的技术方法作为一个专门的问题域来深入理解的话，
模式与框架里面蕴含的概念，只能做为节省代码的工具被动的存在。其实对于满足工作要求来说，足够了。只是对于程序人生来说，也许稍欠缺）。

罗嗦了一些过程，最终还是没有说明“如何做抽象”，因为那个东西似乎不可说。
最后忽然想起来我第一个公司的技术总监有一天把我们程序员召集在一起说了一句话：
“我觉得咱们公司里面最会写程序的人不是你们这些人，而是那边的那个出纳员。因为她比你们更懂得怎么认识理解问题”。
当时觉得玄之又玄，现在想起来可不就是如此。

共勉。。。