More than 1 year has passed since last update.

ゆめみさんのインターンでモブになってきた話

Last updated at 2022-08-28Posted at 2022-08-25

先日の8/20 (土)、株式会社ゆめみさんのフロントエンド1dayインターンに行ってきました！

インターンではモブプログラミングを行いました。本記事はその記録になります！

筆者について

就活中の大学院生(M1)
Rust大好き(記事には関係ないです)

対象読者

ゆめみさんのインターンに興味がある方
モブプログラミングって何？どうやるの？という個人開発者

どちらにも当てはまる過去の自分宛てに残すイメージで書こうと思います！

株式会社ゆめみとは？

ゆめみさんは「BnB2C(ビーアンドビートゥシー)」というビジネスモデルで他社の内製化支援やインターネットサービス開発協力を行う、「アウトソーシングの時代を終わらせる」ことをミッションとする企業です。「『働く』意味を問い直し、組織のひずみをなくす」という目的を掲げており、「全員CEO」や「給与自己決定制度」等大胆な制度があるちょっと変わった？会社です。詳しくはゆめみは成長環境しか提供できません。（会社紹介・採用ピッチ資料）｜Ray Kataoka｜note という代表片岡さんのnoteを読んでみてください。

Qiitaによくアクセスする読者の方ならば「無職やめ太郎( @Yametaro )さんが所属する会社ね！」とご存知の方が多いかもしれません(何より私もやめ太郎さんから知りました)。やめ太郎さんは関西型言語を用いた対話形式の記事で有名です。やめ太郎さん以外にもたくさんの方¹が記事を出しています。

筆者が好きなorお世話になった記事抜粋

その他ゆめみさんの変わった点としては、公開できる限りの社内の多くの情報(規定とか)が 公開されている ことです。ゆめみさんに行きたいなと思った理由の一つとしては、公開情報のお陰でどういう風に働くことになるのかが他の企業よりはイメージしやすかったからというのがあったりします。

モブプログラミングとは？

自分はモブプログラミングはおろかペアプログラミング等も行ったことがなかったためインターン前に少しだけ調べてみました。メルカリさんのブログが読みやすかったです。

3人以上で 1つのコンピューターの前に座って協力して行う。分担は以下
- ドライバー(タイピスト): ナビゲーターのアイディアに従い、実際に手を動かしてコードを書いていく人
- ナビゲーター(残りの人): タイピストやそのほかのナビゲーターに問題解決のアイディアを説明する人(つまり横からやいのやいの言うモブ)
ローテーションを組んで行う。大体10～20分ぐらい経ったらドライバーが他のナビゲーターに順番に交代します。
モブプロを始める前に実装の手順を予め共有しておく: 大きな間違いとかがないよう、そして効率的に進めるため

太字にしたところがモブプロの特徴です。「なんでモブプロするの？」って部分が気になる点だと思います。先にあげたメルカリさんの記事では「リソース効率」と「フロー効率」という概念を用いて説明されており、簡単にいえば1つの機能実装にみんなで取り掛かることにより分担した場合よりもその機能を素早くリリースできたりすることに恩恵があるようです。この説明だとピンと来ないかもしれないですが「すぐ相談できるので1人でウンウン悩む時間がなくなる」みたいなイメージが近いかなと思います。1dayインターンでもそれを感じるシーンが多かったです。

実際に今回のインターンで行ったモブプログラミングの様子はモブプログラミング実践の節にて説明します。直下じゃないのは記事の流れの都合ですｽﾐﾏｾﾝ ><

が、インターンを通して感じたメリット・デメリットは先に書いておきます²。メリットについてはメルカリさんの記事の引用的な部分もあります。(つまり実際に体験できたメリットといった感じです)

メリット

悩む時間や手が止まる時間が減った

上述したメリットです。すぐに相談できるので無駄な時間が少なくなります。手が止まっている時間は、ナビゲータがアイディアを説明している時でした。1人で開発するときはコードを書くために「虚無の時間」が必要がちですが、モブプロでは一定の集中があるため、虚無の時間もなくなりました。

知識を全員で共有しながらコーディングできる

これが一番大きいものでした。細かく分けると以下のようなメリットです。

