音声書き起こし
1. オープニング
@spring_raining
こんにちは、UITの玉田です。今回も、UIT INSIDEを始めたいと思います。
テンサイドは、ユーザーインターフェースと、テクノロジーを愛する開発者のためのポッドキャストです。
最新のウェブ表示の動向や開発、フレームワークの変遷、uiやuxに関することまで、毎週フロントエンドに情報を発信していくことを目的としています。
@spring_raining
はい、今回はLINEnewsのえ、お2人を呼びました。えかさんとおさんを今回はいおびしました。
そこで、やられているフロントエンドリポジトリの改善の話ということをえ、今回されるということなので、ちょっとそれについて 聞いていこうと思います。それではよろしくお願いします。
@jaycompsci
はい、します、よろしくお願いします。
2. 自己紹介
@spring_raining
はい、 ではですね、お2人あのこさんは多分以前に出られたと思うんですけど、結構まということなので、ま、一旦お2人に自己紹介というか、どういったことをされてるかっていうのは 聞いてみようかなと思います。
@jaycompsci
はい、結構前に出演したんですけども、しばらく経ってます。LINEwsの堀と申しますプライベートでは、jって呼ばれてます と、LINEnewsの開発の他には、UITprybookの編集をしたりしていますよろしくお願いします
@spring_raining
はい、よろしくお願いしますそれでは、さんはい、ご紹介お願いします。
he.shuangbing
はい、デブチームのかと申します。去年の4月に新卒入社して、今同じくLINEnewsのフロント の開発業務が携わっています。今日は、初めてのユインサイトの参加になりますが、よろしくお願いします。
@spring_raining
はい、よろしくお願いします。それでは、あのじっくりと聞いていこうかなと思います。じゃあ、まずは まバックグランドって言いますか。LINEnewsというプロダクトでのフロントエンドの立ち打ち的なのをちょっと聞いてみようかなと思うんですけども、 どれぐらいのチームとかから聞いてみますか。
3. LINE NEWSのフロントエンド
@jaycompsci
規模ですかね。
@spring_raining
はい
@jaycompsci
と、LINEニュースをシムでやっている、フロントエンドエンジニアが10人ぐらいいるんですかね。ざっくりと。まあ、関わっているエンジにはもっとたくさんいますね。フロントエンドエンジニアだけの話ですけど、もま、バックエンドの エンジニアもま同じぐらいの数がいてま。その人たちはUITではないんですが、います。
@spring_raining
うん、なるほど、結構あのLINEの中でも1つのプロダクトにフロントイドインジニアが10人っていうのは、かなり大きいという プロジェクトになってますよね。
@jaycompsci
そうなんですかね、他のプロダクトにいたことがないので、
@spring_raining
までも大きい方だと思いますね。
@jaycompsci
はい、 その広告の開発チームだったり、機械学習だったりとか、いろんなところと関わることもあるし、開発する機能 の数も多いんで、フロントエンドエンジニアの必要な数も結構多くなってきてるのかなと思ってます。
@jaycompsci
んで、チームがいくつかに分かれていて、フロントエンドエンジニアと、バックエンドエンジニアと、qaプロジェク とマネージャーとかのが何人かずつのチームを1つの塊にして、それが ま3つとか4つとか食って、同時進行で機能だったりとかで分けて
@jaycompsci
やっているのが、あの今の体制になってます。
@spring_raining
うん、うん、うん、なるほど、いや、でも、話を聞く限り、やっぱり第1部だなっていうのは、私の周りの仕事では思いますね。うん、
@jaycompsci
まそうですね、一応LINEの中でもあの数字で見ても、スタンプを除いたら1番大きいと考えていいんですかね。
多分はい
@spring_raining
ま、そういったこう大規模なプロジェクトだからこそっていうところですかね。今回、そのポジトリの改善の話っていうところなので、 まあ、その直接のプロジェクトの何か新機能ができたっていうところではないと思うんですけど、結構そういった問題点みたいなのが、 大規模開発する上で出てきたという感じですかね。
he.shuangbing
そうですね、このニュースのリプストリーの回線自体は、まずっと僕がいる前からずっとなんか継続的にやっている感じですね。はい、
@spring_raining
そうですねまでも、こういった継続的に取り組めるっていうところ、自体が割とその羨ましいところでもありますね。
大規模開発ならではだなっていう感じがします。じゃあ、そうですね、 多分、今まで改善って言ってきたところの具体的な内容について聞いていこうかなと思うんですけど、今
4. 改善した内容
@spring_raining
8つぐらいですかね。列挙されていて、どれから聞いていこうかなって思うんですけど、これはあの、どんな順番とかで開発されましたかね。
参加者 4
うん、うんうん、
@jaycompsci
それ以外は殺すはもう何年も前からあるし、え。
he.shuangbing
リリースの手順の解約感も割と最近入れたかなと思います。
@spring_raining
うん、うん、うん、すごい余裕をされていて、じゃあなんか1番気になるところから、 あの、esィルドローダーの話前からちょっと聞きたかったですね、これ、あの話では聞いてたんですけれど、
he.shuangbing
はい、ああ、そうですね、元々この導入したそのリポジトリが。 バベルローターとウェブファックの組み合わせを使っていて、結構このリボストリーが膨大で、コンポネントの数も結構 のでが、デブサーバー立開けるだけでも、1分ぐらいかかったりしてる感じだったんですね。
参加者 4
うん、うん、うん、
he.shuangbing
なんか、他のチームメンバーいくのさんが、これをシとで、あのイエスビルドロータを投入したら、 早くなるんじゃないかっていう話をチームにしていて、ニュースは毎週の水曜日にもブーフローという時間があって、 そのもちらももクロの時間を使って、みんなで一緒になんか導入をしてみて、結構2時間、
he.shuangbing
その時間ですでに導入ができて、
@spring_raining
あ、そうなんです。
he.shuangbing
そうですね、それと、なんか、デブサーバーの立ち明けの時間を10秒ぐらいになったので、めっちゃ 時間の短縮ができたっていう話ですね。
@spring_raining
いや、すごいそんなに出頭できるものなんですよ、あの、結構野心的な変更かなって個人的には思ってたんですけれども、
he.shuangbing
あ、この適用されるのがデブサーバーのみで、あの、 そのプロダクションビルととかに影響はしていない感じです。あ
@spring_raining
あ、はいはいはい、なるほどなるほど、
he.shuangbing
ほんとにあのイエスィルドローダを入れて、で、ウェブマックのコンフィックを新たに用意して、 それをデブサーバーの時に使うみたいな感じで実装したと思います。
@spring_raining
あ、そうなんです、そんなに簡単にまでもまあ結構そうですよね。その本番プロダクションのビルドに差し替えるっていうのは、なかなかリスクでは あるところにあるんです。っていう環境から差し替えるっていうのは、すごい妥当な感じがします。
じゃあ、さっきちらっと殺すって出てきたと思うんですけど、これ、社内用語というか、LINEnews用語ですよね。
he.shuangbing
そう
@jaycompsci
まあ、あのころすっていう名前をつけただけで、何かというと、細かい作業を自動化しています。
@spring_raining
で、はいはい
@jaycompsci
えと、まあスラックでこう書いたらこういう情報が見えるとかそういうやつですね。
@spring_raining
はいはいはいはい、これは実態はスラックボットなんですかね。
@jaycompsci
スラックボット、あれなんでしたっけ。フボチ
@spring_raining
はいはい、ああ、はいはいはい
he.shuangbing
とかベースで作ってるですね、
@spring_raining
どれぐらいの機能があるんですかね、結構いっぱい多機能ですか。
he.shuangbing
結構なんか色々追加されてて、なんか 普段の開発ツールから、なんかデプロイの焦らせるのも全部できてる感じですね。
@spring_raining
ああ、
@jaycompsci
これは元々結構え、多分3、4年前なのかわからないですけど、みみさんが まあ、みんなのために親切に色々自動化してくれた ので、生まれたのかなと思っています。なので、ちょっとその時の名残りで、コーヒースクリップで書かれていたり、
@jaycompsci
ていう事情がありえ、まあなんだろ。タイプスケルトとかで書き直すまでもないかなっていう感じで使い続けてる感じですね。
@spring_raining
そうですね、ヒルボットそうですよね、これヒスクリフトですよね。意外とそのスラックボットって、大体が なかったりっていうとこあるんですけど、まあでも、例えばそのギットハブ上のボットにするかとか。そういったまあ、選択肢も。
@jaycompsci
はい、それはちょくちょく話題になりますね。これは、うんうん、ギッドハブの方でもいいんじゃないかなとか。
@spring_raining
でも、そういうまあ、長年続いているというところですし、結構あとLINEnewsの場合ですと、スラック上でのコミュニケーションが活発という 印象があるので、そこ上でできるとこうなんですかね。ログというか、後で見返すときとか、便利かもとはちょっと思ったりしました。
@jaycompsci
確かにそうですね、まあ、あのギッドハブのプルリクエストがアップループされたあとか、通知もこすが スラックに出してくれてるので、はいはい、結構こすはLINEwsのスラックに出てきますね、
@spring_raining
よく見えます。
@jaycompsci
ライトハウスを毎朝10時出してくれたりとか、産業とかにまとめて
@spring_raining
いいですね。毎朝計測して、結果をちゃんと出すというところが出てきてます。
@jaycompsci
はい、
@spring_raining
じゃあそこの関連であれですかね。webバイタルズとか、デスティングライブライとかの話も。
@jaycompsci
はい、webbitrsの話しましょうか。LINEnewsのと、プロダクション環境での webitlsの通知を取るようにしました。で、経緯としては、LINEnewsでパフォーマンスを 向上させていこうっていう話がずっと出てて、それをしっかりやっていく前に、パフォーマンスを計測できる
@jaycompsci
あの環境 つくりたいということを考えました。で、まあ、LINEnewsは結構たくさんデータとってるんですけども、 パフォーマンスの指標っていうのは、基本的にとってなくて、で、ライトハウスっていうのは、1つのデバイスの限られた
@jaycompsci
数字しか取れなくて、あんまり本当に役に立つものかどうかっていうと、 限界があるんですね。うんで、そこでユーザー体験指標として、まあ最も優れているであろうウェブバイタルズを 導入してみようと考えました。
@spring_raining
なるほど、
@jaycompsci
はいでえ、それを実際にま僕が実装してと数値を取り始めて、で、それがまだ 2ヶ月前とかなんですけど、で、まあ、数値をちょっとまとめてみたりして、利用を今始めてるとこです。
@spring_raining
なるほど、ありがとうございます。あの、コアウェブファイタルズに関しては、確か そうです。去年にLINEバイトで、そのインターンの方が導入されたっていうのは、ポットキャストであったかと思います。で、 まあ、あの、そういうパフォーマンスの計測という面では、非常に有用なもので、私も導入したい
@spring_raining
なって思うプロジェクトはいくつもあります。
@jaycompsci
あの、導入してみて、まあ、学んだというか、その家庭の中でわかったことは、まず 最低限の統計学の知識がやっぱ必要で。うん、まあ、例えばパーセンタイルっていうものは何なのかっていうのは、 あの理解しないといけないし。で、パーセントアイル、
@jaycompsci
例えば、75パーセントアイルに基準を設定すべきなのか、90パーセンタイルなのか で、その根拠は何なのかとかを。あの、まあ、googleとかが色々提供してくれてる資料だったりとか、色々読むと、 その自分たちのプロダクトにとって、どこのパーセンタイルに設定すべきかとかの答えがま導き出せるかなとか
@jaycompsci
ていうことがわかりました。 で、LINEnewsみたいなおっきなプロダクトで言うと、一部のユーザーに対してえ、遅い スピードの悪い体験が提供されても、結構な数絶対数でいうと結構な数だったりするので、
@jaycompsci
あの、やっぱり無視できないところもあるし。なので、 平均値を見てしまうとわからないことも、パセタルを使うとわかる。だったりとか、ま、そういった気を付けないといけないことは結構あったなっていう感じはしました
@spring_raining
そのあたりもかなり気になりますね、そういったところは、こう導入した後っていうのもそうですけど、導入しながら身につけられるっていうのはそうですね。
@jaycompsci
そうですね、意外とはい、知らないといけないことが多かったって感じがしましたね。
すごいひどい数字のところはなかったんですけど、まあ、改善の余地があるところは見つかりましたし、あとは、 リリース日と比較してみるとんと、こういうのが
@jaycompsci
リリースされたから、この数字がちょっとこう変わってるのかな。みたいなことがわかったりとかして、これからちょっと 利用していくと、結構プロダクトのためになるあの、改善点とかが見つかっていく可能性があるかなと思って。
@spring_raining
そうですね、まあ、もう でもすでにそういった改善点見つけられてるっていうところですよ。多分、こういう計測系というのは、長い間取って 比較して初めてわかるところとかもあったり、そうなっていうのは
@jaycompsci
そうですね。あの、ウェブバイタルズはほんとにいろんな。変数があって、いろんなことが影響しての数字なんで、 やっぱりあの数字がどう変化したかを見てくっていうことが大切だと思い。
@spring_raining
なるほど、いや、やっぱりそれを考えると、早く導入しないと意味がないというのもよくわかります。
@spring_raining
じゃあ、他の改善点、結構他にも割とどういった関略かとか、 リリース手順の観略化とか、あと、自動生成とか、なんかこう便利機能的なのがあると知りたいですね。
he.shuangbing
はいえ、じゃあ、リリース手順の火力化をちょっと説明します。
he.shuangbing
今まで、そのニュースのデプロイの手順を簡単に説明すると、そのUIT3メル内で そのショートカットがあって、ショートカットを開いて、そのリリースするブラン地名を入力して、それをサプミーとして、 リプレイがデプロイが走るみたいな感じだったんですね。
@spring_raining
はい、
he.shuangbing
そのリリースしたいプランチ目を自分で入力する必要があったんですけど、その リリースパンチ名はフォマトがて、あの英語のリリースとスラッシュと後ろが8桁の仕付け になってる感じですね。はいて、例えば5月10がリースだとしたら、レディーススアッシュ、2022
he.shuangbing
0510みたいな感じで、これをリリースするたびに入力が必要だったんですね。
ま、そんなに不便ではないと思うんですけど、ベタキ営期間中に細かいバグがいっぱい出た時に、これを リプロイする時に入力しないといけなくて、ちょっとした手間がかかるなと思って、これを
he.shuangbing
省略できるようにしたっていう感じです。このに、リースブランチの名前の入力をうん、同実現した かっていうと、ギターップのAPIを使って、そのランチ目のリストを全部設置して、 その中から1番そのリリーススアシュ。あし、あの質が新しいものを自動的に探して、
he.shuangbing
そのままデプロイするようにしたっていうのは、あの観略がですね。ま、 これを入れてからは、そのデプロイする時は、もうビスブランチのしてはしなくても、そのままボタンを押すだけで、ディプロイできるように あったっていう感じです。
@spring_raining
ああ、なるほど、ありがとうございます そういうあれですね、細かい多分、どこのプロジェクトでも、こう必要に迫られて作ったりとかしますよね。あの、うちのオフィシャルアカウントでも、 プロジェクトの同じような流れをこの前体験しましたね。そのこのブランチから、このブランチに
@spring_raining
ま味をしたら、このリリースのciが走るっていうところとかはまああるんですけれども、結構その 最近、そのちゃんとリクエストに対して、あのアプリーブしないといけないというところとか、ちゃんとしないといけないというところもあって、結構その なんですかね。これ、あのレプロイのためのアップルのやり取りが何回も起きるみたいなところが。はい、
@spring_raining
うちのプロジェクトでもあって、そこの辺りをトイトのメンバーの1人が開発をされたりっていうところとかで、めっちゃ共感しましたね。
he.shuangbing
そうです、なんか、こういう細か細かいところで、なんかちょっとしたストレスが溜まると、ちょっと直したい気持ちはなりますね、
@spring_raining
わかります、はい、そうですよね、あの、ちょうど そういう話をしたポットキャストのかすいません、昔のポットキャストの話ばっかりなんですけど、も、 エピソード96のあのところで、あの、zxっていうツールを紹介して
@spring_raining
たことがありまして、これ、あの、そのjsでそのシェルスクリプト風の スクリプトを書くみたいなライブがあって、結構そういうのを個人的には活用したりとかしてて、シェルスクリプト よりも安全だけれど、もしリスクリストほど柔軟に使えるみたいな。そういったのは結構
@spring_raining
使えるなっていうのは、個人的にはありますね。あと、あれですね、ギッドハブpiとかも結構その他の そのciのツを見ながら、自分で開発するみたいなことが多くて、結構その場限りみたいな感じだったんですけど、 どうですか。結構ツールとかの開発とかは、気づいた人がやるみたいな感じになりがちなんですけれども、
@jaycompsci
ハイニュースでも、シェルスクリプトが好きな人が何人かいて、はいで、他の人はあんまり書いたことないとかってことはありました。
@spring_raining
そうなんですよ、シスープとそうなりがちですよね、
@jaycompsci
zxとか今ちょっと見てみたんですけど、これとか使ってみたいなって思いました。googleのやつですか。
@spring_raining
あ、そうですね、はい、結構シックスクリフトって、あのかける人が限られがち になってしまうっていう。フロントエンドエンジニアだと特にそうなんですよね。結構そのサーバーサイドエンジニアだと、 そういうの活用するっていうのが、まあ割とキル的に求められるんですけど、不安編で、時代だとなかなか
@jaycompsci
あれもありますしね。ノードのスクリプ、
@spring_raining
はいはい、
@spring_raining
あれとかで、なんかちょちょっと生えちゃったりしてしまいがち、リスリフト力が多分弱い。私もそう思います。
@spring_raining
そういった面で、ジェットは割とすすめですねフロントで、トにはには特に。
じゃあそうですね、割と言い出しっていうか、解決しがしっていう弊害のところのところに行って、ちょっと LINEnewsのチームに聞きたかったところで言うと、結構その
@spring_raining
こういう改善って、大体自分がここよくないなと思って。はい、自分で直しました。みたいな感じになってしまいがち なんですけれども、そことかって、LINEnewsのチームではどうしてるのかなって思い、
@jaycompsci
確かに、そういう細かい便利機能に関しては、え、やりたい人がやるってことが多いですね。
he.shuangbing
そうですね、
@jaycompsci
うん。ただ最初に話したんですけど、いくつかのチームに分かれて開発を行っていて、 で、以前は改善チームっていうチームがあったりとかで、今は僕と小原さんの2人で、 その開発チームに所属しないチームを作って、トラテジックでベロップメントチームって、自分たちが呼んでいて、
@jaycompsci
かっこいい。ここは戦略的開発なので、あの長期的に。
重要だけど、緊急性がなくて、え、あんまりちゃんと やってこなかった。そのパフォーマンスだったりとか、テストだったりとかをやっていくチームっていうのを作って、今やっています。
@spring_raining
なるほど、ストラリジック、ディビルップメントってめちゃくちゃかっこいいですね。
@jaycompsci
ちゃんと名前をつける話をちゃんと最初にして、色々候補をたくさん出してきました。
sdチームとかって、略されてますけど、
he.shuangbing
あと、なんかあの影響がひそうな改善の案は、あの、毎週の月曜日の振り返りの時に、なんかみんなで話し合って、 そういうのを誰かやるとか、どのチームでやるみたいな感じで決めてるのもありますね。
@spring_raining
なるほど、水曜日そうですね、水曜日にあのモブプロをしているという話もさされてて、やっぱり結構そういうの。
@jaycompsci
LINEnewsでは、月曜と水曜日にこう開発イベントがあって、 水曜日はモブブロ、月曜日は1時間。も、バトルグラウンドって呼んでま。意見を戦わせるっていう意味で名前つけたんですけど、ま、そこで、 今管理してるのがキッドハブの
@jaycompsci
なんでしたっけ。トレロみたいな機能カードを作ったりとかできるやつですね。で、ま一周を作って、やりたいことを並べてったりして、 で、集まった時に定義してでやるって決めたら、どのチームがやるとか、優先順位決めたりとかしてやってます。
@spring_raining
まあ、でもなんかあれですよね、こう地道だけど、大事なことばっかりですね、そう、そういうところで、ちゃんとその機能かいやつだけじゃなくて、改善の タスクもちゃんと割り振れるっていうのは、いいチームだと
@jaycompsci
思いますね。多分やってないと、もうほんとに複雑性が爆発してしまい、 大変なことになるので、ある程度のリソースはこういうことについていかないと、結構辛いことになります。
@spring_raining
や、おっしゃる通りだと思います。
@jaycompsci
それと、テスティングライバリーの話だと、LINEにはあの デベロップメント、プロセスレギュレーションズっていう、あのプロダクト開発で守るべく共通の開発規定が定められていて、8つぐらいのカテゴリーの中に テスティングバデベロッパーズっていうのがあって、まあ、テスト自動化しなくちゃいけなくてっていうのがあるんですよね。はいで、LINEnewsでは、あの、
@jaycompsci
その中でも必須とされているところは満たしているんで、最低限のテストが書かれています。例えば、ユーティリティ には必ずテスト書くとか。ただし、あの、それ以上は結構できてないっていう課題があって、 まずテスト思想について統一させることによって、
@jaycompsci
あの最終的に求める形っていうのがに近づけるんじゃないかなと考えました。で、 ユニットテストっていう思想と統合テストっていう思想でま統合テストというか、まあい、ファンクショナルテストですね。
ていう思想は結構対立すると思うんですけど、ユニットテストは関数だったりとかに直接テストを書いていくで、ファンクショナルテストっていうのは、
@jaycompsci
名前がちょっとややこしいんですけど、ファンクションていうのは機能の方ですね。機能、例えば、ユーザーがボタンをクリックするとか に対して、その振る舞いに対してテストを書いていくっていう方で、で、あのリアクトンにも、あのテスティングライブよりのリアクトラパ があって、リアクトテスティングライバリーっていうのは、結構リアクトの世界ではまあまあ人気が出てきてて、それを導入することを提案しました。
@jaycompsci
いいところ、悪いところを説明してで一貫させることが結構大切。その複数の思想があって、 みんなが自由にテストを書いていくよりも、1つの思想に基づいて 進めていく方が、プロダクトのテストっていうのは、全体を網羅できるので、そこを統一するってことが大切だと
@jaycompsci
考えました。で、それでリアクトテスティングライバリーを 実装するのをチームとしてやっていくために、勉強会を何回かに分けて、僕がやって でなんだろうな。まあ、最初はスライドからで全体に説明して、そのあとはまあ、実際にコードをライブコーディングみたいので、書きながら
@jaycompsci
説明していったりとかってことをして進めてきました。で、結構あのテストに関することって議論が終わらない と思うんですけど、そこの議論の沼にはまらないように、あの 早めに統一しようと思って一応進めました。それで、今は結構ディアクト、ディスティングライバルで、
@jaycompsci
ファンクショナルテストを書いているエンジニアが増えてきています。
@spring_raining
おお、なるほど、ハンズオンのところからやるのっていうのは、大規模な
@spring_raining
大規模、大規模、大規模言いすぎですね。でも、でも、そういう多人数でのテスト開発っていうのは、そういったところのコストとかも かかってくるんだってのはありますね。うん、テストは割とそうですよね、そういうなんて言うんすかね、思想ではないですけれども、やり方というか、方針が人それぞれみたいなところもありますし、
@jaycompsci
テストの経験がみんなバラバラで、はいは過去に所属してきたチームとか、組織とかで、全然違うやり方でやってきていることが多いので、 統一されてないことが多いかなと思います。
だから、みんなでテストをこうどういうテストを書けばいいのかってことを話し合ったときに、いきなり一致するってことってほぼなくて、
@jaycompsci
大体いろんな多様性のある意見が出てくるっていう印象がありますね。
@spring_raining
いいですね、対応性
@jaycompsci
なので、結構誰かがこうリーダーシップをとって、まとめないと、ずっと議論が終わらないままで進んでいってしまうのかなと思ってます。
@spring_raining
ああ、なるほど、
@jaycompsci
テストに関しては特にそうです。
@spring_raining
そうですよね、ユニットテストだと、ま、これは普通にカバレッジをあげるで大丈夫ではあるんですけど、
@jaycompsci
結構から字でもみれ見ていけるし、全ての関数とか全ての分岐 ミテストを書いたとかってやると、まあ書いたことにはなるから、それで、なんかそれが好きっていう人もいるかもしれないんですけど。
ま、カレチを上げることは本質ではないので、何が目的なのか、
@jaycompsci
何が音質なのかっていうことを考えた時に、ユニットテストを選ぶべき状況っていうのは限られてくるのかなと思ってます。っていうのは、その ファンクショナルテストで、全体にテストを書いていっても、ユニットテストを全く書かないわけではなくて、あ、ユニットテストを選択するときもあるので、 その辺がなぜユニットテストなのか、なぜファンクショナルテストなのかっていうのも
@jaycompsci
理由が、説明できたりとかわかっていくと、あ、色々迷わなくなってくるのかなと思って
@spring_raining
理由ですか。そうですね、なんか、どちらがどちらかだけでもダメですし。そうですね、特にファンックスナル テスティングだと、カバレッツっていうのは、あまり
@jaycompsci
っていうのは、あんまりカバレッジも本当に100パー、例えば、100パーセントのカバレッジとしても、それが本当に100パーセント変わって、 実は言いきれなくて、純正関数じゃない関数にテストを書いてで、その関数の中の分岐全部を網羅したとしても、 その関数が他の関数を使ってたりとかして、
@jaycompsci
純粋じゃなかったりすると、実はそれカバーされてないって話になるんですよね。
だからだったら、もう関数にテストを書くっていうことよりも、あの機能ごとに書いていくっていうことでいいんじゃないかなっていうのも、まあ、1つの主張として言えるし ていう議論が色々あるかなとは思います。
@spring_raining
奥が深いです
@jaycompsci
多分その辺になってくると、関数は純粋であるべきかみたいな。
はいはい、話に最終的に行っていったりするのかなと思いますね。ユーティリティ関数は、必ず純粋関数でなければならないし、とかっていう話になっていくのか。
@spring_raining
はいはい、これはあれですかね。テスト会をもう1回
@spring_raining
あ、でもそういう議論を行える環境っていうのはいいですね。そう思いますじゃあ、 もし今まだここ困ってるみたいなところとかで改善したいこととかってあったりしますか。
5. 今後取り組みたい改善
he.shuangbing
最近で言うと、あの先ほどのテストと関連してるんですけど、なんか、この前、チームメンバーがテストの優先順位表が 作っていただいて、結構最近はその優先順位表を見て、テストをカバーしてないところで、あ、テストを書いたりとか と。最近なんか、ストーリーブックの導入もなんか進行している感じですね。
@spring_raining
はいはい、あ、なるほど、ストリックを結構既存のプロジェクトにど導入するには、結構力が入る作業ではあるんで。
he.shuangbing
そうですね、
@spring_raining
割とまでもあると便利っていうのはありますねこさんは、何かあったりしますか。
@jaycompsci
そんなに言いたいみたいなのはないですかね。
@spring_raining
それをもう普段からこうちゃんとストラレち
@spring_raining
としての活動をされているかといういや、名前がか使いたい。
@jaycompsci
あの、まあ、名前は結構あのモチベーションに繋がったりするんで、大切ですよね。
@spring_raining
そうですね、
@jaycompsci
はい、プレイブックっていう名前とか、バトルグラウンドとかも全部僕が名前つけてるんで。
@spring_raining
あ、そうなんですね、
@jaycompsci
名前をつけるのが結構好きです。
@spring_raining
じゃあ、ちょっと今度かっこいい名前を
@spring_raining
プロジェクトを作るときに考えてもらいたいです。
@jaycompsci
相談には
@spring_raining
お願いします
@jaycompsci
でも、UITensidもかっこいい名前ですよね、
@spring_raining
そっか、そうですUIT INSIDEは誰なんですかね、ポテトのかかさこさんか、どっちかだと思うんですけど、 私は入社した時には既につけられてて、連れ去られた記憶しかないですね。そうですね、多分どちらかだと思います これはあれですかね、小ノートに名付け用を書いときます。
6. クロージング
@spring_raining
今回はえ、LINEnewsフロントエンドチームに。改善の話を色々と聞いてきました。
ラインのフロントエンド組織uytでは、このような技術的なキャッチアップをひ行っております。
UITサイト以外にも、毎週の車内勉強会で、フロントエンドの情報交換を行っています。
@spring_raining
今後も、UIT INSIDEを通して、このような情報を外部に発信していけたらと思います。最後に、 現在ラ株式会社では、インターン中途作業ともに大募集しています。
このポッドキャストを聞いて、第2丁を持たれましたら、正のと1番下にある9人ページからぜひアクセスしてください。
@spring_raining
それではありがとうございました、ありがとうございました。
