より速くコーディングする方法（品質を犠牲にすることなく）
私は数年プロのコーダーをしてきました。私のコードに関するコメントは一般的に同じです：十分にテストされた素晴らしいコードを記述しますが、高速である可能性があります。
では、品質を犠牲にすることなくどうすればより高速なコーダーになりますか？この質問のために、スコープをC＃に制限します。これは、主に私が（楽しみのために）コーディングするもの、つまりJavaです。これは、重要な多くの点で十分類似しています。
私がすでにやっていること：
- 仕事を終わらせる最小限のソリューションを書く
- 多数の自動テストを作成（リグレッションを防止）
- あらゆる種類の再利用可能なライブラリを作成（および使用）
- よく知られているテクノロジーを使用する（例：Hibernate）
- 所定の位置に適合するデザインパターンを使用します（例：シングルトン）
これらはすべて素晴らしいですが、私の速度が時間の経過とともに増加しているようには感じません。私はdo気を付けます。なぜなら、もし自分の生産性を（たとえ10％でも）向上させることができれば、競合他社よりも10％速いからです。 （私が持っているというわけではありません。）
その上、小規模なFlash開発であろうとエンタープライズJava/C++開発であろうと、私は常にマネージャーからこのフィードバックを得ました。
編集：私が速いとはどういう意味か、そして私が遅いことをどのように知っているかについては、多くの質問があるようです。もう少し詳しく説明します。
私は、さまざまな企業のさまざまなプロジェクトやさまざまなテクノロジー（Flash、ASP.NET、Java、C++）の中小規模のチーム（5〜50人）で働いていました。私のマネージャー（彼らが直接私に言った）の観察は、私が「遅い」ということです。
これの一部は、私の同僚のかなりの数がスピードのために品質を犠牲にしたためです。彼らはバグが多く、読みにくく、保守が難しく、自動テストを書くのが難しいコードを書きました。私のコードは一般に、十分に文書化され、読みやすく、テスト可能です。
Oracleでは、他のチームメンバーよりも遅いバグを一貫して解決しました。私はそのことについてのコメントを得るので、私はこれを知っています。これは、他の（そう、シニアで経験豊富な）開発者が、私と同じくらいの品質（可読性、保守性、テスト容易性）で、私よりも短い時間で私の作業を行えることを意味します。
どうして？何が欠けていますか？どうすればこれを改善できますか？
私の最終目標は単純です。今日X時間40時間で製品Xを製造でき、何らかの方法で自分自身を改善して、明日20時間、30時間、または38時間で同じ製品を作成できるとしたら、それが知りたいことです。どうやってそこまで行くの？継続的に改善するためにどのようなプロセスを使用できますか？コードを再利用することだと思っていましたが、それだけでは十分ではないようです。
私はこれに対するJeff Atwoodのアプローチが好きです http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html 。
基本的にこの記事では、David BaylesとTed OrlandによるArt＆Fearという本の一節を参照しています。通路は行きます：
陶芸の先生は、初日にクラスを2つのグループに分けると発表しました。スタジオの左側にいるすべての人は、彼らが生産した作品の量だけで評価され、右側の人はすべてその品質で評価されます。彼の手順は簡単でした。クラスの最終日にバスルームスケールを持ち込み、「数量」グループの作業を比較検討しました。50ポンドのポットが「A」、40ポンドが「B」という具合でした。しかし、「品質」で採点されているものは、「A」を獲得するために、完璧なポットではありますが、1つのポットのみを生産する必要がありました。さて、採点の時期が来て、奇妙な事実が浮上しました。最高品質の作品はすべて、量的に採点されているグループによって作成されました。 「量」グループが忙しく作業の山を作り出し、その過ちから学んでいたように、「品質」グループは完全性について理論化し、結局、壮大な理論と死んだ粘土の山。
本質的に手を汚すのが早く、頻繁にスキルを向上させます。時間をかけて「完璧な」方法を研究して理論化するよりも優れています。私のアドバイスは、練習を続け、テクノロジーについていき、デザインを研究することです。
他の誰も言及していないように思われる1つの可能性は、あなたがうまくやっていて、あなたのマネージャーはあまり上手ではないということです。彼らはどのように生産性を測定していますか？彼らはあなたに特定の例を与えることができますか、それは単なる一般的な認識ですか？彼らはあなたと比較して他の人々の仕事を修正するのに費やされた時間を考慮に入れましたか？
多くの人々が物事を成し遂げる功績を認めているのを見てきましたが、彼らのチームの他のメンバーは彼らが残した混乱を修正しています。
人が考える重要なことのほとんどは重要ではありません。入力速度は重要ではありません。高速のマシンやツールは重要ではありません。私たちはタイピストや機械オペレーターではありません。私たちは労働者だと考えられています。 私たちは意思決定者です。
重要なのはフィードバックを使用して継続的に意思決定プロセスを改善することです。これを行う唯一の方法は、他のスキルの習得と同様に、経験、目的のある実践、および継続的なフィードバックによるものです。
- サイドプロジェクトに取り組みます。
- オープンソースプロジェクトに取り組みます。
- あなたよりも優れた開発者と協力してください。ペアプログラム！
- 新しいツールとテクニックに身をさらしてください。機能するものを保持します。
- 意思決定装置をトレーニングするように設計されたプログラミング演習を行います*。
- 欠陥率や速度などの客観的な指標と、コードの品質や適合度などの主観的な指標に基づいて、改善を監視します。
最後に：品質のない速度は役に立たないことを思い出してください。逆もまた同様です。ユーティリティを最大限に活用するには、これらの緊張の間のバランスを見つけます。
速度を上げるために、実際にはsomeの品質を犠牲にするよう求められている可能性は十分にあります。
一部の開発環境1、「十分に良い」で十分な場合に、洗練されたものを作成するために余分な時間を費やすだけの価値はありません。
1-特に「内部ツールスミス」を考えていますが、おそらく他にもあります。
あなたはすべての良いことをしているようです-中期的にはあなたをより速くするので、あなたが実際に遅いかどうかは明らかではありません。あなただけが本当にそれを知っています。 （しかし、それは非常に現実的な可能性です。PeopleWareは、同じタスクについて開発者間で最大10倍の生産性の違いを主張しています）。
だから私はあなたにいくつかの提案があります：
時間は相対的なものなので、おそらく問題はあなたの実際の速度ではなく、むしろあなたが与えている時間の認識です。 1週間かかることを暗示するかもしれませんが、最終的に2週間を費やすことになり、他の人は3週間を費やすかもしれませんが、1週間は遅く見えるだけです。
あなたはこのフィードバックを頻繁に受け取るので、おそらく上司や同僚と話して彼らの言うことを確認する時間です-彼らから学ぶべきことがたくさんあるに違いありません。
「速い」開発者とペアプログラミングをして、違いを見つけることができるかどうか確認してください。
あなたが本当に遅いのかどうかについての人々の質問はすべてばかげています。品質を犠牲にすることなく、より高速なプログラマになることは、すでにどんなに遅くても速くても、常に良い目標です。これは、プログラマーとしての私の最大の目標であり、決して達成されることはありません。私は常に品質を犠牲にすることなくより速くなるように努めています、私はそれに取りつかれています。これが私にとってこれまでに役に立った順に、最後にいくつかの実験的なアイデアと一緒に働いています：
1）学習を止めない：コンピューターのプログラミングと一般的な使用についてできる限りのことを学びます。あなたが苦手な分野を見つけて、それらを学びましょう。あなたの仕事やC＃とはまったく無関係に思われる場合でも、それを探している場合は、それを自分の仕事に適用する方法が見つかることを保証します。学ぶことも経験に関するものなので、読むだけでなく、実際に試してスキルを伸ばしてください。 Windowsを使い慣れている場合は、Unixを試してみてください。通常IDEを使用したい場合は、コマンドラインツールとテキストエディター、またはその逆を試してください。これまで聞いたことのないツールやテクノロジーについて聞いたり、あまり知らない場合は、次に進む誘惑に負けないでください。調べる！既成概念にとらわれず、他の人が実用的でないと言う実験的な新技術を学ぶことを恐れないでください。生産的なプログラミング方法の表面を引っ掻き始めたばかりです。
2）プロジェクトを分割する：プロジェクトをミニプロジェクトに分割してください。毎日または多くても数日ごとに新しいリリースを実行するようにしてください。 「私がリリースできる機能の最小量はどれくらいですか、それでもユーザーに役立つ何かをリリースする」と自問してください。これはあなたがそれを行うことによって学ぶスキルです。これを許可するようにマネージャーを説得する必要があるかもしれませんが、彼らは通常、非常に迅速に結果に満足します。これを行うことにより、機能に不可欠であると考えていたものが、後で開発できる追加機能であることに気づき始めます。これにより、管理者は、作業中の機能に関連するすべての機能ではなく、最も重要な機能のみに優先順位を付けることができます。これにより、心を明確にして集中することで、より速く考えることができます。あなたは今度は合法的に速くプログラムするでしょう。あなたのマネージャー、または少なくともマネージャーのマネージャーは、より多くのリリースをリリースしているため、プログラミングが実際よりもさらに速くなっていることに気付く可能性があります。これのもう1つの大きな利点は、リリースが完了するまでにかかる時間を見積もるのがはるかに上手くなり、マネージャーがこれを気に入ってくれることです。すでに多くの自動テストを行っているので、安定した頻繁なリリースを実行しても問題はありません。ただし、自動ビルドシステムを強化する必要がある場合もあります。 Martin Fowlerシリーズの本Continuous Deliveryを読むことを強くお勧めします。読みづらく、繰り返しが非常に多いため、非常に役立ちます。
3）ポモドーロテクニックを使用して、うまくいかないものを適応/変更します。これをリストの2番と組み合わせると、生産性が大幅に向上します。
4）Vimを学ぶ。これらのコマンドをViEmuを介してVisual Studio内で使用したり、Eclipse内からプラグインを介して使用したり、Emacs内から使用したりしても、生産性が向上します。 Vimを学ぶ最良の方法は、Vimを使い始めて、習得するまでは（無効化/古いツールに戻る）強制しないことです。最初はつらいですが、後戻りしたくなくて、それなしで仕事をしなければならないときさえ、うんざりします。一部の人は、これはあなたの速度をそれほど増加させないと言うでしょう。しかし、特にコードの読み取りと変更がWHAT WE DOの場合は、高速であるほど速くなります。これにより、多くの時間を節約することができます。
5）この最後の方法は、良い方法だとは思えないので、必ずしも推奨されているわけではありません。実際には、生産性が低下する可能性がありますが、とにかく解決します。受け入れテストを増やし、単体テストを減らすことを試みるか、少なくともいくつかの受け入れテストを行うようにしてください。私はSpecFlowで成功しましたが、もっと良いものがあると思います。仕様を書くことさえかなり技術的であるかもしれないので、あなたがマネージャー/顧客に最初に大まかなドラフトバージョンを書かせて、あなたが大幅に変更するかもしれません、あるいはあなたは自分で全部書いて、それらを読んでOKにするだけかもしれません。これは、このリストの2番目に役立ちます。また、受け入れテストは、単体テストよりも実用的で、必要なコードが少なくて済みます。これは、彼らがそれらを置き換えるということではなく、さまざまなことのためのさまざまなツールです。しかし、多くの受け入れテストを行うと、より少ない単体テストで済む可能性があります。
6）これはさらに実験的で物議を醸しています。私は実際に自分でこれを行ったわけではないので、正確に推奨することはできません。 JetBrainsのメタプログラミングシステムを学び、使用してください。それを使用して、マネージャー/顧客が目的のソフトウェアを自分で作成するために使用するツールを作成します。これを使用してマネージャー/顧客が非常に単純で複雑な方法で動作を指定するために使用するツールを作成できる場合は、単体テストと受け入れテストの実行を停止できる場合もあります。アイデアは、プログラマを取り除くことではありません。プログラマは、顧客/マネージャが使用するこれらのツールに新しい機能を追加する必要があります（ツールではなく人々）が、目的の機能を簡単に作成できない場合はいつでも必要です。 MPSやそれに似た他のツールのいずれかが未来の道だと私は確信しています。
実質的には、それはexperienceです。あなたがしていることをより速くすることは、車を運転するようなものです。他の人は高速（または酔っぱらい）ドライバー（またはその両方）であり、安全に家に帰りたい（ソフトウェア用語では、コードを確認したい）ので、最初は怖いです。開発されたとおりに動作し、うまく動作します）。
数年/数か月間、運転と高速道路に慣れると、運転を楽しくするためのいくつかのトリックを学びます。それが経験と呼ばれるものです。それらの「トリック」（私は特性と呼びます）が役立ちます。
私の場合、コーディング（@自宅でも）といくつかの使用法を学ぶことで、デザインパターンの実際の使用法を学びました。したがって、デザインパターンを必要とする問題が発生した場合、過去の経験を利用して、どのパターンが機能し、なぜそれが私の状況で機能する/機能しないのかを確認します。
要約すれば：
- Experienceは、自信とより良いソフトウェアを後押しする特性を作成します。
PS：経験は他者から学ぶことからも得られます。例えば。 SO、ペアプログラミング、ピアレビューなどからの支援。振り返ってミスから学ぶことができない場合（または誰かがあなたの努力に挑戦したことがない場合）は、経験をすることはできません。
問題は、長期的な総コストを見ると、コストが安いかどうかです。
言い換えると、慎重に作成された高品質のバグ修正（テストケースとドキュメントを含む）が勝るより速い同僚によって行われたバグ修正を維持しなければならないためのコストですか？
もしそうなら、あなたは上司にこの事実を知ってもらう必要があります。彼らが測定を行わず、あなたの評価を確認するために必要なデータを持っている場合、議論するのは難しいかもしれません。
いいえの場合は、whyを強く検討する必要があります。
- あなたはあまりにも経験が浅いですか？
- あなたはそこにあるべきだと信じている、要求されていないことをするのに多くの時間を費やしていますか？
- 修正がいつ終了するかを判断するのに苦労していませんか？
- 結局、あなたのコードはあなたが思っているよりも品質が低いのですか？
- コード開発に別の方法でアプローチする必要があるのは、今のやり方を始めるのに時間がかかりすぎるためです。
- このサイトのようなものに時間をかけすぎていませんか？
よく考えて、調査結果で質問を編集してください。
より多くのあなたの脳を使用し、少ないテストを行います。正直なところ、テストはその場所にありますが、コストがかかります。
また、The Art of Unix Programming（無料のオンライン、価格に値する本）も読んでください。
最後に、あなたは正しい場所にいないかもしれません。四角い仕事の丸い釘など.
最終的には、学校のようなものです。「教師が望むものを出力する」は、「経営者が求め、支払うものを出力する」になります。
完成度の高いプロジェクトを取り、1時間あたりのコードの「最終」行数を取得すると、プログラマーが想像していたよりもはるかに遅いコードでコーディングされることがわかります。
1日に数行のコードを話しているだけです。残りの時間は、デバッグ、書き直し、および一般的なプログラマーの作業に費やします。
あなたは古いことわざを聞いたことがあるかもしれません-入力中にエラーをキャッチした場合、ビルド時にそれをキャッチした場合よりも10倍時間を節約できます。リリース後にキャッチするよりも..
では、どうすればスピードアップできますか？私は、どのようなタイプのタイピング速度にも集中しません。エラーを減らし、コードとの他の「将来の相互作用」を改善することは、時間のはるかに良い投資になるはずです。
読みやすく明確なコードが重要です。コードは1回記述しますが、数十回読み込まれます。読みやすさを重視して書くことで、多くのトラブルを減らすことができます（これにより時間も大幅に節約されます）。これまでに戻ってコードを読んで、一瞬でもそれについて考えなければならないなら、あなたはそれを間違っています。
ペアプログラミングはQA時間を短縮できます。1人のプログラマーが1日に数行しか作成しない場合、2つが1つと同じ速度でコーディングでき、エラーが少ない場合は、先に進んでいます。
防御的にコーディングする（たとえば、パラメーターチェック）ことで問題を減らすことができます...チームに本当に優れたアナリスト/アーキテクトがいる場合は、適切な開始設計で時間を節約できます。
それ以外の場合は、設計スキルを向上させ続けます。経験を積むと、機能しないパターンを認識してそれを回避できるようになり、タイムシンクをより早く特定できるようになります。
私が知る限り、それは：
- 良い
- 速い
- 安いです
マネージャーとして、任意の2を選択できます。
あなたがスピードを得ているコメントについて心配しないでください。私は仲間のコーダーとして、一緒に叩かれたものよりもよく考えられ、よく書かれたコードを維持したいと思っています。
作業中に自分自身の詳細な監査を行うことを検討しましたか？ペンと紙で時間をどのように過ごしているかを追跡するか、 Rescue Time のようなものを使用して追跡します。
どのように時間を費やしているかをより正確に理解すると、改善の必要性についてより良いアイデアを得て、そこでの努力に集中することができます。
理想的には、同僚にも挑戦してこれを実行し、結果を比較して、お互いからアイデアを得ることができます。あなたもおそらく彼らが恩恵を受けることができるいくつかの強みを持っています。
自動化できるプロセスの一部に多くの時間を費やしていること、または特定の時間帯に多くの注意散漫があり、別の時間帯が静かであることがわかった場合、タスクを計画することができます。それなど.
あるいは、テストに思ったより時間がかかっていることがわかり、テストが速くなるという認識を再考する必要があります。
他に何もない場合、それはあなたが取り組むことができるいくつかのベンチマークを提供します。
あなたのリストから、あなたはうまくやっています。
同僚がより高いCRAP番号でコードを作成している場合、彼らはより速く進みます。 CRAPは、循環的複雑度とテストカバレッジを組み合わせた、コミカルな名前のメトリックです。
必要以上にCRAPなコードを書かないでください。 ;）
私があなたに提案する唯一の変更は、ライブラリを使用することです。
- あなたの会社は図書館を販売しています
- ライブラリに繰り返しコードをリファクタリングしました
あなたが読んでいて、それは素晴らしいことです。しかし、手続き型またはOOコードについて考えていることに行き詰まっている可能性があります。関数型プログラミング（Haskellなど）やPrologに触れたことはありますか？
OOプログラミング技術を磨くために、Smalltalk/Squeakで遊んだことはありますか？
そして最後に、理論。グラフ理論について少なくとも初歩的な理解はありますか？ （一部のプログラムは、ツリー、DAG、またはある時点での単純なグラフで機能します。ネットワークはグラフです）
引用します ボブおじさん ：
速く行く唯一の方法は上手く行くことです。
品質と速度のトレードオフを誘惑するたびに、速度が低下します。毎回。
OPの「スピードのために犠牲にされた品質」の見方には反対です。
プロのプログラマー（プログラマー）は、3つのオブジェクトを満たす必要があります。
1）コードは意図したとおりに実行する必要があります
2）納期は間に合うはずです
3）優れた品質、ドキュメントなどがある.
4）その他.
おそらく、OPが間に合わなかったために、OPが遅いと非難されたと思います。
これは回避が難しいキャッチ22です。あなたはまだ多くの面で経験とある程度の知識を欠いているかもしれませんがすでにほとんどより速いですが、問題はそれが測定が難しい。
個人的にこの時点でできる最善のことは、自分を測定することです。自分の仕事のやり方についてフィードバックを提供してください。おそらく、仕事の習慣を少し変えるだけで、生産性が向上するでしょう。
メールが中断しただけで、思っていたよりもメールがどんどん食べられていることがわかりました。現在、私は1日に2回だけメールに返信しており、数日のうちに1時間近く生産性が向上しました。 pomodoro のような方法を試してください。測定手段として使用しました。一定の間隔（15分）で、そのとき何をしていたかを書き留めておきます。これにより、私の日々がどのように構成され、効率を最大化するために何ができるかを知ることができました。
私が考えることができる主なものは次のとおりです
- 入力速度を上げます。
- 生産性を向上させるツールを使用します。たとえば、ReSharperです。
- より高速なマシンまたはツール。もっとRAMまたはソリッドステートドライブのように。
コーディングスキルの分野でもできることはあると思いますが、そういうことは全部終わったようですね。上記でリストしたものは、通常、開発者によって見落とされています。
あなたはスピードタイピングコースを取ることができます。タイピングの高速化が問題かどうかはわかりませんが、「コーディングが遅すぎる」のは、単にタイピング速度が遅いことが原因である可能性があります。
コードジェネレータについてはどうですか？時々、コードは反復的になります。リファクタリングによって一部が削除される可能性がありますが、それでも同じリファクタリングされた関数を繰り返し呼び出す場合があります。使用するデータとコードに応じて、コードジェネレーター（Excel、Perl、Javaなどで記述されたもの）mightにより多くの時間を節約できます。また、UI開発にコード生成ツールを使用することは、通常、簡単です。
そして最後に、多分メトリックは間違っています。他のすべてを考慮して最高速の可能な速度でコーディングしていること、およびタイムラインが短すぎてappear遅いコーダーになる？
あなたの質問の編集に基づいて、あなたはあなたの同僚のいくつかのルートを取り、うまくいく最も速い解決策を一緒にハックすることができるようです-そして、ドキュメントとQAは非難されます！
または、特定の領域でより多くの経験と実践を得て、コードベースとAPIを理解し、睡眠中にソリューションをコーディングできるようにします。これは可能ですが、さらに時間がかかります。あなたよりも速い他の開発者がより年長で経験豊富であることがわかっている場合、行うべきことは1つだけです-あなた必須なるより上級で経験豊富！
Squeakの高速コーディングの利点は、「OOPスキルを磨く）だけではありません。JUNITはもちろんのこと、最新のGUIとIDEがSmalltalkで発明されたのには理由があります。 JavaへのSUNIT、「OOP」という用語は、Smalltalkなどを表すために考案されました。
達成したいあらゆるものに最も適した言語と環境を常に使用する必要がありますが、一般的なプロトタイピングでは、少なくともHyperCardを除いて、squeakをあらゆるものと照合します。 Squeakにはハイパーカードのような機能が組み込まれているため、実際にはより高速です。