ep.54 UIT Playbook - これが私たちのコーディングスタイル | UIT INSIDE

2020/07/17 に公開2473 views

このエピソードについて

@spring_raining が @potato4d @jaycompsci @T28_tatsuyaに、現在 UIT で策定中のコーディングスタイルについて聞いてみました。

自己紹介

@jaytype
- UIT フロントエンドエンジニア
- LINE NEWS のフロントエンド開発を担当
@T28_tatsuya
- UIT フロントエンドエンジニア
- LINE Survey, ショップカードを担当

UIT Playbookについて

プロジェクトの概要
コーディングガイドラインを決めるまでの背景
- 元々コーディングガイドラインがあったが、長年メンテされておらず最近はほとんど守られていない状態だった

UIT Playbookが定めるコーディングスタイル

UIT Playbookはまだ始まったばかりだが、ルールの策定や整備はどのような手順で進めているか？
- 基本はGitHubのPull Requestベース
- 議論の過程で決まっていくことも
最初に決めたことはネーミングルール
- Boolean型を返すものは isXXX ？
Playbook という名前について

コーディングルールを決めることについて

どうしてコーディングスタイルを決めるのか？
- 複数人が前提知識を共有して開発することができるもの
- そのコードが恣意的なものか、そうでないかがひと目で分かる
- 1つのコーディングスタイルを導入するのであれば、そのルールが守られ続けていることが大切
1つのコーディングスタイルを守るか、複数のコーディングスタイルを用意するか
ESLint/Prettierの存在
- ESLintには、あるルールに対して理由が添えられている

PR

フロントエンドエンジニア (Lead / Manager) カジュアル面談Days 実施中！
- https://line.connpass.com/event/179229/

採用について

使用素材・クレジット

BGM&SE

音声書き起こし

1. オープニング 00:00

Guest 00:02
こんにちは

Guest 00:03
こんにちは

Guest 00:05
こんにちは

Guest 00:06
こんにちは

Guest 00:07
え。それでは、今週もテインサイドやっていきましょう。

Guest 00:12
UIT INSIDEは、ユーザーインターフェースと、テクノロジーを愛する開発者のためのポッドキャストです。

Guest 00:19
最新のウィフ表示や、開発、フレームワークの編成、

Guest 00:23
eyexに関することまで、様々なフロントエンドの情報をチャッチアップできる、ポップキャストをお送りしております。

Guest 00:31
twitterでのハッシュタグは、シャープUIT、アンダースコアインスタド

Guest 00:37
エピソードのご意見やご感想、リクエストなどなどぜひツイートしてください。

Guest 00:42
で、今回はですね。パーソナリティはえ、私からとあと3人ゲストを用意しております。え、花谷さんと、

Guest 00:51
あと堀さん、山本さんの今回4人でお送りしたいと思います。え、それではえ、よろしくお願いします

Guest 00:59
よろしくお願いします

Guest 01:01
お願いします。

2. 自己紹介 01:04

Guest 01:06
はいで、今回のゲスト3人のうちお2人はまこんこの弱さと

Guest 01:14
初参加ということなので、お2人に少し自己紹介をしてもらおうと思います。それではおりさん

Guest 01:21
まから、まず、自己紹介をお願いしてよろしいでしょうか。はい、

Guest 01:25
LINE株式会社UITで、フロントエンドエンジニアをしています。ほと申します。LINEnewsのチームで

Guest 01:34
働いています、よろしくお願いします

Guest 01:38
よろしくお願いします。では、続きましてやみつさん自己紹介をお願いいたします。

Guest 01:47
はい、LINEのUITのデブロックチームに所属している山本達也と申します。

Guest 01:53
担当はLINEサーベイとか、ショップカードとか、クーポンの開発、フロントエンドの開発をしていますよろしくお願いします

Guest 02:01
よろしくお願いします。はい、では、このお2人とあとはたさんのえ、まあ、4人でお送りしたいと思います。

3. UIT Playbookについて 02:09

Guest 02:10
今回のテーマはですね。とずばりえ、フロントインドにおけるコーディングルールについてというテーマで話していこうと思います。

Guest 02:20
あ、ですが、ま、その前に1つ。今

Guest 02:23
UITで始まった。プロジェクトであるUITプリップというものについて、簡単に紹介させてください。

Guest 02:32
UITplabokはですね、LINEのフロントエンドえ、開発におけるコーディングの、まあ、ガイドライン

Guest 02:40
のようなものになるものを、えも目的として作るというものです。でま、コーディングルールの中でも、結構ドキュメントのま整理みたいなっていうところをこ今押し進めているというところです。

