如何与老项目恋爱 当我们无可避免的要与老项目恋爱时,怎样才能让自己愉快一点呢? 请尝试以下几点: - 用学习型心态来面对
- 不断设立小目标
- 迭代式重构
- 记录你的经历和思考
- 尽人事听天命
稍稍展开一下吧。 这点是最重要的,我们要多想想:通过解决 Bug 、二次开发等,我能从这个老项目中学到什么。比如你有可能学到这些: - 业务逻辑
- 好的软件架构设计
- 不好的设计
- 我之前未接触过的技术
- 如何重构
学习型心态,以解决问题为目的,关注如何解决问题,关注自己在解决问题中可以收获什么。 如果你拥有这种心态,开发工作就会有趣一些。如果你是消极心态,总骂着“靠,怎么这么多烂 Bug !”,那你的工作就充满了撕扯、抗拒以及各种不愉快。 对于老项目的维护和开发,要化整为零,每次就解决一个小问题,每次都给自己一个小目标,这样比较现实,Bug 、需求等小目标实现了,也会给自己一些正向激励。 如果目标太大,就拆分开,一两天完成一个小的,让自己不断有成就感,这样就容易坚持下去。 有时你接手老项目,很长时间就是阅读代码,那这个时候,就给自己定一些目标,比如今明两天了解认证鉴权的逻辑,再接下来了解这些逻辑和代码的映射关系……这样一头大象就可以一口一口的吃,不至于无从下嘴。 如果你自己无法分解你的目标,就找熟悉的同事,或者你的经历,一起讨论出一些目标,再一起拆分成小目标。 相信有不少朋友和我一样,看到不顺眼的代码,阅读时拒绝感很强烈,总想着重写、重写、重写,以为自己出手重写一遍,世界就会美妙起来。 我干过不少这样的事情,但是,后来我发现,当我把所有要支持的功能都叠加进去,所有意外情况都处理了,之后,我重构出来的代码,居然和原来我讨厌的老代码差不多了…… 所以,现在我知道,在我想推倒重来之前,要先了解状况: - 这个项目的需求是什么
- 老代码的历史是什么
- 老代码是如何走到今天的,中间处理了什么状况
- 如果局部重构,该从哪里开始
虽然开发者很重要的一部分工作是做设计写代码,但实际上,阅读代码是比写代码更重要的能力。当你搞不明白一份老代码的意图时,贸然推倒重写,往往会陷入泥沼。 所以,最现实的策略就是,每次都结合你要修改的功能或者 Bug ,设定较小的重构目标,比如改几个函数,改两个类的接口等等,这样既容易实现,又能够让老项目慢慢变好。日积月累,这样微小的重构就可能发生巨大的作用。 我们很讨厌别人的代码没有文档、注释,可是我们自己的代码往往也是如此。让你去看自己两年前的代码,你可能就会讨厌它们,不忍卒读。 所以,当你接手老项目,有一项非常重要的工作可以做,就是记录你的经历和思考,显性化你取得的进展。 在你理解老项目业务逻辑、代码逻辑,修复 Bug ,新增功能的时候,把必要的注释加上,把核心的逻辑流程绘制出来,把不全或缺失的设计文档补上…… 这样做有巨大好处: - 自己能看到自己的成果,有正向激励
- 方便自己以后维护,提高效率
- 方便后人维护
- 提升项目质量,降低整体成本
这也是我们自我成长的方式,只有记录和思考,你才能不断复盘项目复盘自己,才能每做一件事情都有收获。 前面的要求可能有些高,很多人觉得难以达到。没关系,我们并不是要把自己逼死,相反,我们这些要求,是为了做好项目,更重要的,是为了自己的成长,让自己有良好的自我感觉。 而,假如,你面对的情况非常特殊,你的努力几乎改变不了根本问题,很难取得突破,那这个时候,心态也要放平,要有“尽人事听天命”的豁达。 活人不能被老项目逼死,对吧,尽力去做,真做不好,可以尝试换个角度、换个项目再做做看。 不要过分苛责自己,也不要因此认为自己能力不行。这个老项目你搞不定,只能说明你在这个项目上失败了,你理解老项目遇到了困难,它真的不能说明你这个人就彻底不行。你可能很善于做技术探索,很善于架构设计,精于某类算法……我们得客观评价自己,知道自己的长处在哪里,努力把自己放到能发挥自己长处的项目中去。 要对自己负责我们要有专业精神,努力解决问题创造价值,但另一方面,也一定要对自己负责,不要把自己逼死。 如果你觉得老项目真真是让人难以忍受,多看一天人生就多灰暗一天,那就尝试离开这个项目。 有两种方式离开一个老项目: 该离开的时候,就果断一些,更好的位置,出门左转,就在拐角处。
|