ラクス Advent Calendar 2016 の15日目の記事です。
昨日は @tomoyuki-tanaka さんによる 今さら聞けないJavaScriptのややこしいところ（スコープ、巻き上げ、this） でした。
はじめに
15日目を担当する @kanoari と申します。
ラクスの新卒一期生で、6年目の中堅になりつつあります 
現在は、弊社製品の運用保守を担当しています。
私事ですが、先週入籍しました 
ちょっと浮かれています。すみません。
チーム開発におけるコーディング
若手の方も結構見ていると思うので、今回は偉そうにも
チーム開発におけるコーディングについて私の考えをお伝えしたいと思います。
連日、とても技術的で読み応えのある記事が続いているので
ちょっと箸休め的な感じで見てもらえればと思います。
そして1,2年前の弊社ビアバッシュLTに参加したことのある方は
聞いたことがある内容になっちゃうかもです。
（・x・）＜ 時間がなかったから昔のネタを再利用したの？ いえいえ、まさか、そんな。
・・・
オススメなのは、
長期稼働しているシステム（コーディング規約なんかも存在している）に参画していて
私、バグの盛り込みがなかなか減らないなぁと感じている人。ですです。
いきなりですが、私の結論
チーム開発におけるコーディングとは、ズバリ
周りの空気を読んだ、 自分勝手ではないコーディング
だと思います。
それを実現するための具体的な技法は、
記述する一行一行のコードに対して、常にその記述が最善かを自分に問いかける
ことです。
当たり前じゃん！って言われそうですね（・x・）
技法なんて高尚な言い方してますが、
単に考え方とやり方を変えようって話ですね。明日から実践できます。
具体的にお話していきましょう。
バグが生まれる原因
なぜこの技法が有効なのか説明するために、
まずは、バグが生まれる原因について考えていきましょう。
バグが生まれる理由なんて、千差万別ですが
よくバグが生まれた直接の原因（浅い原因）として上がるものを、いくつか記載してみます。
- 似ている機能のソースをコピペしたら、実装する機能と仕様が異なる箇所があり、バグった【コピペミス】
- 登録画面では実装したのに、編集画面への展開が漏れてしまい、バグった【展開漏れ】
- 推奨されている自作関数(Util系)ではないもので処理してしまい、他と挙動が異なりバグった【規約違反】
- ある関数を修正したところ、それが影響し、その関数を呼び出している箇所でバグった【影響調査漏れ】
よくありそうですね。
ではこれ、どうすれば防げていたでしょうか。
そのシステムへの理解を深めるみたいな回答ではなく、システムのことを対して詳しくなくてもできる
解決策を記載しました。
-
コピペミス
記載した（ペーストした）コーディングは本当に、仕様通りの動きなのか？を疑って、
その一行によってどういう処理が行われるのか全て把握し、仕様との差分がないか一行一行、確認すること -
展開漏れ
記載したコーディングは本当にここだけの記述でよいのか？を疑って、
記述するコーディングの前後のソースを読み込み、それと似通った記述を
している箇所を grep して引っ掛けること -
規約違反
記載した関数は本当に使われている関数なのか？を疑って、
関数を利用する際は、記述するコーディングの前後のソースを grep して似ている処理を見つけ、
既に利用されている関数を見つけること -
影響調査漏れ
記載したコーディングは他に影響しないのか？を疑って、
対象のメソッドを利用している箇所、およびそれをさらに利用している箇所・・・と
最後まで突き詰めて調査すること
ここまで読んでいただくと、それぞれの解決策に、共通点があることに気づかれたかと思います。
そうです。自分が記載したものに対して、最初に疑いをかけている点です。
自分が記載したものは本当に最善なのか・・？を疑うと、上のような疑いが次々と生まれてきます。
だから、シンプルに いま書いた一行のプログラムは、常にその記述が最善かを自分に問いかける ことを
地道にしながら、プログラムを書いていけば、バグは確実に減ります。私自身がそうでした。
また、バグが減るだけでなく、自然と保守・可読・汎用性も上がります。
結果的に、長期視点での品質も担保されるようになります。
実際の行動
チーム開発におけるコーディング技法は
記述する一行一行のコードに対して常にそれが最善かを自分に問いかける
ことであることはわかりました。
じゃあ具体的に、どういう問いかけをして、それに対してどういう行動をすれば
回答できるのか、ほんのいくつかですが、紹介していきます。
問いかけ１：そのコードは、最適なコーディング（書き方・書く場所）なのか？
行動
- 最低3か所以上の類似処理を参考にすること（コーディング規約に準じている書き方を知ることが出来る）
- 記載箇所と役割が独自フレームワークに適切か熟考すること
------------------------------------------------------------------------------------------------------------
問いかけ２：そのコードは、どういう処理なのか？仕様とあっているのか？
行動
- 実装はとにかく細かい単位で区切り、チケット化して分割実装し、仕様と細かく照らし合わせすること
- 実装する前に、脳内じゃなくて具現化して実装設計すること（頭が整理できる＆後々振り替えりやすい）
------------------------------------------------------------------------------------------------------------
問いかけ３：そのコードは、他への展開漏れがないか？
行動
- 記載する箇所のソースを grep して類似機能を探す
------------------------------------------------------------------------------------------------------------
問いかけ４：そのコードを書くことによる影響範囲は？
行動
- 前後のソースを見て、自分の追加したコードにより前後のメソッドにどう影響するのか、
引数と返り値といったパラメータの値に着目して調査を行う
まとめ
一行一行、いちいち自己問答し、力を込めて実装するのは、それだけエネルギーも時間もかかります。
それでも、あとからバグが見つかり再リリースや報告書を書くこと、あるいは保守・可読・汎用性の低い
プログラムで後継者の方々が苦労していくことを考えると、一球入魂な書き方のほうが結果的に低コストです。
そんなの当たり前じゃん！と思う方の中でも、見逃してしまった一行や二行はきっとあるはず。
一行に心を込めて、実装すると、品質は大きく変わります。
よければ是非、お試しください。
感想
今回、ラクス Advent Calendar 2016 に参加させていただき、本当にありがとうございました！
Qiita は以前からずっと気になってたのですが、腰が上がらない状態でしたので（登録するだけなのに）
自分が記事を書いたこと以上に、他の方の記事を閲覧するきっかけが出来たことに、本当に感謝です。
企画・運営してくれた @oohira さんありがとうございました！
明日も引き続き ラクス Advent Calendar 2016 をお楽しみください。