Web初心者が２０日でwebサービスを作った際の学び

研究室でPythonでガリガリコードを書いていた私が、今年で社会人になり、退勤後にwebサービスを作った過程を紹介します。
web系の仕事をしていて、数ヶ月間研修させてもらっている状態です。なので、研修の内容がサービス開発にそのまま生きているので、実質、２０日間、連続で一日中プログラミングに向き合っていたことになります。
当方の技術スキルとしては、PHPとHTMLで簡単な掲示板を作ったくらいのレベルでした。
そっから色々勉強して、APIとか色々理解し、アプリの完成に至りました。

その過程や学びを紹介します。

完成物

お見せすることはできないのですが、ざっくりいうと、計算機です。
計算はサーバーサイドのPythonで行い、APIを介して非同期にフロントエンドとやり取りし、リロードなしで計算結果を表示します。

バックエンド

Pythonで色々と計算し、APIでフロントエンドとの連携を取ります。
得た学びを下に羅列します。

APIの実装で巨人の肩のありがたみを知る

最近は、難しいプログラミングを肩代わりしてくれるライブラリやフレームワークがたくさんあると知りました。
これ、全力であやかりに行かなきゃ損だなと思いました。
実際、APIは細かいことをほぼ何も知らないのに、FastAPIというものを利用することで、実装できてしまいました。
FastAPIは難しいことはおまかせで、入出力の結果を吐き出す関数を書けばAPIが完成するという代物です。
１日かけてAPIの概念を把握し、あとはFastAPIを使って、なんとなくで、書いていきました。リクエストヘッダーとかよくわかってないです。
けどコピペでアクセス制御までできました。
やはり巨人の肩しか勝たん。

デザインパターンってすごい

デザインパターンというのがすごいと知りました。
デザインパターンとは、「こういう書き方をすれば難しい機能が簡単に作れるよ」という先人の知恵を集めたものです。（上の世代風にいうと、あんちょこ？）
初心者の方には伝わらなくて申し訳ないのですが、特に役立ったのは、データを渡す際には、直接計算機からAPIに渡すのではなく、一旦バッファを挟んでAPIに送ることです。
そのパターンを、アダプターパターンといいます。
これを適応することで、一度作った計算機に触ることなくAPIなどの他の機能をいじることができ、機能が分離され、かなりプログラムがスッキリしました。この考え方最高だな..という気持ちです。

フロントエンド

Javascriptで書きました。
入力した値から計算結果をグラフに動的に反映するシステムです。

フレームワークはいきなりは厳しいと実感

最初、VueやReactを勉強してたのですが、「これ学習コスト高すぎるにもかかわらず根本のところがわからないままになりがちじゃね」と思ったので、pureなJavascriptで実装しました。
その判断は大正解でした。
ひたすらJavascriptの教本を読んで、クラスとかテンプレートを理解して、それらを上手く組み合わせることで形にできることに気がつきました。
いきなりフレームワークに入っちゃうと、いざフレームワークから外れたことをやろうとした時に、JSの肝心なことがわからなくて一生悩み続けるのではと思いました。

インターフェイス分離の原則でぐちゃぐちゃを回避

綺麗にコードを書かないと、プログラムが大きくなった時にごちゃごちゃになるぞ、と思ったので、先人の知恵を借りました。
俗にいうスパゲティコードの回避です。

今回気をつけたのは、SOLID原則のインターフェイス分離という考え方です。
計算と、表示は分けて作りましょうというものです。
なんのこった、って感じだと思いますが、要するに、「ゲームを作りたかったらディスプレイは別の人に作ってもらってね」とか、「テレビ網を作りたかったら、テレビ本体と放送局は分けて作ってね！」ということです（適当）。

これ、別に本とか読んだわけじゃないんですけど、たまたまネットで読んで、インターフェイス分離って大事そうだなと思い、意識して書きました。
結果、サーバーとはAPIでやり取りし、フロントの計算もクラスに一任する設計になりました。
後半、フロントも複数のJSファイルがそれぞれ３００行とかで、プログラムが肥大化していったのですが、責任の分離を死ぬほど心掛けたおかげで、「一点の変更で連鎖的に色々とコードを直さないといけない」、という状況を回避できました。
ほんと、神概念でした。知っててよかったです。