Guest 02:55
で、ま、このUITplaybookが始まった経緯っていうのが、まあ色々あるかと思うんですけど、ちょっとそこについてはたさん、まず、

Guest 03:04
お話をお伺いしたいと

Guest 03:06
あ、はい、大丈夫です。じゃあ、ちょっとUITプレイブックという取り組みについて紹介させてください。

Guest 03:13
そもそもですね、なんでこんなガイドラインを作ることになるんだっていうような、

Guest 03:18
風に思うえ方もいらっしゃるかなと思うので、ま、そもそもの話をしたいと思うんですけど、これまでえとUITには、コーディングがガイドラインが実はあってですね。

Guest 03:30
まあ、実際そのjavaスクリプト

Guest 03:32
を書くにあたって、ま、こういったガイドラインを使いましょう。みたいな、え、こういった風にコーディングをしましょう。みたいなのがが、実はすでに存在していて、

Guest 03:41
ま。それが過去には運用されていたこともあるんですけど、ちょっと恥ずかしい事情になってしまいますけども、4、5年ぐらい。実は

Guest 03:49
めてされてないガイドラインがあってですね。ま

Guest 03:55
すごく分かりやすい例を言うと、あの、もう、ジェイクエリーのネームスペースを競合しないための命名の仕方が書かれ、書かれているような。ガイドラインが実は残っているみたいな状態になっていて、まあ、実際にはなんでほとんど面定されてない感じですね。

Guest 04:10
のような、ガイドラインがずっとあったっていうところがありますと

Guest 04:14
で、ただですね、まあ、結構私たちも今UITっていう中で、東京だけでも50人ぐらいフロントエンドエンジ内がいる。そして、

Guest 04:23
っていうところで、ま、そのままこう自由なコーディングの状態で、突っ走していっても大丈夫なのかっていうところがあって、まあ、ガイドラインスめていきたいよね。

Guest 04:31
いうところがえ、最近もう1回話として上がってま。次は、ちゃんとメテされるようなガイドラインを作りましょう。みたいな目標で

Guest 04:39
作り直してるようなプロジェクトになります。まあ、ちょっとライン特有の事情かもしれないですけれども、結構

Guest 04:48
日本だけじゃなくて、海外のえにも開発メンバーがいたりとかするので、ま、結構え、その場の対面だけではなくて、まあ、リモートで仕事するような。人も多いんで、やっぱその部署内で、苦電で共有するっていうのはなかなか難しいところが

Guest 05:02
えあるのが実態でして。まあ、なので、え

Guest 05:06
とまそれぞれのプロジェクトに入らなくても、共通のがガイドラインがあると、え、今どんな人でも、アクセスできていいんじゃないかっていうところで、え、今進んでいるプロジェクトとなっております。

Guest 05:17
はい、ありがとうございます、

Guest 05:19
そうですよね、結構LINEの開発体制として、最近は結構そのフロントエンドも、そのプロジェクトのそのコーディングルールみたいなのしも任せるみたいな風潮が、まあ、正直あったところは

Guest 05:33
あって、そうですね。まま、そのプロジェクト内でま開発する分にはいいんですけど、やっぱりこう。まあ、別のプロジェクトのまあに上院するとか、ま、あるいはその

Guest 05:43
別の行動を見るとか、そういう時とかにやっぱりまあ結構

Guest 05:48
ま、そんなすごとても困るっていうことではないですけども、やっぱりそのまあしそれぞれの人によってま。書くことが違うなっていうのは、結構感じることはありましたね。

Guest 05:58
ま、そういうまあまさい結構今回そのほんとにもうガチガチに固めるってよりはもうま

Guest 06:06
それ。それこそドキュメントなので、まあまあこういった風にこういったルールに従いましょうね。みたいな、そういう感じのところではあるので、まあ、そういった

Guest 06:16
ところからこう。まあ、決めていくっていうのは、すごいプロジェクトを映るみたいなことに、時とかにもすごいありがたいですしま。そういうところ決めるっていうのは、すごい

Guest 06:26
良いところだなと思います。

Guest 06:29
そうですね、やっぱりプロジェクトの移り変わりとか、まあ、1人がいろんなプロジェクトを兼任する。UITの都合ならはかもしれないですけれども、結構必要になってくるかなと。

4. UIT Playbookが定めるコーディングスタイル 06:43

Guest 06:44
まこんこのような。まあ、経緯で始めることになった。UITプレップなんですけれども、まあ、そんなにまあまだ結構決まってるっていう感じではなくて、これからっていうところではあって、

Guest 06:55
まあ、割とま。これから決めるところとかはあると思うんですけども、あのほさんは、いまこのワイティブレブックの

