ラクス 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 をお楽しみください。