読者です 読者をやめる 読者になる 読者になる

プログラミング 美徳の不幸

Ruby, Rails, JavaScriptなどのプログラミングまとめ、解説、備忘録。

前任のエンジニアをリスペクトしよう

一人か二人で保守していたサービスがあって、そのエンジニアがなんらかの事情でいなくなったり入れ替わりで引き継ぐことになったとする。 こういうとき世間全体を見渡せば、前任のエンジニアが自分より劣っているか優れているか、確率は2分の1である。

しかしながら一般的に、前任のエンジニアはディスられやすい。というのは、たいていの現場では引き継ぎは不十分だったり、ソースコードには負債があるためである。

心に胸を当てて考えて欲しいのだけど、前任のエンジニアをdisったことはないだろうか? 今から考えれば私も「ここの実装はXXだ」とか「サービスに対して過剰に設計してる」だとか「テストがない」とか散々disってた気がする。 しかし最近は手離れしたプロジェクトが増えてきたので、言われる立場になることも多少出てきた。「初期の設計がおかしい」とか「拡張性がない」とか。

当時はプログラミング初めて3ヶ月とかで何もわかってなかったのをタダ同然でプロトタイプとして作ったようなもんなのに、なんだかんだ何年もそのまま使い続けて仕様も変わっていってる中でそんなこと言われても困りますよとか、言いたいことはいろいろあるのだけど上のdisも所詮そんなようなものでしかない。

というわけで、これからは建設的な開発のために以下のようなことを心がけようと思っている。

誰かに引き継いでもらう場合

  • 難解な設計は行わない
  • ドキュメントを作る
  • 技術的な負債や自分が気になっている点、開発期間を経て仕様が変わったことでおかしくなってしまっている点などは明文化する
  • 平均的なエンジニアが難なく引き継げるものを作る
    • そういう意味でReactとかってどうなんだろう?

誰かのものを引き継ぐ場合

  • 前任者disはあまり行わない
  • 学べるところは学ぶ
    • そのレポジトリに含まれてる全ての知識で前任者より自分が優っているということはほとんどない
    • 前任者のスキルが低くても、「スキルが低い人にありがちな設計ミス」などが分かる
  • 今のアプリケーションや仕様に対して、ソースコードがおかしいのはしょうがない部分もある。時間軸を考慮してあげる

お互い想像力を駆使したいところである。