关于多时区引发一系列的问题

  1. 背景
  2. 头脑风暴
  3. 沉思

背景

最近公司走国际化路线,所有相关产品都要牵涉到时区问题,包括我现在负责的酒店客房系统。

很多会说,多时区的话只要使用UTC的话就能解决,数据库保存UTC,显示的时候根据不同时区显示就好了。
话是没错,但如果是新系统新应用的话确实可以这样做。但如果像一些运行了多年的系统,并且这个系统还会运行在多个时区的话,那这个方案可能不行了,因为开发周期太长了。

头脑风暴

为了上述问题,各个技术主干头脑风暴,共同商讨对策,目的用最短的时候能够使应用国际化。
最终我们确定了一个方案(因保密原因,暂不能公布),虽然方案大家都觉得不错,但我却陷入了沉思。

我目前负责的项目是从.Net转成Java的,但在转之前,我经历了很长的一段时间把他改成了面向对象的设计,包括清除了所有的存储过程采用ORM的方式。
但我知道,还有很多项目并非采用面向对象的方式设计,还有众多的存储过程,所以我明白在后续的改造中,将会是一场恶战。
那造成这种局面的原因是什么呢?

沉思

相信大家面试的时候,经常会被问的,面向对象是什么,有几种特性,最简单的问题却在使用中我们却不常见。
为了赶进度,赶目标,我们把最好的设计都统统抛开,只为凑活的完成功能。在完成的时候我们想着以后要重构,但真的会吗?

其实我经历过,我的领导是一个合格的管理者,但并非领导者和技术者,他对项目的理解只是完成。
但对于我这种完美主义者,我想的更多的是扩展、维护、高可用性,为此我们也爆发了多次的冲突,结果可想而知。

而我负责的项目,只是公司众多项目中的一个,我知道如果我的项目去改造,可能一周时间就可以搞定,但其他项目呢?我预计在1-2个月,而且不算测试时间。

是何种原因造成如此大的差距呢?

首先是技术能力。每个人的技术能力皆不同,所以每个项目完成的情况也都不一样,但我知道一些加班加点的项目,基本上都是为了凑活而完成的,所有的思想都是面向解决问题而非技术架构。
这类应用在这次的改造中,会遇到巨大的挑战。

其次是开发标准。因为在工作经验上的优势,我曾提出过一些改进方案,最终都没有得到任何反馈,所以现在我也明白了,我的领导或许不需要建议。
但作为架构师来说,我明白开发标准的意义,他带来的不是一个规范,更多的会让你的项目开发周期变短,你的维护成本缩小。
有时想想真的可笑,一个以技术著称的企业,却没有几个技术出众之人。(关于开发标准,后续我会另开新篇把自己的想法说一说)

可能疫情的关系,公司很多问题都暴露出来,大家表面心和,但各自还是在暗暗较劲,勾心斗角,我曾在入职没多久提出服务化架构及开发标准等,但这些并没有由我的领导反馈给公司。
大概在今年,其他小组提出了改造方案,并获得大领导赏识,我的领导却只是附和。领导善于画饼,但当你真的能力突出的时候,他却会用权利来压你,很心塞。

当然我相信我们公司还是会更好的,我还是会有很多机会,相信各位也是一样,加油!


转载请注明来源,欢迎对文章中的引用来源进行考证,欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论,也可以邮件至 james@taogame.com

文章标题:关于多时区引发一系列的问题

字数:1.1k

本文作者:脑洞的蜂蜜

发布时间:2020-10-02, 17:13:02

最后更新:2020-10-02, 18:13:47

原始链接:http://www.jamesying.com/2020/10/02/think-about-multiple-timezone/

版权声明: "署名-非商用-相同方式共享 4.0" 转载请保留原文链接及作者。

×

喜欢就点赞,疼爱就打赏