保守性が良いとはいうけれど
システム開発に携わっている方であれば必ず耳にする「保守性」。これを話題にしようとすると「どうせ結論はまたクラスだオブジェクト指向だとかか、○○信者うぜぇ」とか言われそうなので、今回はちょっと方向を変えた話をしたいと思います。
まず、「保守性ってなんだ」と言われて答えることのできる方はどれくらいいるでしょうか。ちなみに今回のコラムを書くにあたって少し調べてみると、意外にも意識の統一が取れていないことがわかりました。あらかじめ決めておきますが、今回の話題は「ソースコードの保守性」についてです。
昔から「コメントを入れろ」とか「サブルーチン化しろ」とか、少し前からは「クラスを分けろ」というのも増えて、皆さんの勤め先でも保守性を高めるために色々と規定を持つことが多いと思います。理由としては「見通しの悪いソースは直しにくい」「他の人でも直しやすいように」など、基本としては「直しやすい」という点に集約されているかと思います。
定義としては間違っていないように思えますが、わたしとしてはこのスタート時点に少し違和感を覚えます。特にオブジェクト指向の記事や意見に多いのですが、的確に分割し、適切に対応するクラスへと権限を委譲してあるソースコードは保守性が良い、となぜ言えるのでしょう。
そもそもここで言う「直しにくい／直しやすい」というのは「誰」にとってなのでしょう？
言うまでもなくここで言われる「誰か」というのは、そのソースに携わる人、もう少し大きくしても、そのソースに携わる企業に所属する人、というところだと思います。仕事としてシステムを作成する以上、何かあった際に短時間で対応が取れるようにする必要が間違いなく存在します。問題が発生した際にできるだけかかる時間を減らすため、という視点から出てきた考え方のように思えます。
それを踏まえると、保守性というのは「あくまでも携わる人達の内において」だけ通用することであり、業界を通して適用できるものではないのではないでしょうか。先のオブジェクト指向うんぬんの部分にて、わたしが違和感を覚えてしまうのはこのような箇所です。
保守性の定義において、ある程度の共通部分は出てくるでしょうが、絶対的な指標というのは存在しないと思っています。
分岐が長く深く続くようなものは当然、見通しも悪く保守性も良くないでしょう。それは修正を行う際にテストしなくてはならないパターンが複雑になってしまい、テスト抜けが発生しやすいためだと思います。
1つのメソッドやファンクションが数百行以上に及ぶものも、同じように保守性が低いでしょう。今でこそ機会が減少していますが、昔のようにソースをラインプリンタなどで出力した時には思い切り怒られます。それ以前にデバッグしたくなりません。
極端にロジックを細分化したものも同じく保守性は低いでしょう。上の例とは反対に、今度は制御が飛びまくってしまい全体のイメージを把握することが難しくなります。
ここまで書いてみて思うことが1つ。
「保守性はかなり属人的な指標である」
ということです。「見通しの良いソースコード」と簡単に書くこともありますが、この「見通しが良い」というのは人によるところがものすごく大きい要素だと思います。「直しやすい」という点も同様に、修正を行う人にものすごく依存する要素だと思います。機械的に対応がとれる仕事であればまだしも、多種多様な価値観を持つ人間が作業する以上は、統一的なルールというのは難しいでしょう。わたしが見やすいコードと、あなたが見やすいコードが同じ方向かと言われると難しいところです。
しかし、仕事でシステム開発を行っている身としては、だからといって何も手を打たないわけにはいきません。それこそ後で保守性の問題にぶつかってしまうことが多い……というよりも、確実にぶつかるためです。パッケージ販売であろうと受託開発であろうと、納品後に一度もソース修正を行うことがないという案件は、とてつもなく実績があり、なおかつ安定した技術を用いたものに限定されるのではないでしょうか。残念ながらわたしは今までこの業界で働いていて、そのようなシステムは1つも見たことがありません（策を練って不具合を覆い隠す仕事は見たことがありますが……）。
ここで重要になると思える事柄が「統一されている」という指標です。
「読みやすい」「わかりやすい」「統一されている」というのが保守性を話題にする上でよく出てくるキーワードだと思います。しかし「読みやすい」と「わかりやすい」というのはここまでの話において書いたように、あまりにも属人的な要素のため、適用する際にはかなり注意しないといけないところだ、とわたしは考えています。
ですが、もう1つのキーワード「統一されている」であれば。
プロジェクトを実行するにあたり、コーディング規約などのルールを決めることは大体の案件で行われている、もしくは考えられているところだと思います。しかし、今現在わたしの関わっている案件がそうなのですが、世の中には規約がなく統一的なルールが存在しない案件というのも間違いなく存在します。そのような案件で作成されるソースコードというのは、まさしくカオスな状態で、後々を思うといささか具合の悪くなるシロモノです。
「よしっ、これは破棄して作り直し！」
などと勇気ある決断をしなくてはならない場面もあることでしょう。そこをできるだけ減らすためにも、案件内に限った話でも十分なので、統一ルールを設ける必要があると思います。そのルールが他の人からみてどう思われるか、業界内においてどうだ、というところは一切考える必要はありません。先に書いたように、そもそも保守性というのは属人的ですので、そばにいない人間のことを考えてルールを決める必要はまったくもってないからです。他人がなんと言おうと、実際に修正するのは自分たちなのですから。耳を傾けることは大切ですが、流されてしまうのはまったくもって良くありません。
最初はどこまでをルールにするべきか、という点で大いに悩むと思います。ですが、何も決めないよりも、何かを決めることの方がはるかに大事です。決めたルールが適さないなら直せばいいだけのことですから。
……と、ここまで勢いに任せて書いてしまいましたが、わたしの中では「保守性」は実はあまり重要視したくない気持ちがあります。
その点については次回以降に書いていきたいと思います。
コメント
三年寝太郎
保守性も統一性もできれば高い方が良いと思いますが、なかなか難しいですね。
読みやすい、判りやすい、は確かに人によって違ってきますが、少なくとも、
読む人の経験やレベルを規定しないままでは、「読みやすさ」や「判りやすさ」の基準すれ作れないので、特定の言語での開発の経験とスキルが似通っている人達であれば、ある程度は可能かもしれません。
とは言っても、人のレベルを揃えることすら難しいのが常なのですけど。
再利用するものが、とにかく動かす事が最優先で、散々苦労して頭を出したモグラだけは全部潰してりリースにこぎつけたようなシステムで、プログラマは二度と触れたくないと思っても、動いてると再利用されてしまうものです。
再利用する前に、無理のあるところをちゃんと直して使うべきなんでしょうね。
そんな時間がどこにある？
と言われそうですが、実際、再利用しようとして失敗したり、大幅に手直しをしたり、殆ど作り直したりと言うことが結構多いですし、確実に再利用できているのはバグ(特に仕様の)だけではないかと思えるプログラムも少なくないでしょう。
つまり、そんな時間・・・は、結局、再利用する時にコストとして上乗せされている(或いはサービス残業のストレスに変換されている？)だけ、なのかもしれません。
手直ししておいた方が安く付いたものも少なからずあったかもしれません。
それに、作りながら保守性を考えるよりも、作った後で次を考えて作り直したほうが、合理的な気もします。
元のソースがあればどう動くかは判るのだから、同じ動きが出来るように作ればいいので、例え元のソースをプログラムした者でなくとも、不備や嘘だらけの仕様書や設計書に悩まされることなく作り直せるのだから。
(プログラマにとって最も信頼できる資料は、基本的にコードな訳ですし)
しかし、そんな工数を認めてくれる気の効いた所があるかと言われると。。。
ビガー
はじめまして、ビガーと申します。
私は部分的な保守性の高低は詰まるところ設計の質と等価であると考えています。
すなわちコメントの質です。これは技術者の意識で変わってくる。
私の携わる最近のプロジェクトは外部設計で実現可能性まで検証して、詳細仕様は
コメントで担保するというスタンスが増えていますね。
ただし、全体的な保守性の担保は別問題ですね。トランザクションとかロックとか
横断的な関心事はやっぱりアーキテクチャ主導でないとつらい。
これにはアーキテクチャドキュメントの質と技術者の質にどうしても依存します。
統一したルールも結局は技術者が変われば陳腐化するケースが多い。
保守性は結局、技術者の質(属人ですわ)で決まると考えています。
ただし、唯一属人化しない手段があると考えています。
それは、その現場にあった文化と教育風土を創ってしまうこと。そうすれば技術者の質も
自ずと上がっちゃうんです。
Ahfさんが保守性を重視したくない理由は良い文化や風土ができれば自ずと保守性は
上がるといいたいのでは？
ただ、これには時間がとてもかかってしまうことがネックです。
Ahf
三年寝太郎さんコメントありがとうございます。
開発に携わる人のレベルを揃えることができれば、ある程度の標準を用意することができる、ただそれすらも難しいというのは私も同じ意見です。
恐らくこの業界に関わる人で同じ気持ちな人は結構多いのではないでしょうか。
「本当なら」と思えるところは仕事を行う上で多々あると思いますが、どれもこれもが時間の都合、または費用の都合で行えていないのが現実だと思います。
このあたり昨今の技術事情などをふまえて良い方向性が見えてくればいいのですけどね。
Ahf
ビガーさんコメントありがとうございます。
コメントで担保する方法というのは良い方法だと思います。今はソースのコメントからドキュメントを生成するツールの類が一般的になってきたことから、経験年数の浅いPGにとっても重要性を意識できる面もあるでしょうし。
そして「重要視したくはない理由」というのはビガーさんが思われることでほぼ当たりです。たどり着くところはどうしても「人」になる話題だと考えていますので、その人をどうにかできなければ保守性もなにもあったものではない、と思っています。
私も今の会社で少しずつですがやっているのですが、３～４年程度ではまだまだ全然、といった程度ですからね・・・。
としろう
保守性という為には
・有る程度万人に読みやすいコード
・フロー＆入出力がわかりやすいこと
・同じロジックが分散しない事
※DBでいう正規化みたいな関係が理想
後はコメントでカバーですかなあ
コメントも処理概要があるのは良いが
コードを読めば直ぐ判るものは不要だし
逆にこの処理がどういう要請で必要・出来たかなど付帯情報があったらうれしい
ただ、書くからには必ずソースコードと同期（矛盾・ずれさせない事）が必要
このぐらいですかねえ
でも、後から書き直しなんて簡単に出来ないので
最初からの骨子の良さとその品質の維持に努める事が重要ですね
新人プログラマも変に直ぐ実践投入して力任せに作らせるのは良くないと思ってます
Ahf
としろうさんコメントありがとうございます。
「万人に読みやすい」というのが私は曲者かな、と思っています。
育ってきた環境というかそれまでに目にしたコードの種類・質によって
何が読みやすいかというのが大きく変わると思うのですよね。
ソースへのコメントで処理概要があると確かに助かりますよね。
概要という形でまとめ上げるのにもある程度ウデが必要ですので、
そういうところでも気をつけて出来るといいですよねぇ。
同期を取ることが結構なネックかもしれませんが・・・。
としろう
万人に読みやすいについては
個人の依存が有る為に～というのはその通りですが
平均的にというか、一般的に80点主義というか、
傾向はあるので有る程度は可能です。
それに、ルールがほぼ内部で統一されているとか
一般的な読みやすいとされるコーディング標準はあるでしょう？
言語だって、ユーザーが多い≒読みやすい とかね
個人の趣味じゃないんだから、そこで諦めたりしては意味が無い
会社として仕事するなら、
あまり俗人的なスタイルのコードでは良くないと思いませんか？
Ahf
としろうさん重ねてのコメントありがとうございます。
80点主義というのがとてもいい指標だなぁ、と思いました。
としろうさんの言われるように、仕事でPGを組む以上コーディングスタイルはある程度のルールに沿った形で実装が行われている必要がある、というかそれでこそ仕事だ、とも思えます。
諦めたりせずに、できるところから始めていかないと何も良くならないですよね。
ちなみに現在私が勤めている会社には標準というものが・・・ｹﾞﾌｹﾞﾌ
としろう
良くも悪くも言われる80点主義はトヨタ車とかに言われていると思ったのですが
聞いた事は無かったですかね？
標準化とか読みやすいコードとかは、逆にしおれが出来ている所からは
意見や要望として下からは出ない物だと思いますよ
ちなみに自分が勤めている会社には標準という物がまだ・・・ｹﾞﾌｹﾞﾌ
各個人がまだ一人親方的にプロジェクトがかなり俗人的・・・ｹﾞﾌｹﾞﾌ
設計書の記述レベル・書き方からなんからまだ中々80点主義ででも
ゴールははっきりしないし色々模索中ですな。
顧客が価格と納期と機能ばかり見る事が多いので
それ以外がバランス的に・・・ｹﾞﾌｹﾞﾌ
Ahf
としろうさんありがとうございます。
80点主義はそのあたりの言葉でしたね。言われるまですっかり失念してました。
しかし・・・なんというか親近感がわくといいますか・・・
同じ会社にいるかのようなデジャブです（笑
三年寝太郎
こんばんは。
ある意味では、システム開発に関わった人が保守をするのが最高の保守性なのかもしれませんね。
それが出来ない、つまり、人がどんどん変わるから、コメントだコーディング規約だ、といろいろ必要と思われる様になってくるわけでしょうから。
しかし、
同じ人がずっと残ってくれるわけでもなく、
同じ技術にずっとしがみつきたい人ばかりでもなく、
同じ技術や言語がずっと使えるわけでもなく。。。
また、基本的にやっつけ仕事の方が圧倒的に多いから、コメントなんか書いてる暇はないというのも判るし。。。
バグ修正時や再利用してソースを書き換えた際にコメントを修正しないままで、それを再利用すると、解析に時間をかけられないときに、誤解を招いてしまうとか、、、
まあ、ソース読めば判るのに、傍に書かれてる言い間違いみたいなものを信じて進むなんてちょっとダメなんですけどね。
そんなケースも無きにしも非ずで。。。
結局、再利用を前提で考えるのなら、素性の確かなものにしておく必要はあるわけで、人の揃ってないプロジェクトであれば、保守対応の時間をちゃんととるとか、人が揃ってるなら、書く前にある程度の縛りを入れておくとか、は、やらないよりやったほうがましなのかもしれません。
ただ、やったからといってそれが有効であるかどうかは、そのソースがどういう扱いをされるかにもよるのかも。つぎのプロジェクトで、経験の浅い人、よく考えない人が修正したら、コメントの修正軟化してられない状況だったら、もともと備わっていた保守性も、それで崩れてしまうので、時間軸を長くすると、保守性を一定のレベルで維持し続けるのは難しい。
自分が作ったり、引き継いで数年単位で改良してきたソースだと、時間がある時にやっつけで作った部分をライブラリ化したり、といったメンテナンスも出来るので、長い時間軸で見るとそれなりに再利用時の時間節約にもなるんですけどね。
納期が限られていて、触る機会も限られていると、そんな事は夢のようなものなのでしょうけど。
少なくとも、保守性を考えてソースを書く方が、緊張感というか、他者への思いやりや責任は感じることも出来そうです。
エンジニアとしての、あるいは人としての経験の少ない人には、動けば良いって訳じゃないぞって事はちゃんと教えるべきなのでしょう。
そういう風土というか空気というか、環境に依存した側面はどんな世界でもあると思うので。。。
取り留めなくてすみません。
Ahf
三年寝太郎さん再度のコメントありがとうございます。
本来であれば、というのは恐らく皆さん同じ思いだと思います。
ただ時間的、費用的、人員的な話題色々複雑に絡み合ってしまい
今の状況に至っているのかなと思えます。
私も動けばいい訳ではない、という点はできるだけ教えていきたいなぁ、と
思ってはいるのですがなかなか難しいですね。
他人の書いたソースを出来るだけ触って貰うようにするのが、
今私ができている数少ないことだったりします。
三年寝太郎
経験が浅い人なら、半年前、一年前の自分のソースを見るだけでも勉強になると思いますよ。
自分が進歩してることもわかるし、どの変が良くなかったかが理解できると、次へのステップに必要なものも見える事も少なくないでしょう。
以前は、まあ、周りに先輩や上司もいたので、何気に余裕があったから、自分が組んだプログラムに機能追加や修正をする機会も多少はありました。
「動いてはいるんだけど弱い部分」は、機能追加の際に手直しをしたリ、作り直したりして、その時点で自分にできるベストやベターなソースに書き直したりということで来たのですが。。。
もっとも、基本は「動いてるものはなるべく触るな」で、
触ったら新しく作ったとき以上に時間をかけて確認しなければならないんですけど。
今は、そんなことが出来るような業務環境は余り無いですからね。
新人が伸びるのを待つなんて事もなかなか出来なくなってるだろうし。
Ahf
三年寝太郎さん度々ありがとうございます。
半年前、一年前のソースは確かに勉強になりますよね。私も自分のソースを見て
「何をやっていたんだ俺は」と思うときもまだまだあります。
実際の所、新人が伸びるのを待てない状態にある企業は結構あるのではないか、と思っています。特に社内で人材の空洞化が起きている企業が以前よりも多くなり、人を育てる余裕も持てないまま日々の業務をこなしているような状態ではないでしょうか。
わかってはいるけど何ともしがたい、そんなジレンマが続いていますねぇ。