オブジェクトによるコラボレーションを定義する時代に変わった。
でも、それだけじゃなかった。
オブジェクト指向プログラミングの時代でも、ただ窮屈な時代はあった。
動物を継承した犬のせいで、オブジェクトは現実の物質から切り離されない誤解。
デザインパターンは、ただ世界を難しくとらえるためのパターンにしか見えなくて辛かった。
その時代のオブジェクトは、フレームワークという複雑な仕組みを構築するためのツールでしか無く
プログラマは、オブジェクト指向プログラミングの申し子のようなフレームワークの上に、いるだけだった。
ただいるだけだった。
オブジェクト指向なんて概念の一切の無い、ただの実体定義する作業でしか無かった。手続き言語の時代と変わらない。
でも、本当に複雑なのは、フレームワークじゃない、表現すべき対象だった。
複雑が故にあきめてただけだった。
キレたら終わる糸をさまざまに張り巡らし、あとは時間という物量の力技で、
綱を渡り終えることを願う、諦める作業こそプログラマの仕事だった。
システムは、常に変化することを要求される。
時間という物量は制限された。
薄っぺらなシンプルな解釈は、システムに小さな変化が発生するだけで
ピンと張られた綱は簡単に弛む。
複雑な対象と向き合うことに拒否することはもう許されない。
そんな時代のSEの仕事は、複雑な対象を複雑だと定義することだ。
プログラマ達が、対象を定義するために必要な、本質を暴きだせ。
それが成功すれば、本質はオブジェクトに変換されて、システムは1つの世界の創造物に生まれ変わる。
※ただし、良いプログラマがいればだが。
お客様の言う通りにするんじゃない。お客様が願ってる世界の本質を暴け。
でも、神の意図を見つけ出し、世界の本質を暴く行為もまた同時に面白い。創造的だ。
もしそれが面白く感じないなら、お前まだコードを書くということに気が付いてない。
俺はもっとコードを書く仕事がしたい。 SEだなんてつまらない。なぜか? つくるものを自分で決められない。お客様の望むとおりにいたします。ふざけろくそが。プログラムを作って...
プログラムが単なる手続きの時代から オブジェクトによるコラボレーションを定義する時代に変わった。 でも、それだけじゃなかった。 オブジェクト指向プログラミングの時代でも...
関数型言語を勉強しような。 あと世界を暴くとかしたいならコードじゃなくて数学をやること。 高校数学とかじゃなくて数学科レベルのやつだぞ。
ああ、ごめん。ドメイン駆動設計を中2病に風に説明しただけで伝わりにくくてごめん。 関数型言語の副作用の排除は、DDDでも不変オブジェクトという副作用関数の排除の根に繋がって...
あっさり論破されてくやしいのぅくやしいのぅwwwwww
数学できないコンプレックスか
考えてみろ。今から10年後に俺は何をしている? システムエンジニアとやらか? お客様に最適なソリューションをインテグレーションいたしますと、澄ました顔で言っているのか...
ミュージシャンを目指した人がいる。 音楽が好きで、自分の音楽で成功したいのだそうだ。 ただ、現実的な問題・怖さからそういった夢を諦めて別の分野で働いている人いる。 そっち...