新项目

八月底一位资深的同事离职,他手上的一个新项目交给我来带,简单的交接后同事就离职了。九月初开始上手这个项目,由于这个项目实际上是后台从老项目迁移,前端重新开发,其中使用到的技术基于微服务架构非常繁杂,简单列举一下:

后端:

  • 开发语言:Golang, Ruby, Shell
  • 开发框架:Sinatra (Ruby), Beego (Go)

前端:

  • 开发语言:Javascript (ES6)
  • 开发框架:React, Redux, Saga
  • 编译工具:Babel
  • 打包工具:Webpack
  • 包管理器:npm

基础架构部分:

  • 服务发现:etcd
  • 缓存:Redis, Memcached
  • 消息中间件:Redis
  • 容器技术:Docker
  • 容器编排:Kubernates
  • 容器安装:Helm
  • 数据库:Mongo

作为架构师我需要熟悉这一系列的技术,重新梳理架构,了解旧代码。吾生也有涯,而代码无涯,之后整个九月都很痛苦,到目前为止也仍然在不停学习中。由于项目时间紧,任务重,从一开始只有两个人,到目前增加了到将近六个人的小团队,仍然都在加班赶工。我自己有很长时间的Java技术背景,做过解决方案架构,又专门去学了项目管理,比较看重用户体验和项目组的氛围,接手这样一个项目之后渐渐会有些感觉不吐不快。政治上的槽点就不宜多说,单说技术和项目管理方面:

  • 这个项目有很多代码是从旧项目迁移过来的,一份代码被若干人改过,风格迥异。
  • 注释偏少(程序员的通病?),搭配一些奇葩的变量命名方式,让人抓狂。
  • 架构的文档少。
  • 接口更是没有文档,有时想调用某个接口,往往需要去直接看代码。
  • 代码日志输出不规范,后端代码调试困难。
  • 一些配置,例如IP地址, 被写死在代码里,直到碰到错误时才发现。

这些都是我们后面需要逐步去改进梳理的,有时在繁忙的工作之余,我会仔细思考一些问题:为什么我们越来越不快乐了,我们曾经是那么喜欢技术本身带来挑战和成就感?把时间耗费在修复前人因为种种原因而犯下的错误是不是对自己生命的浪费?作为对职业的尊重和责任,我常常感到非常无奈,这也许便是成长的烦恼。对于这个项目相关技术现象的几点看法,或许能解释一点点上述困惑,欢迎大家探讨:

  • 前端开发真的是日新月异,像 React 这样的技术虽然克服了传统前端开发的一些性能问题,但是缺少开发工具的支持,开发效率上未见得到实质的提升。现代前端开发我们实际上看到已经形成了一个非常深的技术栈:从开发语言,框架到打包工具等等。这使得前端开发的学习成本越来越高,这大概也是前端开发现在细分成一些专门的职位方向的原因。
  • 过分追求新技术,异构技术对于团队来说不是好事。从技术栈可以看到,我们使用到的语言,框架,基础软件是不少的,这大大地增加了团队,特别是一些新手的学习负担。在我看来,技术够用就好,最关键的还是能够满足需求,只有当一样技术无法满足需求时,再去考虑更新的方案。很多开源框架演进非常快,意味着一定的不稳定性,做技术跟踪也需要大量的时间。
  • 微服务治理是个很大,但是很现实的话题。虽然在为服务架构中,服务注册和服务发现已经有现成的软件去解决,但是仍然不够。服务之间的互相调用仍然是彼此交织在一起,分布在各种代码逻辑里,编织成错综复杂的调用网络,维护起来十分困难。
  • 产业界仍然有很浮躁的气象,虽然重复造轮子的事情少了,但是凡事都想拿来主义,比如原来可以用单一技术将一件事情做到极致,现在却多使用各种开源代码攒成一件成品,就好比苹果电脑和 DIY PC 一样,后者自然是很难做出精品的。

 

183 次阅读

4 Replies to “新项目”

  1. 花大量时间修改前人留下的错误,是对自己生命的浪费。深表同感!
    技术五花八门、层出不穷,面对具体项目时,需要秉承实用主义。深表同感!

  2. 我有一个疑问,为什么不重新写一遍代码呢?先罗列出来要实现的功能,按照自己的习惯重新写比修改别人的难道不更快吗?我只是个技术门外汉,冒昧地瞎说了一句,请见谅!

发表评论

电子邮件地址不会被公开。 必填项已用*标注