web-dev-qa-db-ja.com

「より速い」プログラマになるには?

私の最後の仕事の評価はただ一つの弱点を含んでいました:適時性。私はこれを改善するために私ができることをすでに知っていますが、私が探しているものはいくつかあります。

品質を犠牲にすることなく、出力を高速化するためのヒントやアドバイスはありますか?

タイムラインをどのように見積もり、それを守るのですか?より短い期間でより多くを成し遂げるために何をしますか?

フィードバックは大歓迎です。

142
Nick Gotch

コンピュータの電源を切ります。鉛筆と紙をつかみます。デザインをスケッチします。同僚と一緒にレビューしてください。次に、コードを記述します。

190
gatorfax

いくつかのアイデア...

  • 金メッキを避ける-要求されたものだけを実行します(要件に関して)
  • ビジネス要件を理解し、最初から正しく実行する
  • 環境とツールを完全に理解する
  • 素晴らしいタイピストになり、マウスの代わりにキーボードショートカットを使用する
  • 反復的なアプローチを取り、健全性チェックを組み込んで、正しいパスにいることを確認します
  • 車輪を作り直すのではなく、過去の作業と他の人の作業を再利用することを検討してください
  • 気晴らしをなくし、メールのチェック、外見、同僚との会話などを続けないでください。
  • 過労しないでください-休憩を取る必要があるときを認識してください
149
Mayo

それだけで「より速い」プログラマになりたいというあなたの願いは称賛に値します。 ただし、時間どおりに納品しないことは、あなたが遅いことを意味するのではなく、プロジェクトの計画が不十分であることを意味します。「より速い」プログラマであることは役に立ちません。それはあなたがより早く締め切りを過ぎて叫ぶことを意味するだけです。

あなた(およびあなたのチーム)は、次の誤りの1つ(またはすべて)を実行しています。

  • 過小評価実行する必要がある作業。
  • 欠落計画中の大きな要件またはアーキテクチャの一部。
  • 混乱カレンダーの見積もりを使用して見積もりを行い、会議/電話/その他のオーバーヘッドなどを考慮しません。

上記の3つに対処する方法はいくつかあります。しかし、それらのいずれかを改善する前に、物事がそれらの方法で進んでいる理由を知る必要があります。 事後分析を行う最後の2つまたは3つのプロジェクトの見積もりと実際の所要時間を比較し、余分な時間がかかった場所を特定します。

もう一度繰り返します-コードの記述が遅いからといって、締め切りを見逃すことはありません(その事実を考慮して適切に計画している場合)。

132
Franci Penov

本当に、本当にあなたのエディタを学びます。 IDEを使用している場合は、提供されているすべての機能を使用していることを確認してください。選択したエディタのキーボードショートカットについては、チートシートを入手してください。シェル設定を使用している場合一般的に使用されるディレクトリのショートカット

89
slashnick

「品質を犠牲にすることなく出力の速度を上げるために何をすべきかについてのヒントやアドバイスはありますか?」

多くの人が、(a)シンプル、(b)信頼でき、(c)正しいものを犠牲にして、「究極の」品質を目指して努力しています。

開発をスピードアップするための最も重要な方法は、simplifyを行うことです。そうすることで、できる限りシンプルにできます。

時間通りに配達することに問題を抱えているほとんどの人々は、道を進みすぎています。そして、与えられた理由はしばしばばかげています。それらは、実際の要件ではなく、単に認識された要件であることがよくあります。

多くの人から、お客様が「期待していること」を言われていると聞きました。これは悪い方針です。

可能な限り単純なものを作成します。顧客がさらに必要な場合は、さらに構築します。しかし、最も単純なものを最初に作成します。

38
S.Lott

コードを完全に磨くのを避けて、機能させるだけです。それはビジネスが期待するものです。

しかし、多くの場合、速度が上がると品質が犠牲になります。

32
user8685

再利用-私は以前のプロジェクトから賢い部分を取り除いて、将来のベンチャーでそれらを再利用できるようにしています。 「いつかまた使ってみませんか?」

29
Phil Jenkins

複雑にしないでおく。

TDDを使用する場合、 "red、green、refactor"に従う必要があります。

  1. 失敗したテストを書く()。 (多くの場合、コードにはまだ機能がありません。)
  2. 恐ろしいコーディング犯罪を犯して、テストに合格します(green)。必要に応じてハードコードします。
  3. リファクタリング、おそらくしばらくの間テストを壊しますが、全体的に設計を改善します。
24
bryanbcook

すべての言語/ライブラリのドキュメントをローカルのコンピューターにダウンロードし、ネットワークケーブルを抜くか、電源をオフにします Wi-Fi

ここで面白いことをしようとはしていません。これは本当に役に立ちます!

22
mcjabberz

Stack Overflowを長く読んでいることに注意してください。 「コンパイル」の言い訳は、長い間しか機能しません。 :)

20
Matthew Jones

タスクを頻繁に切り替えることは避けてください。 Mylyn などのツールを使用してタスクを管理している場合でも、注意散漫やタスクの切り替えによって1日が中断する可能性があります。

細分度(30分など)を把握し、目前のタスクに関連するものだけに取り組みます。それ以外のもの(新しいバグレポート、その他の問題に関する電子メール、無関係な手順上の問題)は、少なくとも「次のチェックポイント」まで延期されます。夢中にならないように、ポップアップの電子メール通知を無効にしてください。

物事が本当に溶けて、すぐに注意が必要かどうかを知らせてくれる仲間がチームにいる場合、これは特に効果的です。

20
Uri

正しく、最善の方法で、初めて。それがあなたが立ち止まる前にそれを考える前にしばらく考えなければならないことを意味するなら、それをやってください。時間の90%は機能します。

14
ck01

できるだけ早くタッチタイプ を学んでください。

14
AJ Johnson

明日やる

Getting Things Done も非常に役立ちます。

とにかく私は注目のスパンが短いので、これらの本は私の焦点を保つのに役立ちます...何をもう一度やりましたか?

12
Matthew Jones

練習とハードワーク。

時間と労力を費やす必要があります。使用するツールに慣れ、自信がつくにつれ、スピードと創造性が続くはずです。

特定のスキルを向上させたい場合は、具体的に練習できる演習を設計することも役立ちます。あなたの遅さが設計段階にある場合、オンラインで作業する設計の問題を見つけてみてください。同じエクササイズをやり直すと、より速く完了し、スピードを練習できます。私は個人的に、純粋なプログラミング速度を練習するために TopCoderのアルゴリズム演習 が好きです。デザインの難しさもありますが、試したことはありません。

