From: 松田航
サザンテラスのスタバにて
「えっとここって何が書いてあるんですか？」
「ああ、これは◯◯している場所ですね」
「これって何してる関数ですか？」
「これは△△のモデルにデータを取りにいっています」
「ここで宣言している変数って何に使っているんですか？」
「えっと、これは、、、」
うちのスタッフとの会話です。
彼はかなり育ってきたスタッフで、スラスラとコードを書いてくれるようになっています。ほとんど放置しても大丈夫で、とても楽になってきました。
しかし、最近プルリクでコードを確認すると、上記のような会話が頻発するようになってきました。
僕の理解力が低いのではという話は置いておいて、これは少しまずい傾向です。
初心者を抜け出して、少しコードが書けるようになってくると、陥る罠があります。
かっこよく書きたくなる
ビギナーのレベルを超えた人間が次に目指すのは「かっこよく」です。特に男性陣はその傾向が強い。
・とにかく短く書こう
・とにかくライブラリ化して使いまわせるようにしよう
・関数をたくさん作ろう（何をとってきてんだかわからんgetホニャララ）
とか、そのような感じです。これは初心者ゾーンを抜けたエンジニアによくある病です。
当然、これらが100%いけないわけではありません。向上心も二重丸です。しかし、程度もんだという話です。
目指すべきゴール地点がずれているのです。
かっこよく書くのがゴールか？
なぜ、コードを短く書くかというと、その方がわかりやすく読みやすくなる「可能性が高い」からです。
1万文字の文章と3000文字の文章、どちらの方が早く読み終わるでしょうか？
後者の方が、時間がかからないですよね？
コードも一緒で、3000行のコードと1000行のコードを読むとき、後者の方が早く読めます。
だからこそ短く書くべきなのです。
ライブラリや関数を作って使うのは、それが再利用できて、便利で、コードが読みやすくなるからです。
解読難度の高い１行を作った時点で、どんなに短いコードであっても、読むのに時間がかかるようになります。
少なくとも今は一回しか使わないものをライブラリ化しても、工数も無駄にしますし、コードを読みに行くのが非常に手間です。（３回くらい同じこと書く必要ができたらやるべき）
ゴールは読みやすく
「かっこよく」という定性的な自己満足ではなく、「読みやすい=他人が読んで時間がかかりずらい」という定量的なゴールを目標にすべきです。
自分だけ知っているニッチなフレームワークの隠れ関数を叩いても、他の人にとっては邪魔なだけです。
自分以外が読んでもわかるか否かを基準にコードは書くべきなのです。
どうしても使いたくなったら、上にわかりやすいコメントを書きましょう。（社内wikiは読みに行くのが手間だし、そもそも調べにいかないことが多々）
メンバー全員が、「周りの人が読みやすいコードを」を意識して書いてくれれば、それだけでいいプロジェクトになりますし、メンバーが仮に抜けたとしても、その後のフォローは格段に楽になります。
読みやすいコードを書くには？
オライリーのリーダブルコードを読みましょう。
以上！ 笑
あとは、コミュニケーションと一緒です。一人で暴走しないようにしましょうね。周りに合わせて話す大きさと速度を変えましょうね、ということです。
松田
PS
空気を読めという話ではないので、それが全員に伝わるように研修をやるとかも可。
ただし、新しく入ってくる人がわからないので、マニュアルを作るか（面倒だけど、、）、もういっそプログラムごとの標準的コーディング規則およびドキュメントや本に頼りましょう。
