音声書き起こし
1. オープニング
Guest
こんにちは、UITのフォーディです。ユーザーインターフェースとテクノロジーアイス開発者のためのウィークリーポッド、キャストUIT INSIDE。今週も始めていきたいと思います。
Guest
今週はですね。西山さんとえ、井上さんのニュースチームの開発者の2人をお呼びしてですね。月に1度行われているニュース会ということで、今回はイギリスイントのえーとの付き合い方みたいなところについて話していただこうと
Guest
思っております。お2人とも、本日はよろしくお願いいたします、
Guest
よろしくお願いします
Guest
よろしくお願いします。
2. 本日の内容について
Guest
さてということで、イエスリントに関する話題というところです。けど、イエスリントっていうと、割と色々話題があるのかなと思うんですけど、今回はどういったことについて話していただける感じでしょうか。
Guest
はい、今回は、newsのesrentのdsableの
Guest
種類だったり、数みたいなのを紹介しようかなと思っています。ディセーブルっていうと、ちょっと悪い印象なんですけど、
Guest
newsには結構デセーブルがありまして、その理由が、あの、最近、
Guest
イエスリントのルールの方を変更したっていうのが
Guest
あります。その変更が、UIT全体で推奨のコピグみたいなのがありまして、そちらにえ統一する形で、ニュースも取り入れたために、ルールに違反する箇所が多くあって、出たんで、え。そこに関して、ディセーブルをえ付けているっていう
Guest
ような形になってます。なんで、イスリートのdsbの数だったり、種類を見ると、今までニュースがどういう行動をし、あの書いてきたかとか、あの、どういう違反をしてるのかとか、
Guest
まど、あの、そういうのがわかるかなっていうところで、今回紹介したいなと思っていう感じです。
Guest
おお、なかなか楽しみですね。それはじゃ、歴史との付き合い方みたいなところと、まあ、新しい概念にどうやって適合するかっていうところがま
Guest
聞いていける感じですかね。今回
Guest
はい、そんな感じで
Guest
あ、ちょっとぜひぜひお聞かせいただければと思います。じゃあ、まずえ早速なんですけど、
3. LINE NEWSの最新の運用について
Guest
今ですね。LINEnewsで、どんな感じでesリントを利用してるかとかっていうのもえ、なかなか。私もニュースに全然関わってなくて、知らないんで、なんかえと最新の状況を教えてもらってもいいですかね。はい、
Guest
LINEnesでは、先ほど言った通り、推奨のルール使ってるんですけど、元々esリントとえーノは導入はしてまして、
Guest
一般的な方法で、esリントを導入したり、プリティアの方もえ導入してます。でえ、リンターはciの方で定期的に実行してて、
Guest
ブランチの運用もあのり、ciが通ったらっていうところなんでえ。必ずリントが通るような形になってるっていうのが、あの運用方法と同じ感じです。
Guest
で、後はあのciだとやっぱり
Guest
遅くなっちゃうというか、ciでおあのリントのエラーを切ったところでは、結構試合の実行速度で、あのリント直すまでの時間がかかっちゃうんで、あのハスキーでコミット
Guest
するたびにし、あのリントをかけてて、そこで落ちた時には、あのすぐにあの修正できるような形で入れてたりします。
Guest
じゃあ、基本的にあれですね、試合でもらうからでも、
Guest
必ず実行されるんで、まあのリントが通ってないようなことですが、マージされることがなければ、フルリクエストに出てくることも、まあ、ほぼほぼないっていう風な
Guest
そうですね、状態
Guest
でここまではまあ結構一般的かなと思うんですけど。はい、UITとかニュースならでは。で言うならば、先ほど上げたあの
Guest
会社全体の共通のルールみたいなのがありまして、
Guest
それがはい、それを取り入れてるっていう形ですね。で、それもtsとかdsとかビューとかリアクトっていうくくりで、あの選択できるような形になってるんで、
Guest
ニュースだと、ビーとかリアクトって別々にあったりするんですけど、そこら辺も結構柔軟に対応できて、結構容易に
Guest
利用できるものでもあるんで、新規プロジェクトでも使いやすいものっていうので、そこも使ってたりします。
Guest
あ、メジャー結構基本的には、共通の水晶のパッケージを、まあ、ニュースでも使うようにしているっていう。
Guest
そうですね、最近でも入れたんで、最近結構最近では
Guest
元々はニュースのなんていうんですか。独自のルールでやってきてたんですけど、あそこやっぱあのか。その後に会社全体として共通のルールができたんで、そこに乗っ取ろうっていう形で、最近取り組んでいる。
Guest
もしかしたら、この後教えてくれるかもしれないですけど、結構あれですか。後から適用するのは、大変だったりしましたか。
Guest
そうですね、1番大変なのは多分そこですね、今回のてるんだ理由でもあるんで、
Guest
あ、はいはい
Guest
はい、やっぱり後から追加するっていうのが1番大変で、むしろ新規で入れるときは楽なんですけど、必ず入れるってことは、やっぱ徹底した方がいいかと思います。うん、うん、
Guest
うん、うん、うん。確かに。確かにルールが変わると、ドラスティックな変更にそうなっちゃいますからね。
Guest
推奨のルールは、あのかなりいろんな議論があって、しっかりとしたルールは決まってるので、
Guest
なんかそれをもうそのまま使って、自分たちで1個1個のルールを面でしなくていいっていうのはすごい。楽だし、結構信頼できるので、
Guest
その推奨ルールは使えるっていうのはすごいいいですね、
Guest
確かにかつあれですもんね。あの、共通ルールの方は、あの前にいて、インサイドでも紹介したペイブックの方で、
Guest
あの共通ルール以外のことをやる時は、こういう風にやるといいよって、ガイドラインもある程度定められてるんで、なんか、カスタマイズも最悪しやすいっていうのもあるんで、
Guest
変ではありそうですね。そうですね、
Guest
あとは、ニュースであの固有なのは、マックスワーニングを指定してるっていうのが、ちょっと他のプロジェクトじゃないかなって
Guest
あります。この運用の仕方が、あの、ちょっと特殊でミステ。あの先程もあげた通り、あの
Guest
元々イントを通してない時期もプロタクト初期にはありまして、プリティア自体も後から入ったみたいな経緯が
Guest
で。今ってesリントとプリティアって別々に設定して、別々にリントかけるっていうのが一般的独立してると思うんですけど。
Guest
イスだとブリティアをかけなきゃいけない箇所もすごい多くて、
Guest
で、そこを今はesリントのプラグインとして、プリティアを入れて、
Guest
プリティアに。ワーニングとして、え、e3のワーニングとして設定してるっていう構成になってるんですね。ていうのも、
Guest
プリティアがあの、今かけられないんで、プリティア自身になんてすかね。エラーを消すような仕組みがないんで、
Guest
イエスリントに乗っかって、ワーニングで指定しているっていう感じになってます。そうすると、マックスワーニングっていうのが、その
Guest
ワーニングの数を最大指定できるんで、今、あのニュースのコードに残っているプリティアをかけなきゃいけない箇所を、一旦、その
Guest
ワーニングの数に指定することで、これ以上プリティアの数を増やさないような運用をルールにしていて、マックスワーニングを指定してるっていうような
Guest
ああ、やってますいい
Guest
そうですね、マックスワニング本当は完全一致が嬉しいんですけど、
Guest
ま、今以上には悪くならないっていう手で、マックスワーニングを指定していて、イセルはに関しては全て理性にしてるんでま。ワーニングもエラーもない状態で
Guest
追加されれば、ま、エアラルで落ちる
Guest
ていう感じ。ああ、結構この辺りはあれですね。あとから色々追加していった故の工夫みたいなのが
Guest
見て。そうですね、そんな感じで、今運用している形になってます。
Guest
あれですよね、あの、既存コードを触って、なんかそのファイルがプリティアかけた場合は、マックスワニングが減るので、
Guest
マックスワーニングの数も減らして更新していくみたいな形で悪くはならなくて、どんどん良くなっていく方向にだけなるようにしてるそうです。ですよね、
Guest
だから、そこの運用はしっかりしないとま、ちょっと問題があったりもしますが、今より悪くらないならないっていうところが結構
Guest
重要なとこかなと思ってます。あとは、推奨ルールのほかに、ちょっとしたルールをはい、入れてたりしますよね。西山さん
Guest
あ、そうですね、あの、まだjs環境が残ってる。行動に対しては、esイントプラグインインポートっていう
Guest
の入れていて、tsであれば、例えばインポートのなんかディレクトに移して、インポートパス
Guest
直し忘れてたとかって、コンパイルエラーを切ると思うんですけど、レースだと、なんかそういう時とか、スポートされてないやつをインポートしちゃってるとかの時に、
Guest
気づけなかったりするので。より安全にベースでも、リラクタリングとかできるように。
Guest
インスリントプラグインポートっていうパッケージを追加で入れたりしています。
Guest
そうですね、あのジェストps結構今混在してる状況ではあるんで、そういうところのケアもちょくちょく入れてたりする状況ですね。
Guest
ああ、そうなんですね、
Guest
大体運用についてはこんな感じ感じ
Guest
結構あれですねまあ、あの、今の運用ルール自体は一般的なものかなと思うんですけど、元々esリントが入っていなかったところに、まあ入れていくっていうところから入って、プリッチャーも入れてね、リントルも変えてっていうので、
Guest
変化にこう追従できるような作りになってるって感じですね。全体として
Guest
あれですかね。あの、今回の本題でもあるイエステにセーブルは、このあたりの大きな変更によって生まれていった。
Guest
で、はい、
Guest
じゃあ、ちょっと次イエスイントセーブルについていよいよ。話を聞いていこうかなと思います。
4. eslint-disable の経緯
Guest
ではですね、ちょっとここまでと、今、会社の推奨ルールの方に載せていった話とか、色々聞いていけたかなと思うんですけど、多分その中で結構今回の主眼であるesイントdsブってのが生まれてきたのかなと思うんですけど、
Guest
なんか結構聞いてる限りは多そうな変更が多そうなリセーブルも多そうな状態かなと思うんですけど、
Guest
なんか、具体的に結構で、ニュースのルールから推奨ルールに変わるにあたって、こういうところのリントの違いがあったみたいなで、リセブにせざるを得なかったっていうのって、どういうところが多かったんですかね。
Guest
そうですね、jsのリントとか、dsのリントみたいなのは、ある程度元々入ってたんですけど、リアクトとかビに関するルールは結構入れてなくて、
Guest
そういったところが結構
Guest
あの一気に増えたなっていうのがありますね。特に、リアクトとアのコンポーネントはもものすごい数あるんで、あのあ、それに関する。
Guest
あの、例えば、リアクトプロップタイプっていうプロップタイプで指定しなきゃいけないみたいなところ
Guest
とかは、ものすごい数コンポネットがあったんで、それに付随して一気に増えて、あの1番エリートで引っかけのディセーブルが多い箇所
Guest
ではあります。
Guest
おお、なるほど、なるほど、
Guest
理もそれに付随して結構色々ありますね。
Guest
じゃ、結構あれなんですよね、普通のまいわゆる、ただのjsのコードみたいなところ、jtsのコードっていうところだと、まあそこまで
Guest
膨大なってわけでもなかったが、まあ、リアクトやビューといった、そのフレームマーク専用のルールっていうところが、かなり問題としては、多く出てきたっていう感じ
Guest
ですかね。そうですね、結構そこら辺もルール、僕らニュースでは、あのルール決める時に
Guest
結構相談して決めるっていうとこあるんで、あの推奨で、はい、ガチっと決めてくれてるってのはすごい嬉しいですね。
Guest
ああ、なるほど、嬉しい反面変かも。
Guest
そうですね、ますね、はい、
5. 特に頻出する eslint-disable
Guest
じゃあこのままちょっとぬるっと2番に行こうと思うんですけど、え、なんか、今、あの
Guest
リアクトのプロップタイプとかの話がすごいエラーもあるって話もさらっとしてもらったかなと思うんですけど、なんか具体的に今、リセーブルの数が多い。
Guest
リントエラーとかって、リントルールとかって、どういったものがあったりするんですかね。
Guest
そうですね、先ほどのリアクトの話とかも
Guest
ありますし、あとは、リントかけてない時期もやっぱりあったんで、ボンミスのあ、あのリントエラーみたいのも結構ありますね。あの、オートフィックスで直せるような、
Guest
プリフェアコンストとかま、レットで書いちゃってたケースとか、あの、はいはい、テンプレートリテラルで書いてないケース、プリフェアテンプレートとか
Guest
そういうのが多いですね。
Guest
ああ、なるほど、クレーマーのものが、まあ、1番リアクトのものが多かったとはいえま。結構そういったjs的な部分もま歴史故に残ってる部分もあるって感じ。
Guest
そうですね、
Guest
ちょっとそれは、推奨環境前の時からも、ずっと残ってるものではあるんで。はい、あの、結構触らないコードはずっと残り続けるんだなっていうのも、
Guest
やっぱ直していきたいって気持ちは強いです
Guest
ただ、あれですかね、オートフィックができるものも多いんで、結構一気にフィックスはしちゃったって感じなんですかね。今は
Guest
そうですね、そこは結構議論の余地があって、あの、はい、多分オートフィックで変えて大丈夫だと思うんですけど、
Guest
一応安全に倒してて、変えてないケースもありますかね。あ
Guest
あ、はいはいはいはい、なるほど、なるほど、そこはすごいそれはあれですか。あの、
Guest
もしかして、これからコードフリーズの後とかにキウェイでまとめて、リグレーションしてもらうとか、予定してたりするんですかね。
Guest
そうですね、難しい
Guest
一応、過去に1回かなり大量にオートフィックスしたことがあったんですけど、
Guest
その時は、イエリント側のオートフィックのバグを踏んで、あ、あ、バグるっていうのが実。はい、1件だけなんですけど、あったんで、
Guest
なんで結構オートフィックほぼほぼ大丈夫だろうと思いつつもちょっと怖いっていうのがあります。はいはいはいはい、なるほど、なるほど、
Guest
なんで割と触らないコードはずっとそのまま
Guest
じゃあ、触る時に治るっていう
Guest
感じなんですね。なるほど、なま確かに安全に倒すならそうなっていきますし、ニュースほどの規模になってくると、やっぱり
Guest
何か問題があったときの影響も多いんで、なんかすごい1番いい安だな選択なしますね。
Guest
ちなみに、この辺りの特に多いルールって、具体的に数字で言うと、どれぐらいのエラー量があるんですかね。
Guest
そうですね、1番多い先ほど上げたプロックタイプとかは、991。
Guest
なるほどね。逆に
Guest
言うと、あのディセイブルするのも大変なんですよね。実は
Guest
ああ、はいはいはい、
Guest
あの1箇所1箇所追加していくの大変で。で、他の
Guest
あの僕ちょっとぐちょにやっちゃってたんですけど、他のメンバーがなんか自動でそのディセイブルの箇所を
Guest
コメントしてくれるみたいなのがあって、ちょっと名前は忘れちゃったんですけど、
Guest
それを入れると、そのディセーブルの箇所と、あと、これを修正する人は、このディセーブルを直してください。みたいなコメントも一緒に入れて、
Guest
イセーブルを入れてくれるみたいなツール、cliのコマンドがツールがありました。おお、
Guest
なるほど、あ、ちょっとそれもしよかったら、後で調べて教えてもらってもいいですか。ショートにののけておこうと、はい、
Guest
わかりました。
Guest
なんで、皆さんはぜひぜひそのとからアクセスして、なんかそういうのに困っていたら、強いただければと思います。いや、でも、それにしても991件は多いですね。
Guest
悲しそうですね、なんでこんなお多いんですかね、
Guest
ちなみに、2位になると由来なんですか。
Guest
2はでも、248で、プリファーコンストなんで、コンストに変えるみたいな感じです。
Guest
じゃ、結構だんだんこうあれですね、1個のリアクトのプロックタイプスがすごい多いだけで、あとはまあ
Guest
多いけど、ぐらいの量には収まっていって、
Guest
簡単そうですね。そうですね、
Guest
この辺はままだ言うて、そんな直すの大変じゃない箇所ではあるんで。
Guest
そうですね。そうですね、愚直にできそうなところではあるんでは。
Guest
あとはプリフはテンプレート、リテプレート、リティアルルとかあるんですけど、ここまではあの、結構ぐちょきに合わせるものなんですけど。うん、その次に多い
Guest
リアクトのノーストリングレフズがちょっと1番厄介。ああ、思ってます。
Guest
確かに、トムストリングスは、結構直すの大変なルールなと手間取りそうですね。
Guest
そうなんですよね、これって、あのコンポーネントのあの親の方のコンポーネントが、このストリングレーフして、この方を使ってると、
Guest
影響範囲がすごい大きいんですよね。ここを修正する時、はいはいはいはい、それでちょっと直せないケースがすごいあって、
Guest
これ直したくて。しかも、リアクトの非水晶なんで、他のなんていうんですかね。プリファーとかじゃなくて、もうほんとに直すべきものかな。そうね、
Guest
結構悩みのところの問題で、確かに
Guest
確かに治したいルールとなんか病で治せるし、別に直さなくてもいいみたいな。ルールはちもあるんで、治したいとかは直していきたいですよね。そうですね、
6. 特に直したい eslint-disable
Guest
それで言うと、あの特に結構数で言うと多いやつだけど、あの、そんなにこう本質的じゃないエラーもあるのかなと思っていて、
Guest
その中で言うと数は多くはない、もしくはそこそこの量だけど、特に直したい。イエスリンとビセブとかって、なんかこの中でどういうものになってくるんですかね。
Guest
今のノーストリングレフスもそうだと思うんですけど、
Guest
個人的にはあのeqeqeq
Guest
あ、あのイコーイコールみ、2つを3つにしてくれってやつですよね。
Guest
そうですね、これ、要は今まで暗黙的な型変換を使ってるような。あの企画になってたと思うんですけど、
Guest
なんか、その辺りはちゃんとeqeqでかっちりとしたいな。
Guest
ただ、ここって何も考えずにイコール1個足しちゃうと、振る舞いが変わっちゃうことあるので。
Guest
いや、そうなんですよね、これ結構なすの怖いですよね、正直
Guest
そうですね、直すのかわいいですけど、直し
Guest
そうなおなすの怖いけど、直したいめっちゃありますや、特にいきいきいきで、なんかこう
Guest
なんでしょう。あの、アンディファインドとかと比較されてたりする時の比付き、ちょっとありますよね。
Guest
なんか、トゥルーフォールスで表現できるものがいいんですけど、こう曖昧なデータとかだと、ちょっと怖いなっていうのは確かにありますね。
Guest
なんか、他に特に直したいのありますか。井上さんとか
Guest
そうですね、エクスプリスペニーは、あの、結構嫌だなっていう縁があるのがちょっとなんて言うんですかね。蔓延するじゃないですか、1か所あるとみ、これははいはいはいちゃうっていうのがあるんで、
Guest
あの、ほんとはもうディセイブしないでほしいっていうのがすごいあるんですけど。
Guest
うん、そうですね、
Guest
こことかは確かに今残っちゃってるんで、ここ残ってんならいいんじゃね。みたいなノリで多分入っちゃってると思うんですけど、
Guest
確かに確かになくなってほしいですね、ただ、ちょっとテストとかでと、テストかとあの、モック化するじゃないですか。はい、そういうケースで無理やりモックにするときに
Guest
か、なんとかしなきゃいけないとかいうケースはちょっと議論の余地があって、
Guest
ああ、確かに
Guest
直せないかもしれないし。っていうのはあるんですけど、できるだけなくしていきたいなっていう気持ちは強いです。
Guest
今エは6件あるんですねそうですね、6件だったらなんか倒せないそう
Guest
6件なら、全然頑張ったらいけそうな気はしますね。
Guest
いや、この辺は倒していけるといいですね。なんか、こうめんどくさいけど、てか、ややこしいけど、数は多くないところは、
Guest
できるだけ倒して、割れ窓を減らしていきたいところではありますね。そうですね、
Guest
そうですね、
Guest
あの、逆に結構数も多いけど、そもそもこのルールいらないんじゃないかな、と思うようなものとかはあったりします。
Guest
そうですね、あの、そんなにあのなんですかね、いらないんじゃないかとまでは言わないんですけど、特にあの不便だなって思うのが、
Guest
あのタイプスクリプトの関数の型をつけるやつですかね。
Guest
ああ、はいはいはい、あの推論じゃなくて、明示的にか
Guest
まそうです。そうですね、それってどどどう思いますか。皆さん、あの、僕は結構個人のプロジェクトとかだったら、
7. このルールどうなの?
Guest
ま早さ重視で抜いちゃったりするんですけど、LINEコープの水晶のルールには、確かあった気がしてて、
Guest
あむずいですね。なんか、推論が
Guest
ちゃんと働くところは推論してほしいんですけど、なんかこう
Guest
推論機に寄せたい気持ちは、まあ、それなりにありつつも全部が推論になっていたら、結局こう安全性が担保されきらないんで、あの、
Guest
一定のLINEをちゃんと
Guest
こう方をメージ的に書いているのであれば、省略してもいいみたいな感じなんで。ただ、その一定のラインの担保っていうのがま。組織的に仕事を
Guest
するときには、目線合わせが難しいと思うので、なんか、会社の推奨ルールとして置くのであれば、運んでいいのかなっていう感じがしますよね。
Guest
なるほどです
Guest
まあ、なんかそのプロジェクトごとの最良でオフにするとかは全然ありかなと思うルールではありますね。一方で、
Guest
それこそ個人開発とかだったら、自分の中の基準があると思うんで、なんか別にオフにしてもいいかなと思ったりします。
Guest
西山さんどうですか。
Guest
そうですね、なんかあの、もちろんなんか、関数の入力と出力の方を明治的に書いとく方が
Guest
いいんだろうなっていう気持ちもあり、つつ、たまにめんどくさい時はあるんで
Guest
わかりますね。あとは、まあ明治的に書いた時に、
Guest
この関数のその帰りの方微妙じゃねってなることあると思う。ああ、
Guest
この方で返さない方がいいよねっていう、あのユニオンタイプにしない方がいいよね。みたいなあるかもしれんで、なんかそういう意味では書いて、
Guest
その時にほんとにこの関数のインターフェースはこれでいいのかっていうのを考える機会にはなるのかなとはあ
Guest
ああ。確かにそういう見方もますね。いや、なんか難しいルールであることがわかりましたね、
Guest
一概にこう決めるのが難しい
Guest
そうですね、
Guest
なんか、そのその他で言うとあったりします
Guest
とは、ビューのマルチワード、コンポーネントネームズっていうプールが、
Guest
ああ
Guest
はいはい、ありましてありますか。これも結構元々コードに関しては直しづらいというか、
Guest
はい、あのは、はい、名前変えるものになっちゃうんで、コンポンメント名変えなきゃいけなくなるんで、そこまでして直す価値はあるのかってところは、結構
Guest
新規に関しては、まあ、ちょっと制限あるかな。程度なんですけど、元々のコードに関しては、これは直さなくてもいいかな、みたいにはなっちゃいそうなルールですね。
Guest
ああ、確かに新規は守りたいですけど、既存は悩ましいです。
Guest
なかでも、あの明らかにhtmlタグと名前がかぶってるやつはなしたいですけどね、あのボタンド、そういうファイルがそうですね。
Guest
ただ、そういうものを除けば、確かにこうわざわざ直すもなってなるようなルールでもある気はしますね。
Guest
石山さん的にはどうですか。
Guest
そうですね、ガイドラインにはこういうのも書いてあったもん。そうですね、
Guest
やっぱりそのeエリントで、その人間の努力じゃなくて、ちゃんと機械的に教えてくれるっていうところで言うと、
Guest
ま、ガイドラインに書いてあることを皆守ろうっていうことだと思うので、まあってもいいのかなっていうな、
Guest
ま、ただ既存はやっぱめんどくさいですか。
Guest
そうですね、既存のやつのそのちょっと大変。
Guest
確かに、この辺は新規でやる時だけとかま、これ以上このルールで警告されるのが増えなくなればいい系な気はします。
Guest
増えると良くないが、まあ、今の分は許容してもいいようなものでもあるけど、ありがとうございます。いや、結構あれですね数から見るのも面白いですし、
Guest
直したいものから見るのも面白いですし、疑問があるから、ものから見るのも面白いですね。結構、現場の都合がんとルールから見えてくるみたいなの
Guest
あるかもしれないですね。
8. 勉強会の話
Guest
ちょっとなんか、次の町に行こうかなと思うんですけど、
Guest
結構ですね。ここまで見て、まあ、プロップタイプスのリアのエラーが991件あったりとか、かなり膨大なエラーがあるものもあれば、結構疑問のつくもの、あるいは、5つや6つぐらいのエラーしかないけれども、どうしても直しておきたいeqqeqみたいな
Guest
ルールについて、結構話してきたかなと思うんですけど、
Guest
この辺てまいったリセーブルにはすると思うんですけど、将来的には直したいっていうものがほとんどかなと思っていて、なんか減らすための活動とかしていたりするんですかね。
Guest
そうですね、あの、こういうのってやっぱりみんなの意識がなんていうんですかね。違うところっていうか、
Guest
いろんな考えを持ってコードを書いてるま、チームメンバーが多いことによって
Guest
ま。色んなところで、こういう細かいミスだったり、ま。こういう書き方の問題だったりっていうのが発生してると思うんで。
Guest
みんなで共通認識を合わせるために、勉強会みたいなのをちょっとしたりも
Guest
でま。勉強会の内容としては、あの今先ほど上げたやつで、イエスリントディセーブで起きてる箇所をまカウントして、
Guest
王位順とか直したい順にリストアップして、それをちょっと問題形式にして、え、みんなに解いてもらって、
Guest
今後なんて言うんですかね。そういうディセーブルに当たった時に、すぐにあの迷わず対処できるような形で
Guest
え直していただきたいっていうところで、勉強会を開いたりしてました。
Guest
なるほど、まあ面白いですね、それ、車に変えるのし方になってないかどうか。
Guest
そうですね、結構実践的なクイズになっててま、そもそも間違ってる箇所をクイズにしたっていう感じなんで、
Guest
あのはいは、そのままニュースのコードみたいなのを、みんなにあのあの年収問題として出して解いてもらうみたいなでま
Guest
といった後は、みんなでどういう風に直したかっていうのを認識合わせて、で、実はあの、その勉強会の中でも
Guest
と解きにくいというか、解けないというか、これどうするの。っていうのをちょっとおり混ぜてりして、正解がないっていう感じなんですけど、
Guest
ああ、そういうのも合わせて、みんなで議論で巻き込んで話し合ったりもしました。
Guest
意図的に、議論の余地が残るような題材を中心にやってい
Guest
そうですね。ですか、
Guest
ああ、いいですね、
Guest
オートフィックスとか、簡単な問題になっちゃうんですけど、あの、ロジックから変えなきゃいけないリントのエラとかは、
Guest
こうしたらいいんじゃないかとか。しかも、正解も1つじゃない場合もあるんで。そうですね。なんか、ビジネスロジックも踏まえて
Guest
考えたりもしますね。例えば、なんかエラー握り潰してるところがあって、ほんとに握りつぶし、
Guest
あのなんてすかね。そこで、リントエラーかは起きてるみたいなケースとかは、
Guest
あの、そもそも握り潰していいんだっけみたいな、そういう議論からうん、うん、起きたりもしますね。
Guest
確かにそこは握り潰してのする系は結構こうミスすると影響も大きいですし、
Guest
怖いとこでもありますもん。
Guest
そうですね、
Guest
ちなみに、なんか直し方をなんかそこで勉強するみたいなのが、この機関の趣旨だと思うんですけど、なんか、実際オートフィックスで直せないリンとなって、
Guest
大体テストコード書いてもあ、
Guest
直しなってるかとか、ほんとにちゃんと今の挙動が担保されているか確認しつつやると思うんですけど、なんか、そこも今後セットで
Guest
やってみたりとかする予定あったりしますかね。
Guest
そうですね、それも結構
Guest
すごい重要だなって、そもそもテストもテストじゃないですね。あの、クイズのクイズを出したか感じなんですけど、そのクイズもあ、あのテストを実は裏で書いといて、
Guest
テストを解かせて、実そのテストを簡単なように作って、実はテスト動かないように、そのまま直しちゃうと動かないみたいなのを
Guest
作ったり。だから。まあ、そうですね、あんまりメージ的にテストを絶対書いてから、
Guest
dcブルをなし直してください。とまでは言ってないですけど、やっぱテストを書いて、
Guest
元の挙動と問題なくテストが通って、さらにリセーブを直して通るみたいなのが、やっぱ1番理想ですよね、
Guest
確かにそれが理想ですねですね、やっぱりなんかリントルール直すときって、デグれするのが1番怖いんで、
Guest
やっぱりテストセットにはしたいところではありますよね。
Guest
そうですね、ただ、やっぱちょっとイエリンとディセイブ消すのは、ボランティア的なところもあるんで、
Guest
絶対テストとまではちょっと言えてない感じではあります。
Guest
まあ、でもそのあたりはちょっと仕方ないところではあり、
Guest
なんかこれ実際やってみての書簡とか。結構今、井上さん観点は聞けたかなと思うんですけど、今回主催、多分井上さん主催だと思うんですけど、
Guest
あの西山さんからしたらどうでした。やってみて、
Guest
はいはい、そうですね、僕、自己性が自己性受けたんですけど、そうですね。まんまと井上君の罠にはまって、
Guest
僕が直したやつはテストはかけて、要は、エラー。リットの
Guest
エラーを直した結果、振る舞いが変わってしまう直し方をしてました。で、他の人が解いた時も結構何人か、
Guest
そもそもこれ挙動変わっちゃうよねっていう直し方をしてたりしたので、結構やっぱりオートフィックで直せないようなものは。
Guest
なんていうか、何も考えずにリセーブルちゃえ。ならないように直しちゃうと、振る舞いが変わっちゃうので、慎重に。それこそ、アテストとかキリとか
Guest
必ず必要だなっていうのは思いましたね。あとは、やっぱり後から
Guest
ミントルール入れるのはま、ニュースだとちょっとしょうがない部分はあると思うんですけど、大変なので。
Guest
ま。新規プロジェクト作る時は、もうリントルールとかは、最初にかっちりとしていた方がいいかなっていうね、
Guest
しもいました、間違いないですね、
Guest
確かに、オフィックで直せないっていう言葉は、直せないなりの理由があるってこと。なんで、無職にワが出ないようにするだけだと、確かにてくれるリスって
Guest
なりますよね。そうですね、
Guest
あ、でもいいですね、なんか、こうやってちょっとずつ勉強会で解消していくみたいなのもすごいいいですね。
Guest
そうですね、あとは、あの、そのルールってなんで設定されてるんだろうっていうのが疑問になるのもいくつかあったので。
Guest
ま、そういうま、まそれぞれドキュメンタリーは書いてあると思うんですけど、そういうのを見て、なんでこういうリントルールがあるんだろうっていうのをみんなで話し合ったりとかしたん。
Guest
そういうところもよかった
Guest
いいですね。なんか、勉強会にのきっかけで、ただルールに順守するってだけじゃなくて、その裏のい糸まで、お互いに知る機会があれってのは
Guest
すごい良さそうですね。そうですね、
Guest
ありがとうございます、結構いいですね、なんか、こうやって計画的にリセーブルを外していくっていうのは、
Guest
いい取り組みですね。
9. 総合で将来的にやりたいこと
Guest
結構ここまで色々聞いてきましたけれども、あの、最後になんか結構今色々改善進めてるっていうとこだとは思うんですけど、なんか、これからこういうことやっていきたいなと思ってることとかってあったりしたら、
Guest
きたいなと思うんですけど、まず、井上さんからお願いしてもいいですか。はい、
Guest
話の結構冒頭にあったんですけど、マックワーニングの今運用してて、その数が
Guest
あの最大値なんで減っていくと、その数があのなんてすかね。
Guest
減った分だけ、さらに、プラスで上乗せできちゃうっていう問題があるんですね。ああ、警告が例えば3個あって、
Guest
1個減ったから2個になった時に、そのマックスワーニングの数を2に指定しておかないと、3のままだと、プラス1個分よ。許容されちゃう
Guest
っていう問題があって、で、そこを。まあ、今はちょっと何もしてないんで、あの、なんていうんですかね。
Guest
気づいた人が、マックスワニングを今変えていくっていう運用になっちゃってるんで、たまにデビューで見ると、あれ。これインポート使ってないのに、イポット残ってないみたいなケースがあったりして、
Guest
ま。そこだけちょっとリントがうまく動いていないケースみたいなのがあったりしましたね。だから、ちょっとそこはなんか対策を打ちたいなと思ってたりします。
Guest
確かに、そもそも、マックスワーリングを自分たちで管理していること自体がこうよくないんじゃないか、みたいな話もなってくる気はします。自動的にそうですね、
Guest
変わってくれると
Guest
そうですね、完全一致とかもできたら嬉しいんですけど、まだちょっとeseというそういう機能はなさそうだったんで、
Guest
なんか他にまマックスの数をどっかで指定して、そのなんていうんですかね。リートの
Guest
ワーニングの数を自分たちにとって、そこで落とさす落とすとか、そういうのをちょっとした方がいいかもしれない。
Guest
西山さんはあったりします。
Guest
そうですね、今回のはあの会社公式推奨ルールを
Guest
入れてっていうところだったんですけど、ま。それ以外にニュース特有のルール、
Guest
プラスのプラス、アルファの部分ですね。とかが
Guest
あるので、なんかその辺りはあの自分たちでカスタムのルール作って入れていきたいなのがあります。いいですね、
Guest
例えば、あのnewsタブとかだと、ま、nestbの独自ebビューの
Guest
使用上エタグを使わないっていうルールが実はありまして。はいはい
Guest
なので、ただ、うっかりエタグを使ってしまうことがあるので、その辺りをあり、ルールとして追加して、リンクコンポネート使いましょう。みたいなのにしたいと
Guest
ありますね。確かに、そのドメインごとの独自のルも追加していけるといいですね。
Guest
そうですね、そうですね、結構なんか改善こうしたいっていう時に、これリントで解決できるんじゃね。みたいなのが、ちょくちょく上がるんですよね。
Guest
はい、そういうなんて言うんすかね。リと
Guest
を追加する元々あるリントのルールを追加するのは簡単だと思うんですけど、自分たちでルール作るってなるのがちょっと高くて、
Guest
それを簡単に入れられるような気候みたいなのが欲しいなっていう感じです。
Guest
確かに、イエスイントのプラグインとか、ビントルールがこうと思って、結構at触らないといけなくて、結果こう
Guest
開発メンバーが気軽に触れるものではないっていうのは、結構よくある気がするんで、それは確かに
Guest
なんか難しい。ハードルではありそうですけど、なんか逆に言うと、リントルールになってないルールってこう、主観的なところが大いに出てくるんで、できれば、リントルールに寄せたいっていうのはありますよね。
Guest
なんか、LINE証券とかは、独自のイントルールつか作ってるみたいなんで、その辺も参考にできるといいそうですね。アリスです
Guest
あれかな、確か、リアクトのあの、jsexの連打の時に、アンドアンドを使うと、値によっては1とかだったら、1がレンダリングされるみたいな問題があるんで、アンドアンド使わないようなルールとかを自分たちで開発して
Guest
使ってる感じですね。ちなみに、マックスワーニングスについての、なんかこれ、ほんとにジャストアイデアと、なんか
Guest
こういうのってどうなんですか。っていうぐらいなんですけど、多分これってなんか意図的に
Guest
いや、これこれを制定する意図としては、今のコードよりえワーニングが多いコードが
Guest
アップストリームに取り込まれないっていうのが目的かなと思うんですけど、なんか例えばさ、サークル試合のワークフローを1個設定して、プルリクが出ている時だけ、プロリクの
Guest
周り先のブランチをチェックアウトしてきて、そっちでリント走らせて、その数を先に取得して、で、今のヘッドの
Guest
いい。今のプロリックのベースとなる方の、お送りたい取り組みたいコードの方でも、1回リンと比較して、その
Guest
ワ数同士で比較するとかだったら、自動的に今のコードより良くなっている、もしくは、同じっていうところに抑えられたり
Guest
しないんですかね。ちょっとめんどくさいかもですけど、
Guest
フィーチャーからデブリフルリク送っていてまデブの方もチェックアウトしてきて、えーで、デプス1でチェックアウトしてきて、最新のヘッドだけ取り込んで、
Guest
あのチェックアウトの速度も最小化えさい。1番早くした上でこう両方でリントかけるとかで解決したりしないのかな
Guest
と思ったりしました。
Guest
そうですね、できる気が
Guest
すごい良さそうな、はい、
Guest
そういうのとかなんかできそうだな。
Guest
ちょっと困りましたね、
Guest
すいません、これ、ジャストアイデアです。
Guest
なるほどです、ありがとうございます。
Guest
まいいか、いやいいやいや、もうこれ採用しちゃおういいや、カットしなくていいやすいません。
Guest
いや、でも、なんか色々できる余地がありそうで、めっちゃいいですね。
Guest
今後ちょっともしまたえ、色々リントルールカスタムで作ってみたとかあったら、
Guest
あの、この中でも紹介していきたいんで、ぜひぜひお金お話させてもらえればと思います。はい
10. クロージング
Guest
というわけで、今回はですね。井上さんと山さんのLINEnewsの開発2名にえ、LINEnewsにおける、eesretdisableとの付き合い方について話していきました。
Guest
ラインのフロントエンド組織UITでは、このようなフロントエンドに関するえ、議論や営情共有などを日々行っております。
Guest
UIT INSIDEで、過去に紹介したエピソードの中では、社内勉強会や社内での意見交換から生まれたものも多数ありますので、今後もえ外部に向けて情報を発信していければと思っております。
Guest
また、UITインサイトについてのご意見やご感想があれば、ハッシュタグシャープ、UIT、アンダースコアインサイトにて
Guest
えついていただきます。とえ、スタッフの方で拾がさせていただきますので、ぜひぜひお気軽にピートしていただければと思います。
Guest
そして、最後になりますが、え、ライン株式会社ではえ、新卒中とともにえ、メンバーを大募集しております。
Guest
小のと、サカ部の方にあります求人のリンクからご連絡いただきますと、今だとえズムの方でえ、リモートでのカジュアル面談も可能となっておりますので、え、お気軽にご連絡いただければと思います。
Guest
というわけで、今週はLINEnewsにおける。essblの話でした、ありがとうございました、
Guest
ありがとうございました。