12
DisplacedAussie

ゾーンについて学び、ゾーンに入る方法を学び、ゾーンに入っていないときにそれを認識する方法を学びます。

「ゾーン内」に入ると、非常に生産性が高くなり、コードが流出するだけで、多くの場合、1日で2〜3日のコーディングを行うことができます。しかし、多くの場合、その場所に到達するのは難しいことがわかります。自分自身が先延ばしになり、他のことに気を取られてしまいます(たとえば、スタックオーバーフロー)。

what-tricks-do-you-use-to-get-yourself-in-the-zone からの引用

11
Dustin Getz

IDEとフレームワークをよく理解します。細かいことをすべてGoogleに頼るには時間がかかります。

10
Mike Hall
9
ZeroCool

開発を始める前に:

  • メールボックスからログアウトする
  • [〜#〜] im [〜#〜] クライアントをオフにする
  • 丁寧に仲間に頼んで集中する時間を与える
  • もちろん、ネットサーフィンをやめる

邪魔されるたびに、思考を軌道に戻すには心の時間がかかるため、速度が低下します。中断ごとに、中断前の思考プロセスにリセットするのに5〜10分かかるという数字を聞いたことがあります。中断ごとに時間がかかるため、1日を無駄にするのにそれほど時間はかかりません。

私たちの会社の人々は、実際にはカレンダーで時間をブロックし、毎日数時間、空の会議室に移動しています。

8
dhable

開発を学ぶIDEインとアウト。ショートカットキーを学ぶ。マウスをあまり使わないことを学ぶ。これにより、時間を大幅に節約できることがわかりました。

7
D3vtr0n

同僚よりも遅いですか、それとも見積もりが楽観的ですか?

7
pjc50

ソフトウェアをより高速に生成するために、私は実行する最良のことは、ランタイムAPIをできるだけよく学ぶことです。 LINQ拡張機能が実行するときにリストロジックを入力しないでください。バインディングが機能するときに、一連のイベントリスナーを構築しないでください。

見積もりに関しては、これには経験が伴います。そこにある見積もりソフトウェアを利用して、より良い見積もりを見つけることができます。

個人的に、私はジュニアレベルの開発者と知り、彼らの最初の見積もりが何であれ、それを2倍してから2倍にします。これは、学習、会議、無駄な時間などのすべてを考慮に入れます。上級レベルの開発者ほど、見積もりよりも2倍多く働く傾向があります。

多くの場合、あなたの見積もりが間違っていたかどうかは問題ではありません。それはあなたの見積もりがすべての正しいことを説明したのですか?コーディングの労力またはカレンダー時間の観点から見積もりとタイムラインを提供していますか? 1日中常に考え、そのどれだけが実際の生産的なコーディングか、会議、学習、デバッグなどかを考えてください。

7
James Schek

暗示されているかもしれない2つのことはありますが、生産性を向上させる答えはここではまだ見ていません。

  • ある種のビルドおよびデプロイメントスクリプトを使用します。 app-serverのコンパイル、デプロイ、再起動などは、時間もフォーカスも無駄にせず、ワンクリックで実行できるはずです。

  • なんらかのバージョン管理が必要です。変更をロールバックせずにコーディングする必要があるのは、卵の上を歩こうとするようなものです。

7
Buhb

いくつかのアイデアが思い浮かびます:

  1. あなたの見積もりについて他の意見を得てください-「ねえ、あなたはこの種の機能をこの時間枠で達成できると思いますか?」のような質問をすることができる他の開発者はいますか?誰かがあなたが見積もりをするのにあなたが見逃したたくさんのことに注意するかもしれないので、他の人の入力がいくつかのケースで正確さを助けるかもしれないという考えです。

  2. 見積もりスキルを磨く-見積もりをどのくらい外しているか、なぜ外れているのかを追跡し始めます。他の作業項目が期限に間に合わない原因になっていますか?何かがどれほど複雑かを常に過小評価していますか?それが現実的でないときに、タイムライン全体を提供していますか。尋ねられることは、プロトタイプを作成するだけで数週間かかるほど漠然としていて、他に何をすべきかを再評価する必要があるでしょうか。これを行うことは、スキルの構築に最も役立ち、何かがx時間かかると言った場合、何度も何度もそれを行ったので、自信を持つことができます。これを述べる別の方法は単に練習、練習、練習です。

おそらくあなたはすでにこれらを検討していると思いますが、これらのアイデアを検討していない可能性がある他の人々のためにこれを述べることは価値があると思いました。

7
JB King
  1. 内外のテクノロジーを知る。
  2. やめる!考える!行こう!
  3. 何が起こっても構いませんが、実際に求められていることだけを実装してください。
  4. KISS-シンプルにバカにして
  5. 複雑になりすぎているとしたら、それはよく考えられていません。 (2と4に戻る)
  6. 5で立ち往生しないでください。最初からやり直すことはよくあります(2と4に戻ります)。
  7. 1に戻ります。
7
Rui Craveiro

ここでのキーワードは「適時性」だと思います。彼らはあなたが遅すぎると言ったのではなく、あなたがタイムリーではなかったということです。

プロジェクト管理では、マネージャーが作業項目が正確に完了する時期を推定できることが重要です。あなたの努力がタイムリーであると思われなかった主な理由は、あなたが頻繁に予定通りに配達されなかったアイテムがあり、予定よりはるかに遅れて配達されたためだと思います。

適時性を向上させるには、スキル、経験、およびドメインを考慮して、特定の作業項目を完了するのにかかる時間を理解するために、より多くの時間を費やす必要がある場合があります。これにより、プロジェクトマネージャーにより良い見積もりを与えることができます。ここでの鍵は「より良い」です...ファッジファクターですべてにパディングすることにより、より頻繁に時間どおりに配達できますが、本当に努力したいのは、より正確な見積もりです。

これが実際に問題であるかどうかを確認するために、上司と話し合います。そうしないと、プログラミングが2倍の速さで終了し、以前の半分の時間で約束がつき、見積もりが同じ誤差要因を持っているため、適時性について批判される可能性があります。

7
Larry Watanabe

安定して、安定してください。

わずかな機能を実装する何かを構築し、それがエンドツーエンドで機能することを確認します。その後、新しい機能を追加する間、それを機能させ続けます。ええ、これは一部TDDプラクティスですが、TDDを行わなくても理にかなっています。

理論的根拠は、安定していない2週間のコードを持つ誰かを見たときはいつも、安定するまでにさらに2週間かかるということですget安定します。

stay安定している場合は、その不確実性を取り除き、必要に応じて期限近くに範囲を絞り込む方法も提供します。

明らかな反論は、最終コード以外のコードを安定させるために追加の作業を行うため、これを実行するのに1回だけ書くよりも時間がかかることです。私はこれを少しの間購入しません。 機能するのコードがあり、5行を変更して何かが中断した場合、正確にが中断したはずの場所がわかります。

まったく機能しなかったのコードが10,000行あり、区切りを見つける必要がある場合は、検索するコードが大量にあります。

一貫して安定したFTWであるシステムでの小さな増分変更。ゆっくり進むと速くなります。

7
kyoryu

私にとって、優れた生産性を得るには、何を達成しようとしているのか、どうやってそこに到達するのかについて明確な考えを持つことが重要です。

7
mdma

答えのほとんどすべてが、ここや他の多くの場所で死ぬと言われています。または、少なくとも私はそれが死ぬまで聞いたことがある。 IDEを学び、より速くタイプすることを学び、フレームワークを使用し、コード生成を使用するなどします。もちろん、これらのことは役に立ち、それらすべてのマスターである多くのプログラマーがいるとは思えません。しかし、これらの質問をし、Stack Overflowのようなサイトに頻繁にアクセスするタイプのプログラマーであることあなたはすでにこれらのことを知っていました。あなたは単にそれらをここに繰り返したいのですか、それとも少しだけ通気したいのですか?

しかし、その状態に到達できたらどうでしょうか。私はこれらすべての提案をマスターすることを意味しますか?それから何が起こりますか?上手。タイムラインはさらに短縮されると思います。そして再び、品質の認識に戻ります。つまり、私たちの技術は間違いなく進歩し、数十年でますます生産性が向上しています。しかし、この時期に品質は向上しましたか(もちろん初期の段階を除きます)?

私の答えは簡単です:高品質のソフトウェアには時間がかかります!どちらか一方のみを交換できます(品質/速度)。しかし、そうだと私たちは皆知っていますが、そのトレードオフがしばしばスケールのスピードの終わりに終わる度合いについては正直ではありません。そして、私たちはプロジェクトの早い段階でさらに大きな嘘つきです!

私は言いますあなたはここで過失ではありません。問題は知覚人々は、高品質のソフトウェアがどれくらいの時間を費やすべきかについて持っています。私たちは、上司や私たちが推測するタイプのタイムラインで高品質のソフトウェアを作成できると信じて騙しています。 高品質のソフトウェアは作成しません。機能するソフトウェアを作成しますが、アプリケーションの特定のコーナーで品質のフラッシュが発生する場合があります。

では、これについて何ができるでしょうか?各プロジェクトへの投資を2倍または3倍にする必要があることを上司に納得させることはできません。私は例でリードと言います。本当に素晴らしいソフトウェアをサイドプロジェクトとして作成します。自分の時間をそれに入れ、妥協しないでください。しばらくの間、あなたが進歩する方法に注意を払います。予想外の時間を費やさなければならなかった、明らかに無関係のタスクを書き留め、それを正当化できるかどうかを確認します。これを、これまでに取り組んだ他のすべてのプロジェクトと比較してください。自分自身とこの分析のすべての側面について残酷に正直であること。高品質のソフトウェアを使用して行った余分なことを、実際のプロジェクトで無視できますか?しかし、おそらくあなたの試みは失敗しました。その理由は何ですか?あなたは退屈し、コア機能を完成させるために急いでいますか?私はまだ自分でこのようなことをしていません。そのため、この考えを疑念をもって終わらせたのですが、実際にやってみるつもりです。投稿しておきます:).

