【見ないで!!】いろいろやばいブログを作ってしまったので懺悔とリファクタの決意

はじめに

この記事は東京理科大学アドベントカレンダー10日目の記事です!

今年も僕が、ふじーさんが始めたこの東京理科大学アドベントカレンダーを作らせていただきました!!

みなさん登録ありがとうございます!!

昨日は、後輩の @piffett の「地頭の良い文系エンジニアに勝つ!」でした!

この記事は、僕が属している金町食文化研究会という理科大葛飾キャンパスがある金町のくそディープな飯を食いまくって、発信するサークルのブログメディアを作った(ている)中で、とりあえず作ってみたものの負債&その他諸々やばいのでそれを僕がもし作り直さなかった場合に後世触るであろう後輩に懺悔すると共に、作り直す決意を固めるための記事です。

いろんな意味で参考に出来るところもあるかもしれませんが、多分自分のブログに載せます。

あとは、夏前の自分ポンコツだなってのと特に9月以降2ヶ月くらいひたすら図書館にこもってパワーアップしたので、そのちょっとした成長録。

そのブログは一応世の中には存在していて、以下のURLになっていますが、まだ運用されておらず適当なサンプルデータが置いてあるだけでまだ404のページもありますが、そのくそ具合を知りたい方のみのぞいてみてください。

https://hungryresearch.com (みちゃダメな意味で棒線です笑)

チーム構成

client

backend

  • Railsを中心にインターンしてるGoも書きたい留年4年生
  • Goを勉強したい後輩×3

アーキテクチャ

当初予定していた構成

client

  • ブログの画面、編集画面共にreact製
  • Nodeのサーバー立ててSSR
  • atomic design
  • その他

    • 型はflow
    • storybookでcomponentリスト作りたい

backend

  • GoのAPIサーバー

現状の構成

client

  • ブログの画面はReactで作ったアプリケーションをfirebaseにhosting
  • 編集画面はwordpress
  • atomic design

backend

  • wordpress rest api

    • gcp上にdockerでwordpress
    • 実装時間3時間くらい

ヤバみとwhy

では、これから何がやばいか、また、なんでそんなことになったかを上げていきたいと思います。

そもそも4月には一度完成してローンチしている予定だった

ヤバみ

このブログを作ろうと動き始めたのが、2月そこから新入生歓迎会(4月)の時期には出したいよねと動き始めていました。

そして、最初はRailsでパフォーマンスを意識してないものを新歓に合わせてだすとか言ってたけど、サークル側の都合とかみんなのモチベの問題とかで(そんな感じだった気がする)だらだら...

そうこうしているうちに、やっぱ4月どうでもいいならイケてそうな構成に変えね?!とかで当初予定していた構成になりました。 結局、その後はブログの画面のclientはほぼ実装は出来ていたのですが、編集画面めんどいとか学生団体あるあるなモチベ問題やその他もろもろ絡んでだらだら。

結局8月くらいになり、さすがに完成させないとやばいとなって、GoのAPIサーバーがなかなか上がってこないぞ!からwordpress rest apiでもよくね?!となり3時間で適当に作った次第です。

why

だいたいその場のノリでイケてそうなものを選択するみたいな感じで長期的な実装スケジュールとか、アーキテクチャもふわっとしたこと決めて本人任せみたいな感じでした。

あとは、モチベの管理出来てませんでした。

メディアなのにSSRしていない

ヤバみ

メディアなのでSEOと表示速度が命だと思うのですが、firebase常にhostingしているだけですので、クローラには空と判定されるのでSEOもくそもありません。

また、表示速度およびFMP(First Meaningful Paint)もかなり遅いです。

why

やばい、とりあえずデプロイして記事かけるようにしないと!と思ってとりあえずfirebaseにhostingすればいけるやと思ってこんなことに。

そもそも作り始めた当時の僕がポンコツでCreate React AppでSSRがだいぶ厳しいことを理解してなかったです。

今なら、nodeのサーバー立ててやるとしても評判よくないらしいけど、routingもそんな込み入ったことないしnext使うかなー

インフラ管理する人いない

ヤバみ

結局wordpress rest apiのために、gcp上にdocker使ってwordpressサーバーを立てることにしました。

そもそもこの時点で今後何かしらのインシデントが起こった際には、dockerを使える人間がたまたまサークルにいない限り、僕になんとかしてください的な連絡を送るしかないわけです。まず、これヤバイ。

