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


144

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

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

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

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

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

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

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

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

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

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

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

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


4
他の人は同じ品質であなたよりも速くコーディングしますか?そうでない場合は、保守記録とバグレポートを参照して、速度が問題ではないことを示します。
マイケルK


1
レースに勝とうとするために、最速の馬を選択し、より速く走るためにそれらを打ちます。質問は?
ポール

24
答えはありませんが、気分が良くなるかもしれません。どんなに遅くてもプログラマーのように感じるかもしれませんが、非効率だと感じるかもしれませんが、あなたのマネージャーはずっと悪いです。改善するのを助けずに、「ちょっとボブ、遅すぎる」と言っているのはどんな馬鹿ですか?あなたが短すぎると言うかもしれません。それはリーダーシップではなく、ただhe屈です。私は提案があると思います:あなたの欠点を克服するためにあなたと協力する有能なマネージャーと仕事を見つけてください。
マルヴォリオ

1
すべての答えは私を不幸にします。noob-> mediocreのステップだけが必要な場合は、1つのことを行うだけで十分です。しかし、平凡な専門家は常にすべてを学ぶ必要があります。VCS、エディター、プログラミング言語、フレームワークを深く学ぶ必要があります。あなたは考えずにそれらを行うことができるタフで面白いステップを繰り返す必要があります。そして、顧客のニーズと同僚のニーズの違い、日々の気分がコーディング/設計/議論の能力にどのように影響するかなど、コンテキストを適用する方法を見つける必要があります。あなたが1つのことをしたい場合、これを行う:すべてを学ぶ。
erikbwork

回答:


158

ジェフ・アトウッドのこれに対するアプローチは、ここ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つのポットを生産する必要がありました。さて、採点の時が来て、奇妙な事実が浮上しました。最高品質の作品はすべて、数量で採点されるグループによって作成されました。「量」ながら

本質的に手をより早く汚し、より頻繁にスキルを向上させる方が、「完璧な」方法を研究し理論化することに時間を費やすよりも優れています。私のアドバイス、練習を続け、テクノロジーに追いつき、デザインを学びます。


12
この類推は、陶工が質の高いものを生産する前にごみ入れの山を作ったことを意味しないのでしょうか?プロフェッショナル環境で、すべての良心でそれを行うことができますか?そして、勉強して理論化してから締め切り前に仕事を終わらせた人たちはどうでしょうか?
PDR

4
趣味のプログラミングの経験のために、20個のゴミ入れで構いません。それは私の専門的なプログラミングの経験にも役立ちます。それに、どこかから始めなければなりません。
-ashes999

23
私は表面の価値のためにこれを見ることにしました。「練習は完璧です」。あまり深く見ないでください;)
クリス

6
私はこの答えが嫌いです。なぜなら、「スローアウェイプロトタイプ」が決して捨てられないように、間違ったやり方をとるのは簡単すぎるからです。
ルドルフオラー

2
多くの人がこれに問題を抱えているのは奇妙だと思います。反復的な開発プロセスのほぼ完璧な例えです。要件を満たし、バグを修正し、それが正確で十分になるまでリファクタリングするために、何かを迅速に構築します。この方法でソフトウェアを構築していない場合は、実際に試してみる必要があります。反すうとへそを見つめることは、何かを成し遂げて人々に強打させるよりもはるかに効果的ではありません。
ジミージェームズ

72

他の誰も言及していないように見える可能性の1つは、あなたがうまくやっていて、マネージャーがあまり良くないということです。彼らは生産性をどのように測定していますか?彼らはあなたに特定の例を与えることができますか、それは単なる一般的な認識ですか?彼らはあなたと比較して他の人の仕事を修正するのに費やした時間を考慮に入れましたか?

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


1
これはおそらく問題の大きな部分です。振り返ってみると、私の会社で何年も働いている人たちといつも比較されているのは、あまりにも無意識に思えます。うーん
...-ashes999

その場合は、私の質問の最初の2つを直接聞いて、どのような応答が得られるかを確認し、そこからそれを取る
-pdr

16
実は、実稼働で出力したプロジェクトが、他のチームの同等の作業よりも1桁または2桁少ないサポートコールを体系的に生成するときに、私は無能であると述べたマネージャーにしばしば遭遇しました。多くの人は単に全体像を見ることができません。メトリックスは、迷惑なことと同じくらい役立ちます。通常、このようなマネージャーは、システムのゲームを試みて、統計が良好になるようにします。
ニュートピア