最後に、パフォーマンス評価のほとんど(すべてではないにしても)はねじれており、非常に操作的だと思います。品質と速度を100%に制限することはできません。上司は、組織によって設定された標準に対してあなたを採点する必要があります。品質と速度のトレードオフに関する組織の標準。 OrangeSoft Inc.が33%の品質と66%の速度を期待していると想像してみましょう。したがって、ユニットテストの3分の1程度のコードを記述している場合は、そうする必要がありますが、スピードを上げて納期を短縮することで、レビューで100%近くのスコアが得られます。 (これらはかなり大まかな類似ですが、あなたは要点を理解します)。しかし、代わりに、ボブはコードを非常に高速に記述しますが、バグが多いことで有名です。したがって、彼のパフォーマンスレビューでは、品質は3/5、速度は5/5になります。一方、Carolはコードの作成速度ははるかに遅くなりますが、生成されるバグは大幅に少なくなります。彼女は品質が5/5、スピードが3/5です。どちらの方法でも、ボブとキャロルはレイズにドッキングします。従業員が満点を取ることは可能ですか?これは公正ですか?

6
Thiru

私が使用するテクニックは 進化的プロトタイピング です。

あなたはより多くの情報をググることができます-しかし、何かを素早く生産する必要がある場合、それが唯一の方法です。さらに、ユーザーが好きだと言ったときに、それで済むという利点があります(...そしてドキュメントの作成を開始できます)。

5
slashmais

あなたの時間のボトルネックは何ですか?思考がいつものボトルネックになっていることがわかったので、タイピング速度を改善しても(すでに良い)、ほとんど何もしません。一方、タイピングが速く自然ではない場合は、遅くなる可能性があります。

必要以上のことをしようとしていますか?通常、企業はより洗練された仕事ではなく、多くの優れた仕事を求めており、使用されない機能を追加すると、時間とお金が無駄になり、ビジネスに利益がもたらされません。

急いでるの?時間のプレッシャーの下で、人々はしばしばそれがうまくいくことを望んで、事前の設計と計画を頻繁に怠ります。それは頻繁にありません。

時間をきちんと扱っていますか?開発には、途切れることのない思考時間のチャンクが必要です。そうしないと、効率が悪くなり、遅くなります。

5
David Thornley

Neal Fordの優れた本 The Productive Programmer を読んでください。

役立つヒントが満載です。


編集:

そして、他で言及されているように、あなたのツールのドキュメントを読んでください。私は常にVimのウィキを読んでVimの新しいことを学んでいます。同様に、bashまたはzshのmanページを読むだけで、常に新しいトリックが得られます。

4
Rob Wells

