この記事は「Eureka Advent Calendar 2020」7日目の記事です。
Hi. webチームのspiceです。
昨年から、Svelteというライブラリの注目度が上がっています。
2020年、Svelte界隈で話題になったBytemdを知っていますか?
Bytemdは、byteDance社が作成したSvelteで書かれたmarkdownエディタライブラリです。
単にSvelteで書かれたことだけでなく、UIフレームワークなしでも使うことができ、React向け/Vue向けのバインディングが用意されていることも注目を浴びました。
この記事では、Bytemdを題材に
を探ります。
また、これ以降はSvelte,React,Vueの概要をご存知の方向けの内容になります。
それぞれについて知らない方は、公式サイトなどで概要を把握してからこの記事を読むことをおすすめします。
Svelteで書かれたコードは、ビルド時に全てVanilla JSになります。
ReactやVueで書かれたコンポーネントは、ブラウザのruntime時に、ライブラリを動作させるためのコードが必要になりますが、Svelteの場合はそのようなコードが必要ありません。
例えば、以下のようなSvelteで書かれたコンポーネント、Footer.svelteがあるとします。
この記事は「eureka Advent Calendar 2019」23日目の記事です。
こんにちは!eureka平成最後の新卒エンジニアのすぱいすです。
僕は今年の4月に、新卒としてPairs JP Web Teamにジョインしました。 チームで使われている技術について造詣が浅い中、
先輩社員とのペアプロやPRコメントを重ねる中で多くのことを学びましたが、 振り返ると様々な反省点があります。
この記事では会社に入ってチームに所属したての僕に向けて、
何を意識してエンジニアとして働くべきだったか、 お手紙を書こうと思います。
興味がある方はご自由にお読みください。
手紙ここから
東京の慌ただしい空気には慣れたでしょうか。
慣れない環境の中、日々健闘していることと思います。
さてこの手紙では、新たな環境でエンジニアをするにあたって、意識しておけばよかったことを伝えます。
万人にあてはまる注意点ではないかもしれません。
しかし、僕にとってはいつでも有益なことだと思います。
大きく3つにまとめて整理をしました。
効率良く経験を学びに変えて、エンジニアを続けてほしいと思います。
自分がこれから理解すべきコード/技術の全体像を把握し、
現時点での自分の理解度を意識することは大切です。
知識を素早く身につけるために大事なことの一つは、
「上手く質問すること」
だと思います。
質問によって、自分の足りない知識を効率的に得ることができるからです。
上手い質問のためには、自分が目指すべき状態と現状との差分を知らなければなりません。
足りないことが見えているからこそ、そのギャップを埋めるための質問が生まれます。
以下の項目について理解できているか確認するとよいかもしれません。
コードの全体像をいち早く把握するための手助けになります。
コードを書く時の判断基準を持ちましょう。
あることを実現しようとした時のコードの書き方について、根拠を持って選択しましょう。
たとえそれが間違っていても、基準を持つこと自体が大事です。
今、そのような判断基準を持っていない場合は、それを作るよう行動してください。
判断基準を持つことのメリットは3つあります。
一つは、「基準を設定する中で知識が整理される」ということです。
判断基準を作ろうと試みると、 「質と速度」、「ライブラリの利便性と制約」 といった、
コードを書く上での様々なトレードオフを意識することになります。
それらのトレードオフの優先順位を決めていくためには、
今まで自分が書いたコードや、PRなどのメンバーとのやりとりを振り返り、
それらについて自分がどのような意見を持っているのか整理する必要があります。
この過程で、それまで学習したことを反芻し、自分の経験を体系的にまとめることができます。
もう一つのメリットは、
「ペアプロなどを通して判断基準をブラッシュアップできる」
ことです。
個人の判断基準に差はありますが、どのようなコード設計が求められているかは、 そのコードが今置かれている状況によって変わってきます。
プロトタイプのために用意するコードと、長期的な運用を前提に書かれるコードでは、 同じ機能を実現しようとしても、その書き方には差が生まれてくるはずです。
自分なりの判断基準を持ってペアプロを進めると、 チームに求められている判断基準と、自分の判断基準の差が浮き彫りになります。
自分でそれに気づいたり、他のメンバーに指摘してもらうことによって、 チームが今置かれている状況を理解でき、 チームの一員としての行動を意識できるようになります。
そうする中で自分の持つ判断基準が、実務で通用するものに成長していくと思います。
また判断基準を持つと、チームにとってもいいことがあります。
自分なりの判断基準を持ってチームメンバーと関わることで、 様々なディスカッションが生まれることがあります。
そのディスカッションは、チームに新しい視点をもたらしてくれます。
チームにいる先輩方は、自分よりも経験を持っていますが、全知全能ではありません(それはそう)。
たとえ他のメンバーが自分よりはるかに知識・経験を持っているように見えても、 意見を引っ込める必要はありません。
むしろどんどん意見をアウトプットしていきましょう。
学びを促進するには、自分から機会を作ることが必要です。
ペアプロに慣れてくると、「ただの作業」としてペアプロをこなす、悪いクセが僕にはあります。
目の前の問題をとりあえず解決することで頭がいっぱいになります。
しかし、それではもったいないです。
せっかくのペアプロなのだから、そこから得られる学びを最大化したい。 そのための方法のひとつとして、パートナーの行動の予測をおすすめします。
同じことを実現する際、自分がとりうるコード作成の手順とパートナーの行動の順番が違うことがあります。
それについて質問をしてみると、自分にはなかった視点で問題を捉えていたので行動が変わってくることが多くあります。
理解しやすいコードを書いたり、より早くプログラムを完成させるためには、 今の自分に足りない観点を養う事が必要です。
パートナーの行動を予測することで、効率的に養うことができます。
以上が伝えたいことです。
最後になりますが、貴殿のますますの成長をお祈り申し上げます。
手紙終わり
書いているうちに、エモみ成分が多めの手紙になってしまいました。
色々書きましたが、ここにあることを今完璧にできているわけではありません。
時々振り返りつつ、エンジニアとして成長していきたいと思います!
About