抽象的な学び

速攻でプログラミングのスキルを伸ばすために、色々仮説を持って開発に挑みましたが、それも上手くいきました。

自分のコーディングを後で見ているもう一人の自分を作る

いわゆるメタ認知で自分の失敗を観察

コーディングしている途中、エラーにぶち当たったり、自分の書いたものが意味わからなくなったりして、何時間も手が止まることがよくありした。
その時間って無駄で、生産性の低下に繋がります。
その２時間で賢く立ち回れたら、もっと進められたかもしれないし、プログラミングから離れて映画見たり外に出かけたりできたかもしれない。
そう考えると、同じ失敗パターンで何度も手を止めることほど勿体無いことはないと感じ、「同じ失敗パターンは1度まで」というルールを設けました。

それを実現するために、エラーなどで数時間詰まって問題解決したら、一旦お外に出てチャリを漕ぎました。
チャリをひたすら漕ぎながら、「なぜ自分はあんな１行のために人生の大事な２時間を溶かしたのか？」とひたすら考察し、その悔しさをバネに、2度とせんと誓いました。

その中での学びをいくつか紹介します。

公式ドキュメントを読む

例えば、公式ドキュメントを読むのを途中で放棄して、キータなどの断片的な情報を漁りまくって、結局公式ドキュメントをよく読めば解決できたとか。
大体は、思考停止とか、読解の放棄に起因する時間溶解が多かったです。
なんだかんだ繰り返してしまうのですが、公式ドキュメントに書いてあるじゃん、ということが多いです。
ドキュメントから素早く問題を解決するために、英語・ドキュメントの基本的な形式・クラスや関数の一般的な表現方法等を学び、欲しい答えの位置を、より高精度に当たりをつけられるようになるべきだと思いました。

体系的に学ぶ

また類似しますが、JS等の自分にとって新しいものを使う際には、全体像が一切わからない状態で始めると、確実に無限キータ編に陥るので、一旦全体像を把握することが大事だと思いました。
作りながら学べば学習に対して主体的になれるので、効率もめちゃくちゃ上がりますが、じゃあ「主体的な状態で体系的に一周すれば最強じゃね？」という発想です。
非同期にAPIを叩いてデータを得る際には、Asyncとかが重要だとすぐに気がついて、そこを深ぼって勉強できたのですが、気がつけたのは一旦体系的にやったからです。
やはり、道具の使い方を朧げながら一通り知っていることは重要だと感じます。

ビジネスの本が役立つ

仮説思考・論点思考・顧客視点

ものを作る際に、上で言ったような「メタ認知がいいんじゃないか」とか思いつくのは、おそらく論点思考とかを読んだからです。
そもそもの思考パターンから変容することで、その上のレイヤーにあるプログラミングという技術に対する接し方も大きく変化し、時間あたりの利得もでかくなります。
他にもマーケティングの考え方なども非常に参考になります。これとかどうでしょう。
自分の作ったものが誰にどう生きるかイメージを沸かせることで出来上がったものが喜ばれる確率も上がるし、喜ぶ顔をイメージすることでニマニマして自分をモチベートできます。

まあ上の本は、前提知識多めの部類になるかと思いますのでイシューから始めよからどうでしょう。

何を学べたか

ノリで初めてみたものの、一つのアプリを作るためには大量の技術スタックが必要になることを知りました。
読んだ本とか、ネットで勉強したものなどを一覧にします。

バックエンド

主にロジック周りの理解が深めることができ、これが役立ちました。

APIの仕組み
FastAPI
Java言語で学ぶデザインパターン入門

フロントエンド

Javascriptでクラスを運用して一つのアプリを作る方法をざっくり理解しました。
vue.js (結局使いませんでしたが、フロントエンドの考え方をなんとなく把握しました)
独習Javascript

デザイン

デザインの基礎をひたすら勉強しました。
結局時間なくてほぼ使いませんでしたが、フロント制作の前提の考え方として非常に役立地ました。
そもそも機能として何が必要なのかの洞察が深まり、成果物に対するイメージも明確になりました。

なるほどデザイン
UIデザインの基礎
ノンデザイナーズデザインブック
デザイン入門教室

これからの自分

速度を上げる・幅を広げる・需要に当てる・社会に役立てる
この４つを極めていきたいです。