私はずっと前に、私にとらわれた最適化について何かを読みました。ソースや正確な言葉は覚えていませんが、要点は、「プログラムをより高速に実行する唯一の方法は、プログラムのパフォーマンスを低下させることです。他の計画はそれだけです」でした。同じことが人間にも言えます。軍隊はまた、「急いで無駄にする」と言っています。私たちが今行っているのと同じことをしますが、より速く、問題が生じるだけです。より生産的になるためのさまざまな計画があり、それらが効果的でないと言っているわけではありませんが、それらはあなたのニーズに合わせられません。自分の行動を見て、生産的でない自分の行動を見つけて、それらを切り捨てたほうがよいでしょう。他の計画は、その単純なバージョンです。

4
Imagist

これが私のために働くものです:

  1. 作業を(1)スコープで定義された小さなタスク(2)短いタスクに分割します。 2時間。
  2. それらを順番に紙に書き留めて一日を始めます。いくつかの線を引きます-昼食前に完了すると予想されるもの、1日の終わりまでに完了するものなど.
  3. あなたが行くにつれてアイテムを消して、あなたのリストを動かしてください。
  4. タイムボックスのこと-何かがドラッグし始めている場合は、助けを求める前に調査するための時間制限を設けるか、より簡単な方法で解決します。
  5. 可能であれば、これらの時間枠に公にコミットするように作業を構成します-バグ追跡などで見積もりを入力します。
  6. 研究、読書などの時間をつぶしていることに気づいたら、順序を逆にします。たとえば、スケジュールどおりに1時間のタスクを正常に完了した場合、10分の報酬を自分に与えます。

Stack Overflowに費やす時間を減らすべきだというコメントをいくつか見ました。正しく使用していれば、Stack Overflowによって効率が向上するはずです。ディスカッションを避け、仕事を終わらせるためにそれを使用することに集中します。

3
Jon Galloway

自分を繰り返さないでください

古いプロジェクト資産を再利用します。

IDEを学ぶために1日かかります。スニペットなどのツールが提供されていない場合は、コードのオートコンプリート...新しいツールを入手することを検討してください。

重要な場所にすべてへのショートカットを配置して、物事にすばやくアクセスできるようにします。

まだそうでない場合は、2番目の画面を取得します。

あまり頻繁にメールをチェックしないでください。

一度に1つのタスクのみに集中してください。これが不可能な場合は、何をしているかをよく追跡し、15の無関係なタスクの間に迷子にならないようにしてください。

紙を使用します。私が仕事をしているときは、常にメモを取ったり、取り消したりできる、印刷されたバージョンのタスクを持っています。別の画面で何かを読んだり書いたりするよりもはるかに高速です。 1日の終わりに、すべてをシステムにコピーするのに10分かかります。毎日時間が節約できることに気づきました。

3
marcgg
  1. プログラマーとして、ますます自分を成長させてください...デザインパターンを学んでください!
  2. TDDを使用しますが、適切な方法では、コードに含まれる可能性のあるバグは、最も時間がかかるものです。
  3. ReSharperを使用 :)
3
Denis Biondic

他の多くの回答は設計作業について述べているので、私はコーディングの純粋な機械的側面のみを高速に固執します。これのほとんどはおそらく明白ですが、私の同僚の多くがこれらのことの一部を行っていないことに気付いたので、とにかくそれを言います。

IDEキーボードショートカットを再マッピングして、それらのほとんどを左手で実行できるようにします。これにより、マウスの手が解放され、猛烈なコードのアウトライン化/リファクタリングが可能になります。

次の組み合わせを使用して、カーソルを移動し、テキストを選択する方法を学びます Ctrl、 Shift、 矢印キー、 Home そして End

以下は私のC++セットアップです(Visual Assist Xを備えたVisual Studio)。私はノルウェー語のキーボードを持っているので、我慢してください。

Alt-Z:.hと.cppの間の変更

Ctrl-Shift- <:参照を介した状況依存ジャンプ。 (私にとって<はZの左のキーです、あなたはイギリス人はそれらの1つを持っていません。それからそれをCtrl-Shift-Zにマップしてください。)

Alt- | :メソッドを実装します。最初にヘッダーを記述し、Alt- |を押すだけ常に数秒でクラス全体のアウトラインを作成できます。(|私にとってはエスケープの下のキーです。)これは特に、テキストエディターでcppファイルとヘッダーファイルを隣り合わせに配置して、ヘッダーがアクションを実行するたびに不明瞭になることはありません。

Alt-R:キャレットの下にあるシンボルの名前を変更します。

Alt-D:選択した関数のドキュメントテンプレートを追加します。

これにより、コードの完成が非常に速くなるだけでなく、左手でのリファクタリングも可能になります。

3
Nailer

コードスニペット、経験、そして決して熱意を止めません。常にものを読んでください:プログラマーのブログ、本、文学、他の人々の悪いコード。ものについてより広い視野を得れば、あなたはより速くなるでしょう。関連するあらゆる種類の複雑なバックグラウンドプロセスを想像でき、対象システムの全体的な複雑さを本当に理解している場合。

Pragmatic Programmer's Handbook は一種の素晴らしいものです。それは、ソフトウェア開発のさまざまな側面のベストプラクティスと主要な落とし穴についてです。ゴム製のダッキングなどは、明らかにオタクでバカに聞こえます。ただし、ほとんどのプログラミング問題の本質は、あまりにも複雑に考える傾向があるということです。私はシンプルで簡単なソリューションの大ファンです。素晴らしいトリックも、超エレガントなハックもありません。最も単純なソリューションを使用するだけです。

チームが優れている場合は、共同作業を試すことができます。 Bespin と他のいくつかのフレームワークでは、現在1つのファイルを一緒に編集できます。あなたが本当にそれに興味があり、同僚が魔法をやっているのを見るならば、それは素晴らしいです;)。

3
wishi

より長い間隔でメールをチェックして、TwitterやFacebookなどのオンラインソーシャルツールの使用を停止してください。

これを使う wallpaper

開いた正面図で作業してみてください。私は通常、無料の会議室を使用しています。

あなたの周りの他のプログラマーと協力してみてください。

3
Adnan Memon

秘訣はコードをより速く書くことではなく、動作するコードをより速く書くことです。

バグの発見が早け​​れば早いほど、それを修正するための労力は少なくなります-これは、プログラマーのパフォーマンスに影響を与える主なものです。

入力する速さやコンパイラの速さではなく、バグを特定して修正しながら修正する速度です。

したがって、より速くする方法としてペアプログラミングをお勧めします。バグを回避するためです。それとテスト駆動開発。 2組の目があると、バグがすり抜けるのが2倍以上難しくなります(とにかく)。