これは答えというよりもコメントです。個人的には、他の人がどう思うかに関係なく、コーダーとしてより速く、より効率的になりたいです。トピックについて議論することは間違いなくたくさんあります。
アンドレスカネラ

@AndresCanellaこの質問のすべての答えは、基本的に長いコメントです。あなたは正しい、議論することがたくさんあります。これは実際には議論に適した形式ではありません(そうすることも意図していません)。しかし、それはそもそも良い質問でした。だから、それは閉じられ、コミュニティWikiとしてマークされています。
pdr

39

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

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

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

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

* http://codekata.pragprog.com/


他のサイト/用語をグーグルに提案できますか?1週間に1つの奇妙な課題に取り組むと、脳がさまざまな次元で動く可能性があると思います。
-ashes999


1
最初の部分は意味がありません。あなたをより速くするものはすべてあなたをより速くします。少なくとも時間の一部がタイピングに費やされている場合、タイピング速度を向上させるとより速くなります。少なくともあなたの時間の一部がコンピューターを待つことに費やされている場合、コンピューターの速度が速いほど速くなります。できるだけ速くなり、常に改善するための探求をしているとき、見落とされるべきものはありません。
still_dreaming_1

12
タイピングやコンピューターの速度などの小さなことは大きな違いを生みます。これは、予期しない副作用が原因です。コンピュータを待たなければならない場合、ほとんどの人はイライラし、気が散ることさえあります。フラストレーションと気晴らしの組み合わせは、生産性を大幅に低下させます。同様のことがタイピングにも当てはまります。あなたがタイピングが速い場合、それはおそらくあなたがタッチタイピングが本当に上手になったことを意味し、おそらくあなたはタイピングについてあまり考えないでしょう。これにより、目と脳が解放され、目の前のタスクに集中でき、生産性が大幅に向上します。
still_dreaming_1

@INTPnerd同意します。画面に「投げる」という言葉がどのように表示されるかを考えることに時間を費やす場合(「マウスをそこに移動してからクリックし、キーボードの「t」を見つける必要がある」)、あなたの脳には時間がありません実際の決定を考慮してください。
erikbwork

25

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

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


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


5
それは私が初期の仕事から結論付けたものです-他の人は、非常にスピードを犠牲にして、著しく低い品質を書いていました。それが私のアキレス腱です。後で噛み付くことがわかっている悪いコードを書くのは非常に難しいと思います。
ashes999

これは簡単に解決できる問題です。ソフトウェア環境を変更する必要があります。迅速に実行するよりも正しく実行することが重要である環境で作業する必要があります。重要な仕事はそこにあります。
マイケルショー

両方が等しく評価されている環境で働いた経験はありますが、それを正しく実現しているすべての人々の間で、より速くそれを実現している人は、それを適切に遅くしている人を打ち負かしています。そして、私は後者のグループにいると思います。
-ashes999

2
大丈夫、その場合、おそらくコードの記述、テスト、デバッグに使用する戦略次第です。「速い」プログラマーとプログラムをペアリングして、彼らが思考プロセスをどのように整理するかを見ることができますか?
マイケルショー

1
@ ashes999:練習と経験と忍耐で、後者のグループから前のグループに移動します。一晩あなたを移行させる魔法の薬はありません。
FrustratedWithFormsDesigner

12

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

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

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

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

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


8

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

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

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

要約すれば:

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

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


これが正しい答えではないことを本当に願っています。私はすでに自由時間のコーディングの多くを費やしており、私が見逃している何か他のものがあり、私に大きな優位性を与えることを願っています。
ashes999

@ ashes999、OK!自由時間コーディングを使用して、作業をレビューしますか?私のポイントは、コードの最適化に取り組み、それを理解する時間があるに違いないということです。すべてのコードを作成できますが、最適化の時間を何回与えますか?
ブハケシンディ

@TEGプロジェクト間でレビューします。例えば。プロジェクト#1で同様のプロジェクト#2で特定の方法で何かをコーディングした場合、設計の欠陥を熟考し、多くのリファクタリングを行う可能性があります。
-ashes999

@ashes-「多くのリファクタリング」は、初期設計が最適ではなかったため、そこにタイムシンクがあることを意味します。上司が知らない場合は、時間の経過を説明するのに問題があります。上司が知っている場合は、そもそも経験豊富な同僚がデザインをレビューしなかった理由を説明する問題があります。

