タイプライターから似非プログラマへのステップアップ

None

どうも、一日の大半をプログラミングか実験で過ごしている有末です。

最近Kawaz内で勉強会が盛んに開かれていてたくさんの人材が育っているのが羨ましいので プログラマ向けの戯言を書きますよっと。

さて、せっかく書いたんですが、この記事は以下に当てはまるような方は読まないほうが無難です。

  1. 納期が迫っている人

  2. 会社のコーディングルールが意味不明な人

  3. プログラムを始めたばかりで息をするようにプログラミング できていないひと

  4. 逆にプログラム玄人で食事も取らずにガリガリプログラミング してしまうような人

これらの人はこの記事を読むことにより甚大な被害が発生するおそれがあるので注意してください。 とくに納期が迫っている人は、さっさと仕事しろ。

1. 開発環境を見なおそう

真のプログラマはiPhoneでも開発出来ると思いますが、僕は似非プログラマなので無理です。なので 快適な開発環境は開発効率に直結します。以下に見直すべき項目をあげました。

  1. 現実のデスクトップの広さ

    資料を広げたり、メモ書きをとったり…プログラマは広いデスクが必要です。

  2. デュアルディスプレイにしてみる

    プログラミングは常に資料との格闘です。デュアルディスプレイにして片方に ブラウザを起動しておくと効率がグンっとアップします。

    予算的に難しい人は「仮想デスクトップ」の導入を検討してください。 Mac / Linux は標準で、Windowsではいくつかのフリーソフトで導入することが 可能です。

    なお、有末はデュアルディスプレイに仮想デスクトップ12枚で開発を行っています。 ライブラリを並行で複数個開発することが多いのでこの枚数です(笑

  3. 物理メモリを見直してみる

    先の仮想デスクトップに関係するのですが、プログラマはCPUやGPUよりもメモリ容量 のほうが重要なことが多いと思います。ゲーマーや音屋、3DCG屋ほどは必要としませんが ある程度余裕をもったメモリ容量が好ましいです。

    なお仮想OSを使用する場合(Linux で IEのテストを行う場合など)はかなりの容量を 必要とします。

  4. 「え?私のキーボード、安すぎ!?」

    リアルフォースを買いましょう。キーボードに万札を出すのはプログラマの特権です。

  5. キーボードショートカット

    Visual Studio, Eclipse, Xcode ... 様々な総合開発環境があると思いますが、それぞれ キーボードショートカットなどが有ります。デフォルトのキーボードショートカットに 体を鳴らすか自分でルールを決めてキーボードショートカットを合わせましょう。

    マウスを極力触らないで開発が出来るように努めましょう。

  6. Vim / Emacs の導入

    C#やJavaを使っている人には無縁かもしれませんが LL を書く人にとっては革命的とも 言える Vim / Emacs の導入をお勧めします。これらのエディタは学習コストが非常に 高いですが得られるアドバンテージも計り知れません。

    なおこれらのエディタを使用するとマウス使用量を90%くらい削減できるので、時間に余裕が ある方は自分の体を Vim / Emacs 風に鍛えあげましょう。それぞれのエディタでの鍛え方 は下記を参照してください

    Vimの場合 : 目をつぶっていても Esc を押せるように何度も反復練習をしましょう。最初の方は Esc に野球ボールでも接着剤で貼っておくといいかもしれません。また http://image.itmedia.co.jp/nl/articles/1202/14/ah_cushion1.jpg のような ものを利用することで Esc と友達になる方法も推奨されています

    Emacsの場合 : Emacs を使う人は左手の小指を鍛えましょう。目標は左手の小指で腕立て伏せが出来るようになることです。 熟練者は100倍重力の中でも腕立て伏せができ、エディタ戦争においては「Ctrlのことかーーーー!」と 怒鳴りながら髪の毛が金色に染まるようです

2. ドキュメントを読もう

メーリングリストや掲示板を見ていると「〜のここに書いてあるけど…」で始まる回答が多々見受けられます。 このように多くの場合質問者が疑問に思っていることはドキュメントに書いてあります。ドキュメントを深く 読み込むことでこのような無意味な質問をしなくなり、世界は平和になると思います。

なお、プログラミングのレベルに比例して日本語ドキュメントの数は減っていきます。Kawazトッププログラマ 達の多くは日本語ドキュメントを見る機会がものすごく少なく「あれ?これやってるの日本で俺だけじゃね?」状態になっています。 (多くの場合日本語化されていないだけでやっている人はたくさん居るので、自慢するのは自重しておきましょう) そういう時、彼らは英語ドキュメントを読みます。というか日本語ドキュメントがあっても好んで英語ドキュメントを 読みます。日本語ドキュメントは最新版では無かったり、すべての情報が載っていないことが多いので一歩上のプログラマ になるためには英語ドキュメントを読みましょう。

3. ソースコードを読もう

ドキュメントが見つからない?あれ?それオープンソースじゃね?

あなたはプログラマです。プログラマは自分の使用している「言語」を判読する能力を持ち合わせています。 ドキュメントが見つからないからといって諦めないでソースコードを読みましょう。すべてはそこに書かれています。 ソースコードを読むと以下のような利点があります。

  1. たくさんの人にリファクタリングされた美しい実装を読むことができ、自分の知らなかった世界を知ることが出来る。

  2. とりあえず実装された美しい(笑)実装を読むことができ、自分の知らなかった新しい世界(笑)を知ることができ 反面教師として自分のソースコードに反映できる。

  3. ドキュメントに載っていないような情報を用いて「あれ?これできるの世界で俺(と開発者)だけじゃね?」状態 になることができます。ただし多くの場合(ry

4. 標準を知り標準に合わせよう

新しい機能を実装する前に、他の言語の過去の遺産を調べ、その機能における標準を知りましょう。標準とは変数名や 関数名、実装の考え方です。作ってから標準にあっていないことを見つけると非常に寂しい気持ちになります。

5. テストを書こう

TDD とか BDD とか有名ですね。とりあえずテストを書きましょう。

テストを書くためのツールやテストの書き方を調べることに時間を割きましょう。世界には先人たちが作ってくれた 素晴らしいツールが存在しています。

ある程度テストを書いたら、Coverageを調べましょう。これでどの程度テストがコードを網羅しているかが簡単に 調べられます。目指せ100%。もうやり切るしか無いさ!

6. リファクタリングは最後

これは有末が全くできてませんがリファクタリングは最後です。ちなみに今の有末のコーディングの流れは 以下のようになっています(仕様が固まっていない場合)

  1. とりあえず実装を書く。仕様は書きながら考える。

  2. 動かしてみる。挙動や仕組みが気に食わないなら戻る。

  3. 気に入った実装になったらコミットする

  4. テストを書く、一つづつ書いてはチェックしをほぼ100%カバーするまで行う

  5. コミットする

  6. テストが常に合格するようにリファクタリングを行う

  7. コミット & プッシュする

7. 寝ろ

実装に詰まったら寝ましょう。とりあえず書いてその時だけ理解できる不安定なコードを生産するよりも寝たほうが生産的です。

8. 最後に

ドキュメントを整備しましょう。Sphinx + ReadTheDocs を使うといいと思います。

がんばってタイプライターから似非プログラマーまで進化しましょう。なお、上記のステップをちゃんとこなせない人は Bボタン連打で止めるので気をつけてください。

1 ぎぎねっと (@giginet)

9 RedBullは控えめに

10 実装が上手く行かないからといって物に当たってはいけない

6 escorte rendez vous
あなたは現実の優れたウェブマスターである。サイトのローディング速度はすごいですね。それはあなたがどんなユニークなトリックをやっているようだ。また、内容は傑作です。あなたは、この問題で壮大なプロセスを実行しました!最高の願い!
7 Dubai escort
私達と情報を共有するために考えています。
Only registered users are allowed to comment on the entry. Please log in to comment.