Guest 07:05
一応こう主導でこうコーディングスタイルみたいなのに、ドキュメントを管理する、はいっていうことをされている。

Guest 07:12
それなので、まあ今どういった感じでこう決めていこうかみたいな、そういうまあ、プロセスみたいなのが

Guest 07:20
がもしあればててきたらよいです。はい、よろしいでしょうか。

Guest 07:24
はいと、今はそうですね、あの、コーディングのガイドラインも、いくつかの大きな

Guest 07:33
こう分野に分けられるんですね。ま、ネーミングでしたり、テストだったりま、フレームワークだったり

Guest 07:40
で、それのまあ、セクションとかに分けて、ギター部であのリポジトリーを作って

Guest 07:49
で、それぞれのセクションでプリリクエストベースで

Guest 07:53
またたき台みたいなものを作って、そこにあのみんながどんどんどんどんコメントしていって、コメントで

Guest 08:03
ま議論したりして、で、よければ、あの採用するっていう形で進めています。

Guest 08:11
なので、あのUITの中でそれぞれのセクションであのます。興味がある方とかにお願いして

Guest 08:21
ま。どんどん進めていったり。あのま、今もですけど、これからそういう形で全部のセクションを埋めていこうっていう形でやってます。

Guest 08:31
はい、ありがとうございますそうですね、まあ、結構

Guest 08:35
あ、そのドキュメントと言っても様々だと思います。それこそ、そのネーミングもそうですけど、カテゴリーって今何か

Guest 08:43
今決めてるカテゴリーって

Guest 08:45
今だとまあ、例えばeggマスクリプトっていうカテゴリー

Guest 08:53
ネーミングはいとか、テスティング、アトラー、ディレクトリー構成

Guest 08:59
あとはまあ、ツールキットesリントとかはいいですかね。はいは、いま、他にももしかしたら追加したりとかはあのあり得るので。

Guest 09:09
はい、

Guest 09:09
うん、まだモーラできていてないところがあれば追加しますね。

Guest 09:14
はい、ありがとうございますまでも結構あれですね今、最初はネーミングでした。はい、最初今ネーミング

Guest 09:23
は結構それ基本っていうか、割とそうまあ、プリミティブな

Guest 09:30
そうですね、ネイミングっていうのは、結構1番なんて言うんですかね。自由度が高いので、例えばesにとっても正しいか、正しくないかを決めるルールを決めるだけだけど、

Guest 09:42
ネーミングってほんとに任されちゃったら、なんでもできちゃうので。だからこそ、こういうガイドラインのが1番意味が

Guest 09:50
ある分野かなって思ってます。うん、うん、

Guest 09:54
あ、そうですよね。ま、イエスリントがカバーできるんだって、あの、せいぜいそのなんてすか。キャメルケースか、そうでないかの判断とか、それそれぐらい

Guest 10:04
そうですね。まあ、1番なんていうか、プログラミングしてて、1番自由にな、

Guest 10:10
なんていうか、自由があるところってネーミングだったりするかなと思っていて、だからこそ、逆に迷ったりとかしちゃうじゃないですか。

Guest 10:19
だから、ちょっといい名前が分かんないけど、とりあえずこうしておこうみたいな感じで良くない。名前が増えていかいったりとかするのは、こういうガイドラインがあることによって

Guest 10:29
ま防げたりとかするので、重要かなと思います。

Guest 10:33
はいはい、

Guest 10:34
そうですね、今、ちょうどそのネーミングのルールのドキュメントを見てるんですけど、まあ、あれですね。そのローマ字を

Guest 10:44
変数名にしないとか、それはまあそりゃそうだろみたいな感じではあるんですけれども、

Guest 10:51
結構なんかこう議論が起こったりとかしたとこあります。

Guest 10:55
結構まなんでも、少しはやっぱり話し合いになりますよね。うん、どうですかね、あなたにさんなんか

Guest 11:05
ありますか。

Guest 11:07
そうっすね、

Guest 11:09
ネーミングは結構コメントたくさんつきましたよ。

Guest 11:12
そうっすね、ネーミングは元々そのルールとしてあったんですよね。その数年前のドキュメントにも

Guest 11:19
だから、まずそれをベースに改変しようってすると、結構古いものとかま、当時はそこまで考えられていなかったものとかが出ていて、

Guest 11:29
ま。あのあ、そういうのもやっぱりこうだんだん時代が進化するにつれて、ちゃんと命名するようになったんだなっていうので、面白いとこだったら、

Guest 11:37
当時のと、ネーミングルール

