10月ぐらいにprivateなWikiに書いた記事なんですが、中々面白い差分に着目してて眠らせるには惜しい記事だったのでブログにも転載しました。
続きを読むAffogato
ものづくりに関わってると日頃からイデオロギーの対立に向き合うことになります。AとB、どちらが良いのだろうか。いやBは絶対に無い。Bを支持するやつはどうかしてるなど。
ナツ「『アフォガート』って言うの。知ってた？」
ナツ「甘みの代表格とも言えるバニラアイスと、苦味の代表格とも言えるエスプレッソの融合。」
ナツ「一節によると優に数千を超えると言われているスイーツの中でも、絶品だと名高いもののひとつなんだー。」
ブルアカで一番好きな絆ストーリーです。ナツが絶品のスイーツ「アフォガート」を例にアウフヘーベンの概念を教えてくれます。
日本語では「止揚」「揚棄」と訳される。
ヘーゲル弁証法における根本概念。
あるひとつの命題（テーゼ）と、それに反対・矛盾する反命題（アンチテーゼ）との二つの相反する命題を、互いに否定しつつも生かして統合し、より高次元の段階である総合命題（ジンテーゼ）を導くこと。
アウフヘーベンとは 一般の人気・最新記事を集めました - はてな
アウフヘーベン、最近知った言葉ですがものづくりには欠かせない考え方だと思うようになってきました。
一つの考え方を依り代に殻に閉じこもってるようだと、遅かれ早かれ限界にぶち当たります。もっと広く当たらないと行けない。思ってた以上に自分の知ってる世界は狭い。数年キャリアを積んできたのだからあら方知ってるだろうという油断がある、実は何も分かってなかったりする。
もっと死角を突いてみる必要があるのだと思います。もっと死角を突いてくれる人が欲しい。
なので最近の僕は昨日までAは無いなーって言ってたけどひょんなきっかけでAを深掘りしたら面白いところあるじゃんってコロッと認識を変えて周りに広めたり、エンジニアがそんなことまでするの？ってことに興味持って手を出したりしてます。
ナツも満足出来るような、美味しいアフォガートを作りたいですね。
ソフトウェアとアタシ再生産
この間、ダイナミックなリファクタリングをコアなロジックに施術した。
正直このレベルの変更をするのはチームでも難しいと言われてて、かつ重要なロジックなので変更が難しかったのだが、今回思い切ってやってしまった。
そういった壊して作り直すことを考えてたら浮かんできた記事。
"ソフト"ウェアに寿命があるとするなら、その命が尽きるのは変更が無理になってしまったときなのだと思う。
幸運にも生き残ってしまったソフトウェアは、絶え間ない機能追加と仕様変更の波に晒されることになる。初期の頃上手く言ってた設計も日が経つに連れて、限界を迎えてしまう。
ソフトウェアの死は事業の死にも直結する。何も遊びの変化の無いゲームを遊び続けてくれるユーザーは居ないだろう。
とはいえリファクタリングは無尽蔵に出来るものでは無い。私はリファクタリングの成功には経済的合理性が必要だと思ってる。ただの自己満足なのか、それとも事業をより前に進めるための必要経費なのか。
前者は完璧主義なソフトウェアエンジニアが陥ってしまう(私も例外ではないが)罠で、そのリスクはよく知られているはず。より良いものは作りたいが、何から何まで完璧にすることなんてのは諦めたほうが良い。
ただ、後者が必要なタイミングというのは往々にしてやってくる。今回は明らかにそのタイミングだった。
巨大に膨れ上がったトランザクションスクリプトの一挙一動を知ってるのは最早限られた人しかおらず、何もかも読みにくい、この上に更に新規機能を加えるなんてのは流石に出来ないと。
複雑に絡み合ったロジックを紐解いて分かりやすく再構築するのはやっぱ並大抵な難易度じゃない。もっの凄いエネルギーを使う。紐解いて再構築するの大好きなので楽しかったけど。
こうやってソフトウェアを作り変えることをやってると、去年観たレヴュースタァライトという映画を思い出した。あれは舞台のお話だけど、ソフトウェアも似たようなものかもしれない。囚われ変わらないものは、やがて朽ち果て死んでゆく。アタシ再生産。
かつての私はこんな攻撃的なコードは書かなかったなと思う。もっと保守的に書いてた。既存の思想に従った、影響範囲が出来るだけ狭くなるような、そういった改修を自然と選択してた。その選択も間違ってはいないが(実際自分の改修はバグが少なかった)、逆に負債を溜めてしまう結果にも繋がっていた。
0と1で判断出来るようなことじゃなくて、グラーデーションのある事柄なので、何が正しいなんて言えない。けど、変化することを恐れたくないという祈りなのだと思う。
22/06/24 一部添削
ソフトウェアの昔ばなしをひたすら聴きたい
↑会社的にブログ頑張っていくぞ～～みたいなムーブメントあったので、便乗して記事書いた。この場末のブログに書くなんかよりは、PVもそこそこあった感じ。
それはそうとして、この技術の文脈をどう捉えていくかみたいなのは我々新参者には結構深刻な問題だと思う。
例えば今自分が所属してるプロジェクトで、キャッチアップが難しかったなぁと思える技術を上げていくと…
- Clean Architecture
- Zenject
- UniTask
- UniRx
- gRPC
で、これらの技術をどうやって理解していったかって、やっぱり表面じゃなくて、そもそもこの技術は何を解決したいんだっけ？ってのを歴史から紐解くのが一番分かりやすかったんですよね。
Clean Architectureなんてその最たる例で、あの同心円状の図から入るとかは最悪ですよね。レシピを覚えることにあまり意味はなくて、レシピに至るまでの道を理解することが大事で、そこから発展させる必要があるのだけど、レシピで止まってしまうエンジニアも少なくない…。かくいう私もそのレシピに弄ばれた一人ですが。
別にこれは、採用してる技術だけではなくて、今私達が書いてるソフトウェアにも当てはまる話で、何でうちのソフトウェアこんなアーキテクチャしてるんだっけ…？って気づいたら誰も知らないなんて良くある。そこでチームの最古参のメンバーが「昔々かれこれこういう理由で…」と紐解くと、なるほどなーとなったりする。他にもgit blameから古代のPRを引っ張って読み解いたり(これを考古学と呼んでる)
そういう語り継ぐ人が残ってるのは幸運な例なのかなとは思ってて、現実としてコンテキストが喪失してるなんてことも良くある。つらい。いつ消えても大丈夫なように、ドキュメントは書こう。
なので、ソフトウェアの昔ばなしというものがとても面白いなあと思うようになってきた。もっとソフトウェアの歴史知りたい。
最適化に初めて取り組んだ話
しばらく最適化沼に浸かってたときの回想です。
続きを読む最近考えてるゲ開発における設計の話
最近社内の勉強会っぽいところで、ソフトウェアの設計について少し語ったのですが、何だかんだ消化しきれないところがあったのでまとめてみます。
続きを読む