がんばるぞ

がんばります

知らない技術まみれのチームに移動した時に実践したこと

この記事はスターフェスティバル Advent Calendar 2022 11 日目の記事です

qiita.com

昨日は @shota1995m の オブジェクト指向 UI デザインを読んだから図解してみる でした

はじめに

僕は生粋(?)の PHPer なので、PHP 以外の技術はなんちゃってレベルでしか触ったことがないのですが
知らん言語(TypeScript)、知らんフレームワーク(Koa, NestJS, commander)、知らんミドルウェア(Apache Kafka)、知らんその他諸々(Protocol Buffers, Terraform)を使ってるチームに移動して難易度が高めな課題に取り組むことになったため、効率的に技術をキャッチアップできないと終わると思いヒィヒィ言いながらがんばったことを共有します

やったこと

座学の時間をガッツリとる

まずは手を動かす方が有効な場面もありますが、その技術の設計や哲学、全体像を把握してから実践に移る方がスムーズなこともよくあると思います。
特に今後長く付き合う技術であれば、ドキュメントをしっかり読む時間を早めに取っておくと色々と捗ると思っているので主要な技術に関しては座学の時間を多めにとりました。

ライブラリやフレームワークは、公式ドキュメントをあらかた読み切る

ライブラリやフレームワークはドキュメント量がそこまででもない場合が多いので、主要なページはひととおり全て目を通します。
こういう学習コストが低いものに関しては公式ドキュメントをとりあえず全部読むのは個人的にはオススメムーブです。

言語やミドルウェアなど学習コストが高いものは書籍にあたる

言語やミドルウェアはドキュメントの量が膨大であることが多いので、そういった場合は書籍にあたると重要度の高い情報に絞られていて学習の効率が良いと感じます。
(もちろん公式ドキュメントも読んだ方がいい)

雰囲気でいけそうなやつは後回しにする

キャッチアップしなければいけない技術がたくさんある場合は、優先順位をつけて一部の技術に見切りをつけることも重要かなと思います
Terraform に関しては参考にできるコードが社内に多くあり、かつ既存のコードの枠組みに乗れば十分そう(=新たな設計が必要なさそう)だったため、概要をざっくり把握する程度で一旦 OK としました。

期待値調整をする

自分はこの技術についてどこまで知っているのかをざっくりにでも共有しておかないと、工数の見積もりに悪影響が出たり、コードレビューの前提知識をどこに置くかがわからなくなってしまうため 「この技術のこと、全く知らないぜ！」とちゃんと共有するようにしました。

学習の共有

「今この記事を読んでいる」などを共有することで、知見のあるメンバーから「こっちの記事の方がオススメ」といったアドバイスをもらえたり、自分の理解度が周囲に共有される効果もあってオススメです。

言語仕様に慣れれば、得意な言語と同じくらいの生産性に戻る...わけではない

使う言語を本格的に変えたことでわかったことは、僕は PHP だけではなく PHP を取り巻くエコシステムやコミュニティといった文化にも慣れていたということです。
TypeScript はモジュールシステムなどはかなり体感が違うものの、おおまかな構文は PHP と近く「とりあえずロジックを組み立てられるようになる」というところまではあまり苦労しませんでした。

それでもいくつかのポイントで生産性の低下を感じ、言語だけではなく言語の文化に慣れないといけないということを身をもって知りました。

ライブラリ選定に大幅に時間がかかるようになった

PHP であればこの組織が出してるライブラリは品質が良いということを把握していたり、PSR という安定した抽象に準拠したライブラリであればとりあえずで導入しても乗り換えやすいだとかそういった知識をもとにそこまで時間をかけずにライブラリの選定を進めることができました。
しかし、言語が変わるとそもそもデファクトスタンダードを知らないのでそこから調べたり、デファクトスタンダードがないこともあるので複数のライブラリのソースコードを読んで自分で品質を評価したり、評価してるうちに品質の良さの基準(というか文化?)が PHP とは違うっぽいということに気づいたり(JS はモジュールが状態を持つようなデザインが多い気がする)で、PHP 時代に比べて異様に時間がかかるようになりました。

細かい試行錯誤が増えた

言語仕様とは別に TypeScript らしいコードを書こうとした結果、ちょっとした書き方、モジュール設計のノリ(?)の微調整、ファイル名・ディレクトリ名の命名規則(snake_case, PascalCase)、object にすべきか class にすべきか、などなど、慣れている言語では発生しなかった試行錯誤が自然と多く発生するようになりました。
これによって作業が一瞬止まることが度々発生して集中力に悪影響があったり、細かい部分で全体の統一感がなくなるなどが発生してしまいました。

これまでの経験で活きたこと

知らん技術まみれだったのでキャッチアップにどれほど苦労するのか不安に感じていましたが、いざキャッチアップを始めてみると想像よりスムーズに行ったものも多かったです。

これらの多くは1つの技術を深めに学習していたおかげだったので、深く学ぶことは大事だなと改めて感じました。

PHP などで培われたプログラミング言語の基礎的な知識

PHP から TypeScript への切り替えであれば流用できる知識がかなり多かったので「とりあえず動くコードを書く」程度であれば障害はあまりなかったように感じました（ただし環境構築を除く） Haskell などの純粋関数型言語に切り替わるレベルの変化でない限りは言語が変わっても流用できる知識はめちゃくちゃ多いんだなとわかりました。

  • 構文
  • 式と文の違い
  • 型の知識
    • 主に PHPStan に鍛えられました。PHPStan 最高！
    • PureScript とかを遊びで触ったのも良かった気がする
  • etc

ただ、型システムに関しては TypeScript は PHP に比べてかなり独特なので、型演算周りはもうちょっと学習が必要そうだなとなっています
(が、 Web アプリケーション開発では型パズルが求められる状況はそんなにないと思っているので、のんびり学べばいいかなと思います)

Web フレームワークの知識

今回は同時に 3 つのフレームワークを使えるようにならないといけなかったのですが、PHP のいくつかの Web フレームワークのソースコードを読んだり、個人的にちょっとしたフレームワークを作ったり、オレオレフレームワークの現場でフレームワークレイヤのコードをいじったりした経験があったので
ドキュメントを読んでフレームワークの哲学やリクエストのライフサイクルなどを把握するだけでとりあえず動かすことができる程度には理解が進みました。

おわりに

この記事では知らない知識をキャッチアップする際に僕が意識して実践したことを共有してみました。
中でも座学の時間をしっかり取ったのは一番効果があったように感じています。
目の前に開発タスクがあると焦って手を動かすことを優先してしまいがちなんですが、一回体系的に知識をインプットしておかないと開発スピードの伸びが悪いように感じます。
今回は焦る気持ちを抑えてしっかりドキュメントなどを読んだことで割と早い段階でとりあえず開発はこなせる状態に移行でき、その先の「その言語特有の設計の勘所」のような座学からは学びにくいステップに進むことができました。

まだまだキャッチアップしないといけないことが山のようにあるので、引き続きがんばっていきます！
完！