Guest 11:40
にそ、そういう場合っていうのは、え、ブーリアンを返すやつにはイズをつけましょう。みたいなのがあっては、まあ、それはそうだなと。まあ、確かに納得できる

Guest 11:49
ルールなので、まずこっちに持ってきたんですけど、

Guest 11:51
まあ、昔とかもっと単純に命名してるだけだったら、まあ、伊豆なんとかでもいいえ、良かったとこですけど、またま今だったら結構キャンなんとかとかはなんとかとか、ちゃんと英語として伝わるようなフラグの名前とか

Guest 12:05
もつけることがちゃんとまあ

Guest 12:06
なんでしょう。開発者全体としてて、足が上がってきたっていうのもあると思っていて、まあ、そういったものもちゃんとルールにしましょう。っていうのが、まあ上がったりとかしたのが結構

Guest 12:16
面白いところだなと思いましたかね。なんか、まあ、伊豆なんとかってつけましょう。まず、そもそも伊豆なんとかってつけましょう。っていうこと自体がないところから、まあ、

Guest 12:25
だんだんつけるっていうところが、コイングガイドラインとして制定されていったっていう過去があって、まあ、今は

Guest 12:30
もっとちゃんとした命名にしましょう。みたいなのが議論としてあったのは、結構面白いなと思いましたね。

Guest 12:38
そうですね、これですかね。

Guest 12:40
そうですね、まあまあ割と伊豆なんとかってつけがちではあるんですけど、

Guest 12:45
まあいつなんとか何も考えなくていいです。

Guest 12:49
まあまあ考えるきっかけになったっていうか、ちょっと。なんか。例えば、ローワーキャメルケース

Guest 12:58
っていうのは、まあ1番最初は小文字でで、あと最初の頭文字だけ多くしていく。

Guest 13:07
まあ、ラクダの形だから、キャメルケースで。1番最初の大文字にするやつが、アッパーキャメルケースですよね。

Guest 13:17
なんですよね、では、これは私はパスカルケースって呼んでてで、なんかはいはいはい、ローワーキャメルケース。

Guest 13:26
じゃなくて、パスカルケースよりマッパー、キャメルケースの方がい。

Guest 13:31
一般的なのかもしれないみたいなことを知れたので、ちょっと知識がついたのはいてい

Guest 13:38
のありました。そうですね、

Guest 13:40
確かにパスパスカルケースと

Guest 13:42
呼びますよね。

Guest 13:44
うん、うん、うん、うん、見ませんはい、確かに。

Guest 13:47
なので、こういうプロセスの中で色々知識がつくのも面白いなって思いました。

Guest 13:54
そうですよね、まあ、確かにあまりそのほのまプログラミングの本質っていうよりは、むしろマ知識感

Guest 14:04
や。

Guest 14:05
でも、まあ、でも通じる言語を作っていくっていうか、その組織の中でどの言語を使うかっていうのがこう決まっていくと、コミュニケーションっていうのが円滑になるかなと思います。あ、

Guest 14:16
確かにそうですね、そういう言葉を決めること自体がまそうですね。

Guest 14:19
あの、UITでは、ロワキャメルケースって言います。とかそうね、これだから、ローワーキャメルケースのことは、キャメルケースって単純に言って

Guest 14:27
で、アッパーキャラメルケースのことをパスカルケースっていうケースこともあると思うんですよね。なんか、はいはいはい、その辺が

Guest 14:36
うん、うん、そうですね、結構まあ、そういう言葉を決めるという

Guest 14:41
面でも、こういうドキュメントを整理するっていうのは確かいいと思います。時がある、はい、うん、

Guest 14:50
そのそうですね、ま、こういうちょっと話が

Guest 14:55
変わるんですけど、ま、こういう細かいところと同時に、やっぱりあのプレイブックの方向性として、

Guest 15:04
あの色々考えてるところもあって、この後どうやって行ったらこう古くならないのか。これって、何年か前に作られたものが、結局アップデートされない

Guest 15:14
ままになったっていう。あの、まことがあったので、今回はメンテナンスできるようにしたいと、

Guest 15:21
あんなので。それにまあ例えばですけど、まい半期ごとし、にアップデートするような形にしていくだったりとか、

Guest 15:32
そういうこと考えてます。で、あとは、まあ文化として、やっぱりUITの中でプレイブックっていう

Guest 15:40
ものの、存在を認知してもらって、みんなでメンテナンスしていくっていう文化を作っていけたらなって思ってます。

Guest 15:48
そうですね、に認知されなかったら、やっぱりはなかなかそういうメンテみたいなのは、誰もされなくなってしまうっていうのは、

