最近，様々なフレームワークが出てきて開発が非常な時代になりました．開発が楽になった反面，学習コストが下がったかと言うと必ずしもそう言い切れない部分があります．

フレームワークは開発が楽で短い行数で目的の成果物を簡単に出力できます．では，その裏で動いているコードはどうでしょう？　本来であれば数百行必要だったコードが５行ぐらいで動いているとなれば，その圧縮率は凄まじいものがあります．

一方で，そのような黒魔術的な技術はバックグラウンドで動いているコードを隠してしまいます．カプセル化と言えば聞こえはいいのですが，なぜ動いているのか，という思考を巡らせられれば非常に心強いツールであることは間違いないです．

例えばの話ですが，GUIフレームワークである関数の注意書きに「この関数はメインループのメッセージキューにディスパッチされないので，自分でハンドルしてください」と書かれていたらどうでしょう？　この関数，メッセージキューに突っ込めなかったから応急処置的に実装されたんだなぁとか思います．明らかに地雷なのですが，ドキュメントを読んでぱっと思考できるのとできないのとでは，これから訪れる地獄を予想できるかできないか生死の分かれ道みたいなところがあります．

エンジニアリングというものは，こういう基礎ができているか，できていないかで地獄を見たり見なかったりします．基礎力がないと罠が見えないわけです．

親の顔よりフレームワークを見た人であると，ついついフレームワークのことしか考えられないかもしれませんが，フレームワークも流行り廃りがあるので１ヶ月後にイケイケなフレームワークが出てきて仕事を奪われることがあります．

こうならないためには，プログラミング言語の基礎を学習することであったり，文字列操作とかに頼らず整数型配列だけで文字列を表現してみるとか，ある程度の訓練であったりアルゴリズムの学習は必要です．

だいぶオブラートに包みましたが，エンジニアとしてフレームワークしか使えない人はフレームワークを使えない環境に放り込めないので仕事の幅がめっちゃ少なくなるので基礎をちゃんと学習しようということです．

基礎的なところだと基本情報処理技術者試験は受験しなくても学習する価値があります．時間はかかりますがなぜコンピュータが動いているのか理解することがITエンジニアとして大切だと思います．

なぜこのようなことを書くのか？

最近，電磁場解析をするのにUnityを使っていたのですが，メモリ効率が悪くて32GBもメモリを積んでいるのに仮想メモリにお漏らししていました．GCを回しても全く解決せず，デバッグを実行するだけで2時間も待たされるのでこれはまずいと．

仕方がないのでC++でちゃんとメモリを管理しようという話になるのですが，Unityでオーバーヘッドが発生したいくつかの部分はわかるのでどこを潰せばいいのかはわかります．一方で，早くしようとすると様々なアルゴリズムを駆使しなければなりません．

メモリ効率でここまで悩んだのはおよそ8年ぶりぐらいだと思います．一方で，高速化をすると様々なアルゴリズムが必要になります．

例えば，文字列を数値に変換する，という部分を取っても1GBを超えるデータをメモリにぶち込んで改行位置を探してポインタを置くとか，大量のデータをゼロクリアするのに領域をdouble型に変換してSIMDでまるっと32バイト単位で初期化しようとか，結構頭を悩ませるわけです．

システムの性能に問題があるとき，コンピュータと仲良くした時期が長いと解決する方法や実装としてどんなものが挙げられるか，頭の中で考えられるというのは大きいです．

正直なところ数年前からの積み重ねになってしまいますが，初心者の頃から2年3年とフレームワークですり潰すのではなく，コンピュータと仲良くなっていないと今後キャリアを考えたときに結構ヒヤヒヤすることがあった，という次第です．