分享 《架构腐化之谜》随想

mvj3 · 发布于 2013年12月29日 · 最后由 zeeler 回复于 2013年12月30日 · 1856 次阅读
29

陈金洲 @mechiland 很早写的一篇文章,参加过RubyConf2012可能都看过,地址在 http://www.infoq.com/cn/articles/cjz-architecture-corruption

我觉得这是关于系统架构演化的很深刻的一篇总结分析文章,在经验上很足,对Java和Ruby社区很有启发意义。

最初提到的AOP的概念让我重新去维基百科 http://zh.wikipedia.org/wiki/面向侧面的程序设计 仔细看了一下,AOP作用的范围其实是可以远超过"日志和权限"的,说白了就是业务之外的依赖技术(或者说实现业务的DSL)才是难点,也是很多项目最终失败的原因。

发现我之前写的《人类思维和软件工程学》 http://mvj3.github.io/2013/12/15/human-mind-and-software-engineering/ 里的提到的三间段已经被 这篇两年前的文章在形式上做了类似的说明了,看来后来者走的坑都是一样的。

我把他对应的最终解决方案重新理解一下,"采用新技术"理解为"针对业务来说更精简的新技术", "重构到物理隔离的组件, 将独立的模块放入独立的进程"理解为"开源和Unix管道工具化", "形成高度松散耦合的平台+应用"理解为"资源调用管理的操作系统式开发"。

和"关于文档"提到的"想象一下现在的Rails3/Spring框架,他们往往有超过20个第三方依赖,我们却没有觉得理解困难,最重要的原因是依赖隔离之后,这些模块有了独立的文档可以学习。"一样,开源是把系统架构解耦和模块化的最好手段。

共收到 12 条回复
96

所以没事不要折腾架构啊 ...

29

#1楼 @bhuztez 。。。那不是只能待在别人制定的框架之内了么。如果框架解决不了,那问题就难解了。

1411

这个文章很不错,适合大的长期项目的技术主管来学习一下;另外,看到这个文章让我想起来马云曾经说过的一句话,大意就是:现在的阿里集团没法管理,因为他的管理能力可以管理的团队大小是有限的,那怎么办?拆!搞成一个个小公司或者小事业部。

29

#3楼 @zeeler 在理,不过难得的就是马云如何拆,如何重构整个阿里集团的人力资源。

172

我们当年一起专门也就这篇文章哦

7072

人脑的能力其实还是挺可悲的,"the number of chunks of information you can remember accurately with no memory degradation is only one",所以学习新动,分解问题就很重要,如果都连在一起。。。就很困难。

有一种处理legacy code的方法,是一边写character test,一边重构。代码乱了,感觉除了功力深的,没发写,所以要重构。然后写完了,可以把测试当文档用。 当然写测试,也需要很好的能力。。。

29

#6楼 @yfractal 嗯,所以代码就是写给有记忆限制的人类去读的,顺便让机器运行。但是人类不能和机器比如何去细枝末节地分析所有业务代码的程序语法树。

96

#2楼 @mvj3

不要提架构,千万不要提架构

trivial programming需要屁个架构啊。

能定义清楚schema和protocol就不错了

人月神话都说了,理解了数据之后,代码通常是可以丢掉的 ...

29

#8楼 @bhuztez

哈哈,“架构”这个词确实和“大数据”一样是忽悠人的:)

我也和你理解的一样,真正的架构都蕴含在HTTP,数据库,编程范式里了,而另外一端就是在一个项目里做细节性的编程。不过有些项目真的比较大和难,比如12306.cn,两端得很深地结合在一起思考。

人月神话说的”理解了数据之后,代码通常是可以丢掉的“确实没错,因为这里的代码指的就是业务代码,公司上下都理解业务,当然这代码就微不足道了。”数据“就是一种设计啊,它是我们好用的"家电"。

96

#9楼 @mvj3 12306.cn难个屁啊,就一个卖票的网站 ...

29

#10楼 @bhuztez 哈,不和你理论这个G点,我说的是它相对的在Rails网站中的技术难度排名(不要和我说其他框架或架构)。

1411

#10楼 @bhuztez 因为垄断了所以会难搞,因为供远远小于需求,所以会难搞,可以看看这个 http://coolshell.cn/articles/6470.html 搞好一个最大的卖票网站远比你想象的复杂,高并发会让所有简单的东西变得超级复杂

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册