Guest 15:55
すごいこう。今までの経緯も考えても、そうまずまず守ってもらってから

Guest 16:01
守ってもらうで、多分、そういうアップデートみたいにかけてもらう。はい、

Guest 16:05
特にこれってなくても、仕事進んでいっちゃうものなので、あるとより良いものじゃないですか。

Guest 16:14
うん、うん、だから、やっぱりそういう意味でも無視されないように、やっぱり進めていくっていうのがいいかなって思います。

Guest 16:23
ま、ちょっと余談なんですけど、プレイブックっていう名前は、あの、バスケのバスケットボールのコーチが使う戦術長から取ってて、

Guest 16:32
やっぱりなんか例えばマイケル上ダみたいな。すごい選手がいたら、それだけでも勝てるんだけど、戦術をチームで遂行することによって、得点効率が高まるんですよね。

Guest 16:42
だから、プレイブックっていうのは、そういう存在であり、皆さん素晴らしいエンジンが集まってるから、いいプロダクトはそれだけでも作れるんだけども。

Guest 16:51
より組織で同じ戦術を使っていくことによって、より良くできる組織として強くなれる

Guest 16:59
で、プラス。やっぱり、最新の戦術をどんどんどんどん取り入れていくことによって、あの、

Guest 17:07
やっぱり得点効率が高まるっていうのがあって、やっぱなんかピッタリの名前だなって自分では思ってます。あ、

Guest 17:13
そうだったんですよ、すごいめっちゃ深い話が聞けた

Guest 17:18
なんでちょっと思い入れがあります。

Guest 17:20
なるほど、ええ、すごいあれですね、こうち、チームチームワークというか、そういう

Guest 17:28
なんかこういうつみんなでこう高めていくみたいな。そういうすごい意思がこれてて、そうですね、はい、ありがとうございます。

5. コーディングルールを決めることについて 17:39

Guest 17:39
まあ、

Guest 17:41
こういった感じで。まあ、私たちuytではプレイブックというもので、そういうコーディングスタイルを定めていきましょう。という

Guest 17:49
まあ、プロジェクトが始まりました。でま、もうちょっとこうこう一般的な。

Guest 17:56
視点に立ち返って、そういうコーディングルール。なぜま決めるのかっていうことについて、もうちょっと皆さんで

Guest 18:05
話し合っていきたいなと思うんですけども。まあ、結構さっきは話にも出てたんですけど、まあ、正直なくても

Guest 18:13
あのプロジェクトは進むものではあるけれども。まあ、こうやってわざわざこう。コーディングルームを定めるっていうこと

Guest 18:20
ていうのは、やっぱりこうま定めることによって、そういうやっぱりプロジェクトごとのまあ差みたいなのなくすみたいな。そういう点もあるんですけど、まあ、もっとこう。

Guest 18:29
皆さんでこうコーディングルールを定めることによって、どういういいことがあるのかっていうことを話していきたいなと思います。で、今回

Guest 18:39
ままそのどなぜコーディングルを定めるのかっていう話をしていこうと思うんですけど、結構まあ正直はっきりした理由みたいな出ないかも

Guest 18:49
しれないと思っていて、ま。ただ、こういうコーディングルールを決めることについて。皆さんなんかこう意見みたいなのがあれば、ちょっと

Guest 18:58
お伺いしたいなと思います。で、ここはまずちょっと山本さんに、あの、結構あのLINEは転職で入られた

Guest 19:09
でした。はい、そうですよね、で、結構そのプロジェクトでこうでこう書くみたいな経験。私より全然

Guest 19:18
よくやられてると思うので、もうなんか、そういうコーディングルールがあったらよかったなとか、逆にあったことによって、なんかこう

Guest 19:27
こんなことがありました。みたいなっていう話をもしあれば、お伺いしたいなと思うんですけど、

Guest 19:32
はい、そうですね、まあ、転職でも今のLINEのところでもあまり変わんないと思うんですけど、

Guest 19:41
個人的にははい、あの、新しく入った人とか、そのデビューで見た人とかが、あの、どういう

Guest 19:49
ソースコードがどういう状態になってるのかをなんかわかりやすくするようにしたいなみたいな思いが

Guest 19:57
あります。んで、例えば、どんなリントルールを使ってるのかもわかるとか、逆に使ってないことがわかるとか、

Guest 20:05
あの、個人的にはちょっと気持ち悪い書き方なんだけど、実装者からすると、何かしらの方針を持って書いてるかもしれないし、

Guest 20:12
で、そういう感じの認識のズレみたいのをなくせるようにしたいな、みたいなことはちょっと思ってました。

