[Rust][Typescript]今日の学び2022-08-17 Next.js x NEARプロジェクト雛形作成作業ふりかえり
この記事の結論を書くと
「個人的にやっていたプロジェクトの雛形作成作業のふりかえり」
です。
控えめに言っても頻繁にはやらない比較的地味な作業ですよね（※個人の感想です）
ただ作成しただけではツラいので、普段気にしていることを３つ書きます。
ズレた事を言っていたらごめんなさい。ツッコミを入れてもらえると喜びます。
はじめに
まず、需要があるかはわかりませんが
こちらが作成したテンプレートです。
↑Rustでスマートコントラクトを書き、Next.js/Reactのフルスタック環境で開発したい→プロジェクトの雛形整備
この記事はそのふりかえり(のような内容)。
「このような雛形作成作業に取り組む時間は、どのようなところで活きると感じるか」
というテーマで自分目線で書いていきます。
目次だけで言うと、以下の3つです。
- 自分軸がある豊かさと安心感
- いざという時には構成を考えて決めることが可能
- 許容範囲(自然な構成 vs おかしな構成)の区別がつく
だれかの参考になれば幸いです。
参考情報
- Cargo.io - cargo init
- Rustc book - Platform support - tier-2 - wasm32-unknown-unknown
- Next.js - The React Framework for Production
- Emotion - Simple Styling React
- NEAR Developer Documentation
- NEAR University - One place to learn about NEAR and Web3
本題
先に構成の紹介
- とりあえずプロジェクトの構成一覧を載せておきます(※OSは intelチップのmacOSです)
| Name | Version |
|---|---|
| NodeJs | 16.16.0 |
| Rust | 1.62.1 |
| Terraform | 1.2.7 |
| Serverless Framework | 2.72.* |
| AWS-cli | 2.5.3 |
| NextJs | 12.* |
| React | 18.* |
| Emotion/react | 11.* |
どのようなところで活きると感じるか
1. 自分軸がある豊かさと安心感
-
自分で考えてひな形をつくる時間を過ごしてると自然と以下のようなことは気にして作ります
- 個別の設定の意味。公式のリファレンスの所在の確認
- 備忘録的にコメントを入れていく。
- ディレクトリ構成が慣用的な構成なのか(変えられるのか)
- フレームワークの規約の場合、設定ファイルで変更できるか（フレームワークレベルで決まっていて変えられないのか）
- そもそもなぜこの構成なのか（メリット・デメリット）
- 雛形を作る時間を自分で確保していることで、自分軸ができて安心感が1ポイントたまる。
- 比較対象がある豊かさ。問題に気づくきっかけを得られる場合もあります。 - 既存のプロジェクトテンプレートが最適とも限らない。
- 個別の設定の意味。公式のリファレンスの所在の確認
-
大前提として、自分軸がそのまま採用されることは稀です
- 特に、既存のプロジェクトの開発に参加する場合。
- 繰り返しになりますが、最近はコマンド一発でテンプレを作成できるレベルがスタンダード。
- いずれにしても、決める余地がない場合はある。
- ただ、「コマンド一発でテンプレを作成できるレベルがスタンダード」の現代社会では、自然と思考停止しやすい(※個人の感想です)
- 自分は、忙しいと実際の仕事では正直思考停止しがちなタイプです。
- 仮に自己流であっても、自分軸がある豊かさと安心感よ。
- 自分は、忙しいと実際の仕事では正直思考停止しがちなタイプです。
2. いざという時には構成を考えて決めることが可能
-
ただ
構成の紹介に載せたようにいくつかの技術スタックを組み合わせてプロジェクトの雛形を作り上げる場面も一定ある。- 開発の体制によって、ディレクトリ構成・リポジトリ分割単位が変わることも。
- 参画した案件や、巡ってきた開発の機会(チャンス)で、自身を持って構成を提案できる(※この記事の構成で何かが保証されるわけではない)
-
大前提として「そもそも、そういうことを考えなくてもよいこと」のメリットはあると思うので留意。
- 最近は、Reactのcreate-react-appのようにコマンド一発でテンプレを作成できるレベルがスタンダード。
- いずれにしても、決める余地がない場合はある。
- あくまでも必要に応じたとり決めという意味合い。
3. 許容範囲(自然な構成 vs おかしな構成)の区別がつく
-
いくつもの案件に出入りする中で、軸を交えて、許容範囲の区別ができる自分でありたい(※個人の感想です)
-
自分の場合は、案件参画直後にプロジェクトの構成をみて「そのまま進めるか」「改善の提案活動を計画するか」考えます
- 後から構成を変えるのはだいたい大変(ほぼ不可能)なので、参画直後にほんの一瞬だけ考える。
- その前提として、参画する前にかならず自分で構成を組んでから参画するという習慣があります。
- そして、分別がつけられるのは幸せだと思う(※個人の感想です)
- というよりは、初めて入った環境で区別がつかないと怖くて挙手できなかった気がする(※個人の思い出です)
- そして、分別がつけられるのは幸せだと思う(※個人の感想です)
- その前提として、参画する前にかならず自分で構成を組んでから参画するという習慣があります。
- 後から構成を変えるのはだいたい大変(ほぼ不可能)なので、参画直後にほんの一瞬だけ考える。
-
特に20代−30代は経験を求めて、いくつかの技術スタックを経験したいと考えて実践することは多いはず。
- 結果、ことや、初めて出くわす構成もあるのでは?(※自分の体験ではそれなりにありました)
-
区別をつく＝声高に批判・指摘するという意図はありません(※個人の感想です)
- 自律的に分別を付けて、改善提案できるように準備する
- 後から構成を変えるのはだいたい大変(ほぼ不可能)なので
- 自律的に分別を付けて、改善提案できるように準備する
-
-
大前提として、やるまでもなくどうみても違和感のある構成はあると思います
- フォルダ分割されてないとか
- フォルダ名に意味のわからない単語が使われているとか
- フォルダに全角スペースが入っているとか(※全角スペースのファンの皆さんすみません)
- 良し悪しや分別がつくかどうかに関わらず、対応ができない場面も存在します
おわりに
↑の文章にも書きましたが、最近は、create-react-appのようにコマンド一発でテンプレを作成できるレベルがスタンダード。
今回は、めぼしい構成を見つけることができず、自作しました。
贅沢な時間の使い方をしました。そして、今回つくったプロジェクトの雛形は志半ばという感じはあります。
- テストのカバレッジとかアピールしたい。
- 英語化をちょっとずつめざしているが、全部を英語化できていない
- 実装をしながら変えていく部分もあるだろう。
それはそれとして目的は技術研鑽。
またあしたからRustの腕を磨いていきます。以上!
Discussion