プログラマのお仕事

それはプログラムを書くこと

終わ…らない。

プログラムを書く際に必要となるのは「論理的思考」
間違っても設計書通りに作成することではない。

抽象的な書き方だけど、整理し、重複を排除し、綺麗に整える。

依頼されたものを作るのも自分で考えて作るのも一緒。

1.どうするべきか考え、仮説を立てる(設計)
2.仮説に従いやってみる(プログラミング)
3.仮説通りか確認してみる(テスト)

結果、思っていた通り      → 1に戻る(次の作業)
結果、思っていた通りに行かない → 1に戻る(同じ作業)

ひたすらこの繰り返し。

仮に1から2に進めない場合は、1で考えている範囲が広すぎたり、難易度が高すぎるので、そもそもの作業分解度をもっと細かくすべき。人は「イメージできるものしか作れない」ということ。

1〜3の工程で使う時間は内容によるので何分がちょうどいいとかはない。「if文書いてtrueならa、falseならbになる」を確認するレベルなら1分でもできそう。ただ経験上、1サイクルが終わるまでの時間配分は次ぐらいの割合。

1.考える(50%)
2.やってみる(20%)
3.確認する(30%)

よく、PDCAサイクルとかいうけど、Aはいらない。なぜかというとAct(改善)は次のPlan(計画)と同義であり、実際に行動しているのに、わざわざAct(改善)で手を止めるというのはかなり滑稽な状況に陥る。もしAct(改善)を必要とするのであれば、それはマネジメント側。つまり外側から見て、大きなズレがないかを確認する立場の人間だと思う。

PDC → PDC → PDC → PDC → …

ちょうどこんなイメージ。


つまり、プログラマのお仕事は「じっくり考え、素早く試し、素早く確認する」だと思う。

プログラミングするのに以下のようなものがオプションとして付く場合、思考の妨げとなるため、同じプログラミングであっても、2倍3倍とかかる時間が増えると思った方がいい。

設計書

設計(デザイン)は必要だが、必ずしも書類を準備する必要はない。
記憶を留める。確定事項を共有する。
という目的には適合するので、絶対不要ではないが、いちいち書く必要はない。

コーディング規約

何十人もいるならまだしも2、3人でやるなら存在が悪になる。
ないとダメという人はプログラミングやめた方がいい。

チェックリスト

確認する立場の人間が持つのに相応しいと思うが、
プログラマが自己でチェックで運用するのであれば無意味。時間の無駄。

命名規約

常識がある人には不要

どれもこれも、マネジメント側が整理やチェックすればいいものばかりだと思うよ(。・ω・)ノ゙