
コードが美しくないことによる、現実的な痛み、について考えています。ただの美学の問題ではないことがだんだんわかってきました。
リーク問題もいろいろあります

有馬:難しいですけど、やっぱりその壊せちゃう問題は、SIerでもすごくこわい問題であって、それがメモリーリークっていう言葉でよく語られることがありますね。開発中においては、ほとんどわからないんですね。ただ、本番にリリースした後に、なんか最初は問題なく動いてるんだけど、段々、動きが遅くなった、もしくは急に死んでしまうっていうことがあるんですよ。
小野:最終的には、プロセスが止まっちゃう。ソフトウェアが落ちると思ってください。
有馬:本来アプリケーションとして、これくらいのメモリを確保していれば動くはずのものが、意図せずにメモリーを使いきってしまうっていう状態なんですけど、それはバグを持ったプログラミングによって、オブジェクトにどんどん値が追加されてしまって、メモリーが解放されずにどんどん蓄積してしまうっていうような状態になります。それをメモリーリークと呼んでいます。
小野:リーク問題はいろいろあって。メモリーリークもあるし、あとスレッドのリークもあるし、あとファイルディスクリプタのリーク、ファイルの閉じ忘れみたいなやつもあるけども、リークの話も大きく言えば不正な状態、閉じるべきものが閉じられていない。さきほど例に出したような、整合性の矛盾をきたしてる場合もあるけれど、メモリリークも大きな問題ですね。
有馬:そうですね。実際に以前に起こった例で言うと、それは単純なプルダウンをWeb画面に表示する改修案件でした。画面にプルダウンを表示するための情報を格納したオブジェクトがあって、通常そこには10個程度表示すべき項目が入ってるはずなんです。リリースした初日はちゃんとそのプルダウンが出ていたんですが、リリースして2、3日経った時に、その画面が急に開かなくなったんですね。じゃあなんで開かなくなったんだっていうのを見てみると、そのプルダウンを出すリストの数が10ではなくて、何百万っていう数になっていた、そのため、プルダウンを表示するためには100万回ループさせなきゃいけないので、それでもう遅延が発生して画面が開けなくなったっていう事象がありました。

小野:そのケースって、例えば最初10件じゃない?2回目アクセスした人がプルダウン押すと20個になってて、みたいな感じなんですよね?
有馬:そうです。
小野:100万個とかになる前に、なんかすごいここ出てるけど、と、クリックしてたら気付いてたかもしれないけど。
有馬:画面を表示する度にそのオブジェクトに対して加えられていきました。2、3日たってるのでもう何万回表示されてると思うんですけど、その間に10個、20個、30個っていうふうに追加されていった。
小野:プルダウンを押さないと見た目はわかんない?
有馬:見た目はわかんないですね。
小野:それがあんまり使われてないプルダウンだったりすると、気付かなくてそういうことも、簡単なテストで気付かなくて。状態を壊しちゃうってことは、不正な状態に起因するバグっていうのはすごくね、障害の解決に時間がかかることがあるんですよね。今の例だと突き止めちゃえば簡単だけども、いつの間にか状態がおかしくなってるとか、何かが漏れてるっていうのって、長いこと回していかないと、運用していかないと、発生しないから、バグ直す時って最初にまず再現させることが必要なんですよ。こういう条件だと起こるよねって。起こっちゃえばだいたい勝ちで、その問題が起きてる状態を発生させれば、後は例えば半分に割って、こいつのせいじゃなかった、じゃあこの中で、こっちは関係なかった、と、切り分けて絞り込んでいくんですよ。こういうケースは特定できるんだけど、リーク系のやつとか、状態が不正になった原因とかバグとかって、「なんかの条件でこことここが矛盾しちゃってて、それが原因でこうなってるんですね、なんで矛盾するかわかんないです」みたいなことが起こり得る。だから状態壊せちゃう問題って、解決が難しい障害を生み出すことがありますよね。解決に時間がかかる。難易度だけじゃなくて。それもユーザーにはちょっと、少し作る人寄りすぎて分かりづらいかもしれない。なんとなく今の話わかります?ちょっと難しいかな。
編集部:ユーザーにしてみたら、障害になるかもしれないものが、コードに埋まってるっていうことですかね。
小野:障害が起きる状態にできちゃうことがまずい。できないように必ず整合性のある状態にしかできない作りになってるほうがいいじゃないですか。壊せないですよね。壊せないコードってのは、一見、見た目の美しさとかじゃなくて、作りの美しさなんですよね。そこはね、けっこう大事な。
編集部:それはあれですよね、ユーザー側でなかなか確認しようがないというか。「壊せちゃう系のやつないだろうね?」とか聞けないですよね。
有馬:一般のシステム開発でSEがそれを見つけるのもなかなか厳しいと思います。
小野:本当にコード見ないと絶対わかんないと思いますけど、それは。あとそういうのって詳細設計とかに書かれてることって、ほとんどないでしょ?
有馬:まずないです。
小野:「ここはイミュータブルにしてほしい」とか。ないでしょ?イミュータブルっていうのは不変っていう。
有馬:そういうのはないですね。
この記事は参考になりましたか?
- ユーザーとSlerをつなげる「美しいコード」の物語連載記事一覧
-
- コードが美しくないために起きる問題を考える(後編)―テクニックの乱用・誤用問題
- コードが美しくないために起きる問題を考える(中編)―リーク/魔法の手順/影響範囲が分かりに...
- コードが美しくないために起きる問題を考える(前編)―重複のあるコード/誤読問題
- この記事の著者
-
小野 和俊(オノ カズトシ)
セゾン情報システムズ常務取締役CTO 兼 アプレッソ代表取締役社長。大学卒業後サン・マイクロシステムズに就職し、シリコンバレー本社での開発を経験。その後24歳でアプレッソを起業し、DataSpid...
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
-
有馬三郎(アリマサブロウ)
セゾン情報システムズ2009年にセゾン情報システムズ入社。これまで金融、運輸業界などのSIを17年間担当。2016年より当社内でモダン開発を推進する組織であるモダン開発推進チーム、通称「モダ推」のリーダーとして、「楽しい開発」を社内に展開中。
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか?
この記事をシェア