より速くコーディングする方法（品質を犠牲にすることなく）[完了]

私は数年間プロのコーダーをしています。私のコードに関するコメントは一般的に同じです。優れたコードを記述し、十分にテストされていますが、より高速になります。

それでは、品質を犠牲にすることなく、より高速なコーダーになるにはどうすればよいですか？この質問のために、私はスコープをC＃に制限します。それは主に（楽しみのために）コーディングするものであるか、またはJavaであり、これは多くの点で重要です。

私がすでにやっていること：

• 仕事を成し遂げる最小限のソリューションを書く
• 多数の自動化されたテストを書く（リグレッションを防ぐ）
• あらゆる種類の再利用可能なライブラリを作成（および使用）する
• よく機能する場所でよく知られた技術を使用する（例：Hibernate）
• 所定の位置に収まるデザインパターンを使用する（シングルトンなど）

これらはすべて素晴らしいですが、時間の経過とともに私の速度が向上しているとは感じません。私がやる私が（でも10％）私の生産性を向上させる何かを行うことができれば、それは私の競合他社よりも10％高速ですので、注意して。（私が持っているわけではありません。）

それに加えて、小規模なFlash開発であろうとエンタープライズJava / C ++開発であろうと、私は常にマネージャーからこの報酬を受け取りました。

編集：私が速いとはどういう意味か、そして私が遅いことをどのように知っているかについて多くの質問があるようです。さらに詳細に説明します。

私は、さまざまなプロジェクトやさまざまなテクノロジー（Flash、ASP.NET、Java、C ++）で、さまざまな企業の中小規模チーム（5〜50人）で働いていました。私のマネージャー（彼らは私に直接言った）の観察は、私が「遅い」ということです。

これは、私の仲間の多くがスピードのために品質を犠牲にしたためです。彼らはバグがあり、読みにくく、保守しにくく、自動テストを書くのが難しいコードを書きました。私のコードは一般に、十分に文書化され、読みやすく、テスト可能です。

Oracleでは、他のチームメンバーよりも一貫してバグをゆっくりと解決していました。私はそのことに対するコメントを得るので、これを知っています。これは、他の（はい、より上級で経験豊富な）開発者が、ほぼ同じ品質（読みやすさ、保守容易性、テスト容易性）で、私がかかった時間よりも短い時間で作業を行えることを意味します。

どうして？私は何が欠けていますか？どうすればこれを改善できますか？

私の最終目標は単純です：今日40時間で製品Xを作成でき、明日20、30、または38時間で同じ製品を作成できるように、なんとか改善できるなら、それが知りたいことです-どうやってそこまで行くの？継続的に改善するためにどのプロセスを使用できますか？コードを再利用することだと思っていましたが、それだけでは十分ではないようです。

ジェフ・アトウッドのこれに対するアプローチは、ここ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つは、あなたがうまくやっていて、マネージャーがあまり良くないということです。彼らは生産性をどのように測定していますか？彼らはあなたに特定の例を与えることができますか、それは単なる一般的な認識ですか？彼らはあなたと比較して他の人の仕事を修正するのに費やした時間を考慮に入れましたか？

多くの人が仕事を成し遂げた功績を称えられ、残りのチームは残された混乱を修正しました。

人々が重要だと思うもののほとんどは重要ではありません。入力速度は重要ではありません。高速なマシンやツールは重要ではありません。私たちはタイピストや機械操作者ではありません。私たちは労働者と考えられています。私たちは意思決定者です。

何で重要なことは継続的にあなたの意思決定プロセスを改善するためのフィードバックを使用しています。これを行う唯一の方法は、他のスキルを習得するように、経験、目的のある実践、および継続的なフィードバックによるものです。

• サイドプロジェクトに取り組みます。
• オープンソースプロジェクトに取り組みます。
• あなたよりも優れた開発者と協力してください。ペアプログラム！
• 新しいツールとテクニックを体験してください。動作するものを保管してください。
• 意思決定装置を訓練するためのプログラミング演習を行います*。
• 欠陥率や速度などの客観的なメトリック、およびコード品質や適合性などの主観的なメトリックに基づいて、改善を監視します。

最後に、品質のない速度は役に立たないことを覚えておいてください。ユーティリティを最大限に活用するには、これらの緊張関係のバランスを見つけてください。

* http://codekata.pragprog.com/

それは実際に、あなたが犠牲に求められていることを十分に可能だいくつかの大きな速度のため、品質を。

一部の開発環境¹では、「十分に良い」場合でも、洗練されたものを作成するのに余分な時間をかけるだけの価値はありません。

