blog.fuktommy.com

キーワード引数の代わりとしての関数はアリか否か

流れるようなインターフェイス - 予定は未定Blog版から、部分文字列を作る疑似コード？

"hogepiyofoobar".Substr().From(2).To(5);

なんか素直じゃない気がするんですよね。これ、言語仕様が許すのであればキーワード引数を使って

"hogepiyofoobar".substr(from=2, to=5);

と書いた方が素直だと思う。 JavaとかPHPはキーワード引数がないからこんなになっちゃう (元記事はC#なんだけど、C#は知らない)。 PHPだと連想配列を使って、

"hogepiyofoobar".substr(array('from' => 2, 'to' => 5));

みたいなスタイルも可能ではあるのだろうけど、これはこれでもやもやする。

流れるようなインターフェイス、あるいは単なるメソッドチェインでもいいんだけど、 "hoge".substr().from(2).to(5) みたいな書き方をすると、from()関数、to()関数に適切な機能が分割できて、それぞれの関数がすっきりして、使う側からも読みやすくなるというのが幸せなのだろうとは思う。

依存性の逆転原則を生かしてコーディングすると、オブジェクトに、それが依存するオブジェクトをいろいろ設定しなければならなくて、コンストラクタの引数で渡せればいいのだけど、

$hoge = new Hoge(logger = $logger, pdo = $pdo, memcache = $memcache);

のようにキーワード引数が使えないから、

$hoge = Hoge::factory()
      ->withLogger($logger)
      ->withPdo($pdo)
      ->withMemcache($memcache);

こんな風に書いてたりする。妥協の産物ではあるんだけど、 with*() 関数がそれなりにすっきりするので、そんなに嫌いではない。

キーワード引数がもっといろんな言語で使えたらいいんだけどなあ。

説明の下手な人

今さらディズニーが嫌いになったに反応するんだけど、

両親が泊るのを代わりに予約してやっただけなのに、宿泊者名で予約しないとダメですの一点張り。

ディズニーかつ名前つながりで似たようなことがあったからね。保険組合の優待券でディズニーランドに行ったら、優待券には本人が会社名とか被保険者名とか被扶養者名とか書くんですけど、窓口に持って行ったら「被扶養者の名前を書いてください」って言われたんですよ。でも僕は被保険者本人であって、被扶養者ではなかったので、「僕は本人ですよ」と言ったのですが、「被扶養者の名前を書いてください」の一点張り。

これってまずい状態なんですよ。僕としては被扶養者の名前を書きたくないわけじゃなくて、書く内容がないよということ、あるいは「じゃあ何を書けばいいんだよ」「言ってる意味がわからないよ」ということを伝えたいんですけど、それが「僕は本人ですよ」の一点張りになってるんですね。窓口の人には窓口の人なりの考え方があるはずで、「被扶養者の名前を書いてください」の一点張りになってると。

結局「じゃあ何を書けばいいんですか」と聞くことで「本人の名前を書いてください」という返事を引き出すことはできたのだけど、なんかもやもやするんだよなあ。「被保険者本人なら被扶養者名の欄には本人の名前を書いてください」というのは窓口の人が最初に言うことじゃないかと。標準的ではない書き方だし、そういう特殊な書き方をするというのを知っているのは窓口の人で、客としてはそんな特殊ルールの存在にすら思いが至らないので。

私の頭の中のソースコード

今いちばん興味があるのは頭の中にある設計図をできる限りそのままプログラムに書き出すことなんだよね。多くの場合はプログラミング言語の書き方に引きずられて、設計図がそのままプログラムにならない。

コンパイラでソースをアセンブリ言語に変換することができたりするので、それを比喩に使うと、真のソースは頭の中にしかなくて、プログラム書いたよと言ってる「それ」はコンパイル済みのアセンブリコードであり、読もうとすれば読めないこともないけど、ソースじゃないよね、という感じです。

つってもこれって個人的な技能の域を出ない話なんだよなあ。設計の技能、つまり頭の中にある設計図をよりよいものにする技能の方が、よりプロダクトに貢献するだろうし。いやもちろん、設計図がそのままソースコードになっていれば理解しやすいから、メンテナンスコストが下がるとか、重複コードを書かなくて済むようになって開発速度が向上するとか、設計の技能に繋がってはいるはずなんだけど、直結している気はしないんだよね。

うーん。全体設計とかアーキテクトとかいう言葉を意識しすぎ？

プログラムの出来がわかるのは半年後

「渋日記: きれいなソースコードを書けるようになるためには」を読んで連想したこと。プログラムって書いたときには「わかりやすくて、きれいなソースコード書いたぞー」って思ってるはずなんですね。最初から出来が悪いと思ってるコードを本番環境にマージしたりはしないはず。ところがですよ。半年くらい経つと、新機能を追加しなければならなくなったりして、このコードに手を入れることになるんですが、このときに、はたして「わかりやすくて、きれいなソースコード」かというと、そんなことなかったりするんですね。

そもそも何をやってる関数なんだ、これ？
どこに手を入れればいいんだろう？
直すべき箇所はわかったけど、ここを直すと関数名と処理が不整合になっちゃうよな。
直したはいいけど、既存の機能に悪影響を与えていないかな？
短かった関数がどんどん長くなるよー

最初にプログラムを書いているときは、頭の中に完璧な設計図があって、実際のコードはその設計図をきちんと反映してなく、ドキュメントにも設計図はきちんと反映してないのですが、とにかく頭の中の設計図をもとにコーディングして、読んでるので、読めるんですね、きっと。それが半年後になると、頭の中の設計図は失われ、残ったのは不十分なソースコードのみということになってしまうと。

なので「心掛け」としては、「頭の中の設計図を全部コードに反映させさい」ということなのだけど、それはすぐにできるようにはならない。もし昨日やったことを忘れてしまう薬があれば、それを毎日飲むことで頭の中の設計図を消去し、コードしか頼りにならないという状況を作ることで、頭の中の設計図を全部コードに反映させるということができるのだろうけど。

20代後半とか、30代とかになると、脳の力が衰えてきて、頭の中に設計図を保つことができなくなってきて、コードの質を良くしないとコーディングできなくなるというのは、あるかもしれない。