はじめに
どうも、レガシー組込みエンジニアで整理収納アドバイザーの@yagisawaです。
2023年春ドラマの私のお嫁くんを見ていまして、1話でヒロインの汚部屋を片付けるシーンがあるのですが、これってソフトウェアにも通ずるものがあるよな…と思い、筆を執ってみることにしました。
本記事は
- 個人の経験からくる主観が多分に含まれている
- コード整理の定義が曖昧
- プログラミングに関する原理原則をかなり薄っぺらく解釈している
- 内容がSIer・組込み・C言語に偏っている(あえてタグは付けませんが)
ことからポエム扱いにしようと思います。読み物としてお楽しみください。逆にこの記事を読んで「原理原則・リファクタリング完全に理解した」とか思わないようお願いします。
書こうと思った経緯
しれっと肩書を追加しましたが、好きが高じてだいぶ前に整理収納アドバイザーの資格を取りました。実際は下手の横好きで、資格が役に立っているわけでも整理整頓がうまいわけでもありませんが、そんな私から見ても世の中(業界？)に整理整頓が上手い人ってそんなにいないよな…と思ってしまうような状況を何度も見てきました。
私はSIerなのですが、例えば
- デスクがいつもぐっちゃぐちゃな人がいて、月一の点検で毎回指摘が入る。
- 備品棚卸しで毎回紛失物がある。
- ファイルサーバにこれ絶対使わないだろう？と思うような199x年と書かれたディレクトリがある。
- 同じファイルがあっちにもこっちにもある。しかも内容が一致してなくて更新履歴もないのでどっちが新しいかわからない。
- 他社からベースコードを引き継いだ流用案件だが、コードがぐちゃぐちゃで読めない、コメントと一致していない、設計書とも一致していない。いや、設計書があるならまだよくて殆どの場合設計書がない。
- サブモジュールの関数名変えたらビルドが通らなくなった。調べてみると別モジュールで勝手に
externされていた。
などなど。で、なんとかしてみようとなぜなぜ分析を試みるも「んー、忙しいんだよね」で終わってしまう歴史を繰り返す。木こりのジレンマにも通ずる話です。
最近は良いコード／悪いコードで学ぶ設計入門とかちょうぜつソフトウェア設計入門等きれいなソフトウェアを作るための設計技術・コーディング技術にフォーカスした書籍をよく見かけるようになりました。またリファクタリングという言葉もかなり定着してきたと思います。ですが正直身の回りの整理整頓もできないような人や組織がこんな崇高なことできるわけがないと思うんですよね。だって「リファクタリング」って家に例えるなら「リフォーム」とか「増改築」に相当するレベルの話ではないかと思いますので。あとSIerなら首がもげるほど頷いてくれると思うのですが、リファクタリングに誰もお金を払ってくれないですよね？
そこでハードルをぐーんと下げて、まずはコードのお片付けから始めてみるのがいいのではないかと思ったわけです。きっとリファクタリングほど効果は出ないでしょう。よくてコーディング時間が1秒減るだけかもしれません。でもそれでいいんです。1秒を積み重ねて1分効率化できるはずです。その1分を使って1時間、その1時間を使って1日…とやっていけるはずです。継続は力なりというやつですね。ついでに身の回りのお片付けもできるようになっていると一石二鳥ですね。
片付けの3つのステップ
ググればすぐに出てくると思いますが、まずはドラマでもやっていた
- 全部出す
- 使う/使わないで分ける
- 使っているものを仕舞う
でやっていこうと思います。
STEP1. 全部出す
これはドキュメンテーションツールが有効です。C言語の場合はdoxygenが使えます。「doxygenコメントを書かないとドキュメント生成できないのでは？」と思うかもしれませんが、EXTRACT_ALLやEXTRACT_STATICを有効にしておけばコメントが書かれていなくてもエントリをピックアップしてくれます。またCALL_GRAPH CALLER_GRAPH REFERENCES_RELATION等を有効にしておくとエントリの依存関係を見える化できます。これを使って次のステップの作業ができます。
STEP2. 使う/使わないで分ける
呼び出し元依存関係図や参照元を見ると誰からも参照されていない関数や#define等が見つかります。これらが「使わないもの」となります。
原理原則としてはYAGNI原則が有効です。実際には「ほら、やっぱり必要なかった！」原則なのかもしれませんが。
またDRY原則やOAOO原則も有効でしょう。資格を取るときに聞いた話で「ある老夫婦のお宅を整理したら、毎日1本使っても100年経っても使い切れない量の綿棒が出てきた」というものがありましたが、コードについては基本的に1つあれば十分なはずです。基本的にと言うのは「普通のはさみとキッチンばさみ・裁ちばさみは別物」ですので、やり過ぎ注意という話です。
ドラマでは「使う/使わないの判断は1年以上使ってないか」や「使う/使わないに迷った時用の保留箱」等のアイディアが出てきましたが、コードについては現時点で使っていないものはサクッと捨ててください。流石にバージョン管理ツールは使ってますよね？後で必要になったらそこから取り出せばいいだけですよね？が理由となります。
STEP3. 使っているものを仕舞う
コードは物理的なものではないので仕舞うという行為はピンとこないかもしれませんが、仕舞う場所に関しては単一責任原則が有効かもしれません。ですが、「責任って…？」とか「今後を考えると…」とか難しく考えると大変ですので、まずはお片付けで言うところの「キッチン収納にサニタリー用品入れないですよね？」とか「冷蔵庫にアイス入れないですよね？」とか当たり前のところからやってみるといいと思います。
整理・収納・整頓
片付けの3つのステップは散らかった部屋を片付けるまでの話でした。別の見方として「整理・収納・整頓」があります。資格を取るときに「この3つの違いわかりますか？」と最初にされた質問でして、ググると人によって捉え方が違うようですが、私は
- 整理：3つのステップのSTEP2に相当
- 収納：3つのステップのSTEP3に相当
- 整頓：上記状態を維持すること
だと習いました。
この「整頓」がSIerにはなかなか難しいことだと思います。納品したらおしまいのプロジェクトって結構あると思いますので。継続案件の場合やそうでなくても合間合間で整頓もやっていきたいところです。大掃除って年一で大々的に(風習とかで)やるから大変なのであって、小掃除を春夏秋冬に分けて4回やればそんなに大変じゃないですよね？といった感じです。
整頓に使える原理原則はボーイスカウト・ルールが有効そうです。ただし注意点としては「変数名・関数名をわかりやすいものにする」ぐらいのバイナリが変わらないような変更であれば問題ありませんが、ロジックを変えてしまうような変更はテストとセットになっていないとデグレに繋がります。ボーイスカウト・ルールが習慣化してない組織ではテストフェーズ前にちょっとだけでも時間を作って習慣化につなげたいところです。
また整頓時に私がやっているズボラ法がありまして、正直きれいな状態を維持し続けるのって大変だと思います。そこで、クローゼットの片隅に「とりあえず箱」を作りまして、「短期間だけ使うDM・チラシ」や「新しく買ったんだけど仕舞う場所が決まらないもの」等をとりあえず放り込み、箱がいっぱいになったら整理するようにしています。
これをコーディングに置き換えますと、おすすめとまではいきませんがcommon.cなんてやつは必要悪なんじゃないかと思います。「責務を決めきれない関数」や「ライブラリ化しようか悩ましい関数」なんかをとりあえず入れさせてください！といった感じです。コードは物理的なものではないので200行超えたら整理するとか、テストフェーズの前に整理するとかルールを決めておくとよいでしょう。恥ずかしくて納品できないようにtoriaezu.cなんて名前にしておくのもよいかもしれませんｗ
収納グッズ・家電について
組込み業界以外のことはわかりませんが、組込みソフトウェア開発で使われる設計・コーディング技術は昔からあまり進化していないと感じています。しかし収納グッズや家電は日々進化していますので、是非ホームセンターや家電量販店に出向いて新しいものに触れていただきたいと思います。どういうことかと言いますと
- いつまでおばあちゃんにもらった桐箪笥(
switch文で状態遷移)だけ使ってるの！スリ○やニ○リに便利な収納グッズ(オブザーバパターンとかストラテジパターン)があるでしょ！ - いつまで洗濯板で洗濯(Excelで関数表手作り)してるの！全自動洗濯機(doxygen)があるでしょ！
- いつまで昔買ったONとOFFしか無い掃除機(C89の仕様)使ってるの！軽くて自走式で消費電力が少ない掃除機(C99やC11の仕様)があるでしょ！
のような話です。
整理収納アドバイザー公式テキストに「はるか昔には、モノそのものが少なかったわけですから、そもそも整理する必要がなかったのです」という文言があります。その通りでパンチカードでプログラムを書いていた時代やROM数KBのマイコンを使っていたような時代は整理とは無縁だったと思います。しかし、現在はリソースがメガ単位になりコード量は人が暗記できる限界をとっくに超えています。時代にあった整理術が必要であり、そのためには時代にあった収納グッズや家電を使っていく必要があるのです。「使ったこと無いから」とか「(主に年配エンジニアに)受け入れられるかわからない」という理由でレガシーな技術を使い続けるのではなく、これからの日本を支えていく若手エンジニアのためにもモダンな技術を積極的に使っていける組織を目指したいものです(っつーかデザインパターンもdoxygenもC99も枯れてますわ！)。
整理整頓のその先に
ここまでのことを当たり前のようにできるようになっていると、少しは時間に余裕ができていると思います(そう信じたいです)。しかし、ソフトウェアの世界では頻繁に新しい家具が買われたり(仕様追加)、家電の買い替えが行われたり(仕様変更)が発生します。そうなると今の家の間取りや大きさでは収まりきらなくなる可能性が出てきて、リフォームや増改築を検討する必要が出てくるでしょう。大丈夫です、ここまで頑張って来れたのですからきっとリフォームのイメージ(クリーンアーキテクチャやDDD等)はスッと頭に入ってくることでしょう。きれいになったマイホーム(ソフトウェア)で素敵なエンジニアライフをお過ごしください。
おわりに
千里の道も一歩から。まずはできることから少しずつが重要です。ソフトウェア業界に少しでもきれいなコードが増えることを願って、筆を置きたいと思います。