为什么所有的架构都是糟糕的

几乎在所有的软件项目| 产品中，软件架构师永远都是冤大头。

至少在我所经历过，参与过或是听说过的所有产品里，似乎没有任何一个软件架构是不被吐槽黑出翔的。现在想想，就在几个月前我自己也在吐槽某产品的架构烂透了。 天知道哪根筋错位居然因此挖了个坑自己跳了进去决定自己来做这个项目的架构，于是有了各种让人哭笑不得的故事。

大概，“烂透了”本身就是国内任何一个软件架构的宿命所在。只是曾几何时像鸭子一样伸长脖子看砍头的我如今自己来到了这个断头台上，周围的人们一如曾经的我，恨不得上来自己一刀把断头台上的人砍了，好抢在所有人前面吃到那个带血的馒头。

 

******以下纯属虚构，请勿对号入座***************

 

 

---------------------------------------- 邪恶的分割线 --------------------------------------------

故事一

“小A， 某某功能你帮忙实现以下吧，继承一下xxxx接口，到调一下xx类的xxx方法...blabla（比较简单的功能实现）..顺便熟悉一下现在的架构。”

若干天后， pm召集项目组开会了解进度。

小A：“xxx目前架构下实现不了，架构耦合度太高了。”

架构师:“哪部分由困难？哪里不好弄？”

小A：“xxx类和xx类里面好多锁， 完全不知道这些锁是干嘛的 ，很容易死锁，没法维护的(ps:这两个类和他要实现的功能毫无关系，只是简单的线程池调度实现，共享资源有加锁 )”

架构师:“晕，你看那俩类的具体实现干嘛，要用他们的时候只要调 xx方法就行了，你完全不需要关心实现，何况你压根不该用那个， xxx.dll在干些什么你知道吗?”

小A：“不知道，系统复杂而且混乱，我压根看不懂。。”

......

接下来基本就是这样的逻辑:

if( Relation(PM, Architect) > Relation(PM, A) && (count++) < PM.TrustRate)

PM.say(“回去再看看是不是你自己没看明白”);

else

咔嚓，人血馒头做成。

 

程序员的逻辑1： 如果某功能我做不出来，那一定是架构耦合度太高了。至于耦合度是啥意思，pm不知道， 因此他自然也不可能知道其实我也不大明白，管它呢，那么难做，耦合度肯定高。

程序员的逻辑2： 如果某模块式干嘛的我没看懂（那一大篇英文文档有病才会去看），那一定是系统复杂性太高了。不然怎么可能连我都看不懂呢？

 

我i想说: 尼玛，连哪个dll干嘛的都没搞明白你就说耦合度高？？？？让做个用户权限验证的逻辑跑去multithreading.dll 里面找完了抱怨有锁，你写不好多线程不意味着所有多线程都是会死锁没法维护的！

 ------------------------------------ 又是邪恶的分割线 ----------------------------------------

 

故事二：

某系统已经维护了2年有余，当时操刀设计的两个人和本人私交不错，据我所知两人技术水平了得，至少比我强一个档次。可惜两人双双已经离职，因为公司薪资竞争力每况日下，导致这两年招聘要求一降再降，一些优雅的老系统维护渐渐就成了问题。

某天和PM闲聊，谈到上述系统。

PM:“(blabla一堆闲聊前文)， 所以软件架构很重要， 像我们当时那个X系统，当年xx做的，问题很大，现在没人看的懂，又要重新做过。。”

我:“有文档留下来啊，怎么会没人看得懂”

PM:“原来的系统设计太差了，没法用, blablabla”

我也就没再说什么。pm不是做技术的，系统设计太好或者太差当然不是他自己看出来的。至于是谁告诉他系统设计太差，要说现在团队里会有人比当时的设计者技术强， 我绝对不信。 同样是做技术的，随便聊两句就能大致知道对方几斤几两，然而PM可能知道吗？他当然更倾向于相信在职员工而不是已经离职的人。

结论：如果你不幸做了某系统架构设计然后离职走人，上帝知道你会不会哪天打喷嚏到窒息最后一命呜呼。

 

 ----------------------------------最后一根邪恶的分割线 --------------------------------------

 

某天有人抱怨系统有一个模块设计不好。那是事实，那个模块可谓是当前系统最失败的设计之一 （PS:厄，确实是我设计的，略烂..）。

于是某天开会：

我:"X模块设计不大好，现在考虑把它重构下"

某资深程序员:"的确阿，你看XX和XX有耦合，xxxx不符合xxx最佳实践。。blabla（以下省略1000字长篇大论）"

我(心里说"似乎可造之材，搞不定可以培养下看看"):"那你看看试试把它重构了呗"

资深程序员:(略慌张的) “那 ....那..我最近时间精力有限。。。blabla..”

最后的结论： 作为资深程序员，最优雅的方式就是尽可能地指出不好的地方，但绝对不要实际参与改进。 兵无常势水无常形，在不确定是否会赢的情况下，绝对不要拔剑。

 

 

 

结论的结论：

在沟通能力变得越来越重要，大家都追求德智体全面发展，加上做技术长远看没前途的大背景下，

在越来越多的程序员“沟通能力” 远比技术能力强悍的时代中，

作为向产品负责的PM,如果很不幸你不是技术出身，软件架构就会彻底成为<罗生门>，每个人都说着不同的故事，谁也不知道谁说的才是真相。

而剩下的，只有交情，信任等等，这时候，请双手合十祈祷专精技术的员工，在建立交情和信任方面要比其他人来的更强。