歴8年のエンジニアが 改めて『Clean Code』 を読んでみた結果 JUNE-JUNE（植竹） 

自己紹介 HN：JUNE-JUNE ‣ 本名：植竹（ウエタケ） ‣ 1社目：受託開発エンジニア　 2社目：アプリのサーバーサイドエンジニア 現在：自社サービスのWebエンジニア 現所属 ‣ 虎の穴ラボ ‣ オタクの多いエンジニア会社 ‣ 主にFantiaやってます 比較的得意なもの ‣ Rails ‣ GCP 趣味コンテンツ ‣ バンドリ ‣ 金曜日のWebマンガ各種 

今回は…… エンジニアとして働いて8年と 結構年月が経ちました。 慣れてきた今こそ 良書と言われる『Clean Code』を 読むべきではと突然思い、 今日の登壇に至ります。 

なぜ今、読んだのか ・『わかる』ことが増えている ・劣悪なソースの例に見覚え、書き覚えがある ・慣れてきたとはいえ、著者が歴40年以上のエンジニアなので 　自身の経験より理論に重みがある 

では早速、読後で感じたポイントを挙げていきましょう 

『命名』について ・変数やメソッドの命名は分かりやすいものに 　⇒　実際に短い1単語のメソッド名は分かりづらく、 　　　言語によっては検索で追いづらい ・ノイズワードを入れてはいけない 　⇒　『name』でよい所を『nameString』のような命名をしてしまう 　　　個人的には身に覚えがある部分で、意識していきたい 

『メソッド』について ・引数は少なくするべき 　⇒　あまり意識できておらずやりがちな行為の筆頭 　　　『めんどくさい』という気の緩みでやりがち ・メソッドは『値を返す』『処理をする』のいずれかだけにする 　⇒　かなり同意できる部分 　　　過去のコードでも混在しているものは理解し難い 

『メソッド』について def test_controller test_model = TestModel.find(1) message = test_model.update_test_name_message ※戻り値を用いた表示処理※ end class TestModel def update_test_name_message self.save(name: ‘hoge’) "名前は#{self.name}" end end def test_controller test_model = TestModel.find(1) test_model.update_name message = test_model.get_name_message ※戻り値を用いた表示処理※ end class TestModel def update_name self.save(name: ‘hoge’) end def get_name_message "名前は#{self.name}" end end メソッドは増えるが、 右のほうが目的が明瞭。 ※サンプルソースは 　Rubyとなります 

『コメント』について ・コメントで説明するより意味が明瞭なメソッドにする ・コメントはノイズにもなり得るので影響が大きい 　⇒　コメントだから……と軽く思いがちな時がよくある 　　　『説明が不正確なコメントは残さない』 　　　『TODOコメントは失くしていく』など 　　　レビュー時でしっかりチェックしたりメンテナンスする必要がある 

『エラー』について ・メソッド内のエラーは戻りコードよりも例外が望ましい 　⇒　今回読んでみて最も頷いた部分 　　　人によって好みが別れる部分でもある 　　　ネストを深くしないために例外はそのまま例外として処理する 

『エラー』について def test_controller response = TestModel.test_method if(response[:result]) ※成功時の表示 ※ else ※失敗時の表示 ※ end end class TestModel def self.test_method begin raise ‘Error’ rescue return { result: false } end { result: true } end end def test_controller TestModel.test_method ※成功時の表示※ rescue ※失敗時の表示※ end class TestModel def self.test_method raise ‘Error’ end end すごく極端な例だが、 右の方がネストが浅く 理解しやすいコードとなる ※サンプルソースは 　Rubyとなります 

『単体テスト』について ・綺麗なテストを書くことは『クリーンコード』を 　書くことに直結する 　⇒　タスクに忙殺され全ての処理でのテストコードを 　　　書くのは難しい場合もあるが、 　　　単体テストで防止される不具合は多い ・ひとつのテストにひとつのアサート（assert） 　⇒　複数書いてしまいがちな身に覚えがある部分 　　　目的を明瞭にするためにも意識していきたい項目 

『同時並行性』について ・本書の『同時並行性』はマルチスレッド処理限定 　の注意事項ではない 　⇒　規模が大きく、何人ものユーザーが実行処理する 　　　サービスでも起こりうる可能性がある ・SQLでのデッドロックエラーがあればスコープの限定化や 　ロジックの見直しが必要 ・プロセッサより多いスレッドでテストすることでの再現性向上 説明しづらいので没 

最後に ・慣れてきたときこそ思い当たる経験が蓄積されてる ・たまに読み返すとより実感が持てて 　スキルとして定着しやすそう ・17章に全体の要約がまとまっているので、 　そこだけでも定期的に読む価値がある