他の人のお陰で色々得られる・助けられる
- 新しい知識
- 自分では気づけない解決方法の提示やミスの発見(今回実際に救われました)
すぐにフィードバックが得られる
- 正しい書き方であるかやわかりやすい書き方かがわかるので自分の書き方が矯正される(特に変数名とか)
コードの属人化を防ぐことができる
- コーディングの引き継ぎ等の問題なども解決できます

チームに一体感が生まれる

ただし「型にハマった」場合です。ある程度お互いを知っているか、技術力が同程度なら、いろんな話題で盛り上がれたり、みんなでタスクをこなせた達成感で、仲間意識が深まります。吊り橋効果みたいな感じでしょうか？

型にハマらなかった場合は後述するデメリットが発生する可能性があります。技術力に差がある場合、できる人はできない人が嫌な思いをしないような言い回しや立ち回りが必須になるでしょう。ただ立ち回りに自信があるならむしろアイスブレイクとかに取り入れるのはありかもです。(ゆめみさんもそれを狙ってインターンに取り入れてそうな気がします)

デメリット

「精神的には結構消耗する」

↑ 色々考えましたが一言にするとどれもこれに尽きるかなと思います。具体例は以下です。

常に一定の集中・緊張状態

常に人に見られているというのはすぐ思いつくデメリットです。これは手が止まる時間が減ったメリットの裏返しになっています。仕事した気分にはなれるのでメリットと捉えられなくもないです。

適度に休息は挟んだほうがいいでしょう。

気を使う

例えば上司と部下でモブプロすると、忖度などが生じてうまくいかないと思います(要出典)。ゆめみさんでは上下関係みたいなものはない(らしい)ので、ゆめみさんにおいてはモブプロはかなり有効な手段でしょう。しかし、技術力の差が大きい場合も意見に偏りが出たり初心者が圧を感じてしまう等の問題が起きそうな感じでした。上司であったり、技術力がある人はその辺りを意識しながら発言に気を使う必要があります。つまり誰かしらは疲れます。

人間関係に影響がありそう

「気を使う」とほぼ同じです。気の置けない³、別に今更何言ったところで大して関係が変わらないぐらいの友人とモブプロするならすごく楽しいでしょうが、まだあんまり打ち解けていない人と行うとコードを媒介に間接的に相手をディスってしまったりする可能性があり、人間関係にダメージを与えてしまう可能性が少しありそうでした。

以上メリット・デメリットより、あくまでも個人的に思うところとしては、プロジェクト立ち上げ時や新機能実装を始める時にはモブプロはとても効果的に感じますが、精神的な疲弊を考慮すると、毎日行える手法というわけではなさそうです。ここぞというところに使ったり、一定のインターバルを置いて行ったりすると効果的かなと思います。

あとデメリットについては「モブプロができるぐらいの仲間意識がないのにプロジェクトがうまく行くわけないよね」という視点で見ればモブプロが一種のバロメータとなっているのかもしれません。

ゆめみインターンの流れ

ここからはフロントエンド1dayインターンについて参加経緯から当日の様子まで順にまとめて行こうと思います！ここまでの内容とは異なり、日記というかポエミーな個人的な感想とかが多く含まれてくるので読みにくいかもしれませんが、それはご了承ください。(大事なことはここまででモブプロ実践以外話したはず...)

インターンタイトル「伸び代しかないコードを一緒にリファクタリングしよう」

今回の1dayインターンは、予め用意されたRESAS APIという各都道府県の人口を取得できるAPIを用いたReactプロジェクトのソースコードをモブプログラミングしながらリファクタリングしよう！という内容でした。

Reactの開発経験が条件で、参加するには「自信作のReactリポジトリを提出して応募」する必要がありました。

で、自分はJavaScriptにはちょっと自信があったのですが、実はReactもTypeScriptも全く書いたことがなかった⁴ので、今回のインターンに参加するためにちょっとした作品を作り、それを提出しました。以下にダイマさせていただきます()

N=1なのでどれぐらいのレベルのものを提出すれば通るのかわからないですが、ゴリゴリにReactが書ける必要があるかと聞かれると、フロントエンドの基本的な知識さえ揃っていれば別にそこまでReactに強くなくても大丈夫なんじゃないかなと思います。

