4
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

はじめてのアドベントカレンダーAdvent Calendar 2024

Day 14

エンジニア5年目にして初めてリーダブルコードとやらを読んでみた

Last updated at Posted at 2024-12-13

はじめに

今年でIT業界5年目になりますがいわゆる技術書?みたいなものには触れ無いようにしてた(読んだところでなんか変わんのか?くらいの肌感):frowning2:
ただ、今更ながらエンジニアなら業務以外でも技術力くらいつけろよと思い手を出してみることにしました!!

目的

「エンジニアならこれ読んどけ」みたいな情報をいくつか見たことがあるようなないようなリーダブルコード
要約とかは頭いい人たちがいっぱい書いてると思うのでいざ読んでみた感想を書いてみました!
読んだことない人やこれから頑張る人のきっかけになれば嬉しいです:grimacing:

そもそもリーダブルコードってどんな内容?

タイトルにもなってる通り「読みやすいコード」へ向けてのアドバイス

コード書いてるとどうしても
 ・「動いてるからOK」の精神を多用
 ・後で変えるからといって名前を「test」にして結局変えるの忘れる
 ・後でコメントつけると言いつつつけない
 ・処理考えるのだるくて無理やり実装して冗長化
等であんまり他人とコード書いてるとは思えないものを無限に生成してしまう、、

こんなのに当てはまるような例とこうしたらもっとわかりやすくなるよが挙げられてた
綺麗事だけじゃなくて割と開発経験に基づいたものが多いのですごいイメージが湧きやすい内容だった

読んでみた感想

「分かりやすさ」への再定義

正直「動いてるからOK」でコードは書いてしまいますし、何年経っても自分で書いたコードに文句言ってます。:frowning2:
今まで「この程度で読みやすいだろう」と思っていた命名は、実は曖昧だったり、関数に詰め込みすぎていたり…。これを読むと、自分のコードの中の「絶妙なわかりにくさ」を客観的に見つける感覚を得られるきっかけになるかも?

チーム開発におけるルール決めの参考

大小様々なチーム、案件で異なるコーディング規約があったりします。
他にもエディタとかでLinter設定したりとか整形ルールがあったりとか...
ただここで気にしたいのはルールが何というよりは納得できるルールをチーム内で共有できてるか?だと思ってます。

思いつきだけで決めるのではなく、例えばこの本を参考にしつつ選定というのもありなのかな?:confused:

基礎ステータスのレベルアップ

エンジニアが知識をアップデートする際、新しい言語やフレームワーク、ツールに目を向けがちです。しかし、この本を読んで気づいたのは、「コードの読みやすさ」は色んな技術スタックにおいて必須のスキルであり、代わりがあんまない価値があることです。

最新技術は数年で腐っていくことも多いですが、「読み手に優しいコードを書く技術」は、どんな状態でも割と通用します。むしろ、いろんな技術が溢れている現代だからこそ、まず読んでみて基礎ステータスアップに向けてチャレンジしてみるのも良いのではないでしょうか?:hugging:

特に刺さった・気になった部分

JavaScriptのグローバルスコープ

普段こういう書き方しなかったからわからなかったけどJavaScriptで変数定義の際、
letやconstをつけずに定義するとその変数はグローバルスコープになってしまうらしい:hand_splayed:

例えばfor文のiをそのままi=0で定義してみると

for(i = 0; i < 10; i+=1){
	console.log("for文の中:",i)
}

console.log("for文の外:",i)

実行結果は以下のようになる。
①iが0~9まではfor文の中のconsole.logが実行される
②iが9のconsole.logが終わったらi+=1が実行されi=10となりfor文終了
③forの外のconsole.logでi(10)が出力される。

こういう書き方がそもそもOKなの知らなかったけどついミスってしまうことありそう、、、:japanese_goblin:

ネストを浅くする

例えば以下の項目がすべてOKになるものだけリターンする関数があったとする。
・空文字じゃない
・英字ではじまるか
・10文字以内か

改善前の例:深いネスト

def find_valid_usernames(usernames):
    valid_names = []
    for name in usernames:
        # ユーザ名が空文字でないかチェック
        if name != "":
            # ユーザ名が英字で始まるかチェック
            if name[0].isalpha():
                # ユーザ名が10文字以下かチェック
                if len(name) <= 10:
                    valid_names.append(name)
    return valid_names

このコードには3段のifネストがあり、読み手は一度に多くの条件をトレースする必要があります。「まず空文字でないことを確認して、その中で英字で始まるかを確認して、その中で長さを確認して…」という具合です。条件が増えると、このようなコードはさらに複雑になり、抜け漏れを起こしやすくなります

改善後の例:早期リターンやガード節を利用してネストを浅くする

def find_valid_usernames(usernames):
    valid_names = []
    for name in usernames:
        # 空文字であればスキップ
        if name == "":
            continue
        
        # 英字で始まらない場合はスキップ
        if not name[0].isalpha():
            continue
        
        # 10文字以下でなければスキップ
        if len(name) > 10:
            continue

        # ここまで来たら条件をすべてクリア
        valid_names.append(name)
    return valid_names

この例では、条件が満たされない場合はcontinueを用いて早めにループの次の繰り返しへ移動する、いわゆる「ガード節」のパターンを使っています。こうすることで、ifのネストが深くなることを避け、コードの読み手は「この条件を満たさなければスキップする」という流れを直線的に追うことができます。

ネストが浅くなることで、読み手はロジックを左から右、上から下へとシンプルな流れで理解できます。「この条件をパスしなければならない」という正当ルートを常に下方向に進んでいくため、ブロックが何重にも入れ子になった構造よりも直感的です。

まとめ

エンジニアとして5年目にして初めて『リーダブルコード』を読んでみて、「今読んでよかった」と感じる内容でした。
エンジニア1年目とかに読んでも私の頭ではイメージつきづらくそりゃそうだろとか思ってたかもしれません。
まあ一回読んだだけじゃよーわからんとことか覚えてないことも多いですが:point_up_2:

コード書ける力とかも重視しがちですが、その中で「読みやすさ」という普遍的な価値を発見できたことはいい経験になりました!

気になった人いたらぜひ読んでみてね:santa_tone2:

4
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?