人を子供扱いすれば、子供のような仕事しかしない。
小さなチーム、大きな仕事はある意味僕の人生を変えた本なのですが、その本の中でも一番好きな一節です。
実戦的なコードの書き方は、どのようにして身に付くものなのでしょうか？
文法を覚えること？ それともオブジェクト指向言語であれば、オブジェクト指向自体を学ぶこと？ 見方を変えて、関数型のエッセンスを学ぶこと？
以前ちょっとお高いプライベート・ジムでトレーニングしていたことがあるのですが、筋力トレーニングって「あ、もうだめかも」というところからが勝負で、そこから歯をくいしばってどのぐらい行けるかが、効率よく筋力アップするコツだということを教わりました。
そういった意味では、プログラミング能力に関しても同じことが言えるのかも知れない、と最近思ったのです。
ふと、「コードを読んでいるときって、どんな思考プロセスで読み進めているんだろう」と思ったのです。
僕はプログラマーなので、毎日人のコードを読んでいます。で、時には他の人が書いたコードをレビューしたりもします。「ふむふむ、ここはこうしとかないとまずいんじゃない？」なんて。
しかし、他人のコードなんて、よく読めているなーと疑問に思い、ふと、その思考プロセスってどんなものなのだろうと考えたのでした。
どんなサービスを利用するのでも、自分のした行動よりも見返りが多い「行動＜見返り」となった時点で価値を感じられるのだと思います。
例えばスマホでタクシーを呼ぼうとしたときに、仮に凄く画面が使いづらかったとして、タクシーを呼べはしたけど、結局電話した方が早かった・・・なんてことがあったりすると、これは行動の割に見返りが少ない「行動＞見返り」の関係なので、アプリの価値が感じられないなー、ということになります。
30歳を迎えて、仕事でも技術でも、様々なことを明文化する必要に迫られることが多くなってきた気がしました。今までやってきたことを分かりやすくいろいろな人に伝えていく技術というのは、どんな場所でも必要とされています。
深くやればやるほど、「そこでしか通用しないやり方／考え方」みたいなのが増えていく気がする。「それだとつぶしがきかない人間になってしまう」といやがって、外の世界に目を向けてみるけど、深くやらない限りクオリティが上がることはないし、だからこそ評価もされない。
中学生ぐらいからプログラミングはしていたのですが、長らくオブジェクト指向というのがよく分かっていない時期がありました。
MFCでプログラミングしたりするためには理解できていなければならないものだったのですが、ものの本を読んでも「Animalクラスを継承したDuckクラスのインスタンスがガーガー鳴く・・・で？」という感じで、全く要領を得られませんでした。
「パフォーマンスは正義」（出展不明）と言われるように、どんなに良いシステムでもパフォーマンスが悪いだけで使われなくなってしまうということは、ままあります。
そんなわけで、11 Best Practices for Low Latency Systemsという記事で低レイテンシなシステムを作るための11のプラクティスが紹介されていたので、ざっくりとご紹介します。