最も過小評価されているプログラミングツール[終了]

優れたプログラマーのテキストエディター、IDE、デバッガー、バージョン管理システムなど、プログラミングに役立つ多くの優れたツールがあります。一部のツールは、仕事を成し遂げるための多かれ少なかれ必要なツール（コンパイラーなど）です。 。

多くの場合に役立つツールは常に存在しますが、さまざまな理由であまり注目されていません。たとえば、リリースされたとき、時代を先取りしており、今では多かれ少なかれ忘れられています。

プログラミングツールのどのようなタイプであるあなただと思います最も過小評価さ1？答えに動機を与えます。

ゴム製のアヒル。はい、そうです。

http://en.wikipedia.org/wiki/Rubber_duck_debugging

ラバーダックデバッグ、ラバーダッキング、およびラバーダッキーテストは、ソフトウェアエンジニアリングでコードのデバッグ方法を示すために使用される非公式の用語です。名前は、名前のないエキスパートプログラマーが常に机にゴム製のカモを置いておき、コードを1行ごとにカモに説明するように強制することでコードをデバッグするという、おそらく隠された話への参照です。

このプロセスを使用するために、プログラマーはラバーダックなどの無生物にコードを説明します。誤ったコードに到達して説明しようとすると、プログラマーはエラーに気付くことを期待しています。コードが行うべきことを説明し、実際に何をするかを観察すると、これら2つの間の不一致が明らかになります...

ペンとノート。

1. 電気なしで動作します。
2. ポータブル。
3. 会議で退屈したときのオン/インでの落書き
4. 有用な情報を保存します。
5. それが書き留められている場合、人々はそれをより重視します。
6. 他の人はそれを読んで学ぶことができます。

ログ出力またはフラットテキストファイルのデータを比較する場合、差分ツールはあまり使用されていないようです。それとも単にニッチですか？プログラム実行の膨大なログを比較し、変更された1つまたは2つの詳細を特定することは、デバッグに非常に有用で役立つと思われます。

パフォーマンスのプロファイリングツールも、特に重要なボットネックにぶつかった場合に非常に優れていますが、それらに精通している人はほとんどいないようです（そして、このカテゴリである程度認めています）。

優れたXMLツールは非常に重要です-XMLファイルを数十行以上または複数のスキーマで作業している場合。他のエディターが提供する基本的な構文の強調表示以上のものが必要な場合があります。また、XMLを使用する場合、XSLの学習は非常に役立ちます。多くの場合、アプリケーションのコードの多くの行で行われる単純なXSL変換で何ができるかを確認します。明確にするために：XML自体が「過小評価されたプログラミングツール」であることを示唆していません。私が見たものから、優れたXMLエディターの価値は過小評価されていることを示唆しています。

正規表現

彼らはとても便利です。ログファイルを検索したり、テキストを解析したりするときに役立ちます。非常に便利です。

それらに関連する学習曲線が少しあるので、私はそれらを決して使用しないことを知っている何人の人々を奇妙に思います。多くの場合、単純な正規表現がすぐにそれを取り消すことができたときに、人々が難しい方法で物事を行うのを見ます（注：正規表現の前に私は物事を困難にしました）。

あなたのチームメイト。ホットショットのアイデアに取り組み、チームを組み込むことを忘れた場合、チームがうまくいかない理由やさらに良くなる理由についての懸念やアイデアを聞くことはありません。

私はこれを言います。なぜなら、プログラミングは、人々が素晴らしいアイデアで隅々でやる反社会的なことだと考えるのは簡単だからです。これがチームやチームメイトの価値を過小評価していると考える人々は、アイデア/プロジェクトを沈める/泳ぐのを助けます。

Google。まだ解決および文書化されていない問題はほとんどありません。適切に調整されたGoogleクエリは、すべての人の時間を大幅に節約できます。

「ボトルネック」を見つけるための最も過小評価されているツールは、デバッガーのCtrl+ Cまたは「一時停止」ボタンです。

この投稿の最後の段落、およびこの投稿、およびこの投稿を確認してください。

「プログラムが遅すぎる！どうすればいい？プロファイラを試してみたが（もしそうなら）プロファイラを試してみたが、それが何を言っているのか理解できない。 」まあ、推測はそれだけです。私がいつもやっていること、そして他の人たちも持っていることは、それを実行し、中断し、呼び出しスタックを調べることです。問題が本当にひどい場合、ビンゴ、それはあなたの目の前にあります。問題が軽度の場合、それを数回行います。回避できる複数のサンプルに現れるものは、修正できるボトルネックです。

