只有细节能够决定成败吗？
2019年马上就要过去了，突然意识到自己09年毕业，到今年已经整整过去10年了。真是岁月如梭、光阴似箭啊。
从大一学C语言后，就开始用C语言写练习，到如今也算写了14年的代码了。
记得刚工作时，大家讨论的内容是用table布局呢还是用div布局，10年后的今天再来看看这些事情，可能自己都会笑出声来。
是啊，10年间变化的不仅仅是技术的迭代、兴起与灭亡。还有人，包括自己在内，对很多事物的认知、看法或想法都发生了变化。
刚工作时，总是喜欢关注细节，会为自己又学会哪些知识点或写出了一段自认为还不错的代码而沾沾自喜。
10年后的今天，我更倾向于从整体上或宏观上去看待一件事情或一个事物，甚至去研究它的起因，变化过程或趋势，然后尝试着去推测它的未来。
但这并不是说，我全然放弃了对细节的追求。其实从宏观上观察有时会更利于对细节的理解。细节在关键时刻还是很重要的，毕竟有句话叫“细节决定成败。
无论各行各业，随着时间的推移，唯一不变的就是变化，无非是有的变化的猛烈，有的变化的轻柔罢了。
那么问题来了，“宏观”和“细节”在变化面前，哪个能够坚持的久一些，或者说变化的慢一些？
如果把“宏观”看作是整体架构或结构，把“细节”看作是实现方式或处理方法，你会优先关注哪一个呢？
细节还能决定成败吗？能，当然能。但是宏观同样关乎着命运，甚至影响着未来的走向。
从某种意义上讲，宏观应该受到的关注度更高一些，但至少应该和细节持平。因为“宏观”通常和整体结构对应，“细节”通常和局部处理对应。
整体结构一旦确定下来，后期改起来很麻烦，因为牵扯到的方面太多。但是局部处理因涉及范围较小，后期更换处理方法会相对容易一些。
无论是从理论还是实践来看，实现细节是变化最频繁的。所以我们应该做的是把整体结构设计良好，具体某个地方的实现细节根据实际情况而定。
不过很多人总是会陷入去关注细节，让细节占据自己的大部分思维，往往忽视了从宏观整体上的把握，或在此上面投入的精力不够。
程序 = 数据结构 + 算法
只要是计算机专业的，或半路转行但爱学习的，都知道这样一个公式，程序 = 数据结构 + 算法。很显然，这个公式是老外很早提出的，不过基本上所有人都是认可的。
我之前还看到有老外说过，在数据结构和算法这两者中，数据结构要更重要一些，它的重要性是要大于算法的。我个人是比较同意这个观点的。
比如，有这样一道题目，给你一个单链表，要逆向输出一下。拿到这个题目后，不管最终如何实现，至少要去想一想。
现在把这个题目改一下，给你一个双向链表，也逆向输出一下。拿到这个题目后，根本就不用想，直接从尾部向前输出即可。
可以看到，数据结构变了之后，实现方法一下子就简单了很多。所以数据结构的重要性是要大于算法的。可以说是数据结构决定了算法。
就像人们常说的，虽然条条道路通罗马，但有些人一出生就在罗马。就算你的排序算法再快，都不可能比已经有序根本就不用排序的还快。当然，这是极限思维的运用。
说起数据结构，很多人第一反应就是大学数据结构这门课里讲的东西，线性表啊，树啊，图啊等这些。
说起算法，很多人也肯定认为就是书上讲的那些，冒泡排序啊，快速排序啊，二分查找啊，深度优先/广度优先遍历啊等这些。
怎么说呢，这些其实都是非常学院派的说法，如果是一个学生或刚参加工作时间不长，可以这样来理解。
一旦到实际应用当中，相当于进入了工程界，脱离了学术圈，很多事情都要重新换个立场或角度去看待。
所以数据结构指的是数据的存储方式或描述方式，我们自己定义的接口啊、类啊这些都叫数据结构，并不只是List或Map这些才是。
同样，算法就是指解决问题的方法，我们平常写的一些代码也可以称为算法，并不只是像排序算法、哈希算法或选举算法这些才是。
好了，现在可以想一想我们写的程序代码，大部分都是什么样子的？不就是定义数据，获取数据，传递数据，操作数据，存储数据嘛。
定义数据就是类，获取数据就是查询数据库或从客户端提交，传递数据就是本地方法的参数或远程调用时数据的协议传输，操作数据就是各种运算/转换/排序等，存储数据就是类对象或容器对象或数据库等。
定义数据和存储数据就是数据结构呀，操作数据就是算法呀，所以，程序 = 数据结构 + 算法。
如果数据结构经过精心设计，那么算法就会变得很简单，如果再处理好数据的获取与传递，那最终写出来的程序，一定是非常棒的代码。
不信自己试试看。
软件 = 逻辑抽象 + 合理实现
离散的程序代码可能没有太大的意义，但是把它们堆在一起构成具有某种功能的软件就会产生一定的价值。所以从微观上看，软件就是一堆程序代码。
从宏观上看，软件又分为系统软件、应用软件和中间件。国内搞系统软件的应该比较少，大部分都是应用软件和一些中间件。但不管什么软件，最终都是在计算机上运行的。
那么计算机是怎么来的呢？不是土里长出来的，也不是树上结出来的，更不是某个物种进化的。它是人类的伟大发明，是抽象出来的，而且是符合逻辑的。所以在计算机的世界里，逻辑和抽象占据很重要的地位。
那么软件是怎么来的呢？可能是产品团队会进行市场调研，功能规划，界面设计和交互设计等。严格来说这些只能叫做原型或需求。只有当着手和实现相关的工作时，才是软件的真正开始。
从程序角度，软件的实现都是从逻辑抽象开始，无论是横向的分模块还是纵向的分层，或者说分子系统，只不过是不同的抽象方法运用而已。这个逻辑抽象是非常非常重要的，凡是存活时间长的软件，都是经过良好逻辑抽象的。
因为随着时间的推移，所有事物都在变化，良好的抽象更能抵抗变化，或更能适应变化，所以活的时间就会更久一些。
逻辑抽象是一个很复杂的问题，里面涉及很多哲学的思想或权衡的问题。比如，自动化程度高的软件，定制性不强，不容易满足用户的个性化需求。定制性强的软件，必定自动化程度不高，会造成用户难以上手，不容易普及推广。
大家想想Hibernate的消亡以及Mybatis的兴起，就是一个定制化大于自动化的结果。Linux用作服务器操作系统，需要专人维护。Windows用作日常办公系统，每个人都会用。平板电脑则走进千家万户，连3岁小孩都玩的很溜。无所谓好与坏，定位不同罢了。
所以抽象是一个综合问题，充满着哲学、权衡与取舍。没有特别统一的标准，也没有严格意义的对与错。只有你更关注什么，或更期望什么。
抽象完了之后，一定要能合理实现才行。不能为了抽象而抽象，最后无法实现，一切不能落地的，都是空谈。比如抽象一个脑机接口，把大脑和计算机连接起来，通过意识交流，这恐怕暂时真的实现不了。
总的来说，就是这样：
一、合理抽象，划分好子系统/模块，定义好功能边界、交互方式，这样整体结构非常清晰。
二、精心设计数据结构，定义好类或接口，这样会使代码写起来变的简单，而且后期容易改。
三、其实就是既从宏观整体把握，又着眼于具体实现细节，可称之为有勇有谋。
当然，这是理想情况，实际上是这样：
day 1
老板：“来来来，我有个需求给你说下”。
我：“好的”。
day 2
老板：“昨天的那种方式不好，按这种方式实现吧”。
我：“好的”。
day 3
老板：“昨天的那种方式好像还有点问题，按这种新的方式实现吧”。
我：“好的”。
day 4
老板：“昨天的那种方式好是好，可能别人一时不太好接受，要不还是按最开始的方式实现吧”。
我：“好的”。
day 5
老板：“多长时间能做好”。
我：“投入5个人，大概2个月吧”。
老板：“我给你20个人，半个月能弄好吧”。
我：“这个。。。”。
老板：“哦，对了，以后再招人，35以上的不要了啊”。
我：“好的”。
咦，莫非老板是在暗示我，因为明年我就35啦。
以上内容纯属娱乐，请各位老板不要当真哦。哈哈，祝贺自己毕业10年啦！