ポートフォリオ第二弾を通してシステム開発の流れをお見せします！
薬学アプリ第二弾作ったろ！
こんにちは、薬学生エンジニアの伊藤です。
今回は今現在取り組んでいる「個人開発」についてのお話です。
結論から申し上げますと今現在Java(spring boot) React(next.js) MySQL ElasticSearchなどを使用して簡易的な処方薬情報共有ツールを作成しています。開発中のソースコードはこちら
これに取り組もうと思った動機や今後の方針などのお話をしようかと思います。
動機1:インターンで「美しい設計」を目の当たりにしてしまいある意味対抗心が芽生える！
プログラミング始めた時に作ったポートフォリオと比べて・・・(泣)
まずこれです。一番大きい動機かもしれないです(笑)。というのも僕は以前1度だけ個人開発でアプリを作成したことがあります。
薬理学という科目の学習用アプリで、LINE上で薬の名前を入力すると作用や化学構造式なんかを返してくれるようなものを作りました。使った技術は(Django,Jquery,Heroku )でした。旧アプリのソースはこちら
当時は「これ自分で作れたんだ！俺すごい！」みたいに天狗になっていたのですが、インターンで実際に現場を経験してみて・・・・・
初めて本格的な業務用ソースコードを知りました。圧倒的でした。保守性、運用性、再利用性が考えられていて凄く美しいソースコードでした。
それに感銘を受けるのと同時に、「いつか自分で作るアプリをこれくらいの、いやそれ以上のポテンシャルにしてやりたい」みたいに変な対抗心が心の奥底に目覚めたのでした！
実装にあまり困らなかったのは元々のコードが奇麗だから
実際に開発業務をしてみて最初の2~3ヶ月程度はかなり苦労したものの、なんとかシステムの全体像を掴む事ができました。その後も苦労が無かったか？と聞かれれば噓になってしまいます。
しかしながら○○の機能は△△のコードを見るべしみたいに、ある程度はシステムの内部まで把握できたかと思います。
もちろん先輩方が指導に時間を割いてくれたというのもあるかと思いますが、理由はそれだけではないと思います。システムの設計そのものが美しかったからというのが大きいのかなと考えています。
ドキュメント、テストコードを徹底した美しい設計を。
ここで少し疑問なのですが、「美しい設計」とは何なのでしょうか？
一般的に言われているのは適切な粒度で分割されたモジュール設計、処理の内容が一目で分かる変数名やメソッド名などでしょうか？
実際に業務をしていて感じたことなのですが、「モジュール毎に正しく動作することが担保されているもの、そして問題発生時に発生部位を的確に教えてくれる仕組みが備わっている設計」だと感じました。
それに加えてドキュメントなんかが残っていると、それだけで処理の全体像を把握するのが楽になります！
事情があり今現在は開発業務を行っていません。ただ今後再び現場に入ることになった時、今回の開発で身につけたテスト駆動設計、例外処理、ドキュメントによるコードのビジュアル化などの能力を生かせるようになりたいという意図です。
動機2:やっぱ手を動かさないとね！
本を読むだけだとやっぱ身につかない
これはインターンを始めてからの勉強法の最大の失敗だったかなと思っています。
未経験の言語を使うこともあり、実装面に関しても沢山本を読みました。しかしながら読んだだけでした。確かに知識は身についた気がしたのですが、実務に活かすことはできませんでした・・・・
原因は単純で手を動かしていなかったからだと考えています！
これに対してプログラミング学習を始めた初期の頃はとにかく手を動かしてアプリケーションを自作していました！だから飲み込みも早く2ヶ月程度でアプリが自作できるレベルになったのだと思います。
なので再び手を動かして作ります。これまで本で勉強したことを全てアプリケーションに落とし込みたいです！
要件定義→基本設計→詳細設計→プログラミングの流れを独学で一度でいいから体験したい。
いわゆる上流工程と呼ばれる領域ですが、これって開発ではめちゃくちゃ重要な工程ですよね？しかしながらプログラミング学習初期には適当に取り組んでしまっていた感が否めないです・・・
これらの工程って非常に重要で、ここでレグレッションがあると大きな手戻りになってしまうことを痛いほど学びました。
この辺の企画設計を妥協せずにアプリケーションを開発し、アウトプットしてみたいと考えたのが今回の開発に踏み切った理由の1つでもありました！
開発方針：以前のアプリで感じている問題点と次のアプリでの改善案
以前創った物は以下のような構成のものでした。リンクはこちら
いま考えてる問題点としては、ブラウザとLINEといったある意味別目的の機能。これらに対するデータアクセス用モジュールが中途半端に共通化されていること。
そしてLINEとwebの双方からの同時アクセスが発生した際にweb表示用アプリケーション(赤い部位)に負荷が集中してしまうような構成になっていることです。
これに加えて上記でも述べたような「テスト書いてない」「ドキュメント作ってない」も大問題かなと。※少なくても一年後の自分が見て読めるコードを書く必要があるのかなと！
これを踏まえて次のアプリでは以下の方針で対応して行こうかなと考えています！
1.データアクセスに近い階層のモジュールについては機能に依存せずに使えるような汎用的な設計を維持する
2.インターフェイスに近い階層では機能別の入出力を意識した設計にする
3.中間層に上記二つの違いを吸収してくれるような中間モジュールを作成する。
4.それぞれの挙動、責任範囲を担当する自動テストの作成を徹底する。
今後の方針：個人開発ですがとにかくアウトプット出します！
タイトル通りですが、設計資料,コードなどじゃんじゃんgitHub Quitaなどにアップロードして行こうかなと考えています！今後の発信内容はこのアプリ構築で学んだことが中心になっていくかと思います。
なるべく実際の業務に近い形で開発し発信して行こうかなと思っているので是非参考にしていただければと。
エンジニアに限らず、このように何かを設計して組み上げていくような考え方って役に立つ機会が多いかなと僕は考えています！僕はこの考えをもっと精錬させて、薬学の勉強にも活かしたいとか考えています。
最後までお読みいただきありがとうございました！