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
870
若手が可読性を上げるために気を付けたこと / 20210707_readablelt_nazato
Rakus_Dev
March 14, 2022
Tweet
Share
More Decks by Rakus_Dev
See All by Rakus_Dev
障害対応を自動化した話 / 20220609_Automation
rakus_dev
0
370
横断部門としての取り組み紹介(研究開発、共通基盤開発) / rakus-meetup-202206
rakus_dev
0
360
リーダブルなPHPDocを目指して / 20210707-readablelt-nishihara
rakus_dev
0
870
インフラエンジニアとしての成長記 / 20220302_Meetup_maekawa
rakus_dev
0
400
右も左も分からない1年目が上流工程を理解するまでの話 / 20220302-meetup-nagata
rakus_dev
0
410
入社して3年間で『Rundeck』を使って自動化した「面倒」な作業たち / 20220302-meetup-kanamori
rakus_dev
0
480
ラクスUI開発課のチーム活動 / 220222_uiux
rakus_dev
0
490
SaaSマルチヒットメーカーラクスのインフラ戦略 / 20220208_TechCon2022_kanemoto
rakus_dev
1
1.2k
楽楽精算のサービスと共に成長するエンジニア組織の3年間とこれから / 20220208_techcon2022-seisan
rakus_dev
0
1.2k
Other Decks in Technology
See All in Technology
The application of formal methods in Kafka reliability engineering
line_developers
PRO
1
210
Custom AppをIP制限ありのままで審査に通す方法
yusuga
0
700
Oracle Cloud Infrastructure:2022年6月度サービス・アップデート
oracle4engineer
PRO
0
170
モブに早く慣れたい人のためのガイド / A Guide to Getting Started Quickly with Mob Programming
cybozuinsideout
PRO
2
1.9k
JAWS-UG re:Habilitaion 報告 / JAWS-UG OITA rehabilitation
hiranofumio
0
140
MRTK3 - DataBinding and Theming 入門
futo23
0
210
ZephyrRTOSのLongan Nanoへの移植
tokitahiroshi
0
110
開発組織の生産性を可視化する State of DevOpsとFour Keysとは / deep dive into State of DevOps
yfcgpsebp
0
310
データ分析で切り拓け! エンジニアとしてのデータ分析職キャリア戦略
ksnt
0
190
今どきのLinux事情
tokida
45
36k
Power Virtual Agentsのハジメ
miyakemito
1
150
Retca Cloud
bau
0
580
Featured
See All Featured
A Tale of Four Properties
chriscoyier
149
21k
4 Signs Your Business is Dying
shpigford
169
20k
Keith and Marios Guide to Fast Websites
keithpitt
404
21k
What's in a price? How to price your products and services
michaelherold
229
9.4k
Clear Off the Table
cherdarchuk
79
280k
We Have a Design System, Now What?
morganepeng
35
3k
Git: the NoSQL Database
bkeepers
PRO
415
59k
Product Roadmaps are Hard
iamctodd
34
6.6k
GraphQLの誤解/rethinking-graphql
sonatard
28
6.6k
Raft: Consensus for Rubyists
vanstee
126
5.5k
Web Components: a chance to create the future
zenorocha
303
40k
No one is an island. Learnings from fostering a developers community.
thoeni
9
1.3k
Transcript
若手が可読性を上げるために 気を付けたこと 名里 梨佐
自己紹介 • 氏名 • 名里梨佐(ナザトリサ) • 所属 • 株式会社ラクス •
仕事 • Mail Dealerの開発をしています
本日のお話 個人でプログラムを書くことしかしていなかった人間が、 グループの一員として開発に関わるようになって2年と少し。 可読性を良くするために考えさせられたことを 多かった指摘のコメントランキングと共にお話します。
第3位 コメントが(不要です/必要です)
コメント • 自分一人しか見ないコードは結構コメントを適当に書いていた • コメントの要否の判断の重要性 • 短いコードにいちいちコメントを付ける必要はない • 複雑な処理をしているコードや関数は意味が分かるようにコメントを付ける →
致し方なくこういうコードにしなければならなかった背景・理由など
第2位 名前が分かりにくい
たかが命名、されど命名 • 接頭辞を使う • isXXX • hasXXX • canXXX •
具体的な名前を使っているか • Get()は使いやすいが、状況によってはDownload()などの方がより明確に伝わるか も • Itemなども便利ではあるが、汎用的なので分かりにくい時もある。 例)「checkItem()」→「checkSortItem()」
たかが命名、されど命名 • 一般的な単語を使っているか 命名時 翻訳してみよう→そのまま使うはNG 簡潔な単語を使っても、一般的に使われる単語でなければ、他の人が分からない ただ、逆に簡単な言葉を使って分かりにくくなるケースも… 例)項目名が正しいかをチェックする関数を作りたい 「checkItemName()」 →
「validateItemName()」 checkは便利だが、何をチェックしているかわからない 正しいことをチェックすることがわかるようにしないといけない
第1位 冗長です
何日か後の自分は他人です • 何日か後の自分が読みにくいコードが、他人に読めるはずがない • ネストが深いコードは読みにくさがMAX → 何か月か後に自分が書いたコードだと思って修正しようとすると 思ったより読めない • 対策
• 関数として切り分ける • 複数の処理を関数内で持たせるのは避ける • 複雑にせざるを得ない場合はコメントを残す 特に試行錯誤してやっとできたコードほど読みにくくないかを確認すべし!!
early return • メソッドの先頭で渡された引数が不正な値でないかチェックして、もし不 正な値であれば return で即メソッドを抜ける →その後の処理は引数に不正な値でないか気にする必要がなくなるので、 コードがスッキリ
コメントでコーディング • 状況に応じた粒度で実装の流れを書いてみる →やりたいことが明確になる //実行権限のチェップロードしたファイル関連のチェック //実行権限のチェック //アップロードしたファイル関連のチェック //ファイルの存在確認 //ファイルを読み込めているかチェック //空チェック
//項目数のチェック //項目のデータのチェック //登録処理 イメージ(ファイル関連の処理)
まとめ 可読性の高いコードを書く方法については段々つかめてきたが、 コードを書くということは可読性だけを気にしていたらいいわけではない 次は保守性、拡張性との戦いへ…
ご清聴ありがとうございました!!