Blog - LINE ENGINEERING

Ishikawa Munetoshi

Developer Experience Development

【DroidKaigi 2023】Code Review Challenge 3問目解説
Ishikawa Munetoshi2023-09-26
Developer Experience Development
こんにちは。コミュニケーションアプリLINEのクライアントを開発している石川です。この記事では、DroidKaigi 2023 の企業ブースで行った Code Review Challenge の 3 問目の解説をします。 Code Review Challengeについてはこちらを参照してください。出題タイトル: Slip Through My Async 3 問目では、以下のコードが出題されました。 /** * A repository class to save/load a [ShopItem] to the local storage. */ class ShopItemListRepository( private val shopItemDao: ShopItemDao, private val shopItemThumbnailDao: ShopItemThumbnailDao, private val errorReporter: ErrorReporter ) { /** [CoroutineScope] for DAO re
- Android
- Code review
Kotlin Fest 2022 登壇レポート
Ishikawa Munetoshi2022-12-15
Developer Experience Development
こんにちは。コミュニケーションアプリ LINE のクライアントを開発している石川です。 12月10日に開催された、Kotlin Fest 2022 で可読性から見たKotlinの言語機能 -「使いたい」の、その先へ。というタイトルで発表しました。この発表で最も主張したかったことは、「Kotlin の言語機能は便利だが、『使うこと』そのものを目的としてしまうと、可読性や頑健性を下げかねない」点です。Kotlin の言語機能のアンチパターンとその理由を示し、言語機能を使いたいから使うのではなく、目的に応じた適切な使い方は何かを紹介しています。セッション動画: https://www.youtube.com/watch?v=QGh-a1gg6nk スライド: https://speakerdeck.com/line_developers/kotlin-language-features-and-readability このブログ記事ではその登壇の過程をレポートします。 Kotlin Fest とは Kotlin Fest は、プロ
- Android
- Kotlin
Code Review Challenge 3問目解説
Ishikawa Munetoshi2022-12-09
Developer Experience Development
こんにちは。コミュニケーションアプリ LINE のクライアントを開発している石川です。この記事では、DroidKaigi 2022 の企業ブースで行った Code Review Challenge の 3 問目の解説をします。Code Review Challenge についてはこちらを参照してください。出題タイトル: Truth in deep nests 3 問目では、以下のようなコードが出題されました。 class ProfileImageRepository( private val context: Context, private val metadataDao: ProfileImageMetadataDao = ProfileImageMetadataDao(), private val apiClient: RemoteApiClient = RemoteApiClient(context), private val ioScheduler: CoroutineContext = Dispatchers.IO ) { pri
コードの可読性についてのプレゼンテーション紹介 vol. 5: "レビューとまとめ" 編
Ishikawa Munetoshi2020-03-13
Developer Experience Development
はじめにこんにちは。コミュニケーションアプリ "LINE" の Android クライアントチームの石川です。この記事は、 "コードの可読性についてのプレゼンテーション紹介" の不定期連載記事の第五回です。前回の記事はこちらです。今回はいよいよ最終回です。第八章の "レビュー" についての解説と、本連載のまとめをします。第八章: レビュー持続可能なソフトウェア開発を行うための一手段として、コードレビューで可読性や頑健性を向上させることは効果的です。コードレビューを行うことで、その時点でのコードの品質向上に寄与するだけでなく、情報共有によるチーム全体の技術力の向上も見込まれます。ただし、コードレビュー自体が開発のボトルネックにならないように気をつけるべきです。この章では、コードレビューにおける注意点を、レビューを依頼する側とレビューをする側の両方の観点から解説します。なお、本記事ではレビューツールとして GitHub を使うことを想定しています。GitLab や Gerrit 等、他のコードレビューツールを使っている場合は、 "プルリクエスト" をそれぞれ
- CodeReadability
コードの可読性についてのプレゼンテーション紹介 vol. 4: "依存関係" 編
Ishikawa Munetoshi2020-01-31
Developer Experience Development
はじめにこんにちは。コミュニケーションアプリ "LINE" の Android クライアントチームの石川です。この記事は、 "コードの可読性についてのプレゼンテーション紹介" の不定期連載記事の第四回です。前回の記事はこちらです。今回は、型と型の "依存関係" の話として、第六章と第七章の解説をします。設計やコーディングを行う際、型同士の依存関係というものは避けられません。例えば、ある型を継承する、インスタンスを引数として受け取る・返り値として使う・メソッドを呼ぶなどをした時点で、その型に対する依存関係が発生します。ただし、無計画に依存関係を作ると可読性や頑健性を損なってしまいます。ここでは、依存関係をどのように扱ったらよいかということを、結合度・方向・重複・明示性の四つの観点から解説します。結合度結合度とは依存関係の強さを示す指標です。ここでは、特に避けるべき、もしくは緩和させるべき強さの結合として、内容結合・共通結合・制御結合の３つを取り上げます。それぞれの結合の解決方法の詳細については、プレゼンテーションを参照してください。 1.
- CodeReadability
コードの可読性についてのプレゼンテーション紹介 vol. 3: "状態と手続き" 編
Ishikawa Munetoshi2019-11-27
Developer Experience Development
はじめにこんにちは。コミュニケーションアプリ "LINE" の Android クライアントチームの石川です。この記事は、 "コードの可読性についてのプレゼンテーション紹介" の不定期連載記事の第三回です。前回の記事はこちらです。今回は、一つの型に閉じた話として、第四章 "状態" と第五章 "手続き" の解説をします。第四章: 状態プログラムの実行状態の数やその遷移を減らすことで、プログラム全体の振る舞いが理解しやすくなることがあります。特に、"不正な状態" や "不正な遷移" がある場合、それらを排除することで、可読性と頑健性が大きく向上するでしょう。ただし、状態の削減はあくまでも可読性や頑健性を向上させる手段であり、それ自体を目標にしてはいけないことに留意してください。この章では、可読性と頑健性を向上させる方法として、"不正な状態を削減する" ことと "状態遷移を単純化する" ことの二点について解説します。 1. 不正な状態の削減ここで、二つの変数間の関係として、 "orthogonal/non-orthogonal な関係" という概念
- CodeReadability
コードの可読性についてのプレゼンテーション紹介 vol. 2: "命名とコメント" 編
Ishikawa Munetoshi2019-10-18
Developer Experience Development
はじめにこんにちは。コミュニケーションアプリ "LINE" の Android クライアントチームの石川です。この記事は、 "コードの可読性についてのプレゼンテーション紹介" の不定期連載記事の第二回です。前回の記事はこちらです。今回は、プログラム中に書く自然言語として、第二章 "命名" と第三章 "コメント" の解説をします。第二章: 命名プログラムを書くときは、クラスやリソースなどの様々なものに名前をつける必要があります。その名前が、正確・明確・記述的であると、コードはより読みやすくなります。この章では、どのような名前がコードを読みやすくするかについて、特に型 (クラス, インターフェース, トレイト等)、値 (変数, フィールド, パラメーター等)、および手続き (関数, メソッド, サブルーチン等) に焦点を絞って解説します。ただし、この章で解説している内容はあくまでも一般論であるため、使用する言語・プラットフォーム・プロジェクトによって命名規則が決まっている場合は、そちらを優先してください。ここでは、名前をつける際に重要なこととして以下の三点を
- CodeReadability
コードの可読性についてのプレゼンテーション紹介 vol. 1: "導入と原則" 編
Ishikawa Munetoshi2019-10-01
Developer Experience Development
はじめにこんにちは。コミュニケーションアプリ「LINE」の Android クライアントチームの石川です。先日、コードの可読性についてのプレゼンテーション (https://speakerdeck.com/munetoshi/code-readability) を公開しました。今後、このプレゼンテーションについてのちょっとした解説を、本ブログ上で不定期に連載していきます。今回は、このプレゼンテーションの概要と、最初の章 "導入と原則" についての解説を行います。このプレゼンテーションについてこのプレゼンテーションは、コードの可読性を向上するためのアイディアをまとめたもので、以下の8つの章からなります。導入と原則: 可読性の高いコードの重要性、プログラミング原則命名: 名前の示す内容、文法、語の選択コメント: ドキュメンテーション、インラインコメント状態: 状態遷移の管理、不要な状態の削除手続き: 関数やメソッドの流れの明示化や分離依存関係 I: ２つの型の間の依存関係の強さ依存関係 II: 依存関係の方向、重複、明示性レビュー: コードレビュ
- CodeReadability
git で reviewer を探すスクリプトを作りました
Ishikawa Munetoshi2016-12-01
Developer Experience Development
こんにちは、LINE の Android Client を開発している munetoshi です。この記事は LINE Advent Calendar2016 の 2 日目の記事です。レビュアーを探すスクリプトを作りました皆さん、元気にコードレビューをしていますか？レビューはしっかり行いたいものですが、適したレビュアーを見つけるのって面倒ですよね。特にチームの人数が多い場合、私みたいな引きこもり系エンジニアには、誰が何を担当しているのかを完全に把握するのは難しいです。その割に、私は広く浅くコードに触れることも多いので、"これって誰にレビューしてもらえばいいのかなー" と途方に暮れることもあります。弊社ではコード管理に git/GitHub を使っているので、git history や blame を見ればいいのでしょうけれど、プルリクエストを作るたびにその作業をするのは骨が折れます。そこで、 git history をたどってレビュアーに適した人を探し出すスクリプト"suggest_reviewer" を作ることにしました。で、どうやってレビュアーを探すのさ基本的には、g

1