他のヒントは

  • コードテストのターンアラウンドタイムを最小限に抑えるようにしてください。これは明らかにプラットフォームやツールに依存します。 lameツールを使用したばかばかしい組み込みシステムで作業している場合、ターンアラウンドタイムは非常に重要です(たとえば、システムイメージを再構築してデバイスを再ネットブートする必要がある場合)、VMまたはシミュレーターが役立ちます。
  • ペアプログラミングでない場合は、非公式のコードレビューをときどき依頼してください。疑いなく行う正式なコードレビュープロセスに加えて、これを実行します。
  • シンプルにしてください-やりすぎないでください。あなたはそれを必要としないでしょう。
3
MarkR

独自の生産性ツールを作成します。彼らは最初に書くのに時間がかかるかもしれませんが、見返りは時間とともに大きくなる可能性があります。

私がいつも使っている私が書いたいくつかのツール:

  • SQLフォーマッター。
  • 自動SQLジェネレーター:テーブルを選択するだけです。
  • 単純なタスク優先順位付けツールなので、すべてのタスクを一度に見ることができます。
  • 定期的に私を悩ませているタスクのリマインダー。
  • 区切られたテキストを取り、それをスプレッドシートのようにテキストのように扱うことができるアプリ。
  • PHP/Javascript/HTMLページフォーマッタ。他の人のコードを扱うときの天の恵み。

私は、他の小さなツールをたくさん書いてきましたが、道に迷いましたが、それでも努力する価値はありました。

3
Jonathan Swift
  1. リラックスしながら集中することができるので、プログラムをしながら音楽を聴くのは本当に楽しいです。

  2. 快適な椅子。オフィスの椅子は信じられないほど不快なので、学校のコンピューターラボを使ってプログラミングをすることはありません。

  3. しつこい空腹のように私のモチベーションを損なうものは何もないので、事前に何かを食べます。

3
Matt Phillips

練習。それと、より速く作業できる生産性ツールを手に入れましょう。

たとえば、(使用しているプラ​​ットフォームについては言及していません)、. NET環境にはResharperがあります。

2
Randolph West

見積もりとタイムスケールを再交渉します。 あなたが何かにかかる時間を言っている人であることを確認し、「まあ、我々はそれをもっと早くやる必要がある」または「ストレッチターゲットはどうだ」という提案に負けないでください。

Joel Spolskyの見積もりに関する記事を読んでください。これは基本的に、作業を小さなチャンクに分割することを提唱しており、それぞれを見積もります。それらのいずれかが日数でカウントされる場合は、すべてが時間で見積もられるまで、それらをさらに分解します。

2
harriyott

あなたとあなたの上司/評価者は、実際にプログラムする必要がある時間を決定する必要があります。会議、電子メール、ドキュメント、テスト、その他の中断を作業予定の時間から外し、残っているものを確認します。

時間を監視して、特定のタスクにかかる時間のベンチマークを取得してください。生産的な時間(私にとっては、その日の早い時間帯、または中断なく仕事に就く時間)と非生産的な時間があります。平均を見つけます。

特定のタスクのプログラミングに8時間かかると判断する場合がありますが、1日で完了するとは思えません。

また、自分を他の人と比較してみます。企業風土は何時間もかけることかもしれません。

2
JeffO

まあ、私は遅くないと思いますが、私が与えられた仕事は、利用可能な時間を埋める傾向があります。

とにかく、「ああ、あなたはそんなに早くやった」とよく耳にしますが、それは高速なコーダーであるからではなく、コーディングの手間が少ないからです。

コーディングを減らす主な方法は、DSLのように考えることです。プリプロセッサーでコードを生成できない場合は、コードジェネレーターを作成してください。派手である必要はありません。目的は、単一のスタンドアロン要件が与えられた場合、その要件の実装に必要なsourceコードの違いの数を最小限に抑えることです。理想的には、その数は1です。平均で3〜6程度下げることができれば、それはかなり良いことです。 (それはあなたが書くことが少ないというだけではありません。この数が小さいほど、あなたが入れているバグの数は少なくなります、そしてそれは本当に 時間を節約する。)

これを行うには、 パフォーマンスチューニング を実行することをお勧めします。これにより、コーディングプラクティスがどのようにして最大のスローダウンを引き起こし、コードが肥大化するかを知ることができます。特に、過剰なデータ構造とイベント/通知スタイルのプログラミング。これらのことだけでも、コード量に大きく貢献します。

最近の多くのコード量は、特に動的に柔軟である場合、ユーザーインターフェイスによるものです。 Dynamic Dialogs と呼ばれるその部分を実行する方法を偶然見つけました。これは、学習曲線は難しいですが、UIコードをおよそ1桁縮小します。

あなたはこれであなた自身の方法を見つけなければならないでしょう、恐らく幸運です。

2
Mike Dunlavey

あなたの個人的な生活を整頓してください。特に鉄分が不足している場合は、多くの睡眠をとり、健康的に食事をとり、ビタミンを摂取してください。 「飲み物」に近づかないでください。そして、「ワインと女性の両方が賢い人を迷わせることができる」と覚えておいてください。

また、コードのテンプレートと、正規表現パターンを使用して機能する「コードジェネレーター」を作成します。コピーして貼り付け、類似のクラスを検索して置き換える場合は、このプロセスを自動化します。 PHP=プロジェクトでこれを行いました。このプロジェクトでは、CRUDアプリケーションを作成でき、データテーブルに基づいてすべての基本的なMVCコンポーネントを完備しています。データモデルは、それらが表すデータテーブルなので、これらはテンプレートで設定され、私の初期コードの生成に使用されます。入力にかかる時間を節約できます。

最後に、プロジェクトに関係するすべての人に、コードがあなたが思っているよりも1/4から1/2倍長くかかることを伝えます。早い段階で、自分のためにより多くの呼吸室を交渉します。 「後期」は相対的な用語です。プロジェクトの途中で変更が発生した場合は、さらに8時間の作業が追加されたことを事前に全員に知らせます。 「FogBugz」で提供されているような追跡システムは、以前の経験に基づいて、何かを成し遂げるのにどれくらい時間がかかるかを予測するために、あなた自身とマネージャにとって役立つかもしれません。 「遅くはありませんでした-この機能を完了するのにかかる適切な時間を使用しました-予想よりも時間がかかっただけです。」

別のプログラマーは、「もっと早くできたかもしれません...」と言うかもしれません。たぶん、そうではないかもしれませんが、それについて議論したり、打ちのめしたりする価値はありません。あなたがそれについて考えるなら、彼はあなたを遅くします!しかし、上司の場合は常に悪い状況です。その時点で、私は別の仕事を探すことを検討します。私の本では、そのようなボスは傲慢なジャークです。

