http://q.hatena.ne.jp/1203667934
ソフトウェア開発やプログラミングのスピードを上げる方法はありませんか？
プログラマーとして生きていこうと決めたのですが、いつも見積もりの3倍時間がかかってしまいます。
そのため いつもつらい思いをしています。
環境を良くしようとHHKLite2を使い、カスタマイズソフトでホームポジションから離さずにプログラミングしています。
マウスもゲーム用の高精度のものを使っています。
調べ物にもタブブラウザを使い、拡張し続けて効率化をしています。
DualCoreマシンを使いメモリもたくさん積み、障害がないように心がけがけています。
出始めのころから効率化のためにエクストリームプログラミングも取り入れていました。
単体テスト、リファクタリングも当然行いますが、余計に開発速度が落ちています。
しかし開発速度は効率化とは無縁だとすら感じています。
仕事を減らすことが優先ではないか？と。
昔から創作活動は好きですが、人より時間がかかる方でした。
最近はプログラマーに向いていないとすら言われます。
どうか私にお力添えをください。
僕はプログラマじゃないのだけど、
門外漢の適当な考えでも何かヒントになればと思いつつ。
まず、
4HWW本の Tim Ferris が言っていたように、
タスクを細切れにするよりも、
不必要なタスクをそもそも消すことが大切なのではないか？と考えてきています。
と、いうのが核心かと思います。
でも、一プログラマーがその権限を行使できる領域は少ないかもしれません。
コードの中は支配できてもそれより大きな枠となると、、、
下っ端が会社を自分のいいように変えていく方法
http://finalf12.blog82.fc2.com/blog-entry-396.html
これがヒントになるかな？
ただ、本筋と違うので今回は割愛。
もひとつ注目したのが、
いわゆる驚異的な効率、スピードが出せる「神が降りた」という状態は誰にでもあると思いますが、
そのようなものを人工的に、作ることができるとよいですね。
これに狙いを絞って、たぶん答えとなるページが
論理的思考の放棄
http://d.hatena.ne.jp/softether/20070324
僕は、1 日に少なくとも 3,000 行程度、
多く書くときで 10,000 行以上のプログラムを書くことができる。
その結果、多い月で 10 万行 / 月くらいである。
なお、言語は書くソフトウェアの性質上、大半が C 言語である。
また、プログラミングにはバグが付き物だが、
ここ 2、3 年の間は、発生するバグの数を極めて少なく保つことに成功している。
略、
自分の能力は、上記程度であるが、能力というのはこれくらいが標準的なのだろうと思っており、
自分の能力が特別高いということは思っていなかった。
しかし、どうやら、いろいろなソフトウェア開発者の話を聞いたり、記事を読んだりしてみたところ、
上記の程度にできる人はごく少数らしいということに、最近気付いた。
いろいろ調べたの結果によると、普通の開発者の作業能力は、1 ヶ月数百行程度、
多い人でも 1 ヶ月で 3,000 行程度らしい。
"1 日、数百行" ではなく、"1 ヶ月、数百行" である。
もちろん職業プログラマーの話で、
仕事の他に、毎日大学へ行ったり自分の会社を持っていたりしている訳ではなく、
プログラミングに専念していても、この程度だという。イメージしていた現状と全然違う。
そこで、ここ 4 年間くらい、
自分自身の能力の根源について探求を重ねると共に、いろいろなことを調べているうちに、
普通の人の考え方と、自分の考え方とが大きく乖離しているらしいという事がわかった。
このようなことだけを書くと、
「自分にはそういう能力には縁が無い」とか「少しできるからといって自慢するな」とか「偶然だ」
とか思う人がいるかも知れないから、
これから、誰でも少し考え方を変えるだけで、
上記のような能力・作業効率を獲得することができるのだということを伝えたいと思う。
そうすれば自分一人ではなく、みんなにとって有益だと思うからである。
でも！
登さんの話は哲学過ぎて誰も理解できないのであるｗ
なんで、ちょっと分解して別解釈やってみる。
ホントに生産性を上げるなら、4HWW本の考え方。
ここでは、プログラミングをスピードアップさせて、
没我的な、「フロー状態」でプログラミングそのものを「楽しむ」考え方。
神が降りてくるとは？
「フロー」とか「神が降りてくる」というのはわけがわからんので、
「ずっと途切れずにスピードに乗ってる」と解釈する。
どうすればスピードにのれるのか？ 又はどうすればスピードが維持できるのか？
とんでもなく当たり前のことを言うけど、
石を投げないで欲しいｗ
自分の力だけでスピードに乗るにはまず慣性をつけることだ。
自転車のギアで考えてもらいたい。
いきなり5速ギヤを回そうとしてもこれはつらい。
まず1速。
パワーのある人は2速からはじめてもいい。
これでスピードにのったら、どんどんギヤを上げていく。
そうすれば5速も楽に回せる。
はじめから5速を回そうとしても、スピードにのる前にお昼休憩になったり
いろんな邪魔がところどころ入るので、これは難しい。
登さんの言う
１ 努力しないこと
２ 論理的に考えないこと
３ 頭を使わないこと
を、天才の成せなる技とは思わずに、
１ 努力しないでいいように
２ 論理的に考えなくてもいいように
３ 頭を使わないでもいいように
最初からそう組み上げていく。
では、スピードの邪魔をしてるものはなんだろう？
といったらいくらでも思いつくのでこれも割愛。
逆に、スピードの邪魔を排除するには？
とても大きく複雑で、かつレイヤ的に OS に近い処理をたくさんやるプログラムを書く場合は、
プログラミングをするときでも、事前の設計が極めて重要となる。
設計をうまく行わないと、後になって全面的に書き直しをしないといけなくなったり、
パフォーマンスが低下したりする原因となり、開発者の苦痛の原因となる。
ゲーム開発者で似たような考えの人がいます。
ソラ桜井氏、「スマブラX」におけるジャパンチューニングの神髄を披露
「Development - SUPER SMASH BROS. BRAWL」
http://www.watch.impress.co.jp/game/docs/20080224/gdc_sma.htm
桜井氏は締めとして、ゲームデザイナーは「最初にこそよく考えておくこと」が重要であることを協調した。
「ディレクターにとってはここが一番重要。
キャラクタ設定、グラフィックス、モーション、パラメータがばっちり決まっていればキャラクタも幸せ。
最短距離をまっすぐ進めば、チームの負担も減るし、その分作り込んだ良い作品に仕上がる可能性が高い」と持論を展開。
また、「作ってみなければわからない」という日本におけるプリプロダクション重視の傾向については、
「よほど開発期間に余裕があるときにしたほうが良いのではないか」と、暗にこれを否定した。
開発期間に余裕のあるプロジェクトなど存在しないからだ。
桜井氏は「頭の中で仕様を転がして、頭の中のゲームで遊んだ上で、しっかりスタッフに指示ができるように頑張って欲しい」
と桜井氏らしいアドバイスを投げかけ、
「ゲームを作っていると方向性に迷うことがあるが、ピンチの時こそ自分を信じて突き進んで欲しい」とまとめた。
確か↓このソフトの開発者上田文人氏、
最初に徹底したプロトタイプムービーを作り上げたのと
実際にできあがったソフトにほとんど違いがなかったという話でした。
いかに、スピードの邪魔を徹底して排除するか？
プログラムの分野では、かならずしも徹底した設計が用意されてないことも、
用意してないことも多々あるでしょう。
でも基本的には、そういった環境設定により
「努力しないでいいように」
「考えないでいいように」
「頭を使わなくてもいいように」
プログラミングできるんじゃないかと。
よく、プロの工場とか厨房でとんでもない達人技を高速に仕上げる人がいますが
プログラミングも、環境設定によってはそこまでいっちゃうんじゃないかと。
登さんのように。
しかし環境設定を工夫するほど、効率が落ちることも、、
環境を良くしようとHHKLite2を使い、
カスタマイズソフトでホームポジションから離さずにプログラミングしています。
マウスもゲーム用の高精度のものを使っています。
調べ物にもタブブラウザを使い、拡張し続けて効率化をしています。
DualCoreマシンを使いメモリもたくさん積み、障害がないように心がけがけています。
出始めのころから効率化のためにエクストリームプログラミングも取り入れていました。
単体テスト、リファクタリングも当然行いますが、余計に開発速度が落ちています。
ちょっと、分からない単語もあるのですが、
HHK、
ゲーミングマウス、
タブブラウザ拡張設定、
パワーマシン、
デュアルディスプレイ、
など、これらは大いにギヤを上げやすくするので有効だと思います。
しかしここで突っ込むのは、
「本来の生産性を上げる」ではなく、
「いかにスピードにのったまま楽しくプログラムできるか？」です。
ちょとまて、考えないプログラミングが楽しいのか？
脳トレとかテトリスをハイスピードやってると思うのですが、
単純作業でも速ければ速いほど脳は楽しいドーパミンを出してくれます。
スピードがでるから楽しい、
楽しいからスピードがでる。
もちろん本来の「ひらめきの楽しさ」も
「スピード」から生まれることは多々あるので
それは心配しなくてもよいかと。
その環境設定は、作業を中断させない設定か？
拡張設定や、全体として長い目でみて効率的なクラス構築とか、
環境を整えれば整えるほど、ずっと全体の速度が上がるはずなのに
それを作るのに、毎度毎度ギヤを1速に落とし直してたら本末転倒。
もちろん、理論上はそういう仕組みのほうが全体効率としていいのかもしれません。
ただ「速く楽しくプログラムる」という基準からは離れるのかも。
ただひとつのワンクリック、
ソース的な美しさ、
コメント、
ウィンドウの切り替え、
コピペ、
検索、、、、
もし、こういうのがなくて
たった一つのウィンドウだけで、流れるようにコードを書けたら神も降りてきそうですよね。
プログラマじゃない僕が言ってもなんですが、
「とりあえず動く物を作る」
「できるところから作る」
という、スピード最優先で、あらがあってもそれがどんなに汚くても
「自分が気持ちいい」
という感覚が大事だと思います。
感覚を中断させないOS、
感覚を中断させないソフトウェア、
感覚を中断させないツール、
感覚を中断させないデバイス、
感覚を中断させない設計書、
感覚を中断させないプログラミング、
感覚を中断させない言語
感覚を中断させない机、
感覚を中断させない椅子、
感覚を中断させないチーム、
感覚を中断させないメール、
大きいところから、小さいところまで、数十の減速があると思いますが
これをいかに設定するか？
が、フローに入り、それを維持する肝なんじゃないかと。
スピード最優先、自分の気持ちよさ最優先の環境設定です。
プログラムがtwitter並に、手軽に書き殴れるぐらいのスピード感があったら最強ですよね。
もしかして、登さんの境地はそんなところかも。
これは関係ないかもしれないし、ヒントかもしれない。
twitter を中心にした文章生成作法
http://medt00lz.s59.xrea.com/blog/archives/2007/12/twitter.html
新しい言語を覚えきれないから、流れるようにプログラムできない
英語がしゃべれないから、外人としゃべれないかというとそうでもないですよね。
「ソースが汚くてもいい」のであれば、
中学英語でも、発音がカタカナ英語でも通じるもんです。
完璧な英語をしゃべろうとすると、とたんにしゃべれなくなる。
もちろんきちんと単語や文法をマスターするのが先決でしょうが、
プログラムは、「if」「for」「switch」あたりが分かれば
なんでもでも応用できるという話も聞いたことあります。
ま、極論すぎますけど、
「とりあえず動く物を作る」
「できるところから作る」
というルールなら、いろんなショートカット、
いろんな学習のショートカットもあるかもしれません。
英語を覚えるのには、海外の彼女を作るのが一番とか、
自分の気持ちよさ最優先でいいんですよね。
不完全・不正確な抄訳本
一見の価値あり
頭の切り替えができそう。
確かに面白いんだけど・・・
