仕事始まった

今日は久々に仕事が始まった。 フロントエンドの案件でReactをがっつり使うのもなんやかんや1年ぶり

サービスの全体像の把握はただ触るだけだと難しい？

まず、サービスを理解するために仕事を始めた。

サービス自体の概要を理解することは、そんなに難しくなかったりするが具体的にどう言った機能があってその機能をどう使うのかを理解するのは少し難しそう。

と言うのも適当に触ってみるも、対象としているユーザーがどのように使うのかが分からなかったりするし判断しづらい。なんとなくこんな目的で利用ユーザーがいるとわかっても機能を前にしてどんな使い方をするのかが分からない。

その結果、適当に触るだけだと何をさわれば良いのか何を理解できたら良いのか分からず、うまくサービスの理解ができるってわけでもないなって感覚があった。

これは、どうすれば良いのかわかんないけど、とりあえずのユースケースを作ってその流れで機能を触ってみると良い気がする。一般的とか多いユーザーはこう使うみたいな？

結局、最低限の使い方がわかる、サービスがどう言った使われ方をするのか理解できるってところからなのかな。 細かい部分やパラメーターによって変化するみたいなのは別に後ででも良いし流れを理解していればこれはなんだろ、どうなるんだろうみたいなのも気になりやすい気がする。それがないと、何が分からないかも分からず漠然と本当に触ってみたくらいにしかできない。

フィードバックを送るにもそう言ったユーザー目線になりきったものではないため、サービスの機能的な部分やバグなどの抽象的なフィードバックになってしまう。よりよいサービスを作るためのフィードバックをするならやはりサービスを理解することが大事そう。

そこから、タスクを割り当てられて実際にコードを読む中でサービスの機能や仕様を理解していくことになるとは思うが、やはりそのユーザー視点がかけてると新しい機能が来た時に別の仕様や提案と言うのは難しいのかな？

ここら辺はまだ分からないのでやっていくうちに見つけられたらなと思う。 まずは、どう言った画面があって動かすとどうなるかみたいなのを適当に触るだけでも十分理解しやすいのはあるから確かにとりあえず触ってみるも大事。

E2Eテストをしていく場合にもこう言った使われ方みたいなのがあるとE2Eする場合も使いやすそう？

フロントエンドの本読み終えてレビューした

フロントエンド開発のためのテスト入門 今からでも知っておきたい自動テスト戦略の必須知識

この本読んだ。

思いのほかテストについていっぱい知れたし、何よりフロントエンドのライブラリって色々あるんやなって知れて楽しかった。

kindleからレビュー出来るの結構楽かも。保存できなそうなのがビミョいけど。

markdownで書く時にURL入れたら自動でPreviewするzennみたいなの入れたいな。

テストをどこから始めるか

どこからテストを手をつけようか悩む。まずは自分が実装する箇所からって思うが、他にテストがなかったりするとまずコンポーネントが正しく表示されてるかどうかからテストするべきなのかな？

ただ、コンポーネントが大きかったりすると初期化して使えるようにするだけでも大変で少しめんどくさいって思ってしまう。まずは自分が使う部分を小さく分割したりしてからテストしていく形が良いのかな？

どっから入っていくと良いのか悩む。 とりあえず何かしらのデザインパターンに則った上で適切な責務に分かれているかを考えながら実装する際に粒度が大きければ分割してテストを書きつつ一つ一つ潰していくのと良い気がしてきた。

そのプロジェクトではどう言った分け方でやるのか、他にダブっているものや使っていないものを削除したり書き方を合わせるとかも大事かも。

Story作ってコンポーネントにProps渡したりとかで色々試してみるのが楽しそうやなって思ったので一つづつ覚えていきたい。

atomic designとはなんぞ？

atomic designってのは初めて聞いた。 フロントエンドはすぐ変わっていくから大変だよ。。。

templateとorganismとかどの粒度、責務で分けるのかが難しそう。個人的にatomはわかるがそれ以上の要素に関してはどこが境界線なのかいまいち分からん。

しかし、何かしらデザインパターンに従ってるということはプロジェクトに参加した際、どう言ったコンポーネントが配置されているのか設計方法がある程度わかりやすい。

そのパターンや設計を守っていなかったとしても、ざっくりまとまってくれていればどのような意図でそこにファイルを置いたのか、ある程度わかりやすいのは利点な気がする。 不規則にバラバラだと迷路みたいになるし、設計に関してを他に依存している形になっているとその仕様とかは他の人が綺麗に作ってくれるためネットとかでも探しやすいし。

Atomic Designがいいってよりかは何かしらのデザインパターンや設計に乗っといているとある程度当たりをつけられるのがわかったので個人的には良かった。ただ、Atomic Design自体は原子とか分子とか言われても「わかりやす！」とはならんかったな。

まぁ、あとはそう言った設計やパターンはテストも考えた上で作ってることがほとんどだろうからなんちゃって設計するよりも、何か一つ決めてやっていくのが良さそう。

あとNextJSのフォルダ構成、コンポーネントがどのページにあるのか把握できさえすれば、そっから探して見ていけるのは便利。

スプリント

案件ではスプリントを使った開発を取り入れていて、やったことがなかったので正直楽しみ。 スクラムガイドとか、本読んで小さい単位で改善を重ねていったり目標を適切に立てて実現していく力を身につけられると良さそう。

DiscordサーバーでBANした話

サーバーに暴言を吐いている人がいた。注意して治るなら残しておこうかと思ったけど、前も同じことしたし高圧的な態度できてたからめんどくさいし消した。

最初は残す判断をしてたけど、それでサーバーに入ってきてくれてる人がまた嫌な思いしたり、発言する時に心理的安全性を損なうのであればやはり削除すべきなんかなと思ったのでBANした。

聞き方が結構丸投げって感じだったり、相手に対して答えて当たり前自分の意見に従わない人は従わせるみたいな態度でくるとどうしてもそう言う感じになってしまうのかな？

そういう人はこれ読んどくと良さそう。