Guest 20:20
で、転職でも僕も自身も書いてましたし、あの、他の方々が書いてたものを見たりすることもあったんですけど、

Guest 20:31
あの、その

Guest 20:35
どういうルールに基づいて、僕要するにタブが2位なのか、4なのかとか。まあ、色々な趣味、思考もあるとは思うんですけど、

Guest 20:43
その書いてる人自身で統一性を持って書いてたのか、それとも実は全然そんなことは考えてなくて、書いていたのかみたいなことで、

Guest 20:52
いちいち議論するのは、やっぱ時間とかもったいないし、無駄なので。そういうものをえ、あらかじめわかるような状態に

Guest 21:01
するといいな。みたいなことはちょっと今も思ってます。

Guest 21:06
はあはあはあ、確かにそうですね、あれですね、その前提みたいなのがな、あの、全員でこう共有されてるっていうところは、

Guest 21:16
1つおっきいところですよね。そのうん、さっき言ったその、なんか、こういう

Guest 21:20
コーディングルールにしましょう。っていう、そういうルール、あのルールを定める議論をすること自体が結構まあ、大変みたいな話

Guest 21:28
もすごい共感していて、まあ、もう何の情報も与えられずに、まず行動を見た時に

Guest 21:37
ま。やっぱりなんかこういうなんか変な書き方してるけど、ま、こういうコーディングがあれば、ま。それはまあ、もしかしたら

Guest 21:46
なんかこう意図的なものかもしれないっていうのがまあわかるっていうのは、確かにメリットですよね。なんか、わざわざこんなすごい

Guest 21:54
なんか、周りくどいよくわからない書き方してるけど、ただ単にそその人の趣味だったとかなったら、すごい

Guest 22:01
ちゃぶ台を返したくなります。

Guest 22:04
でも、まあ逆にあのまあそういうesリントルールとかなくても、そのメインのプログラマーの人がそういう方針を持って書いているのであるならば、その時点では、それはまあ

Guest 22:15
正義ではあるので。うん、そこにいきなり茶チャを入れたら、あの修正も大変だし、あの

Guest 22:25
とか、まあ現実的な問題とかもやっぱたくさん出てくると思うので、

Guest 22:28
そういう状態がわかるようになるといいな、みたいなのがちょっと。個人的なUITplaybookの思いというか、きたいみたいなとこがありますかね。僕もまだちょっとUITに入ってから、まだ全然時間経ってないんですけど、

Guest 22:42
あの、初めてUITの実装とかを見ると、すごくたくさんコードコミットどんどん積み上がってるのもあれば、あの割と

Guest 22:51
あんまりアクティブには開発されてないようなことも色々あると思うんですけど、あったんですけど、うんと、その僕が担当したリポジトリーが、

Guest 22:59
そういうルールにのっとっているのかとか、乗っ取っていないのかとか

Guest 23:06
で、一応そのもう結果的にレガシーになっちゃった。既存のガイドラインみたいなのあったわけですけども、

Guest 23:14
それに、ちゃんと従ってるのか、実は同じように見えて、従ってるつもりはなかったのかとか、

Guest 23:22
そういうのがあの明快にわかるようになると、新しく来た人もわかりやすいし。あの

Guest 23:30
まちゅチュートじゃなくても、新しくプロジェクトにジョイした人がいきなりデビューするときも、そういう

Guest 23:36
趣味、趣向の範囲とか、そういうところに関しては、ちゃんと無視した上で、実のあるレビューができるかなみたいなって思いますね。

Guest 23:45
なるほど、そうですよね、なんか、ルールに従ってるようで、従ってないみたいなのが1番あれですね、腹立ちます。

Guest 23:52
なんかそうそう、そうそうこれなんか行けてねえなとかって思ったんですけど、いやいや、それはもうこういうルールがあってねとか、

Guest 24:01
そういう歴史があってねみたいな。いや、実際そういうのはたくさん出てくると思うので。

Guest 24:05
うん、うん、うん、

Guest 24:06
なんかまあ。なので、あくまでUITのプレイブックなので、UITのメンバーが使いやすいようなところに

Guest 24:15
なんとか落とせたり。まあ、ドキュメントも重高すぎても誰も読まないと思うので。あの、その辺のバランスよく、

Guest 24:22
メンutのメンバーが使いやすいようになってくといいな。

Guest 24:27
そうですよね、まあまあ最終的に使うのは結局私たちなので、まあ、そういうま一応そういう一般的なセオリンはま、抑えつつも、

Guest 24:37
まあ、私たちがこう1番こう快適に、まぜ全員が快適に書けるようなルールはまあ

