はじめに

web 業界に参入して約 1 年が経過した。
凡人が 1 年間真面目に勉強 & 開発して経験してきたことを、思いつく限りで書いていこうと思う。本記事のターゲットは Web 業界に興味がある人全般である。

参考までにワイのスペック

年齢: 32歳
性別: ♂
学歴: 地方国立大卒
英語力:
- TOEIC: 550 (在学時)
- TOEFL: 60 (在学時)
資格:
- 普通自動車免許
- 剣道初段 (教員時取得)
特技: 機関銃射撃 (中隊で競技大会の選手に選ばれるくらい)

これまでに経験してきたこと

全体的なこと
- アジャイル開発
- スクラム
- Slack 文化
- エンジニアとのコミュニケーションの取り方
  この辺はやっているうちに慣れるので省略。
業務で使う必須ソフト
- Slack: チャットツール
  - エンジニア界隈では Slack 系のツールは必須である。この文化に適応するのが最初の難関だと思っている。
    これに慣れたら結構いいことずくめである。
    理由としては、
    - 何がわからないかを垂れ流していくことで思考が整理できる
    - 周りのみんなが助けてくれる
    - 前進している雰囲気が出る(これが結構大事)
- YouTrack: タスク管理ツール
  - チーム開発をする上で外せないツールである
  - 正直、この業界にくるまで存在すら知らなかったが、誰が何をどれくらいの期間でやっているのかが、すぐにわかるとても便利なツールである（他にも ClickUp や Trello, Asana, Redmine とかがあるけれど、私の Project では YouTrack を使っている）
- Jooto: タスク管理ツール(最近使わなくなった。ストーリーを線表で確認できるところが良い。)
- GROWI: wiki ツール (...宣伝込み)
  - 社内や組織の知恵袋 Wiki ツールも今や欠かせない存在である
  - いやまあ私が Wiki を開発しているからというのもあるかもしれないが、絶対に取り入れて損はないツールである
    - 特に官公庁などの紙大好き組織は一刻も早く取り入れてほしい
      - 圧倒的に無駄な労力が確実に減る
- GitHub: ソースコード管理ツール
  - 個人でやっている時は PullRequest の作成なんて無縁だった
  - GitHub Actions なんて聞いたこともなかった
  - しかし今は違う
  - コンフリクトが起きそうな時は全力で自分のブランチをマージしてもらうようにレビュワーに圧をかけるべきという考え方に変化した
- Sourcetree: Git クライアント
  - 初めて見た時の衝撃たるやそれはそれは凄まじかった。
  - 個人開発しているときは、よくわからずに add したり commit したり push したり、revert したり... していて無理矢理整合性を合わせて開発していた
  - しかしチーム開発ではそうはいかない
    - 他の人の迷惑になるので、変なことができないからだ
    - なので Git クライアントを使う
    - これを使えば、他の人に迷惑をかける可能性が激減する(Sourcetree は重たいので実は最近使っていなくて、代わりに Git Graph を使っているのは内緒)
オブジェクト指向の基本理解
- 関数について
  - React.js の props のところで書きます
- クラスとインスタンス
  - これはずっと、わかったつもりでいた
    - 強い人: 「クラスとインスタンスを説明してみて？」
    - 昔のワイ: 「たい焼きの金型とそれによってできる実際のたい焼きです！(フッ　余裕やんけ)」
    - 強い人: 「ほーん。じゃあそれ以外で例えてみて？」
    - 昔のワイ: 「.....(おっふ)」
      おそらく、できる人にとっては簡単すぎる問いかもしれないが、当時の私にとっては超難問だった。
- インターフェース
  - これは、クラスとインスタンスを理解してからはそう時間はかからなかった
  - しかし、よくある参考書でなされる説明では決してインターフェースを理解できないと思う
  - 私が習った中で一番痺れた解釈は、インターフェースとは振る舞いを制限することである
- カプセル化
  - これもよくある参考書では、一生ふんわりした解釈で終わったと思う
  - 疎結合・密結合の概念や共通している箇所の切り出し・他への委譲など、この 1 年間でず〜〜〜っと言われ続けてきてようやく辿り着き得た
- エラーハンドリング
  - これは難しい
  - 「なぜそこでエラーハンドリングを行う必要があるのか？」を説明できるようになるまでがとても遠い。
  - 責務の話につながるのだが、HTTP レスポンスが自分の中に入ってくるようになってきて少しずつ見え始めてくると思っている
その他で大事なプログラミング基本理解
- 名は体を表す
  - 死ぬほど言われている。最も大事なものの一つだと思う
  - そして今でも多分到達したとは言えない
  - 強い人の言葉を借りれば、「いくら素晴らしく、わかりやすいコメントがあったって変数名から情報を受け取れなかったら意味ないよ。逆に変数名がきちんと名が体を表していたらコメントなんか入らないんだよ。」である
- ファイル・関数・コンポーネントの責務は？
  - これも死ぬほど言われている
  - 同様に到達したとは言えない
  - 欲張って詰め込みすぎるという悪癖がある
  - まだまだこれからである
フロントエンド
- コーディングルール (各社で規定されているはず)
- JavaScript
  - 基本文法
    - 今でも結構わかんないやつある
    - !! (double bang) を最近知った
  - 非同期処理
    - Promise async/await が結構長い間適当に理解していた
    - Promise.all や Promise.allSettled について問われてちょっとずつ理解を深めていった
  - 文字列処理
    - paiza とか atCorder とか PR の FeedBack で鍛えるしかない(最初からできるやつもいる)
