開発をするときに心掛けたいこと
落ち着くこと
焦っていいことは無い
PRを出した直後に全て見返してコメントをつける
必要に応じてコードコメントへと還元すること
PRを出すときには
背景を書く
なぜ変更が必要なのか
どのような方法で解決をしたのか
影響範囲もあれば書く
懸念点があれば悩んでいるので何かいい案はないか?と聞く
これはPRを出す前に聞いてもいいはず
レビューをするとき
指摘をするときは「どういう理由」で「何をしてほしいのか」を書く
TODO: 例示
思います、と言わない
思いますは感想
〜と思います → はい、そうですね、でいいのか?違うはず
実際コメントをしている時点でそのままではいけない、もっといい案があるからコメントをしているはずである
〜がのほうが〜な理由で優れているのでこうして欲しいです、と言ったほうが単刀直入である
ただし人間を攻撃してはいけない
コードを憎んで人を憎まず
質問をするとき
なぜその質問をしたのか?の理由があると答える方もそっちを組みして返しやすい
このほうが高速
タスクの優先順位
今やっていることの流れで余計なことをやってしまった
それは本当にあるものを提供するにあたって必要なものなのかを考えて不要であればタスクとして積み、優先度順にやるべきた
雑なコードを書く癖を付けない
エンジニア2, 3年目で気をつけるといい
気の緩みや仕事への慣れから雑なコードを生成しがちらしい
これは良くないので気をつける
検証をする
よくわからないまま進めても手戻る
プロトタイプを作るのもこれ
負荷検証できる環境を整えておく
非機能テストを整えるといってもいいかも
MVP方式で進めて、常に繰り返し要求する量を捌けるか?を見ていかないと、負荷検証してみたらダメでした、で炎上する
現状からゴールへの大まかな道筋を立てる
恐らくこれがマイルストーン
これをやらないと、終わりだと思っても無限にやることが現れる
コードを書ききることが終わりではない、ユーザに価値を届けることが終わり
と、思ったがコードは書いたら最後、保守が無限に続くから終わりなんてないのかもしれない
わかってるかどうか、考慮しているかどうかをコメントに書く
これがあるかどうかで全然違う
経験から来るもの
抜けがわかる能力
そういう知見は大事にしたほうがいい
結合テストは大事
やらないと、入れる直前でバグが出て死ぬ
手際がいいのと手抜きなのは違うんや
魚類
わからなかったら今からやればいいんですよ
太田さん