Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
若手が可読性を上げるために気を付けたこと / 20210707_readablelt_nazato
Search
Rakus_Dev
March 14, 2022
Technology
0
2.5k
若手が可読性を上げるために気を付けたこと / 20210707_readablelt_nazato
Rakus_Dev
March 14, 2022
Tweet
Share
More Decks by Rakus_Dev
See All by Rakus_Dev
AIへの再指示を抑える要件、設計、デザイン等のモバイル開発コンテキストの渡し方
rakus_dev
0
110
モバイルアプリ向けに開発したAPIをMCP化したら便利そうだった / mobiletechcafe20250902-2
rakus_dev
0
100
AIによるAndroidアプリのモダン化 / mobiletechcafe20250902-3
rakus_dev
0
110
iOSアプリからMCPツールを使う / mobiletechcafe20250902-4
rakus_dev
0
100
Claude Code × FastAPI-MCP モバイル技術記事の自動作成 / mobiletechcafe20250902-5
rakus_dev
0
110
AI時代にPdMとPMMはどう連携すべきか / PdM–PMM-collaboration-in-AI-era
rakus_dev
0
300
【TECH PLAY Product Management Conference】AI時代にどんなPdMが求められているのか? 〜私たちが見てきたリアルから考える〜 / techplay-pdmconf-ai
rakus_dev
0
300
『楽楽電子保存』開発チームが挑む「AI駆動開発」の全貌 / rakustechcon2025-rakurakudenshihozon
rakus_dev
2
800
数字と感情で語るスクラム導入効果。『楽楽勤怠』開発チームの変革の軌跡 / rakustechcon2025-rakurakukintai
rakus_dev
1
780
Other Decks in Technology
See All in Technology
ブロックテーマ時代における、テーマの CSS について考える Toro_Unit / 2025.09.13 @ Shinshu WordPress Meetup
torounit
0
120
テストを軸にした生き残り術
kworkdev
PRO
0
200
AWSを利用する上で知っておきたい名前解決のはなし(10分版)
nagisa53
10
3.1k
Snowflake Intelligenceにはこうやって立ち向かう!クラシルが考えるAI Readyなデータ基盤と活用のためのDataOps
gappy50
0
220
Function Body Macros で、SwiftUI の View に Accessibility Identifier を自動付与する/Function Body Macros: Autogenerate accessibility identifiers for SwiftUI Views
miichan
2
180
実践!カスタムインストラクション&スラッシュコマンド
puku0x
0
400
「全員プロダクトマネージャー」を実現する、Cursorによる仕様検討の自動運転
applism118
21
11k
COVESA VSSによる車両データモデルの標準化とAWS IoT FleetWiseの活用
osawa
1
280
2025年になってもまだMySQLが好き
yoku0825
8
4.7k
スマートファクトリーの第一歩 〜AWSマネージドサービスで 実現する予知保全と生成AI活用まで
ganota
2
220
【初心者向け】ローカルLLMの色々な動かし方まとめ
aratako
7
3.4k
Webアプリケーションにオブザーバビリティを実装するRust入門ガイド
nwiizo
7
820
Featured
See All Featured
Context Engineering - Making Every Token Count
addyosmani
3
42
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
15k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.9k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
Embracing the Ebb and Flow
colly
87
4.8k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
Mobile First: as difficult as doing things right
swwweet
224
9.9k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
9
810
Writing Fast Ruby
sferik
628
62k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
The World Runs on Bad Software
bkeepers
PRO
70
11k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
Transcript
若手が可読性を上げるために 気を付けたこと 名里 梨佐
自己紹介 • 氏名 • 名里梨佐(ナザトリサ) • 所属 • 株式会社ラクス •
仕事 • Mail Dealerの開発をしています
本日のお話 個人でプログラムを書くことしかしていなかった人間が、 グループの一員として開発に関わるようになって2年と少し。 可読性を良くするために考えさせられたことを 多かった指摘のコメントランキングと共にお話します。
第3位 コメントが(不要です/必要です)
コメント • 自分一人しか見ないコードは結構コメントを適当に書いていた • コメントの要否の判断の重要性 • 短いコードにいちいちコメントを付ける必要はない • 複雑な処理をしているコードや関数は意味が分かるようにコメントを付ける →
致し方なくこういうコードにしなければならなかった背景・理由など
第2位 名前が分かりにくい
たかが命名、されど命名 • 接頭辞を使う • isXXX • hasXXX • canXXX •
具体的な名前を使っているか • Get()は使いやすいが、状況によってはDownload()などの方がより明確に伝わるか も • Itemなども便利ではあるが、汎用的なので分かりにくい時もある。 例)「checkItem()」→「checkSortItem()」
たかが命名、されど命名 • 一般的な単語を使っているか 命名時 翻訳してみよう→そのまま使うはNG 簡潔な単語を使っても、一般的に使われる単語でなければ、他の人が分からない ただ、逆に簡単な言葉を使って分かりにくくなるケースも… 例)項目名が正しいかをチェックする関数を作りたい 「checkItemName()」 →
「validateItemName()」 checkは便利だが、何をチェックしているかわからない 正しいことをチェックすることがわかるようにしないといけない
第1位 冗長です
何日か後の自分は他人です • 何日か後の自分が読みにくいコードが、他人に読めるはずがない • ネストが深いコードは読みにくさがMAX → 何か月か後に自分が書いたコードだと思って修正しようとすると 思ったより読めない • 対策
• 関数として切り分ける • 複数の処理を関数内で持たせるのは避ける • 複雑にせざるを得ない場合はコメントを残す 特に試行錯誤してやっとできたコードほど読みにくくないかを確認すべし!!
early return • メソッドの先頭で渡された引数が不正な値でないかチェックして、もし不 正な値であれば return で即メソッドを抜ける →その後の処理は引数に不正な値でないか気にする必要がなくなるので、 コードがスッキリ
コメントでコーディング • 状況に応じた粒度で実装の流れを書いてみる →やりたいことが明確になる //実行権限のチェップロードしたファイル関連のチェック //実行権限のチェック //アップロードしたファイル関連のチェック //ファイルの存在確認 //ファイルを読み込めているかチェック //空チェック
//項目数のチェック //項目のデータのチェック //登録処理 イメージ(ファイル関連の処理)
まとめ 可読性の高いコードを書く方法については段々つかめてきたが、 コードを書くということは可読性だけを気にしていたらいいわけではない 次は保守性、拡張性との戦いへ…
ご清聴ありがとうございました!!