2
JasonMichael

Q:短期間でより多くを成し遂げるために何をしますか?

A:毎日、オフィスに来て、(付箋)Outlookのメモに、書きたいことすべてを書きます。アイテムのその順序で作業を開始します。結局私を信じて、あなたはあなたがあなたが計画したことをやったと感じて、それは素晴らしい気持ちです。

2
Cshah

ペアプログラム-これにはさまざまなメリットがあります。

  • あなたの考えを明確にし/明確にすることを強制します
  • 他の誰かがどのように機能するか、あなたが採用/試行できる多くのアイデアについての洞察を与えます
  • 新しいテクノロジーを知っている誰かから直接学ぶ
  • 他の人から生産性のヒントを少しピックアップします。あなたはいつも誰かがあなたが以前に理解しなかったメニューコマンド、またはいくつかの便利なUnixコマンドを使用するのを見ます。
2
ndp

少ないコードを記述します。

Not-Invented-Hereを追放し、既存のライブラリー/フレームワーク/ツールキットをうまく活用して、共通の(一般的には非定義的な)機能を提供し、新しいものを書くだけでよいようにします。自分で書く必要のある部分については、再利用を念頭に置いてビルドし、次のプロジェクトでそれらを再度書く必要がないようにします。

1日に生成する作業コードの行数を増やしなくても、各行でより多くのことを行うことにより、より短い時間でより多くのことを達成できます。

2
Dave Sherohman

私が見つけた唯一明らかなことは、気を散らさないことです。これは、一部の環境では不可能です。しかし、特定のタスクに焦点を当て、そのタスクのみに集中できることは、おそらく他の何よりも重要です。これらのコンテキストスイッチは、本当に大きな時間のシンクです。

2
Joe

ジャグリング休憩中

Juggling

2
Cornelius

飲むYerba Mateコーヒーの代わりに

Yerba Mate

2
Cornelius

それは常に同じ唯一の決断、迅速な開発と品質、読みやすさ、拡張性です。コントロールと無限のコードビハインドファイル(迅速かつダーティ)のドラッグアンドドロップ、またはモジュール性、パターン、および慣行(長期投資)?

私の正直な意見では、誰もがコーディングの長期的な方法に投資する必要があります。時間が経つにつれて、迅速な開発も素晴らしい品質になるでしょう。

ただし、お問い合わせ内容が理解できず、ツール、コードジェネレーターなど、迅速な開発の実用的な側面で回答を求めている場合、Resharperを使い始めて、あなたのできる限りのことを学んでください。 IDE :)

1

フレームワークを使用してください!!ハードコーディングを気にしないでください!

1
Koosha

まず、エンドユーザーとの数回の会議に基づいてシステムを設計するべきではありません。実際、プロジェクトの要件フェーズに関与すべきではありません。それは、ビジネスアナリストとエンドユーザーが作業するためのものです。

2番目のフェーズは技術的な要件である必要があります。ここで、ビジネスアナリストと協力して、要求された仕様に対するソリューションを考え出します。

今が重要な部分です。エンドユーザーの要件と機能要件の両方を理解していることを確認してください。ユーザーの期待に応えられなかったことを見つけるためだけに何かを始めても意味がありません。何かが分からない場合は声を上げてください。

さて、エディタをヒットする時間です。しかし、私のアプローチは、実際のコードを決して記述せず、常に最初に絶対的なコメントスタックを記述し、それが簡単である場合は、明確で読み取り/理解しやすい限り、疑似コードで記述します。

コメントを作成したら、a)テストケースの作成b)実装の作成のいずれかを開始できます。

環境によっては、(a)から始めるのが最善ですが、悲しいことに(b)から始めて、テストが実装を満たすように強制します。率直に言って、あなたが大企業の一部だった場合、何かを始める前にテストケースを作成する部門があります。

1
Brett Ryan

誰もが「メールをチェックする」と言っていますが、非常に技術的なメールの作成に費やす時間を考慮してください。 1つのメールを1時間で簡単に作成できます。それを修正するために、1)あまり書かないか、2)絶対に必要になるまで、技術的なもの(および解答するためにコードを読む必要があるもの)を延期することができます。

1
Shin

実際にコードを書くとき、 CodeRush は、特にそのショートカットを習得している場合に非常に役立ちます。さらに無料です:D

1
GaiusSensei

私は毎週少し時間を費やして、自分が現在取り組んでいることに直接関連するかどうかに関係なく、新しい創造的な方法を探すだけです。多くの場合、気づかなかった新しいトリックやツールが見つかり、ワークフローがスピードアップします。

1
fscmj

IDEをよく理解してください。

あなたのIDEがVisual Studioである場合、私は強くお勧めします Sara Fordの本

1
Jim G.
  • デザインパターンを学ぶ。それらは問題を理解し、より優れたプログラマーにするのに役立ちます->いくつかの問題の解決策がすでに用意されているので、はるかに速くプログラミングできます
  • プログラム内の反復部分を抽出します。作成するいくつかのプログラム全体で繰り返されるロジックがある場合は、それらを一般化し、作成した新しいアプリケーションで再利用できるクラスライブラリに抽出することを検討してください。 標準化事柄:時間をかけて、特定の反復作業がどのように最適に行われているかを調べます。達成するための手順を文書化します。次回は、それらを解決/適用する方法を正確に理解します。
  • KISS原理
  • コード生成は有用です(有用なツールが利用可能になったら)。最近、発電機が人気を集め始めています。

注:物事をうまく機能させることはさらに悪いことです!!中には、物事がうまく機能するまでハッキングすることだけを述べているので、今のところはより速くなります。ただし、バグは発生しますが、プログラムの速さの点でも重要です。機能の一部を作成する必要があり、それを適切に作成することに投資し、優れたデザインを持っている場合、おそらくユニットテストで十分にテストされ、半日は必要だと言います。しかし、それがそれであり、機能が動作し、再度触れる必要がないと仮定します。別のプログラマーは、彼の目標の迅速な達成に焦点を合わせただけで、境界を考慮しない(気づかない)例外的なケースであるテストが欠落しているため、(おそらく)悪い設計になります。彼は2時間必要だろう(としましょう)。バグが入り、彼は再びコードに触れ、修正し、場合によっては拡張する必要があります(時間は再び投資されます)。コードを維持するのは難しいでしょう...再開:結局、彼は多くの鉱石時間を費やすことになり、フラストレーションが高くなります。

1
Juri

