ソフトウェアとアタシ再生産

この間、ダイナミックなリファクタリングをコアなロジックに施術した。

正直このレベルの変更をするのはチームでも難しいと言われてて、かつ重要なロジックなので変更が難しかったのだが、今回思い切ってやってしまった。

そういった壊して作り直すことを考えてたら浮かんできた記事。

"ソフト"ウェアに寿命があるとするなら、その命が尽きるのは変更が無理になってしまったときなのだと思う。

幸運にも生き残ってしまったソフトウェアは、絶え間ない機能追加と仕様変更の波に晒されることになる。初期の頃上手く言ってた設計も日が経つに連れて、限界を迎えてしまう。

ソフトウェアの死は事業の死にも直結する。何も遊びの変化の無いゲームを遊び続けてくれるユーザーは居ないだろう。

とはいえリファクタリングは無尽蔵に出来るものでは無い。私はリファクタリングの成功には経済的合理性が必要だと思ってる。ただの自己満足なのか、それとも事業をより前に進めるための必要経費なのか。

前者は完璧主義なソフトウェアエンジニアが陥ってしまう(私も例外ではないが)罠で、そのリスクはよく知られているはず。より良いものは作りたいが、何から何まで完璧にすることなんてのは諦めたほうが良い。

ただ、後者が必要なタイミングというのは往々にしてやってくる。今回は明らかにそのタイミングだった。

巨大に膨れ上がったトランザクションスクリプトの一挙一動を知ってるのは最早限られた人しかおらず、何もかも読みにくい、この上に更に新規機能を加えるなんてのは流石に出来ないと。

複雑に絡み合ったロジックを紐解いて分かりやすく再構築するのはやっぱ並大抵な難易度じゃない。もっの凄いエネルギーを使う。紐解いて再構築するの大好きなので楽しかったけど。

こうやってソフトウェアを作り変えることをやってると、去年観たレヴュースタァライトという映画を思い出した。あれは舞台のお話だけど、ソフトウェアも似たようなものかもしれない。囚われ変わらないものは、やがて朽ち果て死んでゆく。アタシ再生産。

animestore.docomo.ne.jp

かつての私はこんな攻撃的なコードは書かなかったなと思う。もっと保守的に書いてた。既存の思想に従った、影響範囲が出来るだけ狭くなるような、そういった改修を自然と選択してた。その選択も間違ってはいないが(実際自分の改修はバグが少なかった)、逆に負債を溜めてしまう結果にも繋がっていた。

0と1で判断出来るようなことじゃなくて、グラーデーションのある事柄なので、何が正しいなんて言えない。けど、変化することを恐れたくないという祈りなのだと思う。

22/06/24 一部添削

ソフトウェアの昔ばなしをひたすら聴きたい

developer.aiming-inc.com

↑会社的にブログ頑張っていくぞ~~みたいなムーブメントあったので、便乗して記事書いた。この場末のブログに書くなんかよりは、PVもそこそこあった感じ。

それはそうとして、この技術の文脈をどう捉えていくかみたいなのは我々新参者には結構深刻な問題だと思う。

例えば今自分が所属してるプロジェクトで、キャッチアップが難しかったなぁと思える技術を上げていくと…

  • Clean Architecture
  • Zenject
  • UniTask
  • UniRx
  • gRPC

で、これらの技術をどうやって理解していったかって、やっぱり表面じゃなくて、そもそもこの技術は何を解決したいんだっけ?ってのを歴史から紐解くのが一番分かりやすかったんですよね。

Clean Architectureなんてその最たる例で、あの同心円状の図から入るとかは最悪ですよね。レシピを覚えることにあまり意味はなくて、レシピに至るまでの道を理解することが大事で、そこから発展させる必要があるのだけど、レシピで止まってしまうエンジニアも少なくない…。かくいう私もそのレシピに弄ばれた一人ですが。

別にこれは、採用してる技術だけではなくて、今私達が書いてるソフトウェアにも当てはまる話で、何でうちのソフトウェアこんなアーキテクチャしてるんだっけ…?って気づいたら誰も知らないなんて良くある。そこでチームの最古参のメンバーが「昔々かれこれこういう理由で…」と紐解くと、なるほどなーとなったりする。他にもgit blameから古代のPRを引っ張って読み解いたり(これを考古学と呼んでる)

そういう語り継ぐ人が残ってるのは幸運な例なのかなとは思ってて、現実としてコンテキストが喪失してるなんてことも良くある。つらい。いつ消えても大丈夫なように、ドキュメントは書こう。

なので、ソフトウェアの昔ばなしというものがとても面白いなあと思うようになってきた。もっとソフトウェアの歴史知りたい。

クライアントエンジニア一年目で気づいたこととか

BackendなRailsエンジニアやってた去年とは打って変わって東京に転勤してクライアントエンジニアの仕事し始めてから約一年経つので、日々接してる技術スタックなどに対してつらつらと思ってることなど書いておこうかなと。

続きを読む

サーバサイド開発未経験者がRuby on Railsで躓いたところ

全国の新卒エンジニアの皆さん、元気してますか。私はというと学生の頃クライアントしか触ってなかったのに気づいたら半年ほどガッツリとRailsで書かれたゲームのバックエンドのWebAPIと格闘していました…。

で、サーバサイドの開発経験が無い状態でいきなり取り掛かったものですから、色々前提として必要な知識が穴ぼこになっていて結構苦労したみたいなところがありまして。どこらへんで引っかかったかなってのを記録しておくと後々便利だと思ったので、久しぶりにエントリを書いてみます。

もし気づいた点などあればコメント欄や@yashiheiまでマサカリをお待ちしております。

続きを読む

ソリッドな絵をサクッと構築出来る、COLRがいい感じ

assetstore.unity.com

ソリッドな絵、良いですよね。モバイルゲームとかでも、安くて美味い表現方法として多用されている様に感じます。

※安くて美味い点

  • ローポリで十分映えるので、リソースとなるモデルを調達するのが比較的楽
  • 表現のコストが高くないので、大抵のデバイスで動く
  • 一定のアート性がある

そんな、ソリッドな絵をサクッと構築出来るアセット、COLRがいい感じだったので、使い方も含めて紹介したいと思います。

続きを読む