Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
若手が可読性を上げるために気を付けたこと / 20210707_readablelt_nazato
Rakus_Dev
March 14, 2022
Technology
0
1.3k
若手が可読性を上げるために気を付けたこと / 20210707_readablelt_nazato
Rakus_Dev
March 14, 2022
Tweet
Share
More Decks by Rakus_Dev
See All by Rakus_Dev
新サービスのプロジェクト推進に向けた、トライ&エラー / 20221109_kawasaki
rakus_dev
0
350
レガシーになりゆく システムとの向き合い方 / 20221005_inoue
rakus_dev
0
830
PMMやプロダクト関係者と協働するために役割を整理した話 / 20220810_pdmtipslt
rakus_dev
0
230
既存システムのフロントエンド・バックエンド分離 / meetup0706-seki
rakus_dev
0
630
プロダクトデザイン組織の 新しい取り組み / meetup0706-onoda
rakus_dev
1
550
障害対応を自動化した話 / 20220609_Automation
rakus_dev
0
520
横断部門としての取り組み紹介(研究開発、共通基盤開発) / rakus-meetup-202206
rakus_dev
0
1k
リーダブルなPHPDocを目指して / 20210707-readablelt-nishihara
rakus_dev
0
1.3k
インフラエンジニアとしての成長記 / 20220302_Meetup_maekawa
rakus_dev
0
620
Other Decks in Technology
See All in Technology
チケットNFTの仕組み
sbtechnight
0
330
FlexScan HD2452Wの 後継を探して
tring
0
240
DNS権威サーバのクラウドサービス向けに行われた攻撃および対策 / DNS Pseudo-Random Subdomain Attack and mitigations
kazeburo
4
830
lt53
98_justdoit
0
110
ML PM, DS PMってどんな仕事をしているの?
line_developers
PRO
1
200
オンプレk8sとEKSの並行運用の実際
ch1aki
0
130
PCI DSS に準拠したシステム開発
yutadayo
0
230
ROS_Japan_UG_#49_LT
maeharakeisuke
0
200
re:Invent re:Cap / AWS Lambda Updates
bulbulpaul
1
140
Airdrop for Open Source Projects
epicsdao
0
250
Technologies for developing editors / Webエディタ開発を支える技術
shuta13
1
220
GitHub Codespaces が拡げる開発環境、いつでもどこでも Visual Studio Code で!
dzeyelid
0
150
Featured
See All Featured
Learning to Love Humans: Emotional Interface Design
aarron
263
38k
Visualization
eitanlees
128
12k
Building Better People: How to give real-time feedback that sticks.
wjessup
346
17k
How New CSS Is Changing Everything About Graphic Design on the Web
jensimmons
214
12k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
657
120k
GraphQLの誤解/rethinking-graphql
sonatard
39
7.8k
Clear Off the Table
cherdarchuk
79
290k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
15
1.2k
The Web Native Designer (August 2011)
paulrobertlloyd
76
2.2k
WebSockets: Embracing the real-time Web
robhawkes
58
6k
Robots, Beer and Maslow
schacon
154
7.3k
Rails Girls Zürich Keynote
gr2m
87
12k
Transcript
若手が可読性を上げるために 気を付けたこと 名里 梨佐
自己紹介 • 氏名 • 名里梨佐(ナザトリサ) • 所属 • 株式会社ラクス •
仕事 • Mail Dealerの開発をしています
本日のお話 個人でプログラムを書くことしかしていなかった人間が、 グループの一員として開発に関わるようになって2年と少し。 可読性を良くするために考えさせられたことを 多かった指摘のコメントランキングと共にお話します。
第3位 コメントが(不要です/必要です)
コメント • 自分一人しか見ないコードは結構コメントを適当に書いていた • コメントの要否の判断の重要性 • 短いコードにいちいちコメントを付ける必要はない • 複雑な処理をしているコードや関数は意味が分かるようにコメントを付ける →
致し方なくこういうコードにしなければならなかった背景・理由など
第2位 名前が分かりにくい
たかが命名、されど命名 • 接頭辞を使う • isXXX • hasXXX • canXXX •
具体的な名前を使っているか • Get()は使いやすいが、状況によってはDownload()などの方がより明確に伝わるか も • Itemなども便利ではあるが、汎用的なので分かりにくい時もある。 例)「checkItem()」→「checkSortItem()」
たかが命名、されど命名 • 一般的な単語を使っているか 命名時 翻訳してみよう→そのまま使うはNG 簡潔な単語を使っても、一般的に使われる単語でなければ、他の人が分からない ただ、逆に簡単な言葉を使って分かりにくくなるケースも… 例)項目名が正しいかをチェックする関数を作りたい 「checkItemName()」 →
「validateItemName()」 checkは便利だが、何をチェックしているかわからない 正しいことをチェックすることがわかるようにしないといけない
第1位 冗長です
何日か後の自分は他人です • 何日か後の自分が読みにくいコードが、他人に読めるはずがない • ネストが深いコードは読みにくさがMAX → 何か月か後に自分が書いたコードだと思って修正しようとすると 思ったより読めない • 対策
• 関数として切り分ける • 複数の処理を関数内で持たせるのは避ける • 複雑にせざるを得ない場合はコメントを残す 特に試行錯誤してやっとできたコードほど読みにくくないかを確認すべし!!
early return • メソッドの先頭で渡された引数が不正な値でないかチェックして、もし不 正な値であれば return で即メソッドを抜ける →その後の処理は引数に不正な値でないか気にする必要がなくなるので、 コードがスッキリ
コメントでコーディング • 状況に応じた粒度で実装の流れを書いてみる →やりたいことが明確になる //実行権限のチェップロードしたファイル関連のチェック //実行権限のチェック //アップロードしたファイル関連のチェック //ファイルの存在確認 //ファイルを読み込めているかチェック //空チェック
//項目数のチェック //項目のデータのチェック //登録処理 イメージ(ファイル関連の処理)
まとめ 可読性の高いコードを書く方法については段々つかめてきたが、 コードを書くということは可読性だけを気にしていたらいいわけではない 次は保守性、拡張性との戦いへ…
ご清聴ありがとうございました!!