ええ、これは下票ベイトですが、動作します。

どのタイプのプログラミングツールが最も過小評価されていると思いますか？答えに動機を与えます。

コンパイラ。

ほとんどの人は、選択したコンパイラが何をするかを理解するのに時間をかけません。彼らはそれがコードを実行可能なプログラムに変えると感じているだけで、それは彼らが行っている限りです。最近のほとんどのものには、必要な処理を実行できるように、いくつかの構成があります。以下に例を示します。あなたのオフィスの開発者の半分は、警告をエラーレベルとして設定する方法がわからないのではないかと思います（実際に警告レベルがあると仮定して）。デバッグシンボルを出力するにはどのようなオプションが必要ですか？どの最適化（またはどのレベル）を行うか。リストは続きます。

あなたの脳。他のツールは、それなしではあまり意味がありません。

古き良き：

print

デバッガーやプロファイラー、またはUMLフロー図が役立つ場合があります。そして時々彼らはあなたを狂わせます。私はいつも、自分のコードがそれをやっていると思うときに私が思っていることをしていることを確認するために、printステートメント（またはtraceまたはNSLogまたはwhat-have-you）を使用することに後戻りしています。

単純な古いスクリプト ...次世代の言語をいくつ開発しても、スクリプトに大きく依存しています。また、ほとんどの日々のタスクは、数行のスクリプトを書くことで達成できます。

ペンとホワイトボード。

何かを説明しようとすると、ローテクに勝るものはありません。

ack。のようなものgrep -rですが、ソースコードを検索するために設計されています。

Perlおよびその他のスクリプト言語。Agent RansackのようなGUIツールには少し複雑すぎるタスクに最適です。

迅速で頻繁かつ安全なリファクタリングを可能にするキーボードショートカット。いくつかのキーを押すだけで変数、メソッド、定数、またはクラスを抽出（またはインラインなど）する方法を学ぶと、コーディング方法が根本的に変わりました。コストが最小限の場合にのみ、リファクタリングを頻繁に（つまり十分に）行うため、これらのショートカットを2番目の性質にすることは、私が思う限り、良いコードを記述して維持するために不可欠です。

したがって、一般的には、優れたツール（IDE /エディター）を使用し、それらが提供する機能を最大限に活用する方法を学びます。

コードをテスト可能な状態に保ち、リファクタリングの恐れを防ぐために、ユニットテストとTDDが次に来ます。

これらを使用すれば、DRYの原則に準拠し、自己文書化された適切な保守可能なコードを簡単に書くことができます。

単体テストには次の利点があります。

• 開発者はコードの最初のクライアントになります。バグを迅速に発見すればするほど、修正費用は安くなります。ビルド、インストール、またはデプロイの前にバグを発見できます。
• テストにより、コードに対する見方が変わります。設計は明確ですか？コーナーケースを処理しますか？
• ホーソーン効果は、チームが品質/テストのメトリクスを公開していることを単に発表することにより、品質を改善します。
• テストがソース管理にチェックインされていない場合でも、新しい地形を探索して学習するための優れた方法になる可能性があります。
• バグが少なくなる可能性が高い！

コードジェネレーター

コードジェネレーターは、簡単な定義から大量の効率的でバグのないコードを作成できます。ORMタイプの使用は、データアクセスクラスを作成するために最も明白ですが、さらに多くの潜在的な使用があります。

コード生成のサポートは、プログラマーとフレームワークの両方の観点からまだ初期段階にあるように見えますが、今後ますます見られるものになると思います。では.NETあなたが手を染め始めることができたCodeDOMのもの。

AgentRansackを頻繁に使用します。これは、数千のファイルを非常に迅速に検索するのに非常に役立ちます。時間を大幅に節約できましたが、それを知っているか、使用している多くのプログラマーは知りません。

正式な方法。

http://www.amazon.com/Discipline-Programming-Edsger-W-Dijkstra/dp/013215871X

http://www.amazon.com/Science-Programming-Monographs-Computer/dp/0387964800/ref=pd_sim_b_1