人間工学的に最適化されたキーボードレイアウト を使用します。いくつかは、非常にアクセスしやすい特殊文字を介して、プログラマーさえ狙っています。

1
knittl

在宅勤務。締め切りが厳しく、問題に完全に集中する必要がある場合は、上司に自宅で働いていることを伝えます。これにより、環境を最適に設定し、中断を減らし、問題にレーザービームのように集中させることができます。

1
Pedro Estrada

経験を積むと速くなり、APIをより多く覚えることができます。

コードの断片をWebで検索する日々は、今までよりもずっと短くなっています。

また、関数型プログラミングの概念とラムダを使用してコードを削減することもできます:)

1
Vince

あなたがやっていることに興奮していることは、効率を上げるための素晴らしい方法です。それが楽しいことを確認してください!

1
Jakob

あなたのアイデアを紙にスケッチすること、それを思い出してください、いくつかのアイデアを具体化するための素晴らしい方法だと思います。プログラマーとして、プロであれ趣味家であれ、私たちは画面を見つめるのに非常に多くの時間を費やしているので、あなたのアイデアを置くための別の出口を持つのは良いことです。物事を掻き消したり、アイデアを結ぶ急いで線を引いたり、物事を丸めたり、下線を引いたりすることはすべて、アイデアを強調することにつながり、アイデアをすぐに整理するよりもはるかに速くアイデアを整理するのに役立ちます。一部のコンピュータ支援フォーム。

役立つもう1つのことは、小さな部品のプロトタイピングです。昨夜、スピーカーがスパゲッティスティックとマシュマロから小さな構造を構築することについて話し合ったTEDオーディオポッドキャストを聞いたところ、これは明らかに、小グループの社会的建設能力をテストするためにかなり広く使用されている研究です...とにかく、常にそうしたグループさらに、補強と建物の建設を理解した建築家は子供でした。なぜなら、彼らは一定のフィードバックの流れを使用して結果を得たからです。これをプログラミングのアイデアに投入して、小さなことを行って結果を得ることは、生産性を高めるだけでなく、巨大な構造を構築して何日もかけてデバッグするよりもはるかに楽しくて便利だと思うかもしれません。確かに過去の私の「楽しい」アイデアのいくつか。

1
dscher

オフィスにいるときに集中力を維持する必要がある場合は、電子メールクライアントを閉じます。到着したメッセージを「すばやく確認」するという一定の誘惑よりも速く効率を損なうものはありません。私はまた、混乱を管理し、焦点を維持するために Pomodoro Technique をいじっています。

1
Tim Trout

可能な限りコードジェネレーターを使用してください。 Microsoft Excel(またはOpenOffice Calc)でさえ、強力なコード生成ツールであることが判明する場合があります。

0
Canavar

簡単に言えば、ホワイトボード->テスト可能な要件をタスクに分解します(私は Team Foundation を使用して、各タスクとその所要時間を追跡しました)。

テストを使用して、必要なことを行っていることを確認してください。 (まだパフォーマンスについては心配しないでください。)

要件から要件に移動し、それぞれが完了した後にテストします。各タスクが完了すると、残り時間の正確な見積もりが得られます。

すべての要件が完了したら、戻って「磨き」ます。

最初に脚の作業を行うと、すべての要件が解決され、最初から正しく作業を行うことで時間を節約できます。

正しく行われていれば、スタックオーバーフローに費やす時間を増やすことができます:)

幸運を

0
Brad8118

ここには素晴らしいアイデアがたくさんあります。 「ゾーン」に入るために、27分間隔で設定されたタイマーを使用します。作業モードに入ると、ブザーを超えて簡単に作業でき、フローでの作業は簡単です。でもそこに行くのは難しいです。

0
Daver

スピードに最も影響を与えていることに気付いたのは、モチベーションと楽しいことです。これは曖昧に見えるかもしれませんが、やる気があり、楽しいと思うことをしているときは、非常に効果的です。一方、どちらでもない場合は、コードのすべての1行をプッシュする必要があるように感じます。

あなたのスイートスポットを見つけてください。何が本当にあなたに動機を与え、どんな種類のタスクを本当に楽しんでいますか?そして、これを実行できるように、計画に影響を与えることができますか?私にとっては、問題やデザインの問題を解決するときであり、プロジェクトに参加していると感じたときです。

数か月前、私たちには小さなチームに割り当てられた小さなプロジェクトがあり、それはそれにとって本当に重要で非常に非現実的な締め切りでした。しかし、私たちは皆、非常にやる気があり、それを実行するのが非常に楽しく、幸せな顧客と間に合うようにそれを達成しました。私のモチベーションの理由は、私たちがプロジェクトに非常に関与していて、そのために独創的なアイデアを考え出さなければならなかったからです。自分の好きな部分もやらなくてはいけません。

しかし、最近私は基本的にコードモンキーであるプロジェクトに携わっており、頭を麻痺させてイライラさせるタスクを実行している、または可能な限り最速の方法で迅速に修正できるものを持っているだけで、いつか戻ってきて私を苦しめることになるでしょう。近い将来、それはひどく遅くなっています。

それで、あなたのスイートスポットは何ですか?

0
Runeborg
  1. やりたいことを知り、興味を持っている
  2. 数時間かけてコードの調査方法を説明します
  3. コードをコピーして貼り付けて、最終結果を得る
  4. 基本的なGUIで作業を完了し、時間を費やして見栄えを良くする
  5. テストとデバッグ
  6. かなりのGUIに取り組む
0
Matt S.

「適時性」は「速い」と同じではありません。それが問題だった場合、あなたの評価は「遅い」と言ったはずです。だから、あなたが提案する道を進む前に、あなたがあなたに何が期待されているかを知っていることを確認してください。

それは何を意味するかもしれません。同僚の20分後までオフィスに入らない、または時間管理が不十分であることを意味する場合さえあります。それはあなたの「プログラミング速度」とは何の関係もないかもしれません。

私はおそらくほとんどの時間を設計と計画に費やしています。優れた分析と設計からタスクを計画する方が簡単であり、信じられるであろうより良い見積もりを与えるでしょう。さらに、優れた設計により、コーディングははるかに単純でより指示されたプロセスになります。また、タスクを分割して、他の開発者に配布することもできます。

0
Clifford

