来年入社の俺がコードを書くときに気をつけてる事

結構勢いで書いてるので、順番とかは気にしない。

テストを書く

コードを書くなら、テストも書く。
コードを変更するならテストも書く。
テストが書きにくいコードならテストを書かないのではなく、コードを変える。
“テストがない=信用出来ない=怖くてコミット出来ない”くらいのチキンハートになる。

Perlのテストについて知りたかったら、今年のadvent calendarに大体書いてる。
あとはぐぐる。

参考URL: Perl Advent Calendar Japan 2011 Test Trac

コミットメッセージは次の日読んでも分かるくらいに書く。

新卒が書いたコードは、大体先輩のレビューを受ける。忙しい先輩には分かりやすいものを渡した方が良いに決まってる。
コミットログを見て、これはこうしたいっていうのを分かりやすく伝えた方がいい。
忙しい先輩への思いやり、プライスレス。
また以下のような事も出来るのでコミットログ綺麗に書くの本当にオススメ

参考URL: 業務終了後、git logとDist::Makerでさっさと帰る話。 – Perl Advent Calendar Japan 2011 Casual Track

コードを書くときは思いやりを持つ。

なるべくシンプルに分かりやすいコードを書く。難しい事はしない。
まだ存在していない後輩のための思いやりもプライスレス。

行の後ろに無駄な空白とか入れない・タブ文字と空白を混ぜない。

チーム開発なので、なるべく綺麗にする。
エディタの設定で一番後ろに$とか付けるとか色々ある。

エラーが出たら、ちゃんと読む

エラー読めば大体分かる。

わからなかったらぐぐる。それでもわからないなら先輩に聞く。

まずはエラーの内容でぐぐってみる。Googleで大体の事は分かる。それでも分からない事は先輩に聞く。
先輩はすごい人ばかりなので、一瞬でわかりやすく教えてくれて、しょうもない事で自分で調べて数時間が無駄になったとかにはならない。
なので、ぐぐってわからないなら先輩に聞いた方が良い。

なんかおかしかったらまず自分のコードを見る。

コード書いてておかしいな！と思ったら、まず自分を疑う。
大体それで解決する。

なるべくコードは書かない

勉強するには書いた方がいいと思うのだけど、業務の話！
例えば、order byだけが違うだけでメソッドを作ったりはしない。
コードを書くことはそれなりのコストがかかるのだと考える。

勉強したければ他人のコード読むのも良い。というか読んだ方が良い。

なるべく書いたコードは公開する

公開出来るようなコードは公開する。誰かからツッコミもらえたら勉強にもなる。

なるべく待たせない

待つのって結構ストレスだし、先輩や同期も他に仕事があるのでなるべく待たせない。
いつも待たせてスミマセン！

何事も挑戦だ！

とりあえずやってみる。

スイッチを切らない

スイッチが切れたら、なんか話を聞いても頭に入ってこなくなるので、スイッチを切らないようにする。
ほんとやばい。

めんどくさくてもやらなきゃいけない事はたくさんある。

めんどくさくてもやらなきゃいけない事はたくさんあるので、諦めてサクっとやる。
めんどくさいめんどくさい言ってるだけでは何も始まらないし、終わらない。
本当にめんどくさいなら、楽になるように変更する。

例: “業務終了後、git logとDist::Makerでさっさと帰る話”

まとめ

色々出来てないので更に気を付けたい。