在架构的演技过程中,容易掉进如下几个问题的大坑里:

  • “重复造轮子”:这句话相比有过几年工作经验的程序员不会陌生,但这种问题在架构设计中也非常常见。很多时候,尤其是新人,由于经验、视野问题,找不到可用的轮子,遍从头创建一个轮子。就算只有10%的差异,却要重写90%的代码,相比于成熟的开源软件,一两个人维护的产品很难持续。所以实际架构设计中尽量使用成熟、开源的解决方案,及时少量不满足的功能,多数情况也可以通过变通的方法解决掉,或者进行少量的二次开发以满足需求,而不是因为一点满足都要从头开始,再不考虑功能的情况下,这里的时间成本,人力成本,可维护性都是个严重的问题。
  • 脱离实际业务需求:需求决定价值,技术的价值在于满足了业务的需求,在架构设计中为了技术而技术,不考虑业务是否真实需要是没有任何价值的。一味求新求变,尤其是使用很多小众软件,而不考虑是否真正为业务带来价值,是不可取的,有事反而会增加系统架构的脆弱性,维护的难度,反而让架构更加不可靠。再一点就是一位追求大公司的解决方案,互联网行业有很好的分享氛围,网上能找到很多可以借鉴的资料,尤其是大公司公开出来的,所以很多人就变成了伸手党,一味抄袭大公司的解决方案,而不加任何分析,不考虑是否真正能为业务带来好处,一句“Amazon”就是这么做的,“Facebook”就是这么架构的,就成了最终的决策依据。但要记住,你不是Amazon,你也可能不是Facebook,你不一定有那么大的规模,也可能是面临不同的业务问题,所以不要盲目追求别人的方案,可以有选择地借鉴,但不要完全抄袭。

  • 避免无意义的重构:“铁打的营盘流水的兵”,随时时间的推移,架构还是那个架构,维护架构的人的人已经不是之前的那批人了,互联网行业发展这么快,人员流量也很正常,有事一个业务一两年甚至几个月就会换一拨人。对于系统架构,或者程序架构,后来的程序员面对前任留下来的东西旺旺是脸上波澜不惊,心中翻云覆雨,虽然谁技术是相通的,但不同的程序员、不同的架构师面对同样的问题是,态度可能不一样,也许系统中用的某些软件不是他擅长的,或者某些代码风格不是他习惯的,所以很容易就会滑向重构的坑,为了自己运维使用的舒服而把架构中大量的组件重构,而不考虑是否会业务带来价值,如果这种问题不解决,下一波人进来还会重复这种问题,就会不断进入重构再重构的恶性循环。所以为什么我推荐在架构设计中尽量使用成熟的方案,使用敏捷的方式,简单可依赖,才能避免不断滑入毫无价值的重构的坑。

  • 功能完成是完事了:很多时候,很多人认为只要功能完成了,满足业务需求了就是完事大吉了,但还要考虑后期维护,升级的问题。如果没有清晰的文档,教程、后来的人搞不懂架构的细节,面对业务升级,就会不算地打补丁解决临时问题,补丁摞补丁,整个架构逐渐腐化掉,最后积重难返很容易把原来的方案推翻重来,就像前文提到的,就会滑向毫无意义的重构的大坑里。

  • 技术解决一切:双十一秒杀为例,通过验证码,问题方式解决,就可以轻松缓解瞬时压力。

results matching ""

    No results matching ""