プログラマーが超えちゃけない一線とは？
おはようございます。ゼバ会です。
突然ですが皆さん。皆さんの中に、超えちゃいけない一線を超えそうになった方はいますか。
私はあります。
まぁ、私だって人間ですからね。
コンビニで買い物中、ダイエットしてるのにど～～～してもアイスクリームが食べたかったけど、絶対ガマンすべきだったので３個だけにしといたこととかね。
（いやめっちゃ食っとるやん、、、）
ま、世の中にはね。超えちゃいけない一線というのがあります。
とりわけプログラマーは、仕事柄それがシビアです。
超えちゃいけないラインが目に見えないですから。
ひどいときには、超えちゃいけない一線を超えているという理由でクオリティが落ちているのに、そのことに自分でも気づかないし誰も指摘もしてくれなくて、「もっとクオリティを上げろ」とだけ攻められたりします。
世のコンピューターシステムの中には超えちゃいけない一線が正しく管理されておらず、野放しになっているケースも散見されます。
超えちゃいけない一線、、、つまり「バウンダリー」です。
バウンダリーは、新人プログラマーが徐々に認められていくために、絶対に学ぶべきことです。
私の場合、この概念を学ぶ機会が本当に一切全く得られなかったために、プログラマーとしてざっと２０年は伸び悩みました。
私はかねてより Clean Architecture という本をお気に入りと明言していますが、この本において最も重要な要点がバウンダリー違反です。
というより、この本自体がバウンダリー違反の危険性と管理方法だけを延々と３５０ページにも渡って語っているようなもので、これを完璧に理解すれば本は読まなくてもいいくらいです。
また逆に、バウンダリー違反を完璧に理解してからこの本を読めば、アーキテクチャーをキチンと設計することの大切さが本当に身に染みるほどよく理解できると思います。
これ、絶対です。小指賭けてもいい。
、、、、、あ、いや、小指はちょっと行き過ぎかな～、、、、じゃあ今日の晩酌のベーコンを賭けますです。はい。
バウンダリー違反の概念を理解してから Clean Architecture を読んでも、アーキテクチャー設計が大切だと思えなかった方。
いらっしゃいましたらベーコン取りに私のところまで来てください。
（もしくはこっからダウンロードしてもらってもいいヨ！）
でも、ぶっちゃけそんな人絶対いないと思う。マジ。
〇典型的なバウンダリー違反の例
プログラマーとして長く仕事をしていると、いわゆる「最初に作ったのが素人だとすぐ分かる」プログラムに出会うことがあります。
場合によっては、そのようなプログラムが様々なプロの手を渡って点々と受け継がれていることもあるのですが、不思議なことに製造後１０年以上を経過して、数十人以上の手が入ってもなお、最初に作ったのが素人という痕跡だけはちゃんと残るんです。
なんで見て分かるかってぇと、この「素人だと分かる痕跡」が、いわゆるバウンダリー違反だからです。
バウンダリーというのは、英語だと単に「境界」って意味の言葉なんですけど、だったら何の境界かというと、「書き換えてもいい場所」と「書き換えてはいけない場所」の境界です。
たとえば：
・「ユーザー情報」をファイル出力する処理があったとして
・これに新たに「サービス利用履歴出力」を足す必要があった
とします。
あなたはこの仕事を終わらせるために、
１．「ユーザー情報を出力する関数」の中に「サービス利用履歴の出力」を足していいと思いますか？
２．出力を綺麗に整形する際、画面出力用の整形処理が別ですでに存在しており、かつそれが流用できそうなとき、そのメソッドをそのまま使っていいと思いますか？
初級/中堅クラスくらいまでの人だと「２．は最悪やむをえなければ構わないんじゃないか」と感じる人も中にはいるかもですね。
でもこれらはどちらも絶対にやっちゃいけません。
これらはどちらもバウンダリー違反です。
２．は、画面出力とファイル出力の結果が全く同一で、かつその同一性が未来永劫絶対に変わらない確証があるなら流用してもいいでしょう。ですが通常そんな確証なんてないので、流用するのならコピーして同一のメソッドを作らなければ危険です。
もちろんのこと、もし、バウンダリー違反をするのが世界中で唯一ただあなた１人であれば、画面出力処理の流用でもなんでも好きにすればいいです。
世界中であなた１人しかしない違反は、きっと大きな問題にはなりません。
でも問題はそこではないのです。
バウンダリー違反の問題点は、交通ルールの信号無視と同じです。
深夜にあなた１人がちょこっとやっちまうくらい、正直大した問題ではありません。
問題は、そんなことをみんながやったらどうなるかの部分にあるのです。
そんなの明白ですね。
プログラムは時間をかけて徐々に、誰にも意識されないままいつの間にかグチャグチャになるんです。
それが、バウンダリー違反の恐ろしさです。
〇バウンダリー違反の理由1.強引な開発開始
設計段階で、ビジネスロジックがまだ十分に整理しきれていないのに、考えるのが面倒くさくなっちゃって開発を始めてしまうパターンです。
「日本語で書くよりプログラムを組んだ方が早い」という意識がある人によく発生します。
たしかに、うまく考えがまとまらないから、実際に動かしながら確認しようというアイデアは良いと思います。
それは有益な考え方の１つです。
ただし１つだけ忘れてはならないのは、「頭の中でまとまっているかどうか」という観点において、まとめるのに使用したその言語が日本語だったかプログラミング言語だったかは、特に関係がないということです。
人間は誰でも、頭の中で概念をまとめる際はそれ専用の思考回路を用いており、脳内で母国語で思考したりはしていません。
（この、頭の中で自問自答する際の信号のやり取りを仮に言語と見做したもののことを、メンタリース語といいます）
ですので、日本語で考えてもまとまらなかったものが、言語をプログラム語に切り替えたらまとまるなんてことはないのです。
頭の中でまとまらない物事を、実際に動作させながら確認するのはいいのですが、その実装はあくまで「実験」の域を出ることはありません。
ですので、個人的な実験結果を、そのまま納品物として提出してはいけません。
私も若い頃さんざんやったので人のことを悪くは言えませんが、だからといって自分より若い子に「オレもやったからやっていいよ」とは絶対に言いません。
なぜなら、実験の結果たまたま出来上がっただけの製品を提出するのは、飯屋のオヤジが気まぐれに作った試作品を客に出すのと同じだからです。
「試作品の試食しませんか」と言われて出されるならまだしも、そんなものを「これで完成です」と言って出すオヤジとか絶対イヤじゃないですか？
世にはシェフの気まぐれパスタなんて料理もありますけども、あれだって別に本当に気まぐれに作ってるんじゃないんですからね？
そんな失礼なことをお客さんにしてしまわないためには、実験して頭の中がまとまったら、その後あらためて詳細設計書を書き起こし、そこからが本当の「実装開始」としなければいけません。
本格的な実装を開始した結果、実験中に作った部品がたまたま使えてしまうことならあると思いますけど、それは実験の副産物にすぎません。
それから、どうしても頭の中でまとまりそうにないのなら、「仮組みして実験する」という方法論と並行して、やはり１人で抱え込まず、もっとリーダーを頼った方がいいです。
リーダーが頼りにならないなら隣の席の先輩でもいいと思います。
もし仮にその人達が「コードが組めないエンジニア」だったとしても、その人物はあくまでシステムロジックが組めないだけでビジネスロジックを組むこと自体はあなたよりは上手なはずだからです。
〇バウンダリー違反の理由2. 過去の違反の踏襲
いわゆる割れ窓理論でコードが荒れるケースです。
もともとグチャグチャなコードがあって、納期も迫っていてキレイにリファクタリングする時間も確保できない場合に、すでに発生している違反を放置するのみに留まらず、あらたなバウンダリー違反を追加してしまう人がいます。
まぁ、これもやりましたよ。若い頃はね。
だって誰にも注意されなかったし。
でも今なら分かります。
やっていいわけがなかったのです。
あるいは、もう本当にあまりにも度を越してグッチャングッチャンで、どこにどうコードを追加してもキレイに整えようがない場合は、本当にしょうがないことだってあるかもしれません。
ですがそういう場合だったとしても、バウンダリー違反をすることを個人的に判断して、個人的にやるのは絶対にダメです。
それはエンジニア以前に社会人としてちょっとダメ。
工数を伸ばしてでもキレイに整えるか、バウンダリー違反をしてダッシュで逃げるかは、リーダーに判断してもらうのが鉄則です。
また相談の際は、リファクタリングに必要な工数と、その具体的な内容を必ず調査してからにしましょう。どんなに優秀なリーダーでも、突発的に発生したタスクの工数は短く見積もりすぎてしまうのが人間というものです。
それから、万が一「工数は伸ばせないが修正もしろ」とか言うようなリーダーなら、そういう人から逃げる算段もした方がいいと思います。
〇バウンダリー違反の理由3.未来への考慮不足
この３つ目は、予防が最も難しく、かつ重要なポイントです。
そのプログラムが、どんなビジネスロジックを処理したいがためなのかを、将来同じ個所を担当する人に伝わらない書き方をしてしまう。
で、それゆえに将来同じところを見た人がウッカリでバウンダリー違反をしてしまう、というケース。
以前、プログラムに美しいもヘッタクレもある？という記事を書いたりしましたが、理屈の上では、本当に美しく・思いやりにあふれた・どっからどう見ても完璧に分かりやすいコードになっていれば、将来のバウンダリー違反を防ぐことも可能でしょう。
でも私を含め、人間は常に完璧というわけにはいきません。
ですので要は、バウンダリー違反を常に完璧に予防するのは不可能なわけです。
ですがだからといって、完璧は無理だから守る意味がないという理屈にはなりません。
上述の記事では、「プログラムコードの美しさは、次の担当者への思いやりの大きさで決まる」という話を書いています。
その理屈でいけば、完璧は無理だから何も気をつけないというのでは、「私は完璧超人じゃないので何もかもをメチャクチャにします」と言ってるようなもので、そんな考え方ではまともな人間関係すら構築は難しいでしょう。
別に完璧であろうとしなくていいんです。
たとえそれを天の神が許さなくても、私が個人的に許しましょう。
あなたは完璧である必要はありません。
ですが、だからといって、それは完璧を目指さない理由にはならないのです。
無理をして完璧を目指すというより、無理しなくても完璧を目指せる方法を探すことを頑張る感じ。
まぁ、それが大事かと思います。
〇次回予告
はい。てなわけで今回はここまで。
なんとなくだけど、ざっくり精神論的な話になりましたね。
ただ、プログラマーが思いやりの心を持つことは大事だったとしても、「思いやり」それ自体はプログラミングできませんよね。
だって機械畜生にヒトの心はないし、コンピューターにオマエラの血は何色だー！ って文句言ったってコンピューターは血液自体ありません。
ということは、頑張って思いやりの心でプログラミングしたとしても、実際には次の担当の人はこちらが頑張ったことを分かってくれないわけで。。。
それって頑張り損？？
いえいえ、そんなことはありません！
思いやりの心で丁寧にプログラミングしたことを、次の人に伝える方法はちゃんとあります！
なぜなら思いやりのあるコードは、「依存関係」というものが相手に分かりやすく伝わるからです。
これが次の人に伝われば必然的に、自分が頑張ったことも伝わります。
とすると、依存関係についてより深く知っている人が書いたコードの方が、内容が同じでもプログラムの評価は上がりやすくなる？？
そう！ その通り！
依存関係を意識して組まれたコードは、分かりやすいし書いた人も優秀に見えるし、とても有益なのです！
てなわけで次回は、プログラミングの大原則「プログラムの依存関係とは」でお送りします！
この記事が気に入ったらサポートをしてみませんか？