Guest 24:45
定められるのが1番いいというの、

Guest 24:51
こういうコーディングルール。まあ、これからまあ、色々と決めていくと思うんですけれどもま、そういう命名以外にも、まあ、結構

Guest 25:00
1番議論はまかり巻き起こりそうなのは、そのセミコロンをどうするかみたいな

Guest 25:08
ま、シングルコとか、ダブルコとかみたいな。そういうまあところっていうのはま、

Guest 25:15
もうプレイブックでは、もうもうばっさり決めてしまう感じなんですか。

Guest 25:20
ああ、そうですぼ僕的にはあの私的にはそのセミコロンなのかとか、ダブルコートなのかとかが

Guest 25:30
ちゃんと分かればいいなっていう。ああ、思いがあるので、

Guest 25:36
あんまり僕の趣味、思考の方に倒したいなみたいな気持ちはあんまりないんですけれど、

Guest 25:42
とは言ってもなんだろうな。そうやって、いろんな人がいらっしゃるので、あの、なんだろうな。

Guest 25:49
そういうのが選択できるような状態になってると、まあいいのかなみたいなのありますかね。UITもかなりおっきいチームなので

Guest 25:58
はい、いきなりこっちに倒すみたいなのは、やっぱその実作業としても、心的にも大変なところはたくさんあると思うので。

Guest 26:08
まあ、それでも自由しすぎちゃうと。また、それはプレイブックの意味もないので、ある程度の範囲で選択肢みたいなのを作って、

Guest 26:16
これにちゃんと従ってます。っていうのが、プロダクトごとにこう宣言できる状態になってるといいのかなと。個人的には思ってますね。

Guest 26:24
はあはあはあはあ、結構さ加減が難しいそうではあるけど。うん、そうですね、そういう選択みたいなのも、まあ、

Guest 26:32
そのチーム内チーム内で、弱いて内だけれどもまそれっていう。まあ、戦略も確かにあるかもしれない。

Guest 26:41
堀さんは何かこう考え。はい、考えやすごい、ざっくりした質問で申し訳ないです。考えみたいな

Guest 26:50
そうですね、あの、例えばセミコロンが

Guest 26:56
あるかなしか、どっちにイエスリントのルールを設定するか、みたいなのは、個人的にはどっちでもいいと思ってて、その理由は、

Guest 27:07
あのイエスリントがやってることって、どっちも一緒なんですよね。は、基本的にジャパスクリプトって、セミコロンが実はいらないけど、いるケースが

Guest 27:16
2つぐらいあるんで、その時に、自動的に入れてくれるわけじゃないですか。うん、イエスリントが

Guest 27:24
そうですね、あの、自動オトオートにしてるはい、時はで、その逆にzと全部に入る設定にしても、その

Guest 27:33
必要なケースと必要ないケースを。実装する人があんまり意識しなくても、勝手に。例えばセーブした時に、リントで

Guest 27:43
綺麗にしてくれて、直してくれるっていう。どっちも同じことやってるんで、っていう風に考えますね。だから、

Guest 27:53
まあそれが1つと。あと、イリントはルールのドキュメントがあるじゃないですか。はい、例えば引っかかったらそれまgoogleと

Guest 28:02
それのルールが出てきて、で、ルールディテールズっていうところに、なんでそのルールがあるのかっていう理由書いてあるですよね。はい、だから、結構そこを読むのが好きで、

Guest 28:13
そこを読むと、ああ、なるほどって理解できて、なんかより良いプログラマーになる。

Guest 28:21
あの機会になるので、うん、そういうところが好きです。なので、そんなにイエスリントとかのルールにこた強いこだわりがない

Guest 28:30
ですかね。

Guest 28:31
うん、うん、

Guest 28:32
はいはい、そうなんかもっとなんて言うか、裏側のところに興味を持ってるので。なので、ほんとに決まったものに。

Guest 28:44
あ、確かに僕もオートフィックしてくれりゃいいかな、みたいなとこ

Guest 28:48
あるので、結構個人で実装する時はもうとりあえず長いものにまれとくかみたいな有名なルールを入れて、オートフィックスおしまいみたいなみたいなとこは確かにあるので、おじさんと同じような考えを持ってるか。

Guest 29:02
そうですね。なんか、ニュースだと、イエスリントとプリティアを両方入れていて、

Guest 29:10
両方がうまく動くようなコンフィギュレーションにしているので、まい、vsコードとかで、

Guest 29:17
プラグインでプリティア入れてると、セーブしま。設定によっては、セーブした時とかにプリティアもかけてくれるし。そうですね、だから、色々快適に