インターン参加決定

無事に書類選考が通りました！別な企業のインターンには落ちてしまっていて夏休みが虚無になりそうだったので、めちゃくちゃ喜びました。

参加表明はゆめみさんのDiscord鯖に参加し、「自己紹介」することで行いました。

ゆめみさんでは主にSlackを活用しているらしいのですが(曰く、日本一使っているそうです)、流石にインターン生をSlackに呼ぶわけにはいかないみたいです。DiscordにはZoomのような画面共有機能付きのビデオ会話機能も付属しているので、Discordが一番便利だったのだと思います。

参加時、Slackメイン、Discordサブという構成で大学時代に所属していたゲーム制作サークルを思い出しました...新歓イベントにうちのサークルでもDiscordを使用していました。ノリも少しだけ近かった気がします。Discordの空気感の影響でしょうか。1, 2週間ぐらい前からチャンネルが既に動き始め、インターン生の自己紹介を中心に、たまにゆめみの方が書き込んだりして、本当に新歓でも始まるのではないかという感じでした。

インターン当日

インターン当日です！ゆめみさんはフルリモートなので、インターンもDiscord上でフルリモートで行いました。

当日は以下のタイムスケジュールで進行しました。

時間	min	場所	内容	詳細
- 11:00	-	全体	チェックイン	「今の気持ち」をチャット欄に書き込んでDiscordのボイスチャンネルに参加
11:00 - 11:10	10	全体	オープニング	インターン説明
11:10 - 12:00	50	全体	全員自己紹介	1 人 1 分目安だったのですが皆さん張り切っており少し押しました
12:00 - 13:00	60	チーム	`実装`	課題リストアップモブプロする
13:00 - 13:10	10		ランチ準備
13:10 - 13:50	40	全体	ランチ	3 グループに分かれる
13:50 - 14:00	10		小休憩
14:00 - 15:10	70	チーム	`実装`	モブプロする
15:10 - 15:20	10	チーム	小休憩	適宜小休憩
15:20 - 16:30	70	チーム	`実装`	モブプロする
16:30 - 16:50	20	チーム	共有資料作成	Draft PR を作成して PR テンプレートの項目を記載。
16:50 - 17:30	40	全体	最終共有	各チーム 5 分程度
17:30 - 17:55	25	チーム	振り返り	(10m)個別に振り返りを書く (15m)チーム内で共有
17:55 - 18:00	5	全体	クロージング

色々書いていますがほとんどがモブプロの時間でした

インターン説明

会社説明と本日のインターンの心得等の説明でした。

よく印象に残っている心得は2点です

楽しみましょう！: 特に今回はリファクタリング対象となるコードをよく味わいましょう！とのことでした。
禁止ワード「クソコード」: 今回のリファクタリング対象コードをクソコード呼ばわりするのはやめましょう！とのことでした。
- 「伸びしろがあるコード、ノビコード ~~(スパゲティの麺かな)~~ 」、「美しいifのネストだ...」等、表現するにしてもマイルドにしましょうということ
- 「コードを恨んで人を恨まず」。先程モブプロのデメリットで「コードを媒介にして相手を否定してしまう」という内容を書きましたが、それを回避しようという意図も含まれていたのだと思います。クソコードという単語はたしかにコードを貫通して相手をディスってしまいそうです。

自己紹介

Discordに記載した内容をもとに全員が自己紹介を行いました。面接での自己紹介と違って、予めお題が用意されていたので皆面白い自分語りができており、この時点ですごく楽しかったです。

自己紹介のお題例

好きな食べ物
好きなOS
好きなHTMLタグ
きのこ派・たけのこ派⁵

時に好きなOSの質問についてですがフロントエンドはMac OS率が異様に高かった気がします(自分は基本Windows+WSL2派でこちらも一定数いました)。バックエンドとか他の界隈だとどう答えるのか気になる質問です。

自己紹介が終わったタイミングで今回のインターンを記事にして良いかの質問をし、許可を得ました。(自分の気を引き締めるためだったり)

モブプログラミング実践