@TRA申し訳ありませんが、指定する必要があります- 趣味のプロジェクトでは、多くのリファクタリングを行います。職場では、リファクタリングを軽くするか、目に見えるタスクを作成して、リファクタリングしていることをマネージャーに知らせます。
-ashes999

8

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

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

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

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

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

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


8

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

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またはそれに類似した他のツールのいずれかが将来の道であると信じています。


5

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

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

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

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


3
テストを行うと、遅くなるのではなく、速くなります。テストが少ないと、「何かが壊れる」ことを恐れてコードを大幅に飛躍させることができないため、より多くのリグレッションがより長く発見されず、修正が難しくなります。
-ashes999

私にとっての自動テストはコードの匂いです。これは、コードが単純ではなかったことを意味します。
クリストファーマハン

6
コードが非常に単純でテストを必要としない場合、何も興味深いことはしません。
ラインヘンリヒス

正確にどのように知っていますか?ああ、もう一度仮定して...モジュラー性のルール:きれいなインターフェイスで接続された単純なパーツを書くことを紹介します。(Unixプログラミングの芸術から)
クリストファーマー

クリストファー、何かあると思う。ashes99が多くの時間を費やしているのはここです(例: "slew")。何も多すぎるのは悪いことです。この場合、飛行制御システムのコードを修正しない限り、実行するテストの量を再考する必要があります。または、そのような分野に入ります。
-user21007

5

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

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

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

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

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

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

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

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


3

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

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

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

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

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

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


3

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

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

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

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

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

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

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

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


ここにはたくさんの素晴らしいポイントがあります。ゲームXの機能(たとえば、ゲームの複数のセッションにわたるSilverlightストレージ)が必要なため、ライブラリが必要です。私のゲームとは特に関係ありません。私はcomp-sciのバックグラウンドを持っているので、手続き、OO、機能、およびその他(Prolog)を行いました。グラフ理論、ええ。深さ優先のグラフ再帰私は非常に頻繁に使用しましたが、奇妙なことに十分です。
-ashes999


3

私の知る限り、それは:

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

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

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


2

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

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

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


私はこれらのことに関して同僚と平等な競争の場にいます(たぶんタイピング速度に長けているでしょう)。どういうわけか、彼らはまだ高速です。たぶん経験?
-ashes999

1
特定の最小の「ハントアンドペック」最小値を超えると、タイピング速度は制限要因ではありません。

2
あなたには彼らと同じレベルであるかもしれない持っツール(例えば、ReSharperのを)しますが、それらを効果的に使用する方法を知っていますか?多くの人がResharperをインストールして、80%の機能の使い方を学んでいないのを見てきました。さらに言えば、Visual Studioのリファクタリングとショートカット機能をすべて理解してください。一日中キーボードに手を触れているだけで、オフィスの他の誰よりも2〜3%簡単に優位に立つことができます。マウスが遅い:)
EZハート

@EZ Hart:非常に良い点。一部の最新のIDE(Eclipseの頭の中で考えている)には、リファクタリング、コード参照の検索(テキスト「myMethod」が表示される場所だけでなく、クラスまたはメソッドが参照される場所など)のための非常に強力なツールがあります)。これらの「高度な」機能の中には、コードベースをより効率的に管理できるようにするために、5分間かけて学習する価値があります。
FrustratedWithFormsDesigner

私たちはすべてレベルです。私たちは誰もツールを持っていません:)
ashes999

2

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

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

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


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

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


タイムラインではありません。他の同僚は同じ作業をより速く行うことができます。たぶんそれは経験です。タイピング速度の+1。100WPM前後で入力できるので、そうではありません。
-ashes999

@ ashes999:同じ作業をより速く行える人がより経験豊富な場合、問題のシステムをより多く経験することで最も恩恵を受けるでしょう。経験には時間が必要です
...-FrustratedWithFormsDesigner

コードジェネレーターは、混合された祝福です。時間を節約できますが、生成されたコードに多くの時間を費やさなければならない場合は、管理できないほどの損失につながる可能性があります。

2

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

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

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


2

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

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

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


あなたは自分でサンプルプロファイルを作成していると言っているのですか?面白い。:)
sum1stolemyname

実際には、しばらく試した時間追跡方法の副作用でした(davidseah.com/tools/ett/alpha)。タイムトラッカーの部分を超えて調べ始めたときに、興味深い予期しないデータの傾向が判明しました。ポモドーロ、GTDなどについて学んだ後です。
ニュートピア

0

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

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

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.