架构之路:前言目录
终于决心再一次开始这个系列的博客了。之所以说再一次,是因为我之前曾经试着写过这样一个系列,但中途却不得已停了下来。我总记得“之前”就是一两年前,查看博客后才发现原来那居然已经是三年前了!不禁感慨岁月如梭,时间都去哪儿了?大概我转行做软件开发的时候,我的小女儿也开始孕育。如今,她已经是亭亭玉立的一个小姑娘,天真浪漫;而我这六七年的收获呢?
我学计算机学开发,目的很明确,就是奔着“架构”来的。当然,最初我不知道这个名词,我以为我就是去学“做网站”的。什么时候能够学会?最开始我以为三个月应该够了,然后延期到六个月,再延期到一年、两年……直到现在。在这个过程中, 我算是深刻的体会到“学无止境”,或者“学得越多越觉无知”是什么意思。
三年前觉得自己应该有资格可以显摆一下了,但到中途却越来越迷茫困惑,所以不得已再去摸索实践。没想到,这一摸索实践,又是三年过去了!三年过去了,实事求是的说,我比三年前更心虚了:一些以前深信不疑的观点变得犹豫起来,一些从未有过的想法时不时的蹦了出来,新的技术猛烈的冲击着旧有的体系……我会不会还是误人子弟而已?
思前想后,我还是下定决心,重新开始这个系列。因为我百分百的相信,即使再过三十年,我也不会成为一个完美的架构师拥有一个完美的架构。所以,没有必要等到“完美”,也不可能有真正的“完美”。就在现在吧,把我的所学所思所得都展示出来,和大家一起交流碰撞,于人于己,都善莫大焉。
架构太难了!准确的说,是把架构做好太难了。
我曾经把技能分为两类:会和好。比如:“我会写字”和“我字写得好”,这完全是两种不同的境界。“会”其实很容易,而“好”则很难。而很不幸,架构就是一个专注于“好”而不是“会”的技能领域。任何一个系统,无论大小好坏,都有架构;所以只要能开发出一个系统,就已经“会”架构了。但我们的关注点,显然在于如何进行“好”的架构。这个问题如此难以问答,以至于我还没有发现过一本专门论述该问题的书籍。被奉为经典的《企业应用架构模式》更像是一个架构汇编,告诉我们有哪些哪些架构模式而已(当然,我们不能否定它的巨大价值);其他类似的书籍实际上也未能给出明确的答案。在网上,相关的问题通常最后演变成一场“口水战”,让人眼花缭乱最终不知该何去何从。
我实在查不到这段话的出处,但大意是:为什么讲解架构这么难(比如为什么要分层要抽象要封装)?因为如果没有一个足够复杂逻辑的例子,就无法展示这样做的好处;但如果给出一个足够复杂逻辑的例子,就不得不花费大量的篇幅首先讲明这一堆复杂的逻辑,而读者在晕头转脑的理解这些复杂业务逻辑之后,很难再有精力来思考架构的技术问题本身。
所以我最后决定采用这种方式来学习:自己去搭建一个有足够复杂业务逻辑的系统,在实践中一步步的学习领会各种架构知识。这是一个很笨的方法,但确是一个很有效的方法。伴随着系统的不断开发完善,书上的很多说法得以印证,我之前的很多想法得以改变。每写一行代码,我都能感觉到我的一分进步!软件开发是一门实践艺术,坐而论道往往不如身体力行,正应了那句话,“纸上得来终觉浅,绝知此事要躬行”。
所以,接下来我将以两个目前仍在开发的项目(详见:英雄帖:开源项目招募英才)为例,一步一步的讲解,如何通过领域驱动和测试驱动,进行敏捷开发,构建一个面向对象的B/S系统。
- 点赞
- 收藏
- 关注作者
评论(0)