プログラミングについて雑語り

とりあえず失敗しろ。 失敗したら、その失敗がなぜ起きたか考えろ。 その失敗をしないために、どうしたらいいか考えてみろ。 考えたら本当にそれやりたいか考えてみろ。 やってもいいかなって思うくらいの妥協ポイントを見つけろ。 妥協ポイントについてのポイントをまとめて、妥協ポイントをブラッシュアップをしろ。

って冗談。

そこまでやる必要はない。なんとなくアレは失敗だったのかなー？って悩みつつ時間が解決してくれるのを待てばいい。 ポエムとかではなく、これはHow to。

一度は描く理想的な世界

誰でも一度は無駄に考えなきゃいけない事はどこか外側によせておいて、自分が考えたクリーンで簡潔な世界の上でコードを書きたいって思う。 まぁでも実現しない。お前は完璧でも、他が許さない。必ず誰かが理想的な世界を何となく書いたコードでぶち壊す。そしてそれを指摘したお前のほうが気の毒な顔で見られる。 自分一人の趣味コードで書ける？規模が大きくてチームで書くからそういう理想が湧いたんじゃない？ 趣味コードでそんなにコードきれいに書いていける？OSSにすれば？で抽象と具象をごっちゃまぜにしたミルフィーユなコード書くんでしょ？ 思うだけでは無理。どんなコードを書きたいかはっきりさせ、重要なのは強制力をもたせること。 それなりのコスト払うしかないんだよ。やりたくないなら、中庸を目指そう。

ドメイン駆動設計

いやDDDの思想は素晴らしいんだ。 でも自分含めだけど理解できている思った人を見たことがない。 まず、DDDをやる動機って何？DDDやってれば食えていける？ そんなことはない現実問題のほうが大きな比重を占める。 DDDの分析は必要か？自分たちのプロダクトの概観を知るにはいいんだよ。それは成長につながると思う。 けれど、わざわざ名前つけれられるのかよくわからないものにユビキタス言語当てはめるために時間つかってうーんうんうなりながら面倒なこと考えるより なんとなくの共通概念だけでささっとやってしまった方が早い。 まぁ技術的負債になりやすいよ。けどDDDスタイルを免罪符にしたって技術的負債にならないって話ではない。 DDDの良さげなところだけ拾っておくくらいで、雑な方が割と効果が出る。

それでもやってはいけないこと

完璧な設計をめざすことは良いことか？ちがう。そんなことはしてはいけない。 壊れてもすぐに使えるコードを目指せばいい。 壊れても拾えるものがあるコードはすぐに再生する。 ロジックはすぐ壊れるし影響が大きい。自己完結した機能は壊れにくいし、他に影響出しにくい。 なんとなく小分けにしたいからメソッドや関数にするのはだめだ。 その関数はなんであるかをそれ自体に表現させ、そうやって作った関数をつなぎ合わせで壊れることが怖くないコードができる。 （もし意味が分からないならそこまで至っていないのでもっとコード書くしかない。）

言語に精通する必要があるか？

どうだろう？そのソフトウェアの性質に合わせた知識は必要だろう。 パフォーマンスがもとめられる場合の知識と、変更に強いコードを書く場合の知識は違うかもしれない。 やってはいけない事に抜けていたけど、そうであると思っていたものが壊れるようなコードを書くことはやってはいけない。 そのための言語知識も必要になるだろう。さらっと入門書の最後のほうに書いてあることがすごく大事だったりする。全部大事だけど。 けど、机上ではじまらない。何かプロダクトなりのコードを書いて、言語の効率的な書き方も同時に知る必要がある。

他の言語に精通する必要があるか？

緊急をようしない場合は不要かもしれない。 だがその言語のデザインは非常に興味深いので、いろんな言語の外側から見た特徴を知っておくと便利。 いくつか似たような言語機能のデザインがあったとしたら、そこに隠れている問題がある。 そうやって共通点や別の視点からのアプローチがあった場合はそれはプログラミングにおいて重要なトピックスなのだ。 そういうものを知らない手はない。

ねっむ。