over 初心者の罠

over 初心者の罠

From: 松田航
サザンテラスのスタバにて

「えっとここって何が書いてあるんですか?」

「ああ、これは◯◯している場所ですね」

「これって何してる関数ですか?」

「これは△△のモデルにデータを取りにいっています」

「ここで宣言している変数って何に使っているんですか?」

「えっと、これは、、、」

うちのスタッフとの会話です。

彼はかなり育ってきたスタッフで、スラスラとコードを書いてくれるようになっています。ほとんど放置しても大丈夫で、とても楽になってきました。

しかし、最近プルリクでコードを確認すると、上記のような会話が頻発するようになってきました。

僕の理解力が低いのではという話は置いておいて、これは少しまずい傾向です。

初心者を抜け出して、少しコードが書けるようになってくると、陥る罠があります。

かっこよく書きたくなる

for_blog_la

ビギナーのレベルを超えた人間が次に目指すのは「かっこよく」です。特に男性陣はその傾向が強い。

・とにかく短く書こう
・とにかくライブラリ化して使いまわせるようにしよう
・関数をたくさん作ろう(何をとってきてんだかわからんgetホニャララ)

とか、そのような感じです。これは初心者ゾーンを抜けたエンジニアによくある病です。

当然、これらが100%いけないわけではありません。向上心も二重丸です。しかし、程度もんだという話です。

目指すべきゴール地点がずれているのです。

かっこよく書くのがゴールか?

なぜ、コードを短く書くかというと、その方がわかりやすく読みやすくなる「可能性が高い」からです。

1万文字の文章と3000文字の文章、どちらの方が早く読み終わるでしょうか?

後者の方が、時間がかからないですよね? 

コードも一緒で、3000行のコードと1000行のコードを読むとき、後者の方が早く読めます。

だからこそ短く書くべきなのです。

ライブラリや関数を作って使うのは、それが再利用できて、便利で、コードが読みやすくなるからです。

解読難度の高い1行を作った時点で、どんなに短いコードであっても、読むのに時間がかかるようになります。

少なくとも今は一回しか使わないものをライブラリ化しても、工数も無駄にしますし、コードを読みに行くのが非常に手間です。(3回くらい同じこと書く必要ができたらやるべき)

ゴールは読みやすく

「かっこよく」という定性的な自己満足ではなく、「読みやすい=他人が読んで時間がかかりずらい」という定量的なゴールを目標にすべきです。

自分だけ知っているニッチなフレームワークの隠れ関数を叩いても、他の人にとっては邪魔なだけです。

自分以外が読んでもわかるか否かを基準にコードは書くべきなのです。

どうしても使いたくなったら、上にわかりやすいコメントを書きましょう。(社内wikiは読みに行くのが手間だし、そもそも調べにいかないことが多々)

メンバー全員が、「周りの人が読みやすいコードを」を意識して書いてくれれば、それだけでいいプロジェクトになりますし、メンバーが仮に抜けたとしても、その後のフォローは格段に楽になります。

読みやすいコードを書くには?

オライリーのリーダブルコードを読みましょう。

以上! 笑

あとは、コミュニケーションと一緒です。一人で暴走しないようにしましょうね。周りに合わせて話す大きさと速度を変えましょうね、ということです。

松田

 

PS
空気を読めという話ではないので、それが全員に伝わるように研修をやるとかも可。

ただし、新しく入ってくる人がわからないので、マニュアルを作るか(面倒だけど、、)、もういっそプログラムごとの標準的コーディング規則およびドキュメントや本に頼りましょう。

PPS
プログラミングを学ぶスクールならこちら