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
2k
若手が可読性を上げるために気を付けたこと / 20210707_readablelt_nazato
Rakus_Dev
March 14, 2022
Tweet
Share
More Decks by Rakus_Dev
See All by Rakus_Dev
ARR100億超SaaSをさらに成長させるPdM組織の立ち上げと今後について
rakus_dev
0
560
B2B SaaSでSpringSecurityによる Roleを用いたユーザー権限設定の 実装について
rakus_dev
1
390
22歳になる長寿サービスのUI刷新 ~密結合システムからViewを分離した苦労話
rakus_dev
1
4.8k
【ラクステックカンファレンス2023】オープニングセッション/20230208_kude
rakus_dev
1
990
短納期でも進化をあきらめなかった新規プロダクト開発/20230208_matsuura_kawakami
rakus_dev
0
880
フロントエンド横断組織のチームトポロジー/20230208_kunieda
rakus_dev
0
1.1k
ベテラン社員が抜けても若手が成長できるエンジニア組織づくり/20230208_otsuka_aramaki_kuyama
rakus_dev
0
910
デザイン組織が社内下請けから脱却するためにやったこと/20230208_kobayashi
rakus_dev
1
970
ゼロから始めるクラウドネイティブ/20230208_mikata_matsumoto
rakus_dev
0
840
Other Decks in Technology
See All in Technology
Classmethod流のPlatform Engineering / classmethod-platform-engineering-devio2024
tomoki10
0
470
DevIO2024_レガシー運用からの脱却 -クラウド活用の実践事例とベストプラクティス-
jun2882
0
210
GoとアクターモデルでES+CQRSを実践! / proto_actor_es_cqrs
ytake
1
150
ACRiルーム最新情報とAMD GPUサーバーのご紹介
anjn
0
150
Github Actions 로 Android 팀의 효율성 극대화
hadonghyun
0
160
開発生産性をむしろ向上させる セキュリティパートナーの作り方 / Dev Productivity Con 2024
flatt_security
0
360
OSSコミットしてZennの課題を解決した話
dyoshikawa1993
0
150
20240717_イケコパ代表Copilot_in_Teams会社でこう使ってます
ponponmikankan
2
430
サーバーレスAPI(API Gateway+Lambda)とNext.jsで 個人ブログを作ろう!
shuntaka
PRO
0
560
AWS IAMのアンチパターン/AWSが考える最低権限実現へのアプローチ概略(JAWS-UG朝会#59資料改修20分版)
htan
0
330
技術負債による事業の失敗はなぜ起こるのか / Why do business failures due to technical debt occur?
i35_267
0
190
ABEMAにおけるLLMを用いたコンテンツベース推薦システム導入と効果検証
cyberagentdevelopers
PRO
1
720
Featured
See All Featured
How STYLIGHT went responsive
nonsquared
93
5k
[RailsConf 2023] Rails as a piece of cake
palkan
35
4.4k
What’s in a name? Adding method to the madness
productmarketing
PRO
21
2.9k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
13
430
Producing Creativity
orderedlist
PRO
340
39k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
16
1.6k
Documentation Writing (for coders)
carmenintech
63
4.2k
A Modern Web Designer's Workflow
chriscoyier
689
190k
A better future with KSS
kneath
231
17k
The Straight Up "How To Draw Better" Workshop
denniskardys
229
130k
Building Effective Engineering Teams - LeadDev
addyosmani
47
2.2k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
34
1.9k
Transcript
若手が可読性を上げるために 気を付けたこと 名里 梨佐
自己紹介 • 氏名 • 名里梨佐(ナザトリサ) • 所属 • 株式会社ラクス •
仕事 • Mail Dealerの開発をしています
本日のお話 個人でプログラムを書くことしかしていなかった人間が、 グループの一員として開発に関わるようになって2年と少し。 可読性を良くするために考えさせられたことを 多かった指摘のコメントランキングと共にお話します。
第3位 コメントが(不要です/必要です)
コメント • 自分一人しか見ないコードは結構コメントを適当に書いていた • コメントの要否の判断の重要性 • 短いコードにいちいちコメントを付ける必要はない • 複雑な処理をしているコードや関数は意味が分かるようにコメントを付ける →
致し方なくこういうコードにしなければならなかった背景・理由など
第2位 名前が分かりにくい
たかが命名、されど命名 • 接頭辞を使う • isXXX • hasXXX • canXXX •
具体的な名前を使っているか • Get()は使いやすいが、状況によってはDownload()などの方がより明確に伝わるか も • Itemなども便利ではあるが、汎用的なので分かりにくい時もある。 例)「checkItem()」→「checkSortItem()」
たかが命名、されど命名 • 一般的な単語を使っているか 命名時 翻訳してみよう→そのまま使うはNG 簡潔な単語を使っても、一般的に使われる単語でなければ、他の人が分からない ただ、逆に簡単な言葉を使って分かりにくくなるケースも… 例)項目名が正しいかをチェックする関数を作りたい 「checkItemName()」 →
「validateItemName()」 checkは便利だが、何をチェックしているかわからない 正しいことをチェックすることがわかるようにしないといけない
第1位 冗長です
何日か後の自分は他人です • 何日か後の自分が読みにくいコードが、他人に読めるはずがない • ネストが深いコードは読みにくさがMAX → 何か月か後に自分が書いたコードだと思って修正しようとすると 思ったより読めない • 対策
• 関数として切り分ける • 複数の処理を関数内で持たせるのは避ける • 複雑にせざるを得ない場合はコメントを残す 特に試行錯誤してやっとできたコードほど読みにくくないかを確認すべし!!
early return • メソッドの先頭で渡された引数が不正な値でないかチェックして、もし不 正な値であれば return で即メソッドを抜ける →その後の処理は引数に不正な値でないか気にする必要がなくなるので、 コードがスッキリ
コメントでコーディング • 状況に応じた粒度で実装の流れを書いてみる →やりたいことが明確になる //実行権限のチェップロードしたファイル関連のチェック //実行権限のチェック //アップロードしたファイル関連のチェック //ファイルの存在確認 //ファイルを読み込めているかチェック //空チェック
//項目数のチェック //項目のデータのチェック //登録処理 イメージ(ファイル関連の処理)
まとめ 可読性の高いコードを書く方法については段々つかめてきたが、 コードを書くということは可読性だけを気にしていたらいいわけではない 次は保守性、拡張性との戦いへ…
ご清聴ありがとうございました!!