0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

PMや部長レイヤーに開発現場から伝えられていれば良かったこと〜レガシーコードからの脱却より〜

Posted at

はじめに

レガシーコードからの脱却を読んで、とてもいい本だと思ったと同時に、
20代の自身が知っておけば良かったことを記載しています。
自身の力や配慮が足りなかったことの戒めや反省です。
(あまりQiita向けではない気がしますが・・)

下記の問題で疲弊して悩んでいる方や
この記事を読んで、興味が出てきた人は、
本書を買って読んで学んで頂ければと思います。

  • ソフトウェアのバグや不具合が多くて困っている
  • ソフトウェアのリリース頻度が遅くて困っている
  • アジャイル初めてみたけど、なんかうまく回っていない気がする

うまくいってないことに対するインパクトについて

まず、うまくいっていないこと自体は残念ながら特殊な状況ではない(我が会社だけではない)ということです。
本書であげられている例を要約すると、2002年時点のある調査で、アメリカだけでソフトウェアの障害が600億ドル規模で失われていると記載されています。
大体今の(2019年12月1日時点で)任天堂の時価総額より高い、というとPMや部長レイヤーにも伝わる(伝わった)と思います。

現場と上のレイヤーとの認識の違い

開発者がソフトウェアの開発を行うときに、何に時間を費やしているか、
その理解をしてもらうことから始めるのが良いと思います。

特に、開発経験がない人たちには、現場との認識のズレが生じやすい箇所だと思います。

ここは大体本書の通り、

PM・部長レイヤー:コーディングに時間がかかる
実際の現場の結果:仕様書を読んだり、ドキュメントを書いたり、会議に出席したり、デバックに多くの時間が取られている

という状態になっている(た)ことを伝える必要があります。
まず、コーディングという機能という価値を生み出すところに、多くの時間を割くことができていない、という現状を証拠を揃えて伝える必要があります。

なんでコーディングに時間が取れないの?

この質問に対しては『ソフトウェア開発が複雑である』という前提を理解してもらう必要があります。
『なぜ複雑なのか』については、人によって色々と答えがあると思いますが、
まず現実が複雑であり、人がその現実で無意識に行なっていることを(しばしば他の人の頭から)抜き出し・洗い出しを行い、それをコンピューターに対して、正確に伝える(コードを書く)というところにあると、いう回答が当時の自分にも刺さるでしょう。

また、ソフトウェア開発に対して、今のやり方が良くないことを本書のような例を持って、異議を伝えるべきです。

ソフトウェア開発プラティクスに従うことは手術の前の消毒のようなもので、どのようなソフトウェアを開発していても正しく行われる必要がある。
従わなければ最近が患者を殺してしまうように、たった1つのバグがアプリケーションを殺してしまうかもしれない。規律が必要だ。
p.47-p.48

レガシーコードを放置するべきではない

本書では、レガシーコードというキーワードが頻発しますが、
ここでいうレガシーコードとは、マイケル・フェザースのレガシーコード改善ガイドを引用しつつ、

テストのできないコードをレガシーコードと定義している
p.6

としています。
それだと、当時の自分や上のレイヤーの人には、少し伝わりづらい可能性があるので、
『修正や拡張といった作業が難しいコード』
と言うほうが伝わりやすいかもしれないです。

機能の追加や修正といった手を加えることにより、正しく動くかを担保すると同時に、
機能の追加や修正が行われる前のソフトウェアと同様に、他の機能が正しく動くかも担保する必要があり、
その担保はテストにより担保するので、テストのできないコードを放置するべきではない、という論法です。

また、(ユニット)テストを作るためには、先にある程度優れたコードがないと、
テストができないので、コード品質も重要という点も述べた方がいいです。

しかし、優れたユニットテストを行うには、テスト可能な優れたコードがあることが前提となる。これはレガシーコードには当てはまらない。
したがって、コードを整理して、先にいい状態にしなければいけないことになる。これは言うは易く行うは難しだ。
p.7

とはいっても納期、お客様の要望いっぱいあるんだけどどうするの?

要望に関しては、本当に必要なものを精査できる立場、ないしはここまでで聞く耳を持っていただけているなら、5章をまるっと読んでもらえると、とても助かります。
本当にその機能がいるのか、それを突き詰めてもらえると、いくらか案件は消せたと思います。

リファクタして意味があるの?

まず、すべてのコードをリファクタしたい、という要望は絶対に通らないことを理解しましょう。また、リファクタを行うことを本書のように、負債を返すことの重要さをきちんと説明できるようにすれば、リファクタを行うこと自体は受け入れてもらえるでしょう。
そして、本書のような7つの戦略に従い、行うべき対象を正しく精査し、少しずつでも負債を返すようにしていくことが大切です。

終わりに

以上、本書には色々と学びがあり、過去の自分に本書のようなものに出会えていれば、
もっと色々と幸せになれたかもしれません。

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?