[〜#〜] vim [〜#〜] を使用して、Cコーディング速度を実質的に3倍にしました。

0
Liran Orevi

CodeRush!それを得る!大好きです!

0
Bobby Ortiz

高速エディタ、高速コンパイラを選択し、実行時間が短いソフトウェアを記述します。このようにして、通常のプログラマーの10倍のミスを犯しても、他のプログラマーよりもよくなることがあります。これがおそらく、Googleアプリケーションが非常に人気がある理由の1つです。 Web開発には厄介なバグがたくさんあり、バグの多いプラットフォームでより多くのソフトウェアを作成するのはお尻の痛みです。しかし、コードを編集してから結果を確認するまでの応答時間は非常に速いため、c ++プログラムを拡張するよりも、大量のゴミを処理する方が簡単です。 :)

0
AareP

IDEの前よりも、心の中で物事をまとめるのに多くの時間を費やしてください。計画が立てば、ほとんどの作業はすでに完了しています。実装は残りの20%です。プラットフォーム固有の問題が原因でコードの記述が行き詰まった場合は、計画を守り、残りの実装とテストを続けてください。最後に、あなたが残したすべてのスポットに取り組み、それらを1つずつ解決します-いくつかは関連している可能性があり、いくつかを解決することで残りを理解するのに十分かもしれません。私は通常、そのような問題の回避策を使用して、コードの特定の場所に「// TO CHANGE」コメントを追加し、すべてを解決する時間がなければ、最終的に品質とパフォーマンスに最も影響するコメントを書き直します。締め切りまでに。

0
luvieere

独自のコードライブラリを構築する

新しい機能をコーディングするときは常に、可能な限り一般的なものにしてください。短期的にはこれは少し遅くなりますが、長期的には、コードライブラリが大きくなると、多くのビジネスアプリケーションに同様のニーズがあるため(常にではない)、新しいプロジェクトはそれぞれ速く完了しますが、十分に近いコードは再利用できます。

0
Darknight

速いということは、良いという意味ではありません。あなたがより速くより良いプログラマーであることに成功した場合。それはすべてバランスをとるために下ります。あなたはそれをどのくらいの期間行うことができますか?思考、忍耐、計画は常に報われます。時々、開発の世界で「速い」は最悪の結果をもたらす可能性があります。

0
Ryuken

解体。構築しているものはすべて、段階的に実装できる小さな機能に分割します。次に、これらの小さな部分を実行し、それが何も壊さないことを確認するためにテストしたときはいつでも、それを展開し、それをPowers That Beに示します。

小さなイテレーションを使用すると、大規模なプロジェクトをより速く、よりよく完了するのに役立つことがよくあります。これは、進行中にフィードバックが得られ、バックトラックしたりやり直したりする必要がないためです。しかし、そうでない場合でも、あなたは絶え間ない進歩を示しています。これは確かな心理的利益をもたらし、マネージャーまたはクライアントの信頼を取り戻します。

テスト主導の開発も、このアプローチで非常に役立ちます。最初はテストを書くと最初に物事が遅くなるように見えるかもしれませんが、回避するバグでその時間を取り戻すことができ、それらをどのように書くかによっては、テスト自体がPowers That Beに示すことができる成果物になる可能性がありますすべてを書く前に、アプリの動作を確認します。

0
SFEley

Cでプログラミングしている場合、ビットハックを学ぶことは、より高速なプログラマになるための必須条件です。また、Topcoder.comでトップランカーによるコーディング方法を読んでください。彼らのコードは非常に小さく効率的です。

0
avd

設計とコーディングの速度を落とすことで、より速くprogrammerになります。

  • あなたが何をしているかについて考えてください。
  • 設計の影響を考慮してください。
  • 初めてそれを正しく取得します(独自のコードを精力的にテストします)。

それはfeel遅くなるかもしれませんが、スループットは4時間で反復を繰り返し、その前に6ラウンドのQAが必要なコードジョッキーよりも速くなりますコードパス。

0
mmc

再:それを推定し、それに固執する方法:

見積もるときは、 ホフスタッターの法則 と、次のような簡単なことを覚えておいてください。「すべてが実際よりも時間がかかる」。何かがかかる時間について合理的な推測をして、口に出る前にそれを2倍または3倍にします。合併症、後退、注意散漫、忘れるものなどがあります。逆の場合よりも、約束を守り、過剰に提供する方が良いでしょう。

見積もりにこだわる場合は、作業を効率的に完了するために最善を尽くしてください。問題が発生した場合は、遅れを早く伝えます。これは誰もが彼らの期待を調整する時間を与えます。説明が妥当である場合は、より多くの時間または支援を与えられるか、気が散る(騒々しい隣人のように)パスから削除されます。

0
steamer25

次の慣例はよく知られていますが、多くの場合、厳しい期限が原因で、さまざまな理由で無視されることが多いため、ここで言及する価値があります(実際、これらは、支出を避けるために事前に時間を費やすためのメカニズムですもっと時間後):

  • 実行テスト駆動開発;実際に必要な量のコードのみを記述するのに役立ち、機能の追加やリファクタリング時にバグの発生を回避するのに役立ちます

  • commentsと記述しますが、コードがそれを保証するのに十分複雑な場合のみ

  • リファクタリングおよびsimplifyコードを頻繁に

  • 使用まともなソース管理ソフトウェア(GitやMercurialなど)-雇用主が他のものを使用している場合は、ローカルで使用します-

  • Commitコードは頻繁に変更されます。すべての機能またはリファクタリングでコミットを実行してください。

  • branchを恐れないでください。特にGitには非常に高速で「安全な」分岐メカニズムがあります(たとえば、Subversionと比較して)

0
Nick Toumpelis

私は個人的には、すべてコードの再利用性について考えています。毎回完全にカスタムなことをしない限り、利用できる一般的な使用法のライブラリが必要です。以前のプロジェクトで使用した関数の「ジャンクヤード」全体が含まれるutils.phpがあります。私が同様のことをしなければならないときに、TONの時間を節約します。

幸運と落胆しないでください。私たちは皆、時々ゆっくりと、または「おかしい」と感じたと思います。私は知っている!

0
Code Monkey

静的分析ツールを使用します。

コンパイル時に、実行時に追跡しなければならなかったより多くのバグを見つけるのに役立ちます。

特にマルチスレッドのアプリケーションを構築する場合、それらは実際の助けになります。

0
Oliver Weiler

これらはすべて良い提案です。私は、最小限のコードだけでなく最小限の冗長コードで物事を成し遂げる方法を知ることである、私自身の生産性技術を追加します。

一般的に、これはデータ構造が少ないほど良いことを意味します。

最小限の冗長性でコードを作成するには、創造性と学習曲線を課す可能性のある方法で物事を行う意欲が必要です。それが生産性の代償です。 ここに1つの例を示します。

0
Mike Dunlavey