同僚に広めたい基礎教養

tl;dr

• エンジニアとして仕事をするうえで、みんなに知っておいてほしい「基礎教養」を書き出してみました
• （複数のメンバーにそれぞれ別々にこういうのあるんだよって話をしたので。。。）
• 知らないことが悪いわけじゃなくて、これまでの環境や経験の違いなだけ
• チームでやっていくなら、最低限の共通認識は持っておきたい

知っててやらないのと、知らずにやらないのは違うこと

日本人の名前の英語表記

• 昔は「名 → 姓」の順（例：Yoshitaka Nishimura）が一般的でした
• 今は政府方針により「姓 → 名」（例：NISHIMURA Yoshitaka）が推奨されています
• Git の user.name や、Slack などの名前表記もこの考え方で統一しておくと良いです
• もちろんしなくてもよいです（RECOMMENDEDです）

VCS （主に git 以下同じ）のコミットメッセージ（タイトル）

• タイトルには fix: や feat: のようなプレフィックスをつけておくと、リリースノートの自動生成などがしやすくなります
• 英語で書くか日本語で書くかも、チームでルールを決めておきましょう
• 少なくても中身のないタイトル（update documentなど）はやめましょう

コメント

• PR レビューなどでのコメントには、「提案」「質問」「必須」など、意図が伝わるラベルを添えると親切です
• Slack や Issue コメントでも同じことが言えます
• PR のコメントは「対応必須」ではないのが本来ですが、暗黙の圧力が働きやすいので、ラベルがあると助かります
• 個人的には NB:（Non Blocking）って書いてあったら参考にしてもしなくてもいいとわかって欲しい

知らずにやってしまうと周りに迷惑がかかること

ファイルのフォーマット等について

• Markdown やコードなどのテキストファイルは、提出前に必ずフォーマットをかけましょう
• VS Code を使っているなら、まずは Prettier を入れるのがオススメです
• .editorconfig は全リポジトリに入れていいと思っています
• 合意があれば pre-commit などで CI 化するとさらによいです（このブログのリポジトリでの例）

テキストファイルで気をつけたいこと

• 行末の空白を削除
• ファイル末尾に改行を入れる
• 空白行は 1〜2 行まで。それ以上は基本 NG（3 行以上の空白行が必要になるケースがあったら教えて欲しい）
• これらを守らないと、余計な差分が出てレビューの邪魔になります

lint と validate

• Terraform などルールが揃っているツールは活用
• そうでないものは、チームで適用範囲を話し合って決めましょう
• スペルチェックや textlint は強くしすぎると混乱を生むので慎重に

VCS （のリポジトリ）はチームの財産という認識

• 自分のプライベートリポジトリは自由でいいけど、チームのリポジトリはみんなのもの
• 例えるなら「共有の本棚」や「みんなの部屋」。そこにゴミを放置されたら困りますよね
• 綺麗に保つのは、みんなで気持ちよく働くための基本

コードレビューの姿勢について

• レビューでコメントがついたということは、何かが足りない or 改善の余地があるということ
• スルーしてもいい空気になってるなら仕方ないけど、できれば丁寧に議論して高めていきたい
• スルーするのが日常になってしまうと、全体の品質は下がる一方です

おまけ

一般的なこと

• 本を読みましょう
• 日々の積み重ねが未来の自分をつくります
• 自分のことならいつでも何回でも変えていい
• 間違ったら直せばいいのでじゃんじゃん失敗しましょう
• 同じ失敗をしないように工夫することが大事です

最後に

• チームの暗黙知は、なるべく早めに言語化するなりドキュメント化するなりしましょう
• 神は細部に宿るって言いますし、基本的なことこそしっかりやっておきましょう
• 丁寧に書こうと思ったらなんだかいまいちまとまらなかったｗｗ