最近跟一些同学聊了下他们设计的架构，听了下他们的思路，我突然想明白了其实大家技术都很强很能干都能搞出很好的架构，层次分的很清楚，哪块代码写哪里，框架怎么封装，各种东西给你安排的井井有条。但唯一让我感觉纳闷的是，这个架构貌似少了些许灵气。
对于架构，基本上有两种说法，蓝队说一个项目一开始并不需要架构，先堆code上去，等它第一版出来了再重构把架构加进入，因为如果你不能迅速出来第一版，那么你的竞争对手就先比你出第一版，他们可能代码比你的代码还烂，但是他们拿到了市场赚到了钱，所以他们第一版出来后还能在那里重构，而你第一版还没出来就已经丢了市场，到时候再想重构都没有这个机会了，公司已经倒闭了或者你已经被裁了。
红队说要看long term，如果项目一开始不把架构做好的话那么其实你以后就没有机会再改进架构了，因为项目一旦开始你与你竞争对手的竞争就已经开始了，大家都在比谁跑的更快，光加速跑就耗尽了所有力气，哪还有时间来重构呢，最后技术债越来越多，代码就越来越烂，无法维护，公司就输掉。
不幸的是，我对这两种说法都不赞成。
对于架构，我想一个最大的误解其实并非是技术上的，而是哲学上的。大家的思维模式都错了。
还是伟人说的好啊，要用发展的眼光看问题，所以为什么要把架构看成是一竿子捅到底就能完成的，看成做一次定好整个架构后大家就都follow了就不会做第二次的东西呢？我们为什么就不能用发展的眼光来看架构呢，架构为什么不能是一个连续性很强的伴随项目一生的需要随时间而不停的进行调整的东西呢。
架构不是feature，不是做完就好了，架构是项目的终身伴侣，架构的一生就是项目的一生，架构和项目的默契程度需要用项目一生的时间来不断调整。
对于蓝队，我要反驳说怎么能一开始就没有考虑架构呢，那一开始脑子里根本就没想过架构的事情，你以后怎么refactor呢，没有目标的refactor那也估计就是瞎refactor吧。如果你一开始没有想一下架构的方向，没有对code有点约束的话，那等你refactor的时候就会发现一堆不知道什么烂东西，你根本没法下手refactor啊，再花一年重写吗，辛辛苦苦打下来的江山是不是要拱手送给后来者了。
对于红队，我要反驳说怎么能一开始就把架构做的很好呢，这显然是不可能的。你搭了那么大一个架子有用吗，你说是为了应对未来的需求，那难道你能预测未来吗，你花那么多时间精力做了一个这么大而全的架构，可里面80%都是根本不会被调用到的接口。什么你说以后会有用，好吧那我即便假设到了第二版第三版会有用，那你这个架构做了半年又是怎么回事呢，别人第一版已经发出来了，你架构还没搭好，你的架构现在有赚了一分钱了没有？
还是伟人说的好啊，与时俱进啊。我们的架构难道不是同样要与时俱进的吗。在我看来，一开始绝不能没有架构，脑子里要时时不能忘了架构，实践上就弄个简单的就行了，满足现有需求即可，不要过度设计。船大难掉头，难道花个半年做了个大而全的架构，再花半年把它再精简回去吗。
不见兔子不撒鹰。架构是一个长期动态的过程，而不能静止的去看它。因势利导，项目一开始是没有势的，或者说各方向上都有势，而你已知的信息太少，连用户使用习惯都不知道，因为此时项目还什么都没有。所以你无法判断势今后将会往何方发展，你只能根据现在势的形状给出一个简单粗糙的架构，that's enough. 但等到第二版第三版，势必然会朝某一个或某几个方向发展，你每天在写代码的时候就会感受到势的发展方向，此时因势制宜的将恰到好处的架构套上去，不多不少，不肥不瘦，给以后的进化留下足够的空间，又具有精准适当的一点点前瞻性，(闷声发大财)这就是最好的。
敏捷、拥抱变化说了这么久，并不是说的技术层面，而是思维层面。
以上，就是研习架构的心法，说来说去，其实只有一条原则，本人已和盘托出，修行主要看悟性。
网友评论