^{1-特に「内部ツールスミス」を考えていますが、おそらく他にもあるでしょう。}

あなたはすべての良いことをしているように聞こえます-中期的にはあなたが速くなるので、あなたが実際に遅いかどうかは明らかではありません。あなただけが本当にそれを知っています。（しかし、それは非常に現実的な可能性です-PeopleWareは、同じタスクの開発者間で最大10倍の生産性の違いを主張しています）。

だから私はあなたのためにいくつかの提案があります：

1. 時間は相対的なものなので、おそらく問題はあなたの実際の速度ではなく、あなたが与えている時間の認識です。あなたはそれが1週間かかることを暗示しているかもしれませんが、他の人が3週間を費やすかもしれないところで2週間を費やすことになります...しかし、あなたはただ1週間遅く見えます。

2. 頻繁にこのフィードバックを受け取っているので、おそらくマネージャーや仲間と話し、彼らが言っていることを確認する時間です。彼らから学ぶことはたくさんあるに違いありません。

3. 「高速品質」の開発者とペアプログラミングを行い、違いを見つけられるかどうかを確認します。

事実上、要約すると経験です。車の運転のように速くなるには、最初は他の人が速い（または酔っ払っている）ドライバー（またはその両方）であるため怖いです開発されたとおりに機能し、うまく機能します）。

何年も何ヶ月もの間、運転や高速道路に慣れると、運転を楽しくするためのいくつかのトリックを学びます。それを私たちは経験と呼んでいます。それらの「トリック」（私はこれを特性と呼びます）が役立ちます。

私の場合、コーディングパターン（@ homeさえ）といくつかの使用法を学ぶことで、デザインパターンの実際の使用法を学びました。したがって、デザインパターンを必要とする問題が発生した場合、過去の経験を使用して、どのパターンが機能し、なぜ自分の状況で機能するか、機能しないのかを確認します。

要約すれば：

• 経験は、自信とより良いソフトウェアを高める特性を生み出します。

PS：経験は他の人から学ぶことからも生まれます。たとえば、SO、ペアプログラミング、ピアレビューなどのヘルプ。ミスを振り返って学ぶことができない場合（または誰かがあなたの努力に挑戦しない場合）、経験することはできません。

質問は、長期の総費用を見て、あなたがより安価であるかどうかです。

言い換えれば、より速い同僚が行ったバグ修正を維持しなければならないコストを上回るほどの高品質（テストケースとドキュメントを含む）の慎重に作成されたバグ修正ですか？

はいの場合は、上司にこの事実を知らせる必要があります。彼らがあなたの評価を確認するのに必要なデータを測定せず、持っていない場合、議論するのは難しいかもしれません。

いいえの場合、これがなぜそうなのかを強く検討する必要があります。

• あなたも経験が浅いですか？
• あなたはそこにあるべきだと信じている要求されていないことをするのに多くの時間を費やしていますか？
• 修正がいつ完了するかを判断するのに苦労しましたか？
• あなたのコードは結局あなたが思っているよりも低品質ですか？
• 現在の方法を理解するのに時間がかかりすぎるため、コード開発に別の方法でアプローチする必要がありますか？
• このサイトのようなことに時間を費やしすぎていませんか？

よく考えて、調査結果を使って質問を編集してください。

あなたが本当に遅いかどうかについて質問する人々はすべて愚かです。品質を犠牲にすることなく、より高速なプログラマーになることは、すでにどれだけ遅くても速くても常に良い目標です。これがプログラマーとしての私の一番の目標であり、決して終わらない。私は常に、品質を犠牲にすることなく、より速くなるように努めています。それに夢中です。最後にいくつかの実験的なアイデアとともに、これまでのところ私にとって有用だったものを有用性の順に紹介します。

1）決して学習を止めないでください：プログラミングと一般的なコンピューターの使用についてできることをすべて学んでください。自分が苦手な分野を見つけて学びましょう。たとえあなたの仕事やC＃と​​はまったく関係がないように見えても、探している場合は、自分のやることにそれを適用する方法を見つけることが多いことを保証します。学習は経験にも関係しているので、本を読むだけでなく、試してスキルを伸ばしてください。Windowsの使用に慣れている場合は、Unixを試すか、その逆を試してください。通常IDEを使用する場合は、コマンドラインツールとテキストエディターを使用します。聞いたことのないツールや技術について聞いたり、あまり知らない場合は、先へ進む誘惑に屈しないでください。調べる！枠を超えて考え、他の人が非実用的であると言う実験的な新技術を学ぶことを恐れないでください。