いよいよチームに分かれてモブプログラミング開始です！自分のチームのメンバーは自分とインターン生もう一人(以降M君と呼びます)と、そしてメンター役のkeeth( @clown0082 )さんとつつい( @cubenoy22 )さんの計4人でした！ローテは自分、M君、メンターの方々(2人で一枠)と決まりました。

ところでそういえばモブプロって3人以上で「1つのコンピューターの前に座って」行うんですよね？フルリモートだとどうやるんでしょう？

自分のチームでは幸いなことに全員がVSCodeを使えたので、始めにVisual Studio Live Shareという拡張を入れ、Google Documentと似た感じで一つのマシン上のドキュメントを編集する形で進めようとしました。

しかし、複数人で同時に編集すると、差分だけ同期されるわけではなく全体が同期され、書いたところが消されてしまうということが相次ぎ、ドライバーのみが編集した場合もそうだったので、もう少し単純なGitHubを使用する方法に変えました。以降ずっとドライバーが以下の流れを繰り返します。

[最初のみ] GitHubリポジトリを用意する・専用ブランチを用意する
- ローテを回す前に課題リストアップをしました。後述
リポジトリからプルする
- バカ避けのためにドライバー交代時にプルするところから見せるようにしていました
10～20分、あるいはキリが良いところまで、ナビゲーターのアイディアに従い、あるいはナビゲーターに解説しながらコーディングする
動作確認
- 今回テストは時間の都合上書かずに進めたので、意図通りに動いているか確認しながら実装しました。
時間になりコーディングが完了したらプレフィックス+タスク名でコミットメッセージを入れてコミット・プッシュする
ドライバーを交代して2.に戻る

GitHubリポジトリを分けてフォークしてプルリクという方法もありそう⁶ですが、そもそもレビューしながらコーディングしているわけですし、スピードを考えると上記手順が良さそうでした。

画面共有はDiscordの機能を使いました。

課題リストアップ

モブプロを始める前に、一番最初に

何をリファクタリングするか
どの手順・優先順位でリファクタリングをするか

をはっきりさせる必要があります。モブプロをする過程で多少変えるのは構わないのですが、ここを最初にはっきりしっかり決めておくことで、実際にコーディングしている最中にて「このタスクが後に控えてるからここを先にやっておかないとorここは後に飛ばせる」という感じですぐに方針を相談したり変更したりできます。

面白かったのは、今回のReactプロジェクトでは「APIキーがGitHubで公開されている！！！」⁷という伸びしろ以前の伸びしろ(もはや脆弱性)があったのですが、僕とM君は2人とも真っ先にそして同時にAPIキーの分離をリストアップした⁸ことでしたw

妙な一体感が生まれてスタートダッシュから好調でした

2人のリストアップが終わった段階で話し合いをし、共通したものなどを抽出してmust, betterのように優先順位をつけました。

コーディング

ローテを決め課題リストアップが終わったらいよいよコーディングです！

prettierの設定等で環境ごとの差異があったため、最初は結構あたふたしながらやっていました(自分はyarnコマンドを最初に打つ前にコーディングを始めてエラーが表示されまくったり等(笑) )が、慣れてくると各々自分が得意とする領域についてナビゲーターとなり解説をしながら実装が進んで行きました。

手順としては先程述べた通りで、「プルする → コーディングする → 動作確認 → コミット・プッシュする」の繰り返しです。自分はドライバーを3回ほど担当してそこで終わったので、3時間で2, 3ローテ回ったことになります。熱中したこともあり少し時間をかけすぎてしまったかもしれません()

その他コーディング作業中に得られた新しい知識等はAppendix: 新しく学べたことの節でおまけとして記載しました。

昼休憩

タイムテーブルに「ランチ」があり、「え？リモートでランチ会？」と驚いたのですが、本当にリモートでランチ会でした。ご飯は自分で用意してモブプロのメンバーとは別なボイスチャンネルに分かれてランチ会です！

運良くやめ太郎さんとご一緒できました！食事の合間に僕を含めたインターン生が質問攻めをします、(ちなみに関西弁ではなかったです)。

