チーム開発におけるコーディング

[ラクス Advent Calendar 2016](http://qiita.com/advent-calendar/2016/rakus) の15日目の記事です。
昨日は [@tomoyuki-tanaka](http://qiita.com/tomoyuki-tanaka) さんによる  [今さら聞けないJavaScriptのややこしいところ（スコープ、巻き上げ、this）](http://qiita.com/tomoyuki-tanaka/items/07d763325c7cb659efb7)  でした。


# はじめに

15日目を担当する [@kanoari](http://qiita.com/kanoari) と申します。

ラクスの新卒一期生で、6年目の中堅になりつつあります :hatched_chick: 
現在は、弊社製品の運用保守を担当しています。

私事ですが、先週入籍しました :ring: 
ちょっと浮かれています。すみません。

# チーム開発におけるコーディング

若手の方も結構見ていると思うので、今回は偉そうにも
チーム開発におけるコーディングについて私の考えをお伝えしたいと思います。

連日、とても技術的で読み応えのある記事が続いているので
ちょっと箸休め的な感じで見てもらえればと思います。

そして1,2年前の弊社ビアバッシュLTに参加したことのある方は
聞いたことがある内容になっちゃうかもです。

（・x・）＜ 時間がなかったから昔のネタを再利用したの？　いえいえ、まさか、そんな。

・・・

オススメなのは、
長期稼働しているシステム（コーディング規約なんかも存在している）に参画していて
私、バグの盛り込みがなかなか減らないなぁと感じている人。ですです。

## いきなりですが、私の結論

チーム開発におけるコーディングとは、ズバリ

**周りの空気を読んだ、 自分勝手ではないコーディング** 

だと思います。
それを実現するための具体的な技法は、

**記述する一行一行のコードに対して、常にその記述が最善かを自分に問いかける**

ことです。

当たり前じゃん！って言われそうですね（・x・）

技法なんて高尚な言い方してますが、
単に考え方とやり方を変えようって話ですね。明日から実践できます。

具体的にお話していきましょう。

## バグが生まれる原因

なぜこの技法が有効なのか説明するために、
まずは、バグが生まれる原因について考えていきましょう。

バグが生まれる理由なんて、千差万別ですが
よくバグが生まれた直接の原因（浅い原因）として上がるものを、いくつか記載してみます。

1. 似ている機能のソースをコピペしたら、実装する機能と仕様が異なる箇所があり、バグった【**コピペミス**】
2. 登録画面では実装したのに、編集画面への展開が漏れてしまい、バグった【**展開漏れ**】
3. 推奨されている自作関数(Util系)ではないもので処理してしまい、他と挙動が異なりバグった【**規約違反**】  
4. ある関数を修正したところ、それが影響し、その関数を呼び出している箇所でバグった【**影響調査漏れ**】

よくありそうですね。
ではこれ、どうすれば防げていたでしょうか。
そのシステムへの理解を深めるみたいな回答ではなく、システムのことを対して詳しくなくてもできる
解決策を記載しました。

1. **コピペミス**
記載した（ペーストした）コーディングは本当に、仕様通りの動きなのか？を疑って、
その一行によってどういう処理が行われるのか全て把握し、仕様との差分がないか一行一行、確認すること  

2. **展開漏れ**
記載したコーディングは本当にここだけの記述でよいのか？を疑って、
記述するコーディングの前後のソースを読み込み、それと似通った記述を
している箇所を grep して引っ掛けること
  
3. **規約違反**
記載した関数は本当に使われている関数なのか？を疑って、
関数を利用する際は、記述するコーディングの前後のソースを grep して似ている処理を見つけ、
既に利用されている関数を見つけること  
  
4. **影響調査漏れ**
記載したコーディングは他に影響しないのか？を疑って、
対象のメソッドを利用している箇所、およびそれをさらに利用している箇所・・・と
最後まで突き詰めて調査すること

ここまで読んでいただくと、それぞれの解決策に、共通点があることに気づかれたかと思います。
そうです。自分が記載したものに対して、最初に疑いをかけている点です。

自分が記載したものは本当に最善なのか・・？を疑うと、上のような疑いが次々と生まれてきます。

だから、シンプルに **いま書いた一行のプログラムは、常にその記述が最善かを自分に問いかける** ことを
地道にしながら、プログラムを書いていけば、バグは確実に減ります。私自身がそうでした。

また、バグが減るだけでなく、自然と保守・可読・汎用性も上がります。
結果的に、長期視点での品質も担保されるようになります。

## 実際の行動

チーム開発におけるコーディング技法は
**記述する一行一行のコードに対して常にそれが最善かを自分に問いかける**
ことであることはわかりました。

じゃあ具体的に、どういう問いかけをして、それに対してどういう行動をすれば
回答できるのか、ほんのいくつかですが、紹介していきます。

#### 問いかけ１：そのコードは、最適なコーディング（書き方・書く場所）なのか？
**行動**
- 最低3か所以上の類似処理を参考にすること（コーディング規約に準じている書き方を知ることが出来る）
- 記載箇所と役割が独自フレームワークに適切か熟考すること
\------------------------------------------------------------------------------------------------------------
#### 問いかけ２：そのコードは、どういう処理なのか？仕様とあっているのか？
**行動**
- 実装はとにかく細かい単位で区切り、チケット化して分割実装し、仕様と細かく照らし合わせすること
- 実装する前に、脳内じゃなくて具現化して実装設計すること（頭が整理できる＆後々振り替えりやすい）
\------------------------------------------------------------------------------------------------------------
#### 問いかけ３：そのコードは、他への展開漏れがないか？
**行動**
- 記載する箇所のソースを grep して類似機能を探す
\------------------------------------------------------------------------------------------------------------
#### 問いかけ４：そのコードを書くことによる影響範囲は？ 
**行動**
- 前後のソースを見て、自分の追加したコードにより前後のメソッドにどう影響するのか、
　引数と返り値といったパラメータの値に着目して調査を行う

## まとめ

一行一行、いちいち自己問答し、力を込めて実装するのは、それだけエネルギーも時間もかかります。
それでも、あとからバグが見つかり再リリースや報告書を書くこと、あるいは保守・可読・汎用性の低い
プログラムで後継者の方々が苦労していくことを考えると、一球入魂な書き方のほうが結果的に低コストです。

そんなの当たり前じゃん！と思う方の中でも、見逃してしまった一行や二行はきっとあるはず。

一行に心を込めて、実装すると、品質は大きく変わります。

よければ是非、お試しください。

# 感想
今回、[ラクス Advent Calendar 2016](http://qiita.com/advent-calendar/2016/rakus) に参加させていただき、本当にありがとうございました！
[Qiita](http://qiita.com/) は以前からずっと気になってたのですが、腰が上がらない状態でしたので（登録するだけなのに）
自分が記事を書いたこと以上に、他の方の記事を閲覧するきっかけが出来たことに、本当に感謝です。

企画・運営してくれた @oohira さんありがとうございました！:tada:
明日も引き続き [ラクス Advent Calendar 2016](http://qiita.com/advent-calendar/2016/rakus) をお楽しみください。