2022年9月振り返り。技術に関するアウトプット多め

10/1/2022

最近Vaundyの恋風邪にのせてのイントロが頭から離れない。


ずとまよの消えてしまいそうですがいい感じにシティポップしてて気持ちいい


そして月末に上がる藤井風の新MV


仕事関係

8月くらいから新規プロジェクトの開発がスタートし、要件定義や設計を進めていて、9月末に製造が始まった。

今回は今までできてなかったけど挑戦してみたい事をやってみた。

  1. データベース設計時にER図の作成
  2. OpenAPIでAPI定義
  3. GitHub Actionsを使用したCICDの設定
  4. Go言語を使用したAPI実装
  5. バックエンドのアーキテクチャにレイヤードアーキテクチャ採用

ER図の作成に関しては、エンジニアとして4年近く仕事をしているが、実はER図を書いた事がなかった。
もちろんER図は見たことあるし、データの設計も経験がある。

しかし、ちゃんとER図に起こした事がなかったので、このまま一回も書かずにバックエンドエンジニアを名乗るのはちょっと嫌だなと思って挑戦した。

使用したツールは drawo.io
とても使いやすく、レビューもやりやすいと感じたので、今後もER図の作成はdrawo.ioを使うと思う。

ただ、drawo.ioだとバージョン管理が難しく、データ設計が固まった段階でMermaidに移行しようと考えている。


OpenAPIについて。
以前携わっていた開発案件では、FastAPIを使用してOpenAPIを自動生成していたものを使っていた。

ただ、FastAPIを使って自動生成したものを使う場合、APIの実装を先にしないといけない。
そうすると、APIの実装が完了するまでAPIの定義書のようなものがなく、フロントエンド側のAPI繋ぎ込みの部分の開発が後回しになってしまう。

じゃあ最初にスプレッドシートでAPI定義書を作るか、エンジニアとしては他に使えるツールがあれば使いたいと考えた。
(自分は強めのスプレッドシートアンチ、ただスプシを使いこなせてないだけだけど、俗人化を促進させてしまうツールだと思っている。)

実際にOpenAPIで作ってみると、レビュー時にUI上でわかりやすいので指摘も貰いやすくなった気がする。
また、VSCodeのエディタで書けるので、フォーマッターやVimを使えるのも良かった。

ただ、今の懸念として、開発を進めていく中で管理していけるか不安になっている。
APIの変更を逐次反映させていく時間が取れるかであったり、変更が多くなってきた時にOpenAPIに反映させるのを忘れてしまったりそうではある。

もしそうなりそうだったら、コードからOpenAPIを生成するツールを使っていきたいと考えている。
最初の設計はOpenAPIを手で作成し、開発が進んである程度APIが完成してからはコードからOpenAPIを生成するツールを使う事で、API設計書=実装になり、管理する工数も減らせそうで良さそう。


GitHub Actionsを使用したCICDについて

これも業務で書いた事がなかった。
もちろん携わっていたプロジェクトには存在していたが、自分では書いた事が無い状態

9月時点では、まだ実際に製造は始まっていなくて、開発環境の構築で使用した。

具体的には、ブランチのプッシュ時に行う静的解析とテストの実行を行うActionsを作成した。

まだ簡単な事しか出来ていないけど、開発の後半にはデプロイ関係のActionsも書きたいと思う


Go言語を使用したAPI実装について

何気に今の職場ではGo言語の採用実績がなかったが、プロジェクトのリーダーと自分がGoの興味があったから採用を検討し、今回のプロジェクトで使ってみようとなった。

以下、採用理由

  1. ある程度パフォーマンスが出る
  2. 強めの静的型付け言語
  3. Goに興味があるエンジニアが多いため、エンジニア採用強化に繋がると考えた
  4. gofmtによる、エンジニアの趣味で衝突しがちなフォーマットが言語仕様で決まっている
  5. シンプルに実装ができる

学習の方法は、A Tour of Goを一通りやった。
あとは、実用Go言語と、会社に置いてあったみんなのGo言語【現場で使える実践テクニック】を使ってインプットした。

正直、実用Go言語は結構難しい、難しいというより、一通りGoで実装した経験がある人には刺さりそうな内容が網羅されていて、半年後にもう一回読みたいなと思う本だった。

そして新たに初めてのGo言語なる本が出版されていて、これも買って勉強したい。


バックエンドのアーキテクチャにレイヤードアーキテクチャ採用について

今まではフレームワークのアーキテクチャに沿って実装をしてきた、特にMVCの開発が多かった。

ただ、軽量のフレームワークで開発する際、ちゃんとしたアーキテクチャの設計ができない事に気がついてしまった

今回はレイヤー系のアーキテクチャで実装してみようと考えている。

最初は流行りというか、ちゃんとした現場で使われいてるイメージがあるクリーンアーキテクチャをただ使ってみたいという下心からの興味だったが、レイヤー系のアーキテクチャを学ぶ内に、大きいサービスが何故レイヤー系のアーキテクチャを採用しているか理由がちょっとずつわかってきた。

分かりやすい所だと、SOLID原則に沿った実装である事
正直に言うと、まだDIPについてくらいしかよくわかってない、悔しながら。
クリーンアーキテクチャの本を購入したので、このへんは時間をかけて勉強していく

あとは各レイヤーが疎結合であるため、テストが書きやすいという利点もある。

やっぱり実際に自分で書いてみないと、どのようなアーキテクチャ毎にどんなメリットデメリットがあるか実感できない部分があるので、今回の実装でレイヤー系のアーキテクチャのメリデメを理解し、次のプロジェクトからは要件にあったアーキテクチャを採用できるようになりたいです。

今後はクラウドサービスを利用したサーバレスなアーキテクチャが多くなりそうで、そうなるとLaravelやrailsのようなフルスタックなフレームワークよりも軽量なフレームワークが流行りそうな気がするから(もう流行っている?)自分である程度アーキテクチャを設計できる力が必要になりそう。


そして最近は開発して終わりではなく、運用まで経験したみたいなと思う。

仕事系のアウトプット、結構長くなってしまったけどこれで終わり。


私生活&趣味

暮らしに関する今月の備忘録


家の近くに無印良品ができた

黒豆茶や食品を買ってみたがどれも美味しい。


ボルダリング

数年ぶりにボルダリングに行った。

久しぶりにやってみると、楽しくて1時間があっという間に過ぎてしまった。。

月一で行きたい。


僕のヒーローアカデミア

まさかの漫画無料公開

ただでさえ最近はGoやアーキテクチャに関するインプットで時間がないのに。。。

頑張って読む


Vaundyにハマる

今更すぎるけど最近めっちゃ聴いてる。

元々は踊り子や東京フラッシュくらいしか聴いてなかったけど、アルバムを通して聴いてみると良い曲ばっかりなんだよな。。。

流行る理由がわかる。
キャッチーな曲が多くてテンションが上がる

特に好きなのは、怪獣の花唄、おもかげのセルフカバー

怪獣の花唄は、最近六本木クラスで好きになった鈴鹿央士がMVに出ていて、より好きになった曲

鈴鹿央士って、本当に王子様みたいなビジュアルしているよな〜
優しそうな見た目にあのスタイル。今の時代一番モテる気がする


スプラトゥーン3

やってる。

プロコンが買えなくて毎日怒ってる

BGMが良過ぎて試合中にノリノリになってしまう。


今月はGo言語とアーキテクチャとワンピースの事で頭がいっぱいだった

関連記事

Profile

seki

千葉在住のWebエンジニアです。

生活と趣味の備忘録として、

このブログを始めました。

Favorites✨