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
120
モバイルアプリ向けに開発したAPIをMCP化したら便利そうだった / mobiletechcafe20250902-2
rakus_dev
0
110
AIによるAndroidアプリのモダン化 / mobiletechcafe20250902-3
rakus_dev
0
110
iOSアプリからMCPツールを使う / mobiletechcafe20250902-4
rakus_dev
0
110
Claude Code × FastAPI-MCP モバイル技術記事の自動作成 / mobiletechcafe20250902-5
rakus_dev
0
110
AI時代にPdMとPMMはどう連携すべきか / PdM–PMM-collaboration-in-AI-era
rakus_dev
0
310
【TECH PLAY Product Management Conference】AI時代にどんなPdMが求められているのか? 〜私たちが見てきたリアルから考える〜 / techplay-pdmconf-ai
rakus_dev
0
300
『楽楽電子保存』開発チームが挑む「AI駆動開発」の全貌 / rakustechcon2025-rakurakudenshihozon
rakus_dev
2
810
数字と感情で語るスクラム導入効果。『楽楽勤怠』開発チームの変革の軌跡 / rakustechcon2025-rakurakukintai
rakus_dev
1
790
Other Decks in Technology
See All in Technology
JTCにおける内製×スクラム開発への挑戦〜内製化率95%達成の舞台裏/JTC's challenge of in-house development with Scrum
aeonpeople
0
290
Modern Linux
oracle4engineer
PRO
0
170
フルカイテン株式会社 エンジニア向け採用資料
fullkaiten
0
8.8k
「Linux」という言葉が指すもの
sat
PRO
4
150
KotlinConf 2025_イベントレポート
sony
1
150
いま注目のAIエージェントを作ってみよう
supermarimobros
0
370
エンジニアがデザインまで担うための AI駆動UIデザイン/フロントエンド開発実践
kitami
2
140
今日から始めるAWSセキュリティ対策 3ステップでわかる実践ガイド
yoshidatakeshi1994
0
140
実践!カスタムインストラクション&スラッシュコマンド
puku0x
0
580
Generative AI Japan 第一回生成AI実践研究会「AI駆動開発の現在地──ブレイクスルーの鍵を握るのはデータ領域」
shisyu_gaku
0
350
ブロックテーマ時代における、テーマの CSS について考える Toro_Unit / 2025.09.13 @ Shinshu WordPress Meetup
torounit
0
130
Platform開発が先行する Platform Engineeringの違和感
kintotechdev
4
590
Featured
See All Featured
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Side Projects
sachag
455
43k
Intergalactic Javascript Robots from Outer Space
tanoku
272
27k
Context Engineering - Making Every Token Count
addyosmani
3
64
Optimizing for Happiness
mojombo
379
70k
BBQ
matthewcrist
89
9.8k
How to Think Like a Performance Engineer
csswizardry
26
1.9k
Java REST API Framework Comparison - PWX 2021
mraible
33
8.8k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
15k
Rails Girls Zürich Keynote
gr2m
95
14k
Transcript
若手が可読性を上げるために 気を付けたこと 名里 梨佐
自己紹介 • 氏名 • 名里梨佐(ナザトリサ) • 所属 • 株式会社ラクス •
仕事 • Mail Dealerの開発をしています
本日のお話 個人でプログラムを書くことしかしていなかった人間が、 グループの一員として開発に関わるようになって2年と少し。 可読性を良くするために考えさせられたことを 多かった指摘のコメントランキングと共にお話します。
第3位 コメントが(不要です/必要です)
コメント • 自分一人しか見ないコードは結構コメントを適当に書いていた • コメントの要否の判断の重要性 • 短いコードにいちいちコメントを付ける必要はない • 複雑な処理をしているコードや関数は意味が分かるようにコメントを付ける →
致し方なくこういうコードにしなければならなかった背景・理由など
第2位 名前が分かりにくい
たかが命名、されど命名 • 接頭辞を使う • isXXX • hasXXX • canXXX •
具体的な名前を使っているか • Get()は使いやすいが、状況によってはDownload()などの方がより明確に伝わるか も • Itemなども便利ではあるが、汎用的なので分かりにくい時もある。 例)「checkItem()」→「checkSortItem()」
たかが命名、されど命名 • 一般的な単語を使っているか 命名時 翻訳してみよう→そのまま使うはNG 簡潔な単語を使っても、一般的に使われる単語でなければ、他の人が分からない ただ、逆に簡単な言葉を使って分かりにくくなるケースも… 例)項目名が正しいかをチェックする関数を作りたい 「checkItemName()」 →
「validateItemName()」 checkは便利だが、何をチェックしているかわからない 正しいことをチェックすることがわかるようにしないといけない
第1位 冗長です
何日か後の自分は他人です • 何日か後の自分が読みにくいコードが、他人に読めるはずがない • ネストが深いコードは読みにくさがMAX → 何か月か後に自分が書いたコードだと思って修正しようとすると 思ったより読めない • 対策
• 関数として切り分ける • 複数の処理を関数内で持たせるのは避ける • 複雑にせざるを得ない場合はコメントを残す 特に試行錯誤してやっとできたコードほど読みにくくないかを確認すべし!!
early return • メソッドの先頭で渡された引数が不正な値でないかチェックして、もし不 正な値であれば return で即メソッドを抜ける →その後の処理は引数に不正な値でないか気にする必要がなくなるので、 コードがスッキリ
コメントでコーディング • 状況に応じた粒度で実装の流れを書いてみる →やりたいことが明確になる //実行権限のチェップロードしたファイル関連のチェック //実行権限のチェック //アップロードしたファイル関連のチェック //ファイルの存在確認 //ファイルを読み込めているかチェック //空チェック
//項目数のチェック //項目のデータのチェック //登録処理 イメージ(ファイル関連の処理)
まとめ 可読性の高いコードを書く方法については段々つかめてきたが、 コードを書くということは可読性だけを気にしていたらいいわけではない 次は保守性、拡張性との戦いへ…
ご清聴ありがとうございました!!