考え方の違い

最近、考え方に大きな溝があることに気づいた。
周りのみんなはこんな感じ。

  • ソースから何かを読み取ろうとはしない
  • プレーンテキスト*1を使うことを退化だと考えている
  • コードを割り当てることが設計だと思っている節がある
  • 同じコードブロックに対するテストが複数箇所に存在しても気にしない*2

ソースから何かを読み取ろうとはしない

真っ先にソース読むべきとは言わないけど、ソースを読まなさすぎるのもどんなもんかと。
つか、ドキュメント同士のつながり云々言うなら、それこそHTMLとか使ったほうがいいんじゃないか、とか思わなくもない*3
まぁ、あれだけ汚いソースを書いてれば読む気もなくすってもんだろうけど、ドキュメント類はさらにひどいという何のためにドキュメントを作ってるか全くわからない。

プレーンテキストを使うことを退化だと考えている

みんななんであんなにExcel*4好きなんだろうと疑問に思ってたんだけど、どうもテキスト形式に「戻る」ことを「退化」と考えているっぽい。
そもそもExcelを使うことは「進んで」いるのか?というのは置いておくとして、みんなテキスト処理は手作業で行うものだと思っているらしい。
キーマクロや正規表現pythongawkとか使ってテキストファイルを処理してるところを見ては、「そんな便利なものがあるんだ」とか、「そんなことできるんだ」とか言うんだけど、そこから踏み出さない。
仕事は楽しようと考えてるみたいだけど、他に何も苦労せずに楽しようとしか考えてないんじゃないかと。勉強しろよ・・・

コードを割り当てることが設計だと思っている節がある

そのままですね。そこらじゅうに意味不明なコード*5があって、それを管理するためのドキュメント群がある。
で、設計書*6にはそのコードしか載っていないという罠。
連番と決まっていたはずのコードに抜けがあって、それを指摘したら、「何だよー、設計しなおしかよー」・・・って、コード割り当てるのが設計かよ。


と思ったけど、今考えればあれか。設計書*7に散らばったコードを更新しなおさないといけない、という意味か。
でも、それにしたってそれは設計のし直しとは言わんだろ。

同じコードブロックに対するテストが複数箇所に存在しても気にしない

というか、テストケースをとにかく増やしたいらしい。
で、作ったテストケースは基本的に最初の一回しかまともに全部は行われない。
修正があるたびに手動目視であんな大量のテストやってれませんもんね・・・って、それテストの意味が・・・
そもそも「何らかのアクション*8に対する何らかのアウトプット*9」のテストが最小の粒度のテストって時点で何かがおかしい。


・・・あー、ここまで書いてて重大なことに気づいた。
そういえばみんな、メソッドにまとめるということをしないんだった。
同じコードブロックに対するテストが複数個所に存在するのは俺の書いたコードだけかも。

*1:ここではテキストエディタで読み書きできる形式のことね

*2:むしろいいことだと思っている

*3:顧客に納品しなくていいならTracのWiki使えば便利なんだろうけど・・・もうちょっとHTMLが印刷に強くなってくれると嬉しいなぁ

*4:・・・じゃなかった。EXCEL

*5:エラーコードやらメッセージIDやらその他いろいろ

*6:と呼ばれている紙くず・・・じゃなくてExcelくず

*7:と呼ばれている(ry

*8:アプリケーションを起動する、だとか、ボタンを押す、だとか

*9:DBにこういうデータが挿入される、だとかどこどこのセルにこういう値が表示される、だとか