ID:26135さん

開発背景

開発理由はいくつかあり、１つめにポートフォリオを何か作成しておきたい、２つめに学生の頃に行っていた趣味のプログラミングの感覚を思い出したい、３つめに私の趣味である料理レシピをまずは自分のために管理、精査、分析したいの３点によるものです。
この３点をクリアし満足した際には外部に公開してより情報を収集したいとも考えています。

目的

• ReactJsとDjangoRestFrameworkの学習
• 「レシピ研究サイト」というサービス像を形にし、果たしてこのサービスでより良いレシピができるか検証すること

システム概要

バックエンドはAPIを、フロントエンドはSPAの2つのサービスから成り立ちます。
実装機能は以下です。

各種リンク

ポートフォリオサイト

https://shortbread2329.github.io

GitHub
https://github.com/shortBread2329/CookLab

※現在はfeatureReactMockupブランチで開発途中です。

使用言語・フレームワーク・API等

• バックエンドAPI
  • DjangoRestFramework
  • Python
• フロントエンドSPA
  • ReactJS
  • JavaScript
  • SemanticUI

開発環境・ツール

開発前の私のスキル

pythonの実務経験はスクリプトの開発を一年未満ほどと、趣味でスクレイピングツールを開発した程度でした。Reactについては、どんなフレームワークなのか耳にしていただけでした。

開発フロー

1. 簡単な要件定義、サービス像の簡易的な文章化
2. 画面レイアウトのスケッチ
3. 画面の構成検討
4. フレームワーク選定
   • DjangoRestFramework採用理由
     • 趣味の時間なので、経験してみたいが一番の理由ですが、それだけではなく、ORMと管理画面が便利そうである点、あとDjangoRestFrameworkの「ModelViewSet 」というものを使い、モデルを作るとCRUD APIがほぼ出来上がる点の2点から、開発効率がよいのではと考えたためです。
   • ReactJS採用理由
     • 開発以前の、私のフロントエンド開発スキルはJQueryでしたが、今回のシステムをJQueryで実装していた場合は複雑になりそうでしたので、脱JQueryが一つの理由です。あとはVueJsを少しかじっていたため、ReactJSがどんなものなのか知りたかったためというのがもう一つの理由です。
5. 開発準備
   • Githubのブランチ作成
   • DjangoRestFrameworkのインストール、管理画面の使用感確認
   • ReactJSインストール
   • CORSの導入、ハローワールド実行テスト
6. 開発
   • SPAにトップ画面をデザインの通り作成
   • APIにModelを作成することでレシピデータベースやCRUD APIを構築
   • SPAにレシピ参照画面の作成、動作確認
   • SPAにレシピ投稿画面の作成、動作確認を実施するが、Modelの構築に問題が見つかる
   • APIにModel改修を実施し、投稿機能が一連の動作をすることを確認
   • 現在開発中

今後の予定

• レシピに画像も投稿できるようにしたい。

苦労した点

まずCORSについての理解です。セキュリティのためにリクエスト制御はしないといけないなと考えひとまず導入してみましたが、CORSによるHTTPリクエストの流れが勉強不足だったことによって、自身が実装したAPIのPOSTリクエストがなぜはじかれるのか、原因調査に時間がかかりました。この事象に対して、いったん落ち着き冷静になってから、公式ドキュメントなどからCORSのリクエストルールを調べ、リクエストヘッダに余計なヘッダーを設定していたことが分かりました。

ReactJsのState管理もすぐには慣れず、Stateを複数回更新してしまう、Stateの更新ができずにボタンを2回クリックしないと画面が表示されない（1回クリックしただけではクリック前のStateの状態）というような事象が多発し悩みました。State管理を復習しなおした上で現状をフローチャートにし、絵にかくことで頭を整理することで問題を解決しました。

ここまで作った成果と感想

まだ完成していない点は、新しい技術に挑戦しすぎ、勉強コストがかかっていることが原因だと感じていますが、逆に言えば、ここまで新しいことに挑戦し、今まで経験したことのない障害がありましたが、基本機能がある程度完成するレベルまで自分の力で実装できたことが成長を感じます。