2）プロジェクトを分割する：プロジェクトをミニプロジェクトに分割してください。毎日、またはせいぜい数日ごとに1回、新しいリリースを実行してください。「自分がリリースできる機能の最小量はどのくらいですか、それでもユーザーに役立つ何かをリリースします。」これは、あなたがそれを行うことで学ぶスキルです。マネージャーにこれを許可するよう説得する必要があるかもしれませんが、通常、マネージャーはすぐに結果に満足します。これを行うことで、機能に不可欠だと思ったものが、実際に後で開発できる追加機能であることに気づき始めます。これにより、管理者は、作業中の機能に関連するすべての機能ではなく、最も重要な機能のみに優先順位を付けることができます。これにより、頭をはっきりさせて集中することで、より速く考えることができます。これにより、合法的にプログラムが高速化されます。あなたのマネージャー、または少なくともあなたのマネージャーのマネージャーは、あなたがより多くのリリースをリリースしているので、あなたが実際よりもさらに速くプログラミングしていることに気付くでしょう。これのもう一つの大きな利点は、リリースが完了するまでにかかる時間を見積もるのがはるかに上手になることであり、あなたのマネージャーはあなたを愛しています。すでに多くの自動テストを行っているので、安定した頻繁なリリースを実行しても問題はありません。ただし、自動ビルドシステムを強化する必要がある場合があります。Martin Fowlerシリーズの連続配信の本を読むことを強くお勧めします。これは読みにくいものであり、非常に反復的ですが、それでも非常に役立ちます。また、マネージャーは、より多くのリリースをリリースしているため、実際よりもさらに高速にプログラミングしていることに気付く可能性があります。これのもう1つの大きな利点は、リリースが完了するまでにかかる時間の見積もりがはるかに上手くなり、マネージャーがこれを気に入ってくれることです。すでに多くの自動テストを行っているので、安定した頻繁なリリースを実行しても問題はありません。ただし、自動ビルドシステムを強化する必要がある場合があります。Martin Fowlerシリーズの連続配信の本を読むことを強くお勧めします。これは読みにくいものであり、非常に反復的ですが、それでも非常に役立ちます。また、マネージャーは、より多くのリリースをリリースしているため、実際よりもさらに高速にプログラミングしていることに気付く可能性があります。これのもう一つの大きな利点は、リリースが完了するまでにかかる時間を見積もるのがはるかに上手になることであり、あなたのマネージャーはあなたを愛しています。すでに多くの自動テストを行っているので、安定した頻繁なリリースを実行しても問題はありません。ただし、自動ビルドシステムを強化する必要がある場合があります。Martin Fowlerシリーズの連続配信の本を読むことを強くお勧めします。これは読みにくいものであり、非常に反復的ですが、それでも非常に役立ちます。そしてあなたのマネージャーはこのためにあなたを愛します。すでに多くの自動テストを行っているので、安定した頻繁なリリースを実行しても問題はありません。ただし、自動ビルドシステムを強化する必要がある場合があります。Martin Fowlerシリーズの連続配信の本を読むことを強くお勧めします。これは読みにくいものであり、非常に反復的ですが、それでも非常に役立ちます。そして、あなたのマネージャーはこのためにあなたを愛します。すでに多くの自動テストを行っているので、安定した頻繁なリリースを実行しても問題はありません。ただし、自動ビルドシステムを強化する必要がある場合があります。Martin Fowlerシリーズの連続配信の本を読むことを強くお勧めします。これは読みにくいものであり、非常に反復的ですが、それでも非常に役立ちます。

3）pomodoroテクニックを使用して、うまくいかないものを適応/変更します。これをこのリストの2番目の数字と組み合わせると、生産性が大幅に向上します。

4）Vimを学ぶ。ViEmuを介してVisual Studio内で、またはプラグインを介してEclipse内から、またはEmacs内からこれらのコマンドを使用しても、生産性が向上します。Vimを習得する最善の方法は、Vimを使い始めて、マスターするまでは（決して無効にしたり、古いツールに戻って）しないことです。最初は痛みを伴いますが、決して後戻りしたくはありません。これによって速度が大幅に向上することはないと言う人もいます。しかし、特にコードの読み取りと変更が私たちの仕事である場合、高速化は高速化され、私はこれで時間を大幅に節約できることに気付きました。