そして、僕自身もインフラ周りが得意でないのとインフラ超得意マンが友達にいたので丸々頼むことにしました。 僕に連絡きてもわからないし、そもそも僕いてもその友人呼ぶしかない、ヤバイ。

why

技術レベルが一定必要な技術使うのもダメだし、ドキュメントに構成とか全く残せていません。

メンテナンスしなくてもいいサービスなんて作れないけど、なるべく解決しやすいようにしないと。

崩壊したatomic design

ヤバみ

各階層ごとの責務分割を明示していないため厳密に行われていないことや、最後の方はめんどくさくなってatomsに実装依存のコードを書き始めたりと崩壊しました。

why

今となっては夏休みにそれなりにインターンで研究したりしたので、責務の分け方とか最低限理解しているつもりですが、このサービスのコードを書き始めた時にatomic designを導入したのはなんか流行ってるしいいやん的なノリでしたし、そもそもてきとうな記事読んだだけで理解してませんでした。

要するに、勉強不足と知らない技術を適当に採用したから。

途中で投げ出したstorybook

ヤバみ

atomic designに合わせたcomponentリスト作ったらかっこいいし、開発効率上がるんじゃね?と思ってstorybookで作ろうとしたが、途中からstorybook作るのめんどくさくなって投げ出しました。

why

めんどくさくなったから。

根本的な原因としては、もっと簡単に作れるように固定のpropsリストとかその辺考えればDX上がってたと思います。

そもそも使いたかっただけなので次はこの程度のブログ等ならいらないですね。

記事の書き方がややこい

ヤバみ

食レポの記事と飲食店の情報を紐づけて投稿するのですが、そのやり方がくそめんどくさくて、食レポの記事を投稿の店舗カテゴリーという欄に、飲食店の投稿のURLからその飲食店のIDを見て、それを入力せねばならないという煩わしさ。

直感的でないので、ライターの方からも不評だったように思います。

why

wordpress rest apiを3時間でてきとうに作った結果、実装上こうなった。

未公開の記事が見れないのでぶっつけ本番

ヤバみ

未公開の記事が見れるページが今ないので、今どんな配置になっているかをライター確認できないので、ぶっつけ本番で見れるかを確認するしかありません。

why

秒でいけるっしょって思ったらめんどくてやめました卍

結論

全部中途半端だったから起こった。

イケてそうな技術採用するにしても技術の下調べもちゃんとしないし、チームのマネジメントもしないし、おまけには実装の属人性も半端ない。

リファクタリング計画

以上を踏まえてさすがにこれではという思いでリファクタリング。

簡単にいうと、自分のブログとほぼ同じ構成のものを作ります。 と言いますのも、いわゆるJAMSTACKです。

JAMSTACKとは、javascript, apis, markdownを用いたwebサービスです。

僕のこのブログの場合は、

  • React製の静的サイトジェネレーターgatsby
  • headless cms contentful
  • hostingのためにnetlify jamstackに関しては、今度その記事をjamstack advent calendarで書くのでそちらも見ていただきたいのですが、

この構成を簡単に説明すると、gatsbyでreactの静的サイトを生成する際にcontentfulからデータを取ってきて生成し、それをhostingするといった流れです。

gatsbyはブログを作るのに欠かせないいろんなプラグインがあったり、contentfulもデータ構造を指定するだけでブログ書けてデータ取ってこれたり、netlifyはhostingだけでなく、gatsbyのビルドからカスタムドメインの設定までできて超便利です。

これを利用することで、別ドメインでhostingし、contentfulから簡単にまだ公開されていないブログを見るなどもできますし、サーバーの管理もしなくていいのでインフラを触る必要はありません。

使用しているライブラリの問題で動かなくなる可能性はありますが、それ以外はほとんどメンテナンスの手間が省くことができます。

また、これらの構成を採用することでclient側のコードの実装だけを考えればよくなります。

そして、コードの問題に関しては、atomic designを採用するにしても事前に、責務分割を行い、componentを洗い出すことなどを行い実装依存になる問題等を解決します。

まとめ

あとは、スケジュールしっかり立てて気合い入れてコード書いて、運用のドキュメントを残すだけ!!

頑張れ自分!

明日の理科大アドベントカレンダー10日目は、katsuyuki katsuyuki さんです!!