Guest 29:26
書けるかなって思ってます。

Guest 29:28
確かにそうですよね、僕もプリティアはいはい、

Guest 29:32
あ、それでココミットする時にあのリントが走るので、あのイエスレントで、あのエラーがでとかワーニング出てる時はコミットできない

Guest 29:42
ですよね。

Guest 29:42
あ、そうですよね、はい

Guest 29:44
っていう風になってます

Guest 29:45
おおじゃ、ニュースはかなりとってますね、うん、そう、はい、

Guest 29:52
整えてきてますね、うん、はい、

Guest 29:56
僕もあれですね。そのプリキュア以降は、なんかそういうルールをすごい

Guest 30:03
こと、細かく定めることに、なんか意味を感じなくなってしまったっていうのは、僕もとったんです。なんか、まあ、そういう

Guest 30:11
勝手になんかあってもなくても、向こうは解釈してくれるんなら、わざわざ

Guest 30:17
なんかそういうの定める必要があるのかみたいな。まさだ定めてはいるけれども、それにこうなんか

Guest 30:26
は逆らう必要があるのか、みたいな気持ちっていうのは、ちょっともう確かになくなってきてはいつつありますよね。うん、

Guest 30:35
あと、僕、あの堀さんのそのesリとのルールのところ、リユールのところを読むっていうのは、結構あのすごい

Guest 30:45
いいなと思っていて

Guest 30:47
はい

Guest 30:48
ぜひともあれですね。プリードックにも

Guest 30:50
あ、確かに

Guest 30:52
あると

Guest 30:57
納得感が違うので、それは嬉しいです。

Guest 31:02
はい、

Guest 31:04
1つのなんかこう技術を伸ばす方法かもしれませんね。めちゃくちゃ厳しいルールにして、プライベートでコード書いてみるみたいな。

Guest 31:14
で、引っかかるために、ルール読んでたら、多分すごいいいコードかけるんじゃ

Guest 31:20
いかなと思いますけど。

Guest 31:21
うん、確かに理由を書くのはいいかもしれないですね。ルールって、基本的にこうやっちゃダメ系の文章じゃないですか。

Guest 31:29
なので、なんか心情的にもダメって言われたらむってしちゃうけど、理由まで説明されたら、エンジニア的にはそっかってなりそうな。そうですね、

Guest 31:39
はい、はい、確かにそうですよね。

Guest 31:44
もしかしたら、なんか関数型に書くためのなんか、ルールセットとかもあるかもしれませんね。

Guest 31:51
ああまあまち間違いなくあると思いますけど。あの、なんか関数型に書くのに興味を持っているので、ちょっと今思いつきました。

Guest 32:01
あ、そうですね、それをうん、ルールベースでそういうところでこう縛るみたいな。

Guest 32:07
はいはい、そうですね、まあ、純粋関数になりやすいようなルールセットだったりとか、色々あります。あると思うので、

Guest 32:16
そうです。なんか、そういうダブルな処理をこう抑制するみたいなルールみたいな。

Guest 32:21
そうですね、まあ、分岐で絶対にリターンするとか、

Guest 32:25
あ、リターンしない分岐をなくすとかいるとかも確かあったんで、そういうのとかもなんでってことが説明できれば、まあ、関数型が

Guest 32:36
理解できるみたいにできてるみたいなことになるし、

Guest 32:41
確かになんかイエスリント。あの、思った以上に、そういう高度なそういう解釈をしてくれるので、

Guest 32:48
なんか普通にとよくできてます。そうですよね、

Guest 32:52
なんか、自分でもほんとにその一見しただけではわからないようなところとか指摘されたりして、ちょっとたまにこうびっくりすることとかって

Guest 33:01
うん、ありますね。確かに

6. エンディング 33:04

Guest 33:08
はいというわけでえ、今回はフロントエンドにおけるえ、コーディングルールについて、話してきました。

Guest 33:16
私たち、UITのメンバーが所属するLINE株式会社では、このようなフロントに関する議論を行っております。

Guest 33:25
この今回のような、UITプリーブックのような。テーマを社内のま企画

Guest 33:33
で始まった分で、これをまどんどんこう社会社内問わず発信していきたいと思っております。

Guest 33:42
また、ホットキャストを通じて、ラインに興味を持っていただけた方は、カジュアル面談などをお待ちしております。

Guest 33:50
ぜひ、ページ株もリンクにご連絡くださいえ、それではまた次回エピソードでお会いしましょう。

Guest 33:58
あなたにさん、おさん、山本さん、ありがとうございました

Guest 34:03
はい、ありがとうございましたした。