Q. 「チームの規模はどれぐらいですか？」
A. 「チームによるで！各役職に1人ずつのところもあれば、一つの役割に5人以上のところもあるで」

Q. 「フルスタックに働く人はいますか？」
A. 「フルスタックかどうかはわからへんけども、時期によって別界隈のプロジェクトに移る人はおるで！」

Q. 「インターン開催に関するアレコレもプロリクで決めてるんですか？」
A. 「せやで。今回はワイではなくてすずき( @taka10257 )さんが取りまとめているで」

Q. 「他社だと部長になりたい・課長になりたい、みたいな目標がありますが、ゆめみさんの場合はそれに代わる目標はどのように立てればよいのでしょうか？」
A. 「職位ガイドラインや星取表を参考に自己給与を決定するから、これを目標とするとよいで！」

Q. 「Rustのプロジェクトってありますか？」
A. まだ発展途上らしいけど動きはあるらしい⁹

僕はこの内一つしか質問してません(どれでしょう？)が、皆さん結構踏み込んだ質問をされていて興味深かったです。

この他にも「いきなり意見するのではなくて相手を肯定し良いところを挙げてから」といった人間関係の話や、SlackチャンネルにTwitterみたいに自分のことを呟けるようなチャンネルが各自一つ与えられるなど、面白い話を聞くことができました！

ちなみに自分はコンビニで買ったを食べていました

終盤・発表

昼休憩後も休憩前と同様にモブプロをしていきました。モブプロ自体は16:30まで続け、最後にブランチ全体の変更をプルリクとしてまとめ、そこにモブプロの振り返りとして

出来たこと
出来なかったこと
モブプロの感想

をまとめて、Discordの全体ボイスチャンネルにて発表しました。

他のチームの発表は、「やっぱそこ直すよね」というものが結構多く安心した一方、「それは知らなかった...」(主にReactの経験差)というものもいくつかありました。今回CSSのリファクタリングに全く着手出来なかったのですが、そこを直せているチームがいてすごいなと思うなどしました。

発表後、改めてインターン全体の振り返りをチームで共有し、インターンはクロージングしました。

インターン反省点

残り30分ぐらいで自分のドライバーの番が回ってきたのですが、ここで無理をしてしまった結果、モブプロの形を維持できずさらに最後にバグを発生させてしまい、色々躓いてしまいました。「モブプロ形式だったのにも関わらず自分勝手な行動をしてしまった」ことが原因です。モブなのにスタンドプレーしちゃったわけです。

終盤で失敗してしまった点をまとめます。

どうしても直したい箇所と思い無理して着手した
- 他のメンバーを置いてけぼりにしてしまい、モブプロの良さである 「知識の共有」を完全に台無しにしてしまった
- どうしても直したかったならば理由をしっかり説明し、優先順位をあげてもらうべきだった
- おそらく通常のモブプロでは中途半端でも知識共有を優先し後日に回すなどしそう、あるいは分担を決めるなど
最後でバグを出してしまった
- 残り時間的にバグが出たら取り返しがつかないのに、自信過剰な行動をしてしまった
時間を過ぎてしまい、最後にドキュメントを作成する時間を削ってしまった

最後に出してしまったバグはなかなか興味深いものだったため、近日中に単体記事として別にまとめる予定です。↓ ちなみに気づいたのは僕ではなく別な方で、モブプロのメリットに救われました。

(TODO: Highchartsに関するバグをまとめ、ここに記事URLを載せる)

話し合い、大切ですね。。インターンの趣旨は「完成させること」ではなくて「モブプロを楽しむこと」だったので、それを踏まえ、直したかった箇所に取り組むにしてももうすこしモブプロにあった方法を取るべきでした。

ちなみにドライバーはあくまでもナビゲーターのアイディア通りに書かなければならないことを原則とするべきというモブプロのやり方もあるそうです。そういう事情を鑑みても、最後の30分にやるべきだったのはやはり、ナビゲーターの説得であり独りよがりのコーディングではなかったでしょう。

全体の反省点としては、M君やメンターの方に対して気遣いできていたかなーという部分が反省点というか次回があるならもう少し気をつけたいなと思った点でした。

まとめ・所感

