保守性の高いコードを書くのに必要な事

どうも、畜産ペンギンです。

 

今日は保守性の高いコードを書くのにどういった事が必要なのか語っていこうと思います。

 

この記事は実際にどういったコードを書けばいいのかというハウツーだけでは無く、実際にコードを書く事以外の作業、方法論やシステム作りに重きを置いています。

 

では、実際にどんな事が必要なのか調べた中でいくつかピックアップしたので見ていきましょう。

 

目次

・目的を定める。 ・ビルド、結合、デプロイを細かい単位、自動で行う。 ・協力しあう。 ・「CLEAN」コードを作る。

 

目的を定める。

はい、基本ですね。

やはり何事も目的を定めるのは大事です。

 

目的自体の重要性については割愛しますが、その為の手法として受け入れテストに明確な基準を設定しておく。というのがあります。

 

受け入れテストをクリアすれば無事リリース出来る訳ですから、開発を進めえる上でこれほど明確な基準は無いでしょう。

 

そして、予め目的を定める事によって行ったり来たりを無くす事によって余計なコードを無くすといった考え方ですね。

 

ビルド、結合、デプロイを細かい単位、自動で行う。

大抵のプロジェクトで、テスト工程が進む度にローカル環境・テスト環境等で動作確認やテストの実施等を行うと思いますが、これらをすっ飛ばしてシステム間の結合で初めて書いたコードの動作を確認をすると考えたらどうでしょう？

恐ろしくて仕方無いと思うのが大抵の人だと思います。

 

まぁそれは極端な例ですが、「動かしてみて確かめる」というのは結構手間をかけてやってるプロジェクトもあったりして、これを手軽にする事によって誤ったコード等を取り除く負担を軽くしていこうって事ですね。

 

最近ですと、これらの自動化は大抵ツールで自動化出来るので積極的にやっていきたいですね。

コードの結合やバージョン管理に関してはGit。ビルド、デプロイに関してはJenkins、最近だとAWSやIBM Cloud等でもまとめて管理してくれるのでしょうか。

 

協力しあう。

まぁこれも基本ですよね。

 

困難な課題、ややこしい仕様、単純に知らないしドキュメントにも残されていないこと。

これらを解決するのに皆やっている基本的な事は「人に聞く」という事ですよね。

 

これらを更にシステム化すると手順書等のドキュメントを残す、というのがどこでもやってるメジャーな事だと思いますが今回は「保守性の高いコードを書く」、という事に焦点が当たっているのもありペアプログラミングという手法を紹介しようと思います。

 

ペアプログラミングとは、その名の通り2人でペアを組んでプログラミングを進める手法です。

 

役割を「ドライバー」と「ナビゲーター」の2人に分かれます。

ナビゲーターは仕様に基づいた事や、自分の蓄積したノウハウをドライバーに伝えたりしながらコードの記載を指示します。

ドライバーは実際に画面を操作し、コードを書く人となります。

この際に、お互い良いコードを書く為に時にディスカッションやレビューの役割を含めたりしながら進めていきます。

 

一般的にはドライバーを経験値の浅い新入社員等、ナビゲーターをベテランが担当したりしますが、ある程度経験値の高い人間同士でも交互に入れ替えて進める事でも十分な効果があると言われたりしています。

 

どのようなメリットがあるかと言うと、2人で協力して記載する分品質の高い物が出来るという事、また知識の共有等があります。

デメリットとしては2人分の時間を使う事、また片方がもう片方に教える立場だけであると、教える側にはメリットが無いという事もあります。

 

ですが、ペアプログラミングによって直接的に下がる生産性はわずか15%という論文もあるそうです。

これは実際ペアで作業をすると休憩や割り込みが少なくなり、一人で作業するより集中して作業が出来るといった事が理由では無いかとか言われたりしてます。

実際論文を読んだ訳では無いし、具体的にはわかりませんが15%くらいなら得た品質の高さや知識の共有の方が大きい印象がありますね。

 

「CLEAN」コードを作る。

ようやく実際にコードを書く所です。

「CLEAN」コードというのはロバート・マーチンという人が品質の高いコードを書く為の代表的プラクティスをまとめた物です。

以下の5つにまとめられますので、ざっくり説明していきます。

 

・Cohesive(凝集性)

限られた機能を持ったクラスを沢山持つ。

クラスや関数等それぞれ持つ機能は単一であるのが良しとされています。

 

・Loosely Coupled(疎結合)

使いたい機能を直接は使用せず、間接的に使用する事で依存度を下げる事で、分離や改修を用意にする。

抽象クラス等の使用が当たりますね。

 

・Encapsulated(カプセル化)

実際の操作は外から見えなくする、データの直接的変更を防ぐ事で、安全性を守ります。

例えばデータを変更する際、直接値を変更する事は許さず、特定のルール・処理の中でのみ変更させたりする事を表します。

 

・Assertive(断定的)

あれやこれやと好奇心旺盛に色んなデータ、機能を持たずハッキリした役割を持つ事。

また自分が扱うデータは自分で持ち責任を持つ事。

オブジェクトが扱うデータはそのオブジェクト自体に持たせる事を表します。

 

うん、正直ここはいまいちピンと来てない(笑)

 

・Nonredundant(非冗長)

冗長性を持たず、影響範囲を絞る事によって改修を簡単にします。

共通化等があたりますかね。

 

まとめ

保守性の高いコードを作る為には実際にコードを書く以外の作業が大半を占めると言う事ですね。

ウォーターフォールの開発で実際にコードを書く時間は短いように開発業務というのは実際にコードを書く時間は短いなぁと改めて思ったり。

まぁ余計な業務をせず書く時間を増やす、という事に重点を置く考え方もあるので良い悪いは議論の余地はあると思いますが。

 

ペアプログラミングはやってみたいですね。

テレワークが増えてるから1つのPCでというのは難しいですが、IDEのクラウド化もどんどん進んで行くのかなぁ。

 

今回はここまでです。

 

さようなら。