---
# System prepended metadata

title: レビューの観点について

---

# レビューの観点について

NkohWeb内ではレビューの観点を3つに分けています。

| レビュー種別         | レビュー観点                                                 | レビュアー               |
| -------------------- | ------------------------------------------------------------ | ------------------------ |
| コードレビュー       | Lintツールで判断できない**コードの良し悪しをチェックする**   | 実装担当者以外のコーダー |
| デザインレビュー     | デザイナーが関わっている課題のときのみ実施。<br />デザイナーが想定していない形でデザイン素材などが使われていないか？といった**デザイン面のチェックを行う** | デザイナー               |
| ディレクターレビュー | ディレクターが当初設定した**要件が満たされているか？をチェックする**。 | ディレクター             |

原則として自身が担当するレビューで**見るべき観点以外は見ません**。(レビュー時間がいくらあっても足りないので。。。)

我々がチェックするのは**「コードレビュー」の観点**になりますが、コードの良し悪しという抽象的な表現ではわかりにくいと思いますのでもう少し掘り下げて書きますね。



まずコードレビューといっても幾つかに分けられます。



| コード種別                                                   | 観点                                                         |
| ------------------------------------------------------------ | ------------------------------------------------------------ |
| HTML                                                         | ・適切ではないid, class名を付与していないか？（1回目）<br />・共通パーツとして切り出せるパーツをベタ書きしていないか？（1回目）<br />・SEOに有利に働く構造化マークアップができているか？（1回目）<br />※ これは出来たらぐらいの努力目標です。専門のマークアップエンジニアではないので...<br />...etc |
| CSS、SASS                                                    | ・無闇に絶対指定、固定指定をしない(後からメンテナンスが難しくなる)（2回目）<br />・マジックナンバーがないか？（2回目）<br />・BEM、FLOCSSなどのルール設定に準じているか？（1回目）<br />・DRY原則に反していないか？（1回目）※ そもそもBEMを使うとかのルールが今はないんですが...<br />... etc |
| JavaScript<br />その他ビジネスロジック(PHP, Pythonとか)      | ・UI・UXに影響を及ぼす実装になっていないか？（2回目）<br />   (スクロールイベント毎に重い処理を走らせていないか？...etc)<br />・DRY原則に反していないか？（2回目）<br />・デッドコードが存在しないか？<br />・関数、変数に適切な命名が行われているか？<br />・変更を加えることで既存の動作に影響を及ぼさないか？<br />・マジックナンバーがないか？ ... etc |
| 設定ファイル<br />　・package.json<br />　・gulpfile.js <br />　・.gitignore<br />　・docker-compose.yml <br />... etc | ・変更を加えることで既存の動作に影響を及ぼさないか？<br />・汎用的な設定になっているか？ ... etc |



我々が運用しているコンテンツの多くはHTML, CSSのシンプルな静的コンテンツなのであまりJavaScriptなどのビジネスロジックに手をいれることは多くありません。

ので、**基本的にはHTML, CSSの実装がルールに準じていること(※)、メンテナンスがしやすい作りになっていること**。なんかを着眼点として確認してもらえれば良いと思います。
※ フロントエンドのルールが現状ありません。(新規構築時にはBEMを使うとかSassを使うとかWebpackを使うとか...)
   ここは今後水野さんや吹越さんと相談しながらルールづくりを進めてもらえると助かります。



と、ここまでそれらしく書いてきたもののレビューを作業フローを導入したのはつい一月前くらいでして。。。

まだまだみんな手探りでやってる感じです。
ので、こういった観点があるよねーとかそもそものレビューフローの見直しとかも大歓迎です！

----
吹越版

##基本
改行コードは、LFになっているか？
インデントはスペース4つが守られているか？
パスはディレクトリが2階層以上さかのぼるときルートパス指定になっているか？
（相対パスで../となるものはルートパスとなる）
言語宣言は適切か？

HTML
適切ではないid, class名を付与していないか？
共通パーツとして切り出せるパーツをベタ書きしていないか？
コンテンツ要素、インライン要素などは適切に使えているか？ 
（アクセシビリティやSEOに有利に働くことを狙いとし確認項目を設けています。よりよい要素があれば改善を検討ください）

CSS、SASS
BEM、FLOCSSなどのルール設定に準じているか？
DRY原則に反していないか？
無闇に絶対指定、固定指定をしない
マジックナンバーがないか？
デッドコードが存在していないか？

JavaScript
その他ビジネスロジック(PHP, Pythonとか)

UI・UXに影響を及ぼす実装になっていないか？（2回目）
(スクロールイベント毎に重い処理を走らせていないか？…etc)
DRY原則に反していないか？（2回目）
関数、変数に適切な命名が行われているか？
変更を加えることで既存の動作に影響を及ぼさないか？
マジックナンバーがないか？
デッドコードが存在していないか？


設定ファイル
変更を加えることで既存の動作に影響を及ぼさないか？
汎用的な設定になっているか？
