はじめに
「明らかに正しいコードを書く」ことが大切と、atcoderの解説ムービーで耳にしたことがあります。どの回かは覚えていませんが、僕がみたということは、どこかの begginer contestにおける、C問題くらいの解説だったかなと思います。
少し大袈裟に見える言葉かもしれないですが、絶対に正しいコードでなければいけない、ということではなく、「もっとシンプルにできないか？」という視点を持つために、心に持っておきたい言葉という感覚です。
競技プログラミングで目にした言葉ではありますが、普段の業務でも活かせる気がしたため、簡単に記事にしようと思います。
「明らかに正しいコード」とは？
大雑把にいうと、「見通しがよく、何をしているのか理解しやすいコード」と言えるかなと思います。
当たり前と思われるかもしれないですが、少し気をつけていないと、コードは簡単に複雑で、何をしているのかよく分からず、バグも生みやすいものになってしまいます。
どうして、コードが複雑になってしまうのか
いろいろな原因があると思いますが、個人的に最大の原因だと思うのは、「一つのやり方から抜け出せなくなる」ことです。
ソフトウェアというのは、基本的に条件分岐で構成されています。この場合は処理Aをするけど、この場合はBをする、みたいな。
そして、一つのやり方にとらわれると、その条件分岐はいとも簡単に複雑になります。
（簡単に複雑に、というのは皮肉な気がしますね。）
概ねやりたいことは実現できているから、基本的な実装は変えたくない。だから、細かい調整は条件分岐で対応しようと思う。すると、この場合はこの2パターンにさらに分かれて、その1つではまた別の分岐があって、、こっちではこれも考慮しないとか？？みたいになってくると、もう何が正しかったのかワカラナイ！
テストも書きにくいし、簡単に条件見落としなどが起こってしまいます。
これは別に、1からそのコードを設計する時だけではなく、バグ修正や追加対応等でも起こります。というよりむしろ、チケットだとその問題にしか目がいかず、一つの修正自体は小さかったけど、それにより分岐がだんだんと増えていき、結果として難しくなってしまう、なんてことも多いです。
厄介なのが、チケットだと小さく見えるため想定作業時間が短く、本当はちょっとイケてないコードとわかっていながら、それで済ますしかなく、だんだんと腐敗臭のするコードになっていくこともある、ということです。
そうならないように
※僕は、体系的にこうすればいい！という解決策を見つけたりするのはニガテでして、割と抽象的になってしまいます。悪しからず。。
そこで役立つのが、タイトルにもある「明らかに正しいコードを書く」という意識を持つことです。
「なんだか、やけに複雑なことをしているな・してしまっているな」と感じたら、今のやり方に固執せず、一度立ち帰り、全体をみてみると良いと思います。
すると、「どの分岐でもこの場合は単にreturnしているから最初に確認してしまえばいいじゃない」とか、要件を再整理してみると、「この初期化処理はそれぞれのcaseごとで やる or やらないを設定しているけど、その前段で、より簡単な分岐でやってしまえばよさそうじゃないか？」とか、よりシンプルで分かりやすい方法が見えてくるのではないかな、と思っています。
どうしても僕らは人間なので、あまりに複雑なものを管理するのはできないですし。
最後に
もちろん、現実はそう都合よくできておらず、結果現状でいくしかないとか、時間的にちょっと、、、ということもあると思うので、毎回うまくいくわけではないと思います。
そして、元の処理にかけた時間が長いほど、その処理に固執してしまうなんてこともあるでしょう。非常に人間的な感覚ですね。笑 AIなら全く気にせず打ち壊してくれるかもしれないです。
ただ、扱いづらいコード・理解しにくいコードは日々の業務を苦痛にしてしまいます。簡単な修正なはずなのに、思ったより時間かかるとか、修正したはいいものの、別のバグ起因になってしまうとか。（もうやっていられない！なんて。）
ですので、「こんなに複雑にしなくても、もっとシンプルにいけるはずだ」という感覚が舞い降りたのであれば、それに従いましょう。その場では多少修正・テストに時間がかかったとしても、その後の開発で大きな恩恵を受けられると思います。
少しでも参考になれば幸いですmm
株式会社シンシア
株式会社xincereでは、実務未経験のエンジニアの方や学生エンジニアインターンを採用し一緒に働いています。
※ シンシアにおける働き方の様子はこちら
シンシアでは、年間100人程度の実務未経験の方が応募し技術面接を受けます。
その経験を通し、実務未経験者の方にぜひ身につけて欲しい技術力（文法）をここでは紹介していきます。