江苏龙网

  1. 首页 > 人文 > >

没有架构师的命，却得了架构师的病( 三 )


这样的架构师 ， 还要肩负着一个重大的使命 ， 修复开源软件的 Bug 。
在很早之前 ， 我一直误以为开源软件是很厉害的很 NB 的东西 ， 我一直以为这是完美的 ， 很久很久之后 ， 才明白 ， 所谓的完美 ， 都是用血和泪塑造而来的 。
不经过各种各样的验证 ， 环境 ， 使用的测试 ， 很难达到一个上线标准的稳定 ， 即便是上线了 ， 也有可能会出现之前完全预料不到的问题 。
可是 ， 如果你选择了这个框架 ， 出了问题 ， 谁去解决?
架构师 ， 他要开源码 ， 理解这些开源框架的思路 ， 然后去找有可能产生问题的地方 ， 再去修复他 。
我一直都觉得 ， 能看懂别人写的代码的人 ， 都是神 。 某段时间我去看一个 Heritrix ， 看的我神清气爽 ， 各种层出不穷的继承 ， 各种抽象类 ， 连着三天我欲仙欲死 ， 更加坚定了我死也不要 ， 也不允许其他人在项目里使用继承的决心 。
但是 Heritrix 从外表看起来特别牛 ， 他的抓取策略也很 NB ， 用的分布式抓取的解决方案非常轻巧 。 可是我我实在是不想再去读一次了 ， 在当时不读不行 ， 资料太少 。
那么 ， 一个架构师 ， 要对这些源码都了解么?又或者是 ， 他必须具备 ， 需要他去读源码 ， 他就必须读源码 ， 而且去优化的能力?这大概比提前懂源码 ， 更神奇 。
因为是有时间要求的啊 ， 简单来讲 ， 他需要在一个有效的时间内 ， 去弄懂所有的底层的东西 ， 说句实在话 ， 当有同事嘲笑我都没有完整的看过 TCP/IP 协议详解的时候 ， 我真的是无话可说的 。
对于特别底层的东西 ， 我确实了解的不够多 ， 可是架构师们不一样 。
没有架构师的命，却得了架构师的病
本文插图
架构师需要懂业务么?
有了这些 ， 就可以称之为架构师了么?架构师需要懂业务么?
是不是就可以每天看技术 ， 写底层框架(比如我们原来在搜狐用到的 DAL ， 数据访问层 ， 用起来简直是神器的东西) 。
没有不懂业务的架构师 ， 所有的架构 ， 都依赖于业务 。 所有的架构师 ， 也必须要去写业务代码 ， 不把自己设计的东西 ， 用在真正的项目里 ， 恐怕他们自己都不会知道 ， 这种架构设计的合理性在哪里 。
在某团购公司上市之前 ， 他们的 CTO 拿出来了他们的架构图给我看 ， 在给我看之前 ， 所有的技术术语都一样 ， 但是当我认真看了架构图之后 ， 我的困惑......
为什么 Memcache 要放在 Controller 层被调用?不应该是放到 Service 层吗?
怎么会出现你说的 ， 一个 Serivce 负责维护的数据 ， 也有可能被另外的 Service 去更改的情况?
每一个 Service 对数据的操作 ， 必须是独立的啊 ， 除了这个 Service ， 其他的任何服务都决不允许直接更改 DB 啊 。
而且 ， 怎么 Service 拆分了 ， DB 不拆分呢?这样的话 ， 压力大的 DB 会把全站拖跨的啊 。
那张架构图我看到之后 ， 感觉自己的认知被突破了 ， 原来可以这么做 ， 原来同样的 ， 类似的技术选型 ， 可以做出来如此艰难的东西?
就在我以为这其实就差不多是架构师的全部的时候 。 在最近一段时间 ， 我突然间发现了一个问题 。
为什么有的人代码写的这么烂 ， 很多写死的代码 ， 一点儿灵活性都没有 ， 更没有规范 ， 完全就是堆压 。
为什么有的人根本不知道怎么去抽象 ， 并不清楚怎么样积累成公共组件 ， 为什么他们改一个问题 ， 通常会引出更多的问题?
为什么他们的代码里的实现方案 ， 让人看完之后恨的牙痒痒 ， 想改又完全不能改 ， 毕竟 ， 正常工作的代码才是好代码?
很大程度上是因为 ， 很多程序员 ， 不懂的代码的扩展性 ， 不会面向未来编程 。
没有架构师的命，却得了架构师的病


推荐阅读


上一篇：创业板|2020.08.23周末重要消息汇总

下一篇：大众软件海韵发布8Pin转12Pin供电接口