彼らの重要性を誇張するのは難しい。すべてのループとすべてのifステートメントは、何らかの「証明」を必要とするアイデアとして始まります。ほとんどのプログラマは、ほとんどの場合、頭の中でこの証明を行います。ifステートメントが何をし、彼らが明確に、そして論理的に-選択肢が何であるか、なぜ選択肢が完全で、一貫性があり、排他的であるかを明確にします。

しかし、ランダムに推測するように見える人もいます。彼らはより多くの助けを必要とし、正式な方法は彼らが必要とする一種の助けになるでしょう。

コードの代数（および微積分）にすぎません。複雑すぎたり洗練されたりすることはありません。

日光と新鮮な空気を素早くジョギングするために椅子を離れるような物理的なデザインパターンは、最高の状態で脳を動かし続けます。

それはHalf Life 2です（ここにお気に入りのゲームを挿入してください）。問題が発生した場合、解決できず、終了してお気に入りのゲームでプレイを開始すると、突然解決策が思い浮かびます。正直言って、それはゲームではなく、そのようなものではなく、他のことをするものです。問題を解決せずに何時間も問題に座っている人をよく見かけます。彼らがすべきことは、短時間脳をオフラインにすることだけです。

スタックオーバーフロー -立ち往生しているときの迅速な専門家のヘルプ

プロのプログラマー向けの質疑応答サイト。これは、Q＆AサイトのStack Exchangeネットワークの一部として構築され、実行されます。皆様のご協力により、プログラミングに関するあらゆる質問に対する詳細な回答のライブラリを構築するために協力しています...

Notepad / TextPad /シンプルなテキスト編集プログラムだと思います。IDEを開く必要がなく、簡単な編集だけが必要な迅速な修正が必要な場合があります。そして、すべてのコンピューターには、ある種の単純なテキスト編集プログラムがあります。

アサートと優れたalwaysAssert()機能。私見は、単体テストよりも重要です。単体テストでは、テストしようと考えた特定のケースでのみバグを見つけることができるからです。同じプログラマーがコードとテストを書いた場合、彼/彼女はおそらく両方で同じエッジケースを見逃すでしょう。さらに、コンポーネントの機能や動作するデータの環境が複雑すぎて、想定されるテストケースを思い付かないため、ユニットテストが実用的でない場合があります。

主張の美しさは、仮定を文書化し、想定外の入力でそれらをテストする能力にあります。これらの仮定のいずれかが間違っている場合、コードは「動作」する代わりに大声で失敗しますが、微妙に誤った結果を生成します。また、アサートなしの場合よりも、問題の根本に近いところで失敗します。実際には、コードについて十分な仮定を明示的に述べ、これらの仮定がすべて正しい場合、通常、コードは正しいです。

アサートに関する一般的な不満の1つは、それらをオフにできることです。IMHOのすべての言語または標準ライブラリにalwaysAssert()は、同じ機能を果たすassertがオフにできない機能または大まかな同等物が必要です。これは、アサーションをオフにする利点が無視できる、コードのパフォーマンスが重要ではない領域での仮定をチェックするために使用できます。

F1キー。-知らないプログラムや作業中のプログラムに役立ちます。（大規模なアプリケーションであると仮定します。）

ユーザーがソフトウェアの動作方法の解釈に基づいてバグを報告することで、問題を除外することができました。もちろん、デザイン自体に欠陥がある可能性があります。しかし、それは別の話です。

さまざまなUNIXコアユーティリティ。ただし、主にまたはfind時々。特にコードベースを突然継承して修正しなければならない場合、ファイルの深いネスト内で物を見つける能力は非常に貴重です。前述のコードが十分に文書化されていても、おそらく狩りをしなければならず、それを殺すことを強く理解している必要があります。grepedfind

好奇心

それを「プログラミングのなぞなぞ」と呼びます。それを振るう人と比較したツールは何ですか？何かが機能するかしない理由を知りたいという欲求は、特定のツールよりも知識を広げ、それはプログラミングを超えて真実です。

Ctrl + C    
Ctrl + V

世界中で数え切れないほどの時間を節約しました！

尾

Tailは、プログラムログ出力ファイルをリアルタイムで監視するために使用できます。ログを読み取る他の手段を提供しないシステムのために開発するとき、それは大きな助けになりました。

サンプルプログラムは次のとおりです。

• Unixのテール。
• Macのテール。
• Windows用のBareTail。

Perlコールグラフジェネレーターを一度まとめました。これは非常に便利でしたが、非手続き型のコードやファイル外のルーチンではひどく落ちていました。