メインコンテンツまでスキップ

プログラミングについてアレコレ

Sato Taichi

上記 2 つのエントリが面白かったので@voluntas の煽りに乗ってみることにした。

実装の話は随分前に書いたので、それはそれで発掘しておく。

沢山のコードを読む#

世の中流行り廃りが結構あるので、色んなコードを読んでいる。食わず嫌いは基本しない方向で。

例えば、GitHub でスターを付けたリポジトリは、どれもひと通り目を通してる。

最近だと golang、Javascript、CoffeeScript、Ruby、Scala、Java、Objective-C、辺りが多い印象。

アウトプットサイクルとインプットサイクルに傾斜を付ける#

どちらかというとコードを読む時期と、どちらかというとコードを書く時期にメリハリを付けている。

ちなみに、今はコードを書く方が多い時期。

コードを書くほうが多い時期は年間に 4 ヶ月もないので大事にする。

複数のスタイルを使い分ける#

サンドボックスプログラミング#

主に自分に馴染みのない言語やプラットフォームでコードを書く時のスタイル

外的な仕様が頭のなかで明瞭になるまで、色んな仕様書やコードを兎に角沢山読む。既存のライブラリがあるなら、それを動かす。最初は基本的にコードを書かない。

そこから徐々にコードを少し書いてはデバッガを使って動かす。

テストコードを書けるくらいに習熟してきたら、ドライバ部分はテストコードにする。設計とかそういうのではない。

コードを書き始めるまでに明瞭化した外的な仕様が概ね満たされるまでは、かなりダーティなコードでも動かすことを第一に書く。

仕様が概ね満たされたら、一旦コードを全部捨てる。 ここまでに書いたものは動いているだけでゴミであるとの認識。ゴミを作ったところで終ることも多い。

今度は仕様書としてメモをザックリと書いた上で、それなりに正しいコードを一気に書く。

ある程度の品質保証を目的としたテストコードを書いて一気に書いたコードを洗練する。

仕事プログラミング#

自分に強く馴染んでいる言語やプラットフォームで対価を貰う時のスタイル

外的な仕様が頭のなかで明瞭になるまで、色んな仕様書やコードを兎に角沢山読む。既存のライブラリがあるなら、それを動かす。最初は基本的にコードを書かない。

仕様が明瞭になったら、日本語で仕様書を書く。 この仕様書はコンセンサスをとる為のドキュメントで基本的には非プログラマ向けの資料となる。

仕様書を根拠に作業見積もりを作る。仕事プログラミングでは正確な見積りこそが一番大事だと考えている。

高品質な成果が欲しければ、単により多くの時間と金を下さいという話ですね、そこに同意して貰えないなら、それは仕事とは言い難い。

プログラミングする対象の中でインターフェースになる部分から作る。 画面かもしれないし、他のシステムと繋ぐところかもしれないけども兎に角外側から作る。 基本的に価値を評価し易い部分から作る。つまり、エラー処理系は後回しになる。

自動テストをガリガリ回してリファクタリングする程に時間が貰えることは少ない。 それでも、品質保証の為のテストコードは書く。設計のためのテストコードはあまり書かない。

最初の 2 人が書いてないことで、僕が気にしてることは大体書いた感じ。