Some Days You Get the Bear

IT系エンジニアの、日々の気づきや考えたこと。

書こうとしなければわからない ~プログラミングとは何か~

設計時は、システムを俯瞰的に見ており、
大きなふるまいのほうに目が行きがちである。
そして、コードになるときの姿を思い描きながら設計するのは、
かなり粒度が小さくなってからだ。

しかしそれでも、実際にプログラムに落とし込むのとは違うのだ。

コードになったときならではの厳格さ、
書くことで明らかになる、プログラムの構造を通しての気づきというのは結構多い。*1

しばらく設計がメインの仕事をしてて、コードをあまり書いていなかったのだけど、
自分でコードを書いてみることで、プログラミングは設計だということが
あらためてよくわかった。
やはり「動かさないとわからない」と書いていた頃よりも、もう少し理解が進んでいる気がする。

設計とプログラミングに境界はないとも書いたけど、
そもそもどちらも設計だった。
そして何よりプログラミングを「製造工程」などと言ってはいけなかった

では、どうやって、
誰かが設計したものを他のプログラマさんにやってもらったらいいのだろう、と思う。
いいしくみがつくれるのだろうか? 仕様書を細かく書けばいいのだろうか?
こういう形態の仕事は実際によくある。社内で若手にしてもらうにしても、他の会社にお願いするにしても。

一般に「自分でやったほうが早い」というのは「NGワード」ではあるけれど、
ことプログラミングに関して言えば、これも頭の片隅に置いておいてよいことではないか、と
最近思い始めている。
自分の仕事≒他の人がやれないところ、と思っているけれど、早さがそうである場合もあるだろうから。

*1:「エディタの色の見え方でコードのへんなところがわかるだろ」と言ったやつがいるんだけど、こいつホントすげーな、と思ったよ。