はじめに
この記事は「プリンシプルオブプログラミング 3年目までに身につけたい一生役立つ101の原理原則」を読んだ際に記した議事録です。
著作権の関係により、詳細には書きません。詳しい詳細を知りたい方はぜひ本書を読んでみてください。
プリンシプルオブプログラミングをPOPと訳します。
What : 問題コードはゼロではなくマイナス
プログラムをコードする際、二つの道があります。
一つは、時間がかかっても綺麗なコードを書く。もう一つは素早く汚いコードを書く道です。時間がある場合は常に「綺麗なコードを書くべき」です。しかし、時間がない場合などは素早く汚いコードを選択する場合もあります。ただし、「素早く汚いコード」はソフトウェアとして負債を抱えることになります。これが技術的負債です。度をこえた負債は「お金の借金」と一緒で利子でふくらみ、立ち行かなくなり、返済不能になってしまいます。
多数の負債を抱えたコードは利子が指数関数的に大きくなり、アンタッチャブルなコードになってしまいます。
Why : 雪だるま式に膨らむから
技術的負債を放置していると、遅かれ早かれ追い詰められていきます。借金を返済せず、将来を担保に借用し続けると自分の負担は雪だるま式に大きくなっていきます。ですので、ソフトウェア開発においても技術的負債の考え方を取り入れて、この借金をコントロールしていかなければなりません。負債から目を背けるのではなく、しっかりと向き合いうまく付き合っていく必要があります。
「汚くても動いているからいい」「動いているものをわざわざ触る必要もない」という考えの人がいます。コードを綺麗にする必要性はコードを書いて保守した人でないと、実感しにくいものです。自分のことではなく、読み手のことを考えてコードすること必要性があります。
How : 問題コードを管理しよう
「技術的負債」の考え方を取り入れて、問題コードを管理するようにしましょう。技術的な負債の利子を想像する余裕はないかもしれません。しかし、深刻な障害が発生した際に、できる限り素早く修正をするor大きな損失を受け入れるかの選択が迫れらたときに、コードの修正を選ぶのは誤った選択ではありません。
根本的に解決するにはそもそも「負債となるコードを書かない」ことが一番良い選択です。もし汚いコードを書いたとしても少しでも早く、「綺麗なコード」にします。
「技術的負債」の考え方を取り入れて、サービスの運用ができればビジネスが必要とする迅速な対応を提供できるとともにプロジェクトを借金地獄に追い込まなくて済みます。もし、負債を抱えてしまう場合はドキュメントにしっかりと残しておいましょう。
問題コードの生まれる誘引
以下のことが原因で問題コードは生まれやすいです。
- 経験不足のプログラマ
- 締め切りのプレッシャー
- 読みにくいコード
- 特殊化されたコード
- 悪い設計
また、下記のようなチームの文化も悪いコードを生み出す有印になります。
- そもそも綺麗なコードを書こうとしない
- 不明瞭なコードを受け入れる
- リファクタリングに時間を割かない
- リリース直前にテストを実行する安易にコードをブランチさせる
終わりに
この記事ではプリンシプルオブプログラミング 3年目までに身につけたい一生役立つ101の原理原則の議事録を自分用に記しています。
この記事ではカバーしきれていない部分も多いので、是非本書を手にとって読んでみてください。
次回、「【POP81】プログラマの3代美徳について」です。ぜひ、次の記事も読んでみてください。