- React
  - クラスコンポーネント, 関数コンポーネントについて
    - なんとなく書けるようになってきた
    - 最近は関数コンポーネントしか書いていない
  - Hooks
    - なんとなく書けるようになってきた
  - state 管理と props
    - 簡単なことかもしれないが、当初 props と state をよく理解せずに開発していた
    - というか props ってなんやこいつ？状態であった
      - ある時 props と state をごちゃ混ぜに理解した状態で強い人に PR を出した時に props についてピシャリと言われたことがある
      - 強い人:「props の何がわかんないの？こんなもんただの渡ってくる引数だよ。関数で引数取るでしょ？　それと一緒！　なんかの関数に引数を入れた結果、何かしらの値が帰ってくるでしょ？その引数が props になっただけじゃん...」
  - state は、そのもの自体は難しくないのだが、余計な state を作成しない と その state は本当にそのコンポーネントが所有するべきか？ についてが結構難題で、まだまだこれからかもしれない
- Typescript
  - まだまだである
- Next.js
  - Next.js が苦痛というよりは Typescript をマスターしていないという感が否めない
  - PM が Next.js を使うことでページ遷移が劇的に早くなり、きゃっきゃ喜んでいたが、正直その辺の感動はあまりなかった
  - 生粋のエンジニアは感動するらしい
  - state 管理に SWR を用いるという概念は結構大事だと思っている
- Bootstrap
  - なんとなく書けるが、いまだに得意意識はない
- Sass
  - 相当苦手
  - これも要は関数と一緒なんだが、コツを掴んでいない感が否めない
- Atomic Design
  - この考え方を聞いた時は「はぇ〜」ってなった
- XD などを駆使するデザイナーへの敬意
  - 昔のワイ　「デザイン？そんなもんセンスやろ?」
  - 当時は UI/UX や洗練されたデザインについての理解が欠乏していたが、やはり良いものを見せられると昔の自分には戻れない
    - ある UI/UX に対してとことんまで考え抜いたのち、研ぎ澄まされた感性を発揮させて作り上げたデザインを、プログラマーとの間で激論を交わした末にようやく勝ち得たそれは、素人やちょっとセンスのある程度の人間では、到底辿り着き得ない領域であることを悟った
バックエンド
- api
  - api についての概念はあるとき、急にしっくりくるようになった
  - それまでは敵だと思っていた
  - api を深く理解することができたのは、api に苦しめられたからである
  - なんとなくを脱出したのは、フロントが完成されていない状態で開発したことが大きいと思う
  - フロントから潜った人間にとって、フロントありきで思考してしまうが、本来は逆である。バックエンドからコードを書くと自ずと api が近づいてきて、知らない間に仲良くなっていた
    - Postman
    - YARC
      - これらはとっても便利な api を叩くためのツールである
      - バックエンド開発で役に立つ。
- Mongoose
  - もう ODM 信者である。
- Robo 3T
  - 大体みんな間違えて Studio 3T をインストールしがち
- Model 層
- Service 層
  - Model 層と Service 層に対しては相当時間がかかった
  - バックエンドを理解する上では避けては通れない道である
  - 最初にエンカウントする疑問は、なんやこいつら？である
    - オブジェクト指向の概念がないと、本当に理解できない
    - 私は MVC モデルから入ったのだが、そのときは Service 層というもの自体なかったし、Model の役割についても薄い理解しかできなかった
    - その状態でプロジェクトに参画したのだが、プロジェクトの Model や Service は個人が作っているものとは比べものにならないくらい巨大で、まず理解不能である
    - その迷宮をただひたすら進んでいってようやく、ぼんやりとその全容が理解できるようになった
- migration
  - デグレが発生する機能を実装したときに理解が深まる
  - それまでは ??? である
- Jest
  - 何回も挑戦して、その度に敗北する
  - それの繰り返し
環境構築系
- ESLint, StyleLint
- Prettier
- Docker
- docker-compose
- Makefile
- Github Actions
- この辺りは自分のやっているプロジェクトではあまり身につかない
- 理由は、もう完成されてしまっているからである
- なので、自分で 1 からサービスを作るときに勉強する感じである
- 同期や先輩とチームを組んで、サービスを作った時にいい経験になった
その他
- ボードゲーム
  - プログラマーはボードゲームがめちゃくちゃ強い
  - 生物としての個体差を感じざるを得ない
- なんか作ろうや感
  - ソフト開発してきて本当によかったと思えるところ
  - 何かの拍子に、天からアイデアが降ってくることがある
  - 以前の自分なら諦めていたが、今は一緒に遊んでくれる仲間がいて、開発する力がある
  - そのサービスが本当に使われるかどうかはわからないが、みんなで一緒にものを作っているときの楽しさは、控えめに言っても最高である

最後に

ここに記載した項目は、あくまでも私が到達したかな？というものです。
同期の中には驚くほど強くなった人がいたりして、同じ 1 年なのにとんでもない領域に踏み込んでいる人もいたりします。
なので、到達できるところは人それぞれだったりします。
ただ、凡人でも 1 年経過するとここまではできるんじゃないか？という 1 つのベンチマークになるのではないかと思いこの記事を書こうと思いました。
まだまだ書けていないことはあるのですが、そのときはこっそり継ぎ足していきます。
最後まで読んでいただきありがとうございました。

（宣伝）

超最近自分の趣味のメディアを仲間と一緒に作りました！
よかったら雑に立ち寄ってくれたら嬉しいです！
https://www.wai-ware.com/

以下の記事で、私が未経験からエンジニアになるときの戦略を書いてます。
良かったら読んでください。