プログラミングはそれ自体が目的であっていい
これ読んで思ったこと。
プログラミングを勉強したい人が勉強する前にすべきこと - もとまか日記 http://d.hatena.ne.jp/moto_maka/20130512/1368308092
僕がプログラミングをはじめたとき、何を思ってプログラミングをはじめたか思い出してみようとしたけど、よく思い出せなかった。 ただ漠然と感じていたのは、プログラミングは個人が現実的にこの世界に直接手を加えることができる手段の1つであり、それをやらないのは勿体無い、といったことだったと思う。たぶん。 というわけで、最初にやったのはFirefoxのユーザースクリプトを書くことだったし、それはそれでよい経験だった。なんとなくゲームとかウェブアプリとか作りてーなー、と思って色んなライブラリを動かすだけ動かして満足した。プログラミング覚えて初めて最初の一年で10以上の言語のHelloWorldだけやったと思う。その結果Unixの環境構築がうまくなった。 その後はひたすらいろんな言語のウェブフレームワークを触り、PythonとMongoDBで遊んでいた。グラフィック関係もやりたくなったのでJavaScriptのHTML5Canvasで迷路を書いて、A*のアルゴリズムで最短経路を解かせたりしていた。
自分が地力でそこに行き着くまでに覚えた環境構築、ライブラリごとの思想、言語の触り心地、出来上がったアプリの感触、そこに無駄だったものは何一つ無い。 半年でアプリが作れる！という謳い文句を僕は信じていない。そこに至る全てをオミットしているからだ。ちょっとパラダイムが変わると簡単にハマってしまうからだ。現実のアプリを作るレベルで、最短経路の知識で済むこと絶対に無い。 大事なのは、いくつ地雷を踏んだか、だ。地雷を踏んだ数だけ強く慣れる。真に必要なのは、独力での問題解決能力。Python2系でsjisのHTMLをlxmlでスクレーピングすると、地雷を7つぐらい同時に踏めるからおすすめだ。
話題になった技術は概要を読むだけでなく、自分の手で動かすことが大事だと思っている。サンプルを少しづつ変更して、この技術は、何を許して何を許さないかを知ること。それが欠けたプログラミング技術は、ネタなしの寿司である。
僕がプログラミングをはじめたとき、何を思ってプログラミングをはじめたか思い出してみようとしたけど、よく思い出せなかった。 ただ漠然と感じていたのは、プログラミングは個人が現実的にこの世界に直接手を加えることができる手段の1つであり、それをやらないのは勿体無い、といったことだったと思う。たぶん。 というわけで、最初にやったのはFirefoxのユーザースクリプトを書くことだったし、それはそれでよい経験だった。なんとなくゲームとかウェブアプリとか作りてーなー、と思って色んなライブラリを動かすだけ動かして満足した。プログラミング覚えて初めて最初の一年で10以上の言語のHelloWorldだけやったと思う。その結果Unixの環境構築がうまくなった。 その後はひたすらいろんな言語のウェブフレームワークを触り、PythonとMongoDBで遊んでいた。グラフィック関係もやりたくなったのでJavaScriptのHTML5Canvasで迷路を書いて、A*のアルゴリズムで最短経路を解かせたりしていた。
自分が地力でそこに行き着くまでに覚えた環境構築、ライブラリごとの思想、言語の触り心地、出来上がったアプリの感触、そこに無駄だったものは何一つ無い。 半年でアプリが作れる！という謳い文句を僕は信じていない。そこに至る全てをオミットしているからだ。ちょっとパラダイムが変わると簡単にハマってしまうからだ。現実のアプリを作るレベルで、最短経路の知識で済むこと絶対に無い。 大事なのは、いくつ地雷を踏んだか、だ。地雷を踏んだ数だけ強く慣れる。真に必要なのは、独力での問題解決能力。Python2系でsjisのHTMLをlxmlでスクレーピングすると、地雷を7つぐらい同時に踏めるからおすすめだ。
話題になった技術は概要を読むだけでなく、自分の手で動かすことが大事だと思っている。サンプルを少しづつ変更して、この技術は、何を許して何を許さないかを知ること。それが欠けたプログラミング技術は、ネタなしの寿司である。
プラグマティズムと理想
これは業務としてプログラミングをするようになって気づいたんだけど、﹁動けばいい﹂というだけの指針で設計されたコードは、ほとんどにおいて糞コードである。
たとえばリファクターを嫌う創業者が、動けばいいというマインドを共有した技術者だけを集めて書かせたコードは、往々にして破綻する。︵この業界で一番よくあるパターンだ)
﹁動けばいい﹂はプロジェクト初動においてはものすごいベロシティを発揮するが、それを継続するのは至難の技だ。そしてそれを難しいと伝えることは難しい。人は経験からしか学べず、しかもより直近の経験から学ぶから、直近の見た目上のベロシティにバイアスが引っ張られる。コードが書けない人はなおさらだ。
このようなことを起こさないために、そこで必要になるのはある種の言語マニアのような人の存在だと思っている。数万行のコードベース、大規模なアーキテクチャを成立させるためのスキルは、偏執的なデザインパターンや設計に対する執着、言語仕様に対する深い理解から生まれると僕は思っている。︵さらに言うと仕様理解度もだが、ここでは割愛する
モデルとビューの分離の指針、デザインパターンの準拠、インスタンスを握るスコープの最小化や、組み込みメソッドによるコードの単純化、そういうのにこだわりを持つ人のレビューがあって、はじめてまともなコードが成立する。継承地獄やシングルトンという名のグローバル変数が検知されず、使用しているライブラリのデザインパターンを無知ゆえに独自の解釈でねじ曲げた場合、糞コード一直線だろう。
僕がよく個人的によくやるリファクタリングは、糞コードに至るプログラムのフローだけ整えておいて、どうしようもなく出来上がった糞コードを一箇所に押し込める。﹁副作用が0﹂もしくは﹁副作用しか無い﹂ようなメソッドに抽出しておく。その際はメソッド名で、副作用があるかないかわかりやすくしておく。 ここのリファクタリングは、思いついたらやる。だいたい他の箇所のコード書いてるとこう書けばよかったんだって気づく。
モデルとビューの分離の指針、デザインパターンの準拠、インスタンスを握るスコープの最小化や、組み込みメソッドによるコードの単純化、そういうのにこだわりを持つ人のレビューがあって、はじめてまともなコードが成立する。継承地獄やシングルトンという名のグローバル変数が検知されず、使用しているライブラリのデザインパターンを無知ゆえに独自の解釈でねじ曲げた場合、糞コード一直線だろう。
僕がよく個人的によくやるリファクタリングは、糞コードに至るプログラムのフローだけ整えておいて、どうしようもなく出来上がった糞コードを一箇所に押し込める。﹁副作用が0﹂もしくは﹁副作用しか無い﹂ようなメソッドに抽出しておく。その際はメソッド名で、副作用があるかないかわかりやすくしておく。 ここのリファクタリングは、思いついたらやる。だいたい他の箇所のコード書いてるとこう書けばよかったんだって気づく。
言語にしか興味が無い人
たとえば、Rubyist達はRubyで書くこと自体を目的にしているケースをよくみる。一般的に、コミュニティが小さい言語ほどコードの質は高い。美しいコードに囲まれて生活するということは、それだけが彼らの転職目的になりえるわけだ︵Rubyを書きたいから転職、もこの業界でよくみるものの1つだ。
プログラミング自体を目的にした人達は、基本的にHaskellかLispの関数型言語に手を出す印象がある。それはもちろん小さいコミュニティで、コードの品質が高く、言語そのものに対する研究に興味がむくからだろう。
僕もまあそれなりに手を出しているのだけど、他の人も抑えるべきだと思った概念は、次のものだ。
●Haskellにおける入出力IOと副作用の概念
●HaskellのMaybe, またはScalaのOption型
●Scalaのtrait
●Node.jsの非同期Promiseパターン
●C#のgetter/setter/readonly/async等の型アノテーション
それほど敷居が高くないのを選んだので(Haskellの非同期IOはちょっときついが)、興味がある人は調べるといいと思う。
最後に
この記事は昼間からLeague of Legends を飲酒プレーしながらはてブ眺めてたら意識が高まりウッってなったので書いた