背景

既存システムの追加開発を行い続けた結果、運用コストがかかっている点の改善や、システムの統一化と可視化を目的とし、スケーラブルなパブリッククラウドを採用したサービスへ移行する方針が決まった。

既存システム概要

まずクライアント(発注依頼者)から発注データを受信し、システム内部でデータ加工を行った後にメーカー(発注受付側)サービスへ転送、同様にメーカーから受注データを受信し、購入先へ転送するような機能を持ったサービス。
そのサービスがメーカーごとに待機しており、複数のシステムから構成される既存の物流系基幹システムが運用されている。
既存システムがクライアントやメーカーサービスからデータを受信する際に、別のプロジェクトで開発されたシステムを通して情報を受信していた。

新規システム開発概要

既存システムと同様のサービスに加え、各種クライアントやメーカーサービスからデータを受信する際は、各会社ごとの通信仕様に合わせて独自に開発する。

使用言語・フレームワーク・DB・使用サービス等

• Azureサービス

  • AzureFunction
  • WebApps
  • AzureSQL
  • AzureCosmosDB
  • TableStorage

• 開発言語

  • .net C#
  • Python3.6
  • PowerShell

• 使用フレームワーク

  • AzureFunction
  • asp.net MVC
  • XUnit
  • Moq

• ミドルウェア

  • SQL Server
  • NoSql

開発環境・ツール

担当作業内容

４月から９月まで１メーカー用新規サービスの開発を一人で担当し、
システム基本設計からシステムリリースを実施した。
１０月から現在は別メーカー用新規サービスの基本設計から単体テストまでを実施し終えました。

課題

• 知識の共有をするための場所などは整っていたように感じたが、技術者のアウトプットが足りていないように感じた。
• 新規開発したシステムであったが、多くの物流データに対応するため機能追加がたくさん行われ、ソースの冗長化やリファクタリングができる点がいくつかあった。
• AzureFunctionsのランタイムv1でこのシステムは動作していますが、v1は更新がほぼ無くなったためv2への移行(.net Frameworkから.net Coreでの開発へ移行)をすることや、ログの出力管理などの移行後仕様については決まっていたがいつ実施するかなどの見通しは立っていなかった。

アプローチ

• Redmineのナレッジベース機能を使用し、すべての単体テストに使用している基底クラスに使用しているxUnitのテクニックや、Moqフレームワークの活用方法について記事を作成した。
• リファクタリングの提案を実施した。具体的には機能が膨大になったクラスに対しpartial句を使用した部分クラス化を提案した。
• メインシステムの起動トリガーとなるスクリプトだけでもv2への移行を考慮し、ログ出力を改修の中で事前に実施することを提案した。提案の際にv2移行が本格的に開始した際にもスムーズに取り組めるなどのメリットを開発メンバーやリーダーに説明した。

解決

• ナレッジベース機能に記載した記事をSlackで開発メンバーに通知したが、反応はとても好評でした。プロジェクトを離任し、私中心で開発した部分はどんなテクニックを使用しているか、しっかり残すことができました。
• EDI追加開発中に追加で部分クラス化を実施することが決まった。
• EDI追加開発中に追加で起動トリガー用スクリプトのログ管理の改修を実施することが決まった。
• その後も追加機能を実装したEDIシステムのソースコードが読みやすくなった。

成果

• 開発メンバーに展開した際にちゃんと分かりやすい記事であったり、プレゼンテーションを実施するスキルが鍛えられました。
• システムの改善案を提案する能力が鍛えられた。PDCAサイクルをこれまでのプロジェクトに比べて意識したように感じた。
• 上流（基本設計）から下流までを初めて担当し、システム開発の一連の流れを学びました。
• 開発を担当する機能がAPIが多く、プロジェクトの開発メンバーの中でも経験が多く、そのスキルに関してスキルを共有することが多くなりました。