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.2k
若手が可読性を上げるために気を付けたこと / 20210707_readablelt_nazato
Rakus_Dev
March 14, 2022
Tweet
Share
More Decks by Rakus_Dev
See All by Rakus_Dev
ラクスCTOが語る顧客視点を重視したプロダクト開発 / RAKUSTechCon2024_Kude
rakus_dev
0
2.2k
マルチプロダクトでのプロダクトマネージャーのリアル / RAKUSTechCon2024_Inagaki
rakus_dev
4
3.8k
拡大するマルチプロダクトSaaSの顧客理解にデザイン組織はどう取り組んでいるか / RAKUSTechCon2024_Design
rakus_dev
0
2.1k
急成長する大規模プロダクト開発のマネジメント課題とアプローチ / RAKUSTechCon2024_Seisan
rakus_dev
0
2k
パフォーマンス向上とリソース管理のためのアプローチ / RAKUSTechCon2024_RLC
rakus_dev
0
1.9k
急成長するサービスを支えるためのインフラ戦略 / RAKUSTechCon2024_Fujii
rakus_dev
0
2k
楽楽精算のQA改革 / RAKUSTechCon2024_Kaneko
rakus_dev
1
1.9k
新たな顧客課題に挑む17年目の進化とモダナイゼーション / RAKUSTechCon2024_Haihaimail
rakus_dev
1
1.9k
クロージングトーク / RAKUSTechCon2024_Closingtalk
rakus_dev
0
1.9k
Other Decks in Technology
See All in Technology
20241108_CS_LLMMT
shigashiyama
0
250
GraphRAGを用いたLLMによるパーソナライズド推薦の生成
naveed92
0
190
Lambdaと地方とコミュニティ
miu_crescent
2
210
Valuable Lessons Learned on Kaggle’s ARC AGI LLM challenge
ianozsvald
0
100
今、始める、第一歩。 / Your first step
yahonda
2
680
10分でわかるfreeeのQA
freee
1
3.5k
株式会社島津製作所_研究開発(集団協業と知的生産)の現場を支える、OSS知識基盤システムの導入
akahane92
1
180
TinyGoを使ったVSCode拡張機能実装
askua
2
200
音声×Copilot オンコパの世界
kasada
1
110
ドメイン名の終活について - JPAAWG 7th -
mikit
29
17k
Terraform未経験の御様に対してどの ように導⼊を進めていったか
tkikuchi
1
210
OCI Data Integration技術情報 / ocidi_technical_jp
oracle4engineer
PRO
1
2.6k
Featured
See All Featured
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
4
360
Bash Introduction
62gerente
608
210k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
364
24k
Git: the NoSQL Database
bkeepers
PRO
427
64k
Code Review Best Practice
trishagee
64
17k
Adopting Sorbet at Scale
ufuk
73
9.1k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
92
16k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
231
17k
RailsConf 2023
tenderlove
29
890
What's new in Ruby 2.0
geeforr
343
31k
YesSQL, Process and Tooling at Scale
rocio
168
14k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
28
8.2k
Transcript
若手が可読性を上げるために 気を付けたこと 名里 梨佐
自己紹介 • 氏名 • 名里梨佐(ナザトリサ) • 所属 • 株式会社ラクス •
仕事 • Mail Dealerの開発をしています
本日のお話 個人でプログラムを書くことしかしていなかった人間が、 グループの一員として開発に関わるようになって2年と少し。 可読性を良くするために考えさせられたことを 多かった指摘のコメントランキングと共にお話します。
第3位 コメントが(不要です/必要です)
コメント • 自分一人しか見ないコードは結構コメントを適当に書いていた • コメントの要否の判断の重要性 • 短いコードにいちいちコメントを付ける必要はない • 複雑な処理をしているコードや関数は意味が分かるようにコメントを付ける →
致し方なくこういうコードにしなければならなかった背景・理由など
第2位 名前が分かりにくい
たかが命名、されど命名 • 接頭辞を使う • isXXX • hasXXX • canXXX •
具体的な名前を使っているか • Get()は使いやすいが、状況によってはDownload()などの方がより明確に伝わるか も • Itemなども便利ではあるが、汎用的なので分かりにくい時もある。 例)「checkItem()」→「checkSortItem()」
たかが命名、されど命名 • 一般的な単語を使っているか 命名時 翻訳してみよう→そのまま使うはNG 簡潔な単語を使っても、一般的に使われる単語でなければ、他の人が分からない ただ、逆に簡単な言葉を使って分かりにくくなるケースも… 例)項目名が正しいかをチェックする関数を作りたい 「checkItemName()」 →
「validateItemName()」 checkは便利だが、何をチェックしているかわからない 正しいことをチェックすることがわかるようにしないといけない
第1位 冗長です
何日か後の自分は他人です • 何日か後の自分が読みにくいコードが、他人に読めるはずがない • ネストが深いコードは読みにくさがMAX → 何か月か後に自分が書いたコードだと思って修正しようとすると 思ったより読めない • 対策
• 関数として切り分ける • 複数の処理を関数内で持たせるのは避ける • 複雑にせざるを得ない場合はコメントを残す 特に試行錯誤してやっとできたコードほど読みにくくないかを確認すべし!!
early return • メソッドの先頭で渡された引数が不正な値でないかチェックして、もし不 正な値であれば return で即メソッドを抜ける →その後の処理は引数に不正な値でないか気にする必要がなくなるので、 コードがスッキリ
コメントでコーディング • 状況に応じた粒度で実装の流れを書いてみる →やりたいことが明確になる //実行権限のチェップロードしたファイル関連のチェック //実行権限のチェック //アップロードしたファイル関連のチェック //ファイルの存在確認 //ファイルを読み込めているかチェック //空チェック
//項目数のチェック //項目のデータのチェック //登録処理 イメージ(ファイル関連の処理)
まとめ 可読性の高いコードを書く方法については段々つかめてきたが、 コードを書くということは可読性だけを気にしていたらいいわけではない 次は保守性、拡張性との戦いへ…
ご清聴ありがとうございました!!