抽象化

描主宇田川浩行K#F85E
下描き希哲8年(2014年)
06月13日 22:17
利承
ライセンス
希哲館普通利承(KULクール
この描出は「素描」です。
「なんでもメモ」サービス、デライト公開中!
https://dlt.kitetu.com

広告

一覧

=}{*}

あと,「函数再利用のためにあるもの」という考え方もちょっと語弊がある。一箇所からしか参照されない函数でも適切な粒度であれば見通し抽象化に貢献するし,そもそも再利用性というのは,交度コード)を分割していく過程で気付いたりするものなので,函数化出来そうなものは片っ端からするくらいでいい。

=}{*}

デライト開発でも,出場DB)とのやりとりを抽象化した DGDBI だの,HTTP APIKNEST だの,要素技術を色々整備してきたのだが,つくづく柔品(ソフトウェア)開発って概念化作業だなと思う。物作りとは全然違う。

=}{*}

=}{*}

動物行動最適化するためのものなので,「必要十分な精度」で世界を捉えるように出来ている。その単位を「輪郭」として抽象化し,操作出来るように体系化したのが輪郭法

=}{*}

「年季の入った論組屋プログラマー)」の仕事を見ていると,日本人は「抽象化」が苦手なのかもしれないと思うことがある。結果だけを見れば必要の無い交度コード)の抽象化を嫌うというか。良い意味での冗長性を評価出来ないというか。

=}{*}

私は結構新しめの論組屋(プログラマ)なので,古めの論組屋がテトリス感覚で「これとこれはまとめた方が効率的」みたいなことをやるのに驚いた記憶がある。いや,それをやると後で訳わからなくなるから,というところで。

=}{*}

今と昔の論組(プログラミング)に求められるものの違いって,やっぱり抽象的な思考能力だと思う。昔の論組屋(プログラマ)って,考え方が職人的というか工作的な気がする。「意図が異なっても効果が同じものはまとめちゃう」みたいな傾向がある。

出力論組プログラム虎哲*イチ 1.01
制作・運営:希哲社
© K1-13 (2007-2019) KiTetuSha