この場合の、"有能なプログラマ"の定義については以下のURLをご覧ください。
http://d.hatena.ne.jp/fromdusktildawn/20070217/1171679191
すなわち、「つまらない仕事の生産性」をあげるための手法を質問しているのだと思っていただいて結構です。
注意：上記のような「つまらない仕事の生産性」を上げるためには、もちろん心構えや生まれ持ったものも大きいでしょう。
それを答えていただいてもかまいませんが
どちらかというと、技術的な面を聞きたいです。
プログラマを大工に例えるならば
一流の棟梁の道具箱に何が入っているのかを
聞いているのです。
No.1
3
0
15pt
人それぞれだと思います。一流の棟梁の工具箱中身を知ることが一流の技術を盗むことにはつながりません。
ただ、多く使われる、使っているというのを聞くのはAutoHotKey等の作業の自動化ツールや、正規表現等のテキスト操作の高速化です。
AutoHotKeyなんかはGUIツールで勝手にクリックさせておくなんてのもありますし、正規表現で特定の条件をみたすものをすべて置換させるといった手法もよく見ます。
ツールに関してはエディタ等はそれこそいろいろありますし、お好みだと思いますが、簡単な作業を済ませる程度(特定のプログラムを一度に実行するアプリ)であれば、自分で簡単なCUIなりGUIのアプリケーションを作ってしまうほうが早いという方もいらっしゃると思います。
大事なのは『何を使うか』ではなく『どう使うか』だと私は思っています。
回答ありがとうございます。
おっしゃる通り、一流の棟梁の道具箱の中身を全て買いそろえたところで、
一流の棟梁になれるはずなんてありません。
実際には、様々な努力や心がけ（ex. これ自動化できないかな？ とめんどくさがるようにする）などは必要でしょう。
ただ、一流の棟梁の技を盗むには、最低限その人の持ってる道具を持ってないと、棟梁の技の練習もできないのではないかと思い、聞いてみました。
さて、id:rosylillyさんの回答をまとめますと
あと、心構えとして
ということでしょうか。
確かに、正規表現は分かってないと技術系の雑談掲示板すら読めませんからね。重要そうです。
No.2
178296
300pt
>「つまらない仕事の生産性」をあげるための手法
基本ですが、
１．車輪を発明しない
２．めんどくさがること
だと思います。
１．については、何かコードがいるときに既に誰かが作っていないか探すことが必要になります。
例えば以下のサイトなどを使って探すといいでしょう。
後、ring serverとか
sorce forgeもいいと思います。
何か「こんなツールが欲しい」と思ったときはフリーソフトの検索サイトで探して、もし無ければ自分で作って公開するのもいいかも知れません。
2.のめんどくさがることは、とにかく定型作業を嫌がることです。
頭を使わなくても出来る仕事はLL（Lightweight Language）などでどんどん自動化してしまいましょう。
個人的にRubyが好きなので紹介しておきます。スクリプト言語でエディタで書くだけて使えて文字列操作が得意でCGIでも良く使われます。生産性はJavaの10倍くらいと言われています。
http://d.hatena.ne.jp/epictetus86400/20060101
http://jp.rubyist.net/magazine/?0002-FirstProgramming
Ruby以外でも何でもいいのですが、手軽に使いこなせるLL言語を一つ覚えておくといいと思います。
回答ありがとうございます。
なかなか、具体的でよくわかります。
結構まとってるのですが、いちおうid:garyoさんの回答をまとめると、
という事でしょうか。
上記のサイトは、あとで度々使ってみます。
ありがとうございます。
しかし２番目の件は（別に職業プログラマでないとはいえ）恥ずかしながらLLを一つも使えないので、耳が痛いです。
あと、これは私が今思った事ですが、
やっぱ英語は大切ですねえ。
No.4
472
100pt
有能なプログラマが嗜んでいる言語・技法・テクニックとは何ですか？
とありますが、主観的ながら
嗜んでいる言語：アセンブリ、C/C++/D言語、スクリプト言語（Perl,Ruby,Python等）関数型言語（Lisp、Haskell、Concurrent Clean等）、.NET系言語(C# J# VB?)、JavaやLuaあたりだと感じました。
技法やテクニック等はあまりぱっと思いつかないのですが･･･
google:オブジェクト指向やgoogle:アスペクト指向、google:オートマトンなどでしょうか？
有能なプログラマ"の定義から
とありましたが
私もこの有能なプログラマの条件についてうなずける部分が多々ありました。
プログラムを書くためのプログラムを書くという部分に共感しました。
私はまだ本格的にプログラムを組んだ事のない学生なので生産性に関して誤解している面もあるかもしれませんが、私が今までより成果物の開発速度を上げるためにしている事からこの記事の指す生産性に結びつきそうな事を書きたいと思います。
最も適切なライブラリやAPIを鋭く見抜き、もっともパフォーマンスと安全性と保守性のバランスのとれたシンプルで美しいプログラミングをします。
からあるようにライブラリやAPIの概要を認知している事が必要だと思います。
それには事前の情報収集が不可欠で常に新しい技術やソリューションに関してある程度の概要を頭に入れる作業などが必要だと思います。
私は頭に入れる作業が苦手なので調べた資料は保存しています。
その資料を探すためのソフトウェアを入れています。
http://d.hatena.ne.jp/studiokingyo/20061116#p2
http://d.hatena.ne.jp/studiokingyo/20061211#p1
また、技術やライブラリに関する用語（例：Ajaxやboost等）の簡単な概要を書いたメモもしています。
時間が許す限り興味を持ったツールやライブラリは実際にTutorialを見たりSampleプログラムを実行したりして動作を確認しています。
そのときにあわせてソースコードの構造やライブラリの構成もチェックしたりしています。
これによって
「最も適切なライブラリやAPIを鋭く見抜き」
という部分の予習をしています。
そもそも、プログラム自体を編集するスクリプトプログラムをよく書く。
とありますが、今、私が大変になっている所です。スクリプト言語が沢山あるのでどれを先に覚えれば良いか迷っていたのですが、理想は全部一通り分かる方が良いようです。
等･･･他にも沢山あります。
私はPerl、Ruby、Pythonの中からどれか一つ使いこなせる((そのスクリプト言語によってワンライナーやソフト制作が普通にできるくらいの))ものがあればスクリプトプログラミングには困らないかなと感じました。
私は
仕様のエッセンスをコンパクトに記述した簡単な定義ファイルからプログラムを生成するジェネレータを即席で作る。
のような事は出来ませんが、ドメイン固有言語を実装しているソフトウェア等はチェックしています。
私は即席で作るよりはこれらのツールの使い方を覚えているのであればそちらを使った方が速いと思います。
http://d.hatena.ne.jp/studiokingyo/20070215#p1
http://d.hatena.ne.jp/studiokingyo/20060115#p1
そのほかにはBNFからパーサーを生成できるツール（yaccやbison等）
や
その他、様々な目的に適したツールが存在するのでそれを探すのが最近の日課です。
海外まで手を伸ばしますが、そういう便利なソフトに限って日本語の文字コードに未対応だったりして残念な思いをする事もあったりします。
パフォーマンスと安全性と保守性のバランス
とありますが、それは未だに良く分かりません。ここがプログラマーの職人的スキルなのかなと思っています。
安全性に関してはおそらく
http://ja.wikipedia.org/wiki/%E3%83%90%E3%83%83%E3%83%95%E3%82%A...
のようにならないようにプログラムを組む事だと思います。
保守性は
オブジェクト指向やアスペクト指向など保守に関するコーディング方法の事だと思います。
http://itpro.nikkeibp.co.jp/article/COLUMN/20060228/231310/？
パフォーマンスは
沢山のアルゴリズムとそれらの特性を知り、必要に応じて最適化できる能力だと思います。
それら沢山のことを頭に入れなくてはいけないと考えると私はやはり調べた資料は保存してしまうのです。
さらにはそれらのバランスを取らなくてはならないと言うのが大変そうです。
資料を必要な時にキーワードによって検索し閲覧する事ができると言うのは今の時代にプログラミングが出来て幸せだなと思っています。
私の行っている事が客観的に見て生産性が上がっていると言えるかは自分では判断できないのですが、私が生産性を向上させようと行っている習慣でした。
これらの事から今のところ
仕様から決定される
http://ja.wikipedia.org/wiki/%E6%9C%89%E9%99%90%E3%82%AA%E3%83%B...
のような頭の中で考えているFSMをいかに早くコードに落とす事が出来るか？
と言うのが私が考えている生産性です。
その為にはどんなアプローチでもすべきだと思っています。
最後に感覚的な事ですが、全部キーボードで主要な操作が出来るようになると生産性が上がっているような気がするのは気のせいでしょうか？
マウスで選択して右クリックしてメニューを出して必要な操作を選択する･･･というのが時間がかかるし間違った命令を選択をしないように神経を使うのでキーボード操作一発で済むように
プログラム開発環境にマクロをどんどん仕込んでいく。
というような事になるのかなと感じました。
御回答ありがとうございます。
自らの経験に触れながらの御回答は、大変ためになります。
さて、id:studiokingyo さんの御回答をまとめますと
と言ったところでしょうか。
やはり、言語だけでなくライブラリやAPIの熟知も重要ですよね。どちらかというと、ライブラリやAPIなどのほうが、英語文書に頼らざるを得なかったりするので、それは努力しないと行けないような気がします。
大変ありがとうございました。
No.5
92
ここでベストアンサー
250pt
ちゃんと答えるには、少なくとも、記事を５本ぐらい書かなきゃならないので、ここで答えるには、難しいです。
とりあえず、１／５分だけ、記事にしてみました。
御回答ありがとうございます。
この件に関しては、id:fromdusktildawnさんのご意見も聞きたかったので、誠に感謝してます。
きっとid:fromdusktildawnさんのこの件に関するご意見は、私以外の多くの方も興味があると思うので、平に御願いします。
No.6
92
すいません。
本館っぽくない記事だったので、別館に引っ越しました。
http://fromdusktildawn.g.hatena.ne.jp/fromdusktildawn/20070218/1...
御回答ありがとうございます。
なかなか考えさせられる内容でした。
乱暴にまとめると、プログラミング言語のユーザとしてのみ、言語を扱ってるプログラマはダメプログラマになってしまうという事でしょうね。
No.7
92
250pt
*有能なプログラマの特徴を思いつくまま列挙してみました
そもそも、ややこしい要求や仕様を実装しようとするから、プログラムが複雑になり、工数が膨らむんです。
だから、実装に手間のかかりそうな要求や仕様が来たら、
「なぜ、そういう要求・仕様が必要とされるのか？」を細部まで細かく聞き出します。
そもそもそういう要求が発生した動機、背景、相手の真の意図・目的まで、具体的に的確に把握します。
すると、要求者の真の意図、最終的な目的を達成するためには、必ずしも、そういうややこしい仕様でなくても良いことが判明することは、非常に多いです。
その場合、相手の真の意図・最終目的を、より効果的に達成でき、しかも、ずっとプログラミングしやすい仕様を代替案として提案します。
すなわち、要求者とプログラマの双方にメリットのある仕様を提案するわけです。
これをするには、もちろん、あらかじめ要求者との間に信頼関係を築いておく必要があることは言うまでもありません。
また、要求者の真の意図・最終目的を把握するには、要求者のドメインの業務知識がある程度必要です。
たとえば、仕様の要求者がWebアプリケーションの企画屋だったりマーケターだったりするなら、企画やマーケティングにおいて大切なことをある程度はプログラマも理解しておく必要があります。
たとえば、企画屋が気にしているのは、どのようにユーザにリーチするか、どのようにユーザ訴求力を出すか、どのようにユーザに逃げられないようにするか、今後どのようにサービス展開を図るか、などなどです。
C#なら、属性とReflectionを組み合わせたメタレベルプログラミングをする。
CLOSで言うところのメタオブジェクトプロトコルを使ったプログラミング。
たとえば、ブラウザを自動制御するための記述をC#でやると、どうしても煩雑になりすぎる。
それ専用の言語を作ってしまった方がよい。
昔はYaccやLexを使っていたし、それに相当するC#用のレキシカルアナライザジェネレータやパーサジェネレータもあるけど、基本的な戦略としては、正規表現を上手く使えば、簡易言語のインタープリタぐらいは作れる。
複雑な処理が必要な部分は、簡易言語からC#のルーチンを呼び出して委譲できるような言語仕様にする。
クラスの組み立て方のパターン集は一通り頭に入れておく。
参考書は基本的に英語で読む。
なぜかというと、Googleで得られる有用なプログラミング情報は、英語の方が充実しているから。
情報収集は、deliciousで得られる英語情報も。
英会話スクールにも通う
処理系のユーザとして使うだけじゃなく、自分でその処理系を作るとしたら、どう実装するか、と考えながら処理系を使う。
.NETライブラリ、ネットに落ちている各種ライブラリ、CPANなどのライブラリに対する幅広い知識。
宣言的記述と手続き的記述の違いを理解する。
トランザクション、ロールバック、正規化、外部結合、などなど、RDBの基本
言語理論
プロダクションシステム、前向き推論、後ろ向き推論、フレーム、などの人工知能系の概念
PKIの動作原理とか。
SSLが非対称鍵をどう使って共通鍵をシェアしているか、などの原理は理解しておく。
TCP/IPの動作原理の詳細
必要に応じてUDPも使えるように
HTTP、SMTP、などのプロトコルの理解。
Haskell、Prologなどは一通り原理を頭に入れておく。
開発環境のキーカスタマイズは使わない。
汎用のキーカスタマイズツールなら、一カ所の定義で、全てのアプリケーションにおけるテキスト編集の操作が統一的に変更できる。
選択領域をまとめてコメントアウトなど
とくに、関数の呼び出しもとや定義もとへのジャンプ機能などは、マウスから呼び出すようではだめ。
ホームポジションに近い位置のキーに割り当てておく。
VisualBasicでVisualStudioに必要な機能をどんどん追加
たとえば、実行時エラーのスタックダンプの文字列を解析して、
対応ファイルのエラーへジャンプするマクロなど。
プログラミング言語の正規表現だけでなく、たとえばVisualStudioの検索置換用の正規表現をきちんと使いこなす。
Perl、Ruby、VBScriptなどの雑用処理言語を使いこなす。
http://fromdusktildawn.g.hatena.ne.jp/fromdusktildawn/20070218/1...
御回答ありがとうございます。
こうした、細々とした有能なプログラマの特徴は、
言われると納得するものの、
なかなか気づきにくいですし、列挙されるのも珍しものですね。
No.8
90
3pt
イノベーション（Innovation）に対応出来ること？ではないですかね。
回答ありがとうございます。
実際、プログラマーにとって"ノイマン型コンピュータの仕組み"のようにいつまでも変わらないものばかりでなく、
ライブラリやAPIの仕様等のようにやたらと変わるものに関しては，対応できないと最前線で戦えないですよね。
No.9
38724
100pt
私の隣に自他ともに認める「ウィザード」が座っておりますが、彼を見てて、テクニックに関しては以下に挙げる２冊の本の内容を根本から理解、熟知して駆使している様に思えます。（私自身はへっぽこ偽プログラマですので直接質問にお答え出来ません。ごめんなさいー）
The Art of Computer Programming, Volumes 1-3 Boxed Set
蛇足ですが、彼の場合「生産性を上げる事」そのものに無上の喜びを見いだしてる様に見受けられます。
回答ありがとうございます。
Amazonの書評を読みましたが、中々面白そうです。
The Art of Computer Programmingは、非情報系院生の私でも知ってましたが、Hacker's Delightは初耳です。
ウィザードがいるような職場にいらっしゃるのですから、id:shimarakkyoさんも大層な能力の持ち主なのでしょう。なにか、コメントがありましたら、引き続き御願いします。
No.10
20
10pt
デバッグに関して言えば、
因果律・分割統治法・証拠による立証等をきちんと使いこなし、理詰めで原因を突き止めることができること。
「勘」や「当て推量」でデバッグしているようでは素人です。
回答ありがとうございます。
確かに、デバッグは、効率化や網羅性の点で、
有能無能がはっきりしそうですね。
No.11
10
10pt
デザインパターンとアンチパターンだと思います。
便利な定石のデザインパターン、やってはいけないアンチパターンの２種類をきちんと理解することによって、無駄な作業を減らせます。
特に重要なのはアンチパターンで、デザインパターンだけ読んでいると、間違った使い方をする人も少なからずいます。
回答ありがとうございます。
確かに設計の初期段階の構想は
後々まで尾を引きかねない重要な部分ですよね。
No.12
260
10pt
私が思う有能なプログラマは、過程に結果と同じくらい重みをおいて考えられる人、でしょうか。
脳内に仮想マシンと非常に正確なコンパイラ（インタプリタ）をもっているんじゃないかと思います。
脳内で読んだソースコードを素早く脳内でプログラムに変換し、実行して、結果はもとより過程の問題も発見して、どんどん修正して無駄なく美しく高速なプログラムを書き上げているのではないでしょうか…
あと、意外と誰にでもできて多くのプログラマがやってないこと(私の経験統計ですが)は、コンパイラの警告・エラーの報告レベルを最大限に引き上げて、報告してくれる内容を完全に理解し、コンパイラに感謝しつつそこを直すこと。
そもそもそんな箇所を発生させないように次から気をつけられる事。
これをやっていない人は意外と(私のまわりには)多く、私のところにソースコードがくると警告だらけだったりします。
私が有能か否かは不明なので、以上に挙げた点が本当に有能なプログラマの嗜みかどうかは不明、すべては想像の範疇を出ませんが…。
ちなみに私は有能なプログラマの仕事に実際に出会った事がありません。有能無能を判断できずに見逃しているだけだとしたら私が無能な証拠かもしれません。
回答ありがとうございます。
確かに、コンパイルが通ればそれで良しとする態度では
有能足り得ないと思います。
このような心構えは、大切ですよね。
くろょ
2007/02/18 16:34:31
[Program][備忘録][news][英語]最終的には学習スピードの速さとパターン認識能力の鋭さか！？ d金魚による C/C++にてプログラミングする為のノウハウとアルゴリズムの公開とライブラリとアプリケーションの開発の過程を記す dKingyo SDK 日記
1
1
2
1
15
15
harisen
Beirii
shimarakkyo
NAT
御回答ありがとうございます。
この件に関しては、id:fromdusktildawnさんのご意見も聞きたかったので、誠に感謝してます。
きっとid:fromdusktildawnさんのこの件に関するご意見は、私以外の多くの方も興味があると思うので、平に御願いします。