はじめに
こんにちはばーんです！
今回は案件をこなすうちにレビュー(指摘)頂いた内容をまとめました。
1人で学習していると気付きにくい事が多くあるなぁ…と感じました。
- 実務に携わっていない方
- 実務経験はあるけど、チーム開発など他者と組んで仕事していない方
は見ていただけると気付きがあるのかなと思います。
結論
最初に書きますw
1. 独学だけでやりきらない方が良い
メンターでなくとも、コミュニティなどで他者と交わりながら進めた方が絶対いいです。
独学だけだと知り得ない情報が沢山あるなぁと今回気づきました。
2. Gitはお金払ってもいいので覚える
神ツールなので。これも独学でやり切るのは厳しいかも…
GitHub
PR(プルリクエスト)のお作法
- できる限りわかりやすく
これはなにもIT業界だけに限った話ではありません。上司に資料を見せる時、お客様に見せる時なるべくわかりやすい説明を心がけませんか？事前に練習したり、他の人に見てもらって修正の意見聞いたり等。
レビュワーも人間なので30Pのびっしり書かれた資料を渡されても厳しいものがあります。
以下が実際に指摘を受けた内容です。
1. 該当箇所をスクショ(新しく改善した場所を明示する)
TOPPAGEのsearch欄を変更しました。
と書くより写真で載せて印をつけて送った方が丁寧ですね。
2. 事実と仮説を分ける
エラーなどが特にそうなのですが、「何をして何が起きたのか(事実)」と「だからどのように考えるのか(仮説)」は分別して記載すべきです。
分かりにくいですし、この記載がないとレビュワーも同じ方法を試して2度手間になるかもしれません。
3. 粒度を適切にする
これはそのチームでの運用方法があればそちらに則る。なければ項目ごとに分けるのが良いかと思います。
例えばWebのサイト制作であればセクション毎、ページ毎など。
- マークダウンを正しく書く
QiitaやREADME.mdなどで積極的に書いて慣れることをオススメします。綺麗に書かれたマークダウンはとても見やすいです。
見やすい ＝ 伝わりやすいとそれだけコミュニケーションコストも下がり全員が幸せになります＾＾
GitHubの使い方
- Resolve conversation
コメントを書いてもらっている左下にあるボタンです。これを押すとコメントが閉じられます。
「対応終わったよ！」ってことですね。
- files changed(差分確認)
PRをあげると前回との変更点（差分）が見れます！便利！
僕はこの存在を知るまでは人力で確認してました＾＾
- commit suggestion
「こここっちの方が良くない？」「こっちに変えといたからcommitしといて〜」
とレビュワーが修正してくれたものを反映できるボタンです。神。
commit suggestionのボタンを押してpullするとローカルで反映できます。神。
Git
- GitFlowを理解する
GitやGitHubの運用方法をチーム開発であれば決める事が多いかな〜と思います。
代表的なものが↓
https://qiita.com/hatt0519/items/23ef0866f4abacce7296
- コミットのお作法
- 関心毎にコミットする。まとめない
- コミットはなるべく分かりやすく書く(第3者が見ても何の変更がなぜ？どのように行われたか分かるように書く)
- [fix][add]のように、このコミットが何をしたのか？を最初に記す(下記の記事とか分かり易いです)
メールの最初に【共有】とか、【依頼】とつける事あると思いますがそれと似てます。
https://qiita.com/shikichee/items/a5f922a3ef3aa58a1839
コミットは総じて分かりやすく書く事が大事ですね＾＾
自分1人で試してみる
これらGitやGitHubの使い方ですが、自分1人でも試せます。
- GitとGitHubを使いテキトーなディレクトリを管理する
- masterとは別のBranchを切ってpushする
- GitHub上に Compare & pull request という表記が出るのでそれを押す
これで自分自身でコメントしたり、ファイルの差分を確認したりできます＾＾
CSS(scss)
scssのお作法
- コンパイルについて
scssのコンパイルですが、相手がどういったコンパイル方法かは相手次第です。
ですので納品時にはこちらからコンパイル方法まで明記すると丁寧ですよね＾＾というお話です。
僕はEasySass（VSのプラグイン）で楽してたのですが、コンパイルするのに楽してたんだな…と痛感しました。したことないって方は是非してみてください。
また、納品も.min.cssなのか、通常の.cssなのかでコマンドの書き方やignoreする対象も変わります。
.min.cssの場合無駄なスペースがないのでより軽いファイルをデプロイできますし、第三者から読み取りにくい状態です。.cssの場合は納品後も修正ができます。
- mixinやinclude以外の使い方
実はmixinってincludeする以外の使い道ないと思ってましたw
https://qiita.com/nekoneko-wanwan/items/c8498a21ae0e2b2198be
この記事が分かりやすいのでオススメです＾＾
- 色やフォントの管理は変数で
フォントも色も使う種類は3種類程度とされています。なので最初にフォントや色を変数で宣言します。
その宣言を元にスタイルを当てる事で、統一感が出る ＋ 修正時の管理が容易になります。
https://francfranc.io/
こちらはfrancfrancのデザインガイドです。ご参考までに
- 完全な白と黒は使わない
#ffffff や #000000 は使わないという事です。
自然界にない色で目立ちすぎる為。使う場合は微妙にずらしましょう。
クラス名について
絶対にタグにスタイル当てない
これそう聞いていても最初はやっちゃうと思います。BEMを知った後でも「BEMで詳細度上げた後のタグだからいっか」みたいな感覚でつけた事あります…
ダメです。全部にクラスつけます。スタイルもクラスに対して当てます(htmlに対してのfontなどは除く)
具体的な名前をつけない
これはcssだけに限った話ではありませんが。
例えば海の写真をヒーローイメージに起用する時に ocean みたいなクラス名はダメです。
なぜなら写真の内容が変わった時にクラス名も変える必要がでてくるので。
これは逆も然りで、ファイル名に heroImage みたいなファイル名もダメです。
heroImageを別の写真にした時に修正が必要なので。
ファイルパスの指定を絶対パス（相対ルートパス）でする場合
絶対パスのすすめ
http://osumituki.com/hack/internet/4684.html
絶対パスと相対ルートパスで意味合いが微妙に違いますがしたいことは同じです。
納品者から指定されて相対ルートパスで納品した場合などに参照してください。
要するにローカルで作成している場合、ルートディレクトリがわからないので相対ルートパスだとスタイル当たらないというお話と、相対ルートパスでのスタイルの当てた時の確認の仕方が書いてます。
その他
- (JS)アンチパターン
アンチパターンってなによ？って話ですが、要はやっちゃいけないこと。
自分が指摘されたのはevalの使用や、gotoについてです。
eval
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/eval
goto
https://marycore.jp/coding/why-goto-statement-is-bad/
言語名 アンチパターンで調べると沢山出てくるのでおすすめです。
（というか厳密にいうと自分が書いたコードが細かくどういう動きをするのか把握しろって話なんですが…）
- コメントは基本的にWhyを書く（なぜ？以外は書かない）
これはリーダブルコードでも明記されてましたね…
ただ、どーしても不安で書いてしまう。なぜ？以外を書いても良いとは思いますが書かなくて済む努力は必要ですね
- コードは常にきれいに
これは複数名から言われたので真理だと思いますw
一時的にコメントで消すのはOKですが、必要ないと判断したら消しましょう。そして、それに慣れましょう。
さいごに
自分自身も↑に書いた事でまだできてない事沢山ありますが、それを知っておくことは大切かなと思います。
最後まで読んでいただきありがとうございましたm_ _m
1. 独学だけでやりきらない方が良い
2. Gitはお金払ってもいいので覚える
一応結論をもう一回載せて締めにさせていただきます。ありがとうございましたm_ _m