結局定義と評価が大事なのではないだろうか

Note

#抽象

syakoo

最近、私はプログラミングにおける抽象のことについて興味があり色々考えている。

抽象というものは具体に比べると普遍的なものであり、そこが魅力ではある一方ですでに言葉の定義や理論の発達が進んでいるため 「これいいアイデアかも?」と思っても既に言葉の定義付けがされていたり間違えた言葉選びをしてしまうのが怖くてどうしてもインプット >>> アウトプットになってしまう。

が、何もアウトプットをしないとなると進捗がなく感じ、時間が過ぎる一方で辛いので「雑記」として日々の気付きを残すのはアリかなと思いやってみる。

結局定義と評価が大事なのではないだろうか

flowchart LR
nd1["定義"]
--> nd2("評価")

例えば関数は定義するとそのもの自体が生まれ、使うと評価される。 最近の自分の思考のブームは、プログラミングにおいて定義と評価がそのシステムの設計やパフォーマンスなど色々な要素に影響するのではないかということである。 例えば、関数として抽象化するときにその関数の定義場所によって凝集性が変わるし DI のように引数で渡すようにすると関数の決定(評価)が遅れて依存性逆転を防ぐこともできる。

最近のフロントエンドの動向である React Server Component などもいわゆる部分評価によりランタイム(クライアント)のパフォーマンスを軽減する目的なのではないかと思っている。 一見新しい技術で良いものに感じるが、評価の変更は設計にも影響するためいわゆるトレードオフのように感じておりほどほどにといった印象。 page ディレクトリか app ディレクトリで全然異なるシステムになるのでエンジニアとしては大変だなーと感じている。

話がそれてしまったが、最近はシステムにおいて定義と評価が大事だと考えており、レビュー時にもそこを重点的に見ていこうかなと思っている。 この「評価」について私は Haskell を軽くかじっているためなんとなくは分かるが正直全然わかっていない... のですぐポチった 🙃:

関数プログラミング実践入門

こちらの記事も参考になるのでぜひ:

"評価戦略"について勉強したことの整理 - Qiita
学習の素材は、関数プログラミング実践入門この表記は、私見・感想です。評価戦略と遅延評価遅延評価は、評価戦略( evaluation strategy ) の一種である。評価戦略とは、与えられ…
qiita.com
"評価戦略"について勉強したことの整理 - Qiita