以上、ゆめみさんのインターンとモブプログラミングについてまとめました！Reactにしろモブプロにしろ学ぶことができたきっかけは本インターンでした。インターンはあくまでも就活のためのものかなと思っていた時期もありましたが、普段知ることができない知識を得たり、新しいことを実践できる機会であり、振り返ってみると、技術的に得られたことがたくさんありました。

心得であるところの「楽しみましょう！」については、同年代の方と技術的な会話をするなど新鮮な経験ができ舞い上がって本記事を書くに至ったわけですから、十分達成できたと思います！最後は反省点が多めでしたが、そのおかげでモブプロに対する解像度も上がったのでとても満足しています。

たった1日のインターンでしたが、「実際に入社したらこんな感じなのか」とある程度想像でき、ゆめみさんの雰囲気を感じることができました。

貴重な体験をさせていただいたゆめみさんに改めて感謝します。そしてここまで読んでいただきありがとうございました！m(_ _)m

Appendix: 新しく学べたこと

この節は自分のための備忘録です。おまけなので軽めです。「こういう話したんだ～」みたいに感じてもらえれば幸いです。そんなのも知らずにフロントエンドできるって面してインターンに臨んだんですか？！って項目がいくつかあるかも()

Prettier

フロントエンド用のコードの自動整形ツール(コードフォーマッタ)です。リンターとは別物。自分はリンターで満足してしまっておりPrettierを使ったことがなかったので、M君からその存在を教えてもらいました。(Rustだと似たようなもの入れてるのになんで存在に気づかなかったんでしょうね() )

Prettier 入門～ESLintとの違いを理解して併用する～ - Qiita
VScodeのprettierが効かない時の対処法 - Webis Tech LABO.
- なんか拡張入れただけだと動かなかったのでここにお世話になりました
- デフォルトにするのが嫌な場合[typescript]や[typescriptreact]に移すことでも問題ありませんでした

コードを整えることは可読性向上につながることは言うまでもないですが、特にフロントエンドは宗教的な流儀(最後のセミコロンの有無など...どちらかと言うと私はつけるタイプです)がいくつかあるので共同開発するときには必須なのかもしれません。

今回設定していた項目

.prettierrc.json

{
  "trailingComma": "all",
  "semi": false,
  "singleQuote": false
}

状態管理ライブラリ

今回のリファクタリング対象コードには関係あるデータを3つのステートに分けるというなかなかできない素晴らしい技巧が組み込まれていまして、凡人であるところの我々でも理解できるようにシングルトンパターンになるような感じでステートを一つにまとめました。(シングルトンパターンってフロントエンドでも言うのかな)

その発言の後に「状態管理ライブラリ」の存在を教えてもらいました。軽く検索したところ確かにシングルトンパターンという単語の流れから出てきそうなライブラリです。

ReduxやRecoil¹⁰というライブラリがあるみたいです。Fluxの考えを拡張し扱いやすくした状態管理ライブラリ...らしいですがまだ触れていないのでよくわかってはいないです。

useState等のReact hooksとはやっぱり違うのだろうか...?

`interface`

interfaceは知らなかったわけではないですが、インターンが始まる前に自分はtypeを使って型定義をしていたのに対し、M君はinterfaceを使っていて差異があったために今回のインターンでよく記憶に残っています。

後から違いを調べたところ、拡張性があるかないかが最も大きな違いのようです。名前からのイメージ通りinterfaceは拡張可能な一方、typeは(基本)拡張しないで使うもののようでした。

ただ結局どっちを使うべきかは未だによくわかっていないです。propsや引数を一旦まとめたりするのにはinterfaceが良さそう

Fork.dev

つついさんが使用していたGUIのGitクライアントツールです。インタラクティブリベースという機能を使うとドラッグでコミットの順番を入れ替えたりなど(流石にコンフリクト起こすといつもどおり面倒でした)ができしかもそこそこ高速に動くみたいで、真似して使ってみたいなと思いました。

ただWSL上のリポジトリは簡単には開けないみたいだったのでMac使いの人向けかも

型ガード関数

「APIが返すJSONの型は不明のため、バリデータ書きたいですね」と提案し、フロントエンドにわかな自分は事前にjson-type-validationを調べてきていました。