5）この最後のものは、良いアイデアかどうか確信がないので必ずしも推奨されません。実際にあなたの生産性を低下させるかもしれませんが、とにかくそれをやり通します。より多くの受け入れテストを行い、単体テストを少なくするか、少なくとも受け入れテストを行うことをお勧めします。SpecFlowで成功しましたが、もっと良いものがあると思います。仕様を書くことは非常に技術的なこともあるので、マネージャー/顧客に最初に大まかな変更を行う大まかなドラフト版を書いてもらうか、すべてを自分で書いて読んでOKにすることができます。これは、このリストの2番目に役立ちます。また、受け入れテストはより実用的であり、単体テストよりも少ないコードで済みます。これは、それらがそれらを置き換えることを意味するものではなく、さまざまな目的のためのさまざまなツールです。

6）これはさらに実験的で物議を醸すものです。私は実際に自分でこれを行っていないので、正確に推奨することはできません。JetBrainsのメタプログラミングシステムを学び、使用します。これを使用して、マネージャー/顧客が目的のソフトウェアを作成するために使用するツールを作成します。これを使用して、マネージャー/顧客が非常に簡単で複雑でない方法で動作を指定するために使用するツールを作成できる場合、ユニットおよび受け入れテストの実行を停止できる場合もあります。アイデアは、プログラマを取り除くことではありません。プログラマーは、（ツールではなく人が）必要な機能を簡単に作成できない場合、顧客/マネージャーが使用するこれらのツールに新しい機能を追加する必要があります。私は、MPSまたはそれに類似した他のツールのいずれかが将来の道であると信じています。

より多くの脳を使用し、テストを少なくします。正直なところ、テストには場所がありますが、高価です。

また、The Art of Unix Programming（無料のオンライン、価格に見合う本）も読んでください。

最後に、あなたは正しい場所にいないかもしれません。スクエアジョブの丸釘など

最終的には学校のようなものです。「教師が望むものを出力する」は「経営者が求め、支払うものを出力する」になります。

完成したプロジェクトを大規模に処理し、1時間あたりの「最終」コード行数を取得すると、プログラマーが想像したよりもはるかに遅くコーディングすることがわかります。

1日に数行のコードを話しているだけです。残りの時間は、デバッグ、書き換え、一般的なプログラマーの仕事に費やします。

古いことわざを聞いたことがあるかもしれません-入力中にエラーをキャッチすると、ビルド時にエラーをキャッチした場合の10倍の時間を節約できます。リリース後にキャッチするよりも。

それでは、どのようにスピードアップしますか？私は入力速度のどのような形式にも集中しません。エラーを減らし、コードとのその他の「将来の相互作用」を改善することは、あなたの時間のより良い投資になるはずです。

読みやすく、明確なコードが重要です。コードを一度書くと、何十回も読まれます。読みやすくするために書くことで、将来のトラブルを大幅に軽減できます（これにより多くの時間も節約できます）。戻ってコードを読んで、一瞬でもそれについて考えなければならないなら、あなたはそれを間違っています。

ペアプログラミングはQAの時間を短縮できます。1人のプログラマが1日に数行しか生成しない場合、2人が1つと同じレートでコーディングでき、エラーが少ない場合は先に進みます。

防御的なコーディング（たとえば、パラメータチェック）により問題を軽減できます...チームに非常に優れたアナリスト/アーキテクトがいる場合、適切な開始設計で時間を節約できます。

それ以外の場合は、設計スキルを向上させてください。経験を積むにつれて、機能しないパターンを認識して回避できるようになり、タイムシンクをより早く特定できるようになります。

仕事中に自分自身の詳細な監査を行うことを検討しましたか？時間をどのように過ごしているかをペンと紙で追跡するか、Rescue Timeなどを使用して追跡します。

どのように時間を費やしているかを正確に把握すると、改善が必要なものについてより良いアイデアを得ることができ、そこで努力を集中できます。

理想的には、これを行うために同僚の何人かに挑戦し、結果を比較し、お互いからアイデアを得ることができます。あなたはおそらく彼らも恩恵を受けることができるいくつかの強みを持っています。

自動化できるプロセスの一部に時間を費やしすぎているか、1日の特定の時間に多くの注意散漫があり、その日の別の時間は静かであることがわかった場合、タスクを計画することができますそれなど

または、テストに思ったよりも時間がかかっていることがわかり、テストが速くなっているという認識を再考する必要があります。

他に何もない場合、それはあなたが反対することができるいくつかのベンチマークを提供します。

あなたのリストから、あなたは元気です。

同僚がより高いCRAP番号を使用してコードを作成している場合、より速くなります。CRAPは、循環的な複雑さとテストカバレッジを組み合わせた、コミカルに命名されたメトリックです。

必要以上にCRAPなコードを書かないでください。;）

あなたに提案する私の唯一の変更は、ライブラリを使用することです。

1. あなたの会社は図書館を販売しています
2. 繰り返し発生するコードをライブラリにリファクタリングしました

