【2019年版】Gitのレビュールール（オレオレ）【WIP】
アジェンダ
対象読者
- とりあえずProgateはやったレベルの人
- プログラムを書くことに抵抗はなくなったけど、まだエラーメッセージは読めない
- Linuxコマンドの意味が分かる以上のレベルになったけど自分のソースが汚いと感じる人
- 部下のコードレビューをする事になったエンジニア
対象ではない読者
- HTMLは分かるがJavaScriptやCSSは分からない
- 今まさにどこかのスクールで頑張っている人
- まずは私の記事より教わっている講師の方に聞いたほうがいいです。その上で読み進めてください。
- 哲学を持っている人
共通編
インデントを揃える
オートフォーマッターを入れれば発生しない問題です。 人間がやる作業じゃないので、エディタ側かツール側で対応させたいですね。
コンフィグファイル
小規模ならモグラ叩きをすればいいですが、大幅な仕様変更に対応させる場合などは叩く回数が多すぎてなかなか骨が折れます。 find | grep | awfなど一括変更コマンドでも良いんですが、名前が重複した場合はこうも行かない。
そこで、ログイン情報やシークレットパスなどは、アプリケーションから変えられるようにしておくと変更のたびにリリースしなくても良くなります。
のび太.pemに学ぶ変数名
面白かったので本件を取り上げますが、ファイル名が不適当だと後で困ります。 ダメ元で試したらそれえだったパターンは結構多いんです、
転じて、変数名や関数名が分かりにくい、紛らわしいものをソースに混入すると後の人が非常に困ります。
要件漏れ
最初は要件に合わせて作るんですが、出来上がったものが要件と一致しない、というのもあるあるです。 なぜなら、サンプルコードをとりあえずコピペするだけで内容を把握していないために起こる問題です。
任意の数値を起点として100までを和を計算する仕組みを作って、その計算をさせるプログラムを書く時に、「０～１００」が正しい事は確認すると思いますが、マイナスを考慮したり少数点を計算した時にどうなるか？という問題です。 文字列数字を数値変換するとか、「いち」とか「One」を文字とするか数値とするか、など色々課題があります。
ワンライナーコード
ネストしまくったり、極端な三項演算子とか高階関数をlambdaで渡したり。 関数型プログラミングではよくある光景ですが、初心者がこれをやると混乱します。 こういう時はJavaのガチガチの設計がありがたく感じますね。
Ruby編
ぼちぼち追記していきますです……
最後に
大体の場合、リーダブルコードが聖書みたいなものなので、これ一冊を持っておくだけで劇的に変わります。 Kindle版と書籍版がありますので、お好みで使ってください。
初学者なら書籍版を買って、マーカーを駆使すると励みになります。 主にレビュアーに指摘された経験があるな、と思ったところにマーキングをつけると学びが早まります。