バリデータの導入までには至りませんでしたが、「型ガード関数」の存在を知るきっかけになりました。バリデータではないのですが、any型をそのまま扱わなくてよくなるためエディタの補完が効くようになって良いです。以下は今回実際に書かれたコードです。

typescript

function isPrefectureResponse(data: any): data is PrefectureResponse {
  if (!("message" in data) || !("result" in data)) return false
  return true
}

本来はdata: anyの引数部分の型をunknownにし、isObjectLike(lodashのメソッドの一つ？)を使って...という感じでもっと厳格に書くものらしいですが、インターンの時間の都合上、また流石にここまで直す場合上述したjson-type-validationを導入したほうが良さそうだったためそこまではやりませんでした。(たぶんこの辺が近い話)

型ガード関数をバリデータとして機能させたい場合引っかかった箇所を出力するようなconsole.log等を途中に挟むといいかもしれません。

カスタムフック

React hooksのうちuseStateとuseEffectしか知らなかったのですが、useStateやuseEffect部分だけロジックとして別なファイルとかに切り出してビューではフックのみインポートする、というようなことができるカスタムフックがあるということをインターンで知りました。

確かにロジックとなるuseStateやuseEffectは肥大化しやすいですし複雑です。次にReactプロジェクトに取り組むときがあれば使ってみたいと思います。

baseUrl

tsconfig.jsonのcompilerOptionsにbaseUrlというフィールドを加えることで、相対パスの記述をbaseUrlに指定した値からの絶対パスにすることができる機能です。M君に教えてもらいました。

例えば"baseUrl": "."とすればプロジェクトルートが絶対パスの起点となり、import hoge from "src/components"みたいに書けるようになります。

今まで自分は別に相対パスでも良いと思っていたのですが、確かに絶対パスのほうがコピペで移動とかしても依存が壊れなくて良さそうです。今後は設定したいと思います。

まとめはどこって？マウスで一気にスクロールしてきましたね？ここはAppendixになります。こちら → まとめ・所感

記事に登場するゆめみの方でQiita上にアカウントがある方はメンションさせていただいています。名字の場合、漢字がわからないのでひらがなで表記しています(たまたまですがそのほうが都合が良かった感じです)。通知が行って申し訳ないです() ↩
スプラ3発売前ということで最近スプラ2にハマってるんですが、実際しっかりチームで連携して1箇所に集中できている時のほうが勝率が高い気がして、モブプロのメリットに近いものを感じたりしています。 ↩
「気の置けない人」という言葉は置けないという否定の影響か、全く真逆の意味の「まだあまり打ち解けていない人」とか、「警戒する必要がある人」みたいな意味になってしまうことがあるっぽいですが、ここでは本来の意味の打ち解けた人という意味で使ってます。なんか注釈しておきたかった() ↩
とんでもなーーーーーくどうでもいいことですがReactは開発元がMeta(旧Facebook)だったためというくだらない理由で避けていた節がありました。VRやってる人とかなら理由をなんとなく察してくれるんじゃないかと思います。Meta好きじゃないです。...触るきっかけをくれたのでゆめみさんにはめちゃくちゃ感謝しています。 ↩
ちなみに筆者はEmacs派と答えて無事浮きました...チョコまじで食べないのでしょうがないよね() ↩
こんなこと書いていますが結局プルリクを使う方法では一度も試していないので比較しておらず、普通にバッドプラクティスかもです。コメントで教えていただけると幸いです。 ↩
90割わざとそのように書いているのだと思います(あと環境構築なしにyarnコマンドですぐ試せるのでそのあたりの利便性の兼ね合いもありそう)。現在はAPIキーは無効化されています。 ↩
リストアップはLive Shareでやっていました ↩
自分へのツッコミ「フロントエンドの方に何聞いてるんじゃ」slackチャンネルたくさんあるそうですし全部のプロジェクト把握するのは普通に難しそうです。ちなみに１０％・２０％ルールというページで20%ルールのほうで優遇されてます...気になる ↩
最初リコリコを連想しました。面白いのでまだ観ていない方は是非 ↩

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up