あなたは本を読んでやっています。それは素晴らしいことです。しかし、手続き型コードやオブジェクト指向コードについて考え続けることができないかもしれません。関数型プログラミング（Haskellなど）やPrologに身をさらしましたか？

OOプログラミングテクニックを磨くために、Smalltalk / Squeakで遊んだことがありますか？

そして最後に、理論。少なくともグラフ理論の初歩的な理解はありますか？（いくつかのプログラムは、ある時点でツリー、DAG、または単なるグラフで動作します。ネットワークはグラフです）

ボブおじさんを引用します：

速く行く唯一の方法はうまくいくことです。

品質と速度のトレードオフの誘惑に屈するたびに、速度が低下します。毎回。

- 「Vehement Mediocrity」、Robert C. Martin

私の知る限り、それは：

1. 良い
2. 速い
3. 安いです

マネージャーとして、任意の2を選択できます。

あなたが高速化しているコメントを心配しないでください。仲間のコーダーとして、一緒に平手打ちされたものよりも、よく考えられ、よく書かれたコードを維持したいと思います。

私が考えることができる主なものは次のとおりです

• 入力速度を上げます。
• 生産性を向上させるツールを使用します。たとえば、ReSharper。
• より高速なマシンまたはツール。より多くのRAMまたはソリッドステートドライブのように。

コーディングスキルの分野でもできることは確かにありますが、そういったことはすべてあなたのようです。上にリストしたものは通常、開発者によって見落とされます。

スピードタイピングコースを受講できます。タイピングの高速化が問題かどうかはわかりませんが、単にタイピング速度が遅いために「コーディングが遅すぎる」可能性があります。

コードジェネレーターはどうですか？コードが繰り返し発生する場合があります。リファクタリングはその一部を削除できますが、それでも同じリファクタリングされた関数を繰り返し呼び出すことがあります。使用するデータとコードによっては、コードジェネレーター（Excel、Perl、Javaなどで記述されたもの）が大幅に時間を節約する可能性があります。また、UI開発にコード生成ツールを使用することは、通常は簡単です。

そして最後に、メトリックが間違っている可能性があります。他のすべてを考慮して、可能な限り速い速度でコーディングしていること、およびタイムラインが短すぎて、遅いコーダーのように見えることを考慮しましたか？

あなたの質問の編集に基づいて、あなたは同僚の何人かのルートを取り、動作する最も速いソリューションを一緒にハックすることができるようです-そして、文書とQAは気の毒になります！

または...特定の分野でより多くの経験と練習を積むことで、コードベースとAPIを熟知しているので、睡眠中にソリューションをコーディングできます。これは実行できますが、さらに時間がかかります。あなたはより多くの先輩や、より経験豊富であることが知られているよりも速くしている他の開発者が、その後行うに一つだけ存在する場合- あなたはしなければならないとなってより多くの先輩と経験します！

OPの「速度を犠牲にした品質」ビューには異議があります。

プロのコーダー（プログラマー）は3つのオブジェクトを満たす必要があります：
1）コードは意図したとおりに実行する
必要があります2）納期は間に合っている必要があります
3）良質、ドキュメントなどがある
4）その他

おそらく、OPが間に合わなかったためか、OPが遅いと非難されたと思います。

これは回避が難しいキャッチ22です。あなたはまだ経験が不足しているかもしれず、多くの面である程度の知識はすでにほとんどよりも速いですが、キャッチは測定するのが難しいということです。

個人的にこの時点でできることは、自分自身を測定することです。自分の仕事のやり方に関するフィードバックを提供してください。おそらく、仕事の習慣を単純に変えるだけで、生産性を高めることができます。

メールが途切れたため、思った以上にメールが食いつぶされていました。今では1日に2回しかメールに返信せず、数日でほぼ1時間の生産性が得られました。pomodoroのような方法を試してみて、私はそれを手段として使用しました。定期的な間隔（15分）で、そのとき何をしていたかを書き留めます。これにより、私の日々がどのように構成され、効率を最大化するために何ができるかを知ることができました。

Squeakの高速コーディングの利点は、「OOPスキルを磨く」だけではありません。IDEと同様に、最新のGUIがSmalltalkで発明された理由があります。JUNITはJavaへのSUNITの移植であり、「OOP」という用語はSmalltalkなどを記述するために発明されたのは言うまでもありません。

達成したいものに最も適した言語と環境を常に使用する必要がありますが、一般的なプロトタイピングでは、少なくとも、HyperCardの例外を除いて、squeakをあらゆるものと一致させます。 Squeakにはハイパーカードのような機能が組み込まれているため、実際には高速です。