Meist unterschätztes Programmiertool [geschlossen]

Wir haben viele großartige Tools, die beim Programmieren sehr hilfreich sind, z. B. gute Programmierer, Texteditoren, IDEs, Debugger, Versionskontrollsysteme usw. Einige der Tools sind mehr oder weniger "Muss" -Tools, um die Arbeit zu erledigen (z. B. Compiler). .

Es gibt immer noch Tools, die viel helfen, aber immer noch nicht so viel Aufmerksamkeit bekommen, aus verschiedenen Gründen, zum Beispiel als sie veröffentlicht wurden, waren sie ihrer Zeit voraus und sind jetzt mehr oder weniger in Vergessenheit geraten.

Welche Art von Programmierwerkzeug ist Ihrer Meinung nach das am meisten unterschätzte? Motivieren Sie Ihre Antwort.

Eine Gummiente. Ja wirklich.

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

Rubber-Duck-Debugging , Rubber-Ducking und der Rubber-Duckie-Test sind informelle Begriffe, die in der Softwareentwicklung verwendet werden, um auf eine Methode zum Debuggen von Code zu verweisen. Der Name ist ein Hinweis auf eine wahrscheinliche apokryphe Geschichte, in der ein ungenannter Experte immer eine Gummiente an seinem Schreibtisch hatte und seinen Code debuggte, indem er sich zwang, sie der Ente Zeile für Zeile zu erklären.

Um diesen Prozess zu verwenden, erklärt ein Programmierer einem unbelebten Objekt, wie z. B. einer Gummiente, den Code mit der Erwartung, dass der Programmierer den Fehler bemerkt, wenn er einen falschen Code erreicht und versucht, ihn zu erklären. Wenn beschrieben wird, was der Code tun soll, und beobachtet wird, was er tatsächlich tut, wird jede Inkongruenz zwischen diesen beiden offensichtlich ...

Stift und Notizbuch.

1. Funktioniert ohne Strom.
2. Tragbar.
3. Doodle on / in, wenn Sie sich in Meetings langweilen
4. Speichern Sie nützliche Informationen.
5. Wenn es aufgeschrieben ist, legen die Leute mehr Wert darauf.
6. Andere können es lesen und lernen.

Diff-Werkzeuge scheinen beim Vergleich von Protokollausgaben oder Daten in flachen Textdateien zu wenig genutzt zu werden. Oder ist das vielleicht nur eine Nische? Ich finde es sehr nützlich und hilfreich für das Debuggen, große Protokolle der Programmausführungen zu vergleichen und ein oder zwei Details zu identifizieren, die sich geändert haben.

Tools zur Leistungsprofilerstellung sind auch sehr gut, besonders wenn Sie einen kritischen Engpass haben, aber es scheint, dass nur sehr wenige Leute mit ihnen vertraut sind (und ich gebe mich in dieser Kategorie zu).

Gute XML-Tools sind von entscheidender Bedeutung - wenn Sie mit XML-Dateien arbeiten, die mehr als ein Dutzend Zeilen oder Mehrfachschemata enthalten. Manchmal benötigen Sie mehr als nur eine grundlegende Syntax, die andere Editoren zur Verfügung stellen. Auch beim Arbeiten mit XML kann das Erlernen von XSL sehr nützlich sein. Oft sehe ich, was mit einer einfachen XSL-Transformation erreicht werden kann, die in vielen Zeilen im Programmcode ausgeführt wird. Zur Klarstellung: Ich behaupte nicht , dass XML selbst ein "unterschätztes Programmiertool" ist. Ich schlage vor, dass der Wert guter XML-Editoren nach dem, was ich gesehen habe, unterschätzt wird.

Reguläre Ausdrücke

Sie sind einfach so nützlich. Sie helfen beim Durchsuchen von Protokolldateien, beim Analysieren von Text usw. Sie sind nur äußerst nützlich.

Ich finde es seltsam, wie viele Leute ich kenne, die sie nie benutzen, weil mit ihnen eine gewisse Lernkurve verbunden ist. Oft sehe ich Leute, die Dinge auf die harte Tour machen (Hinweis: Vor dem regulären Ausdruck habe ich Dinge auf die harte Tour gemacht), wenn ein einfacher regulärer Ausdruck sie schnell zum Erliegen bringen konnte.

Deine Teamkollegen. Wenn Sie sich auf eine heiße Idee begeben und vergessen, Ihr Team einzubeziehen, werden Sie nie die Bedenken oder Ideen hören, warum es nicht funktioniert oder warum es noch besser sein könnte.

Ich sage das, weil es leicht zu glauben ist, dass das Programmieren etwas unsoziales ist, das die Leute mit ihren brillanten Ideen in den Ecken tun. Menschen, die glauben, dies unterschätze den Wert von Teams und ihren Teamkollegen, wenn es darum geht, Ideen / Projekte zum Sinken zu bringen.

Google. Es gibt sehr wenige Probleme, die noch nicht gelöst und dokumentiert wurden. Eine gut abgestimmte Google-Abfrage kann jedem viel Zeit sparen.

Das bei weitem am meisten unterschätzte Werkzeug, um "Engpässe" zu finden, ist Ctrl+C oder die Schaltfläche "Pause" in einem Debugger.

Überprüfen Sie den letzten Absatz dieses Beitrags und diesen Beitrag und diesen Beitrag für den Anfang.

So oft sehe / höre ich von Leuten, die sagen: "Das Programm ist zu langsam! Was kann ich dagegen tun? Ich habe einen Profiler ausprobiert (wenn sie es getan haben), aber ich verstehe nicht, was darauf steht. Hat jemand irgendwelche Vermutungen? Hilfe! " Nun, Vermutungen sind genau das. Was ich schon immer getan habe und andere auch, ist, es in Gang zu bringen, es zu unterbrechen und den Aufrufstapel zu untersuchen. Wenn das Problem wirklich schlimm ist, Bingo , ist es direkt vor Ihnen. Wenn das Problem nur geringfügig ist, tun Sie es mehrmals. Alles, was bei mehr als einer Probe auftaucht und das Sie vermeiden können, ist ein Engpass, den Sie beheben können.

Ja, das ist ein Downvote-Köder, aber es funktioniert.

Welche Art von Programmierwerkzeug ist Ihrer Meinung nach das am meisten unterschätzte? Motivieren Sie Ihre Antwort.

Der Compiler.

Die meisten Leute nehmen sich keine Zeit, um zu verstehen, was der Compiler ihrer Wahl tut. Sie haben einfach das Gefühl, dass es den Code zu einem ausführbaren Programm macht, und das ist so weit wie sie gehen. Bei den meisten modernen gibt es mehrere Konfigurationen, die Sie eingeben können, damit sie genau das tun, was Sie brauchen. Hier ist ein Beispiel: Ich wette, die Hälfte der Entwickler in Ihrem Büro hat keine Ahnung, wie die Warnung als Fehlerstufe festgelegt werden soll (vorausgesetzt, sie hat tatsächlich eine). Welche Möglichkeiten haben Sie, um Debug-Symbole auszugeben? Welche Optimierungen (oder welche Stufe) möchten Sie vornehmen? Die Liste geht weiter.

Dein Gehirn. Andere Werkzeuge hätten ohne sie keine große Bedeutung.

Gute alte:

print

Manchmal ist ein Debugger oder Profiler oder ein UML-Flussdiagramm hilfreich. Und manchmal machen sie dich verrückt. Ich greife immer wieder auf print-Anweisungen (oder trace oder NSLog oder what-have-you) zurück, um sicherzustellen, dass mein Code das tut, was ich denke, dass er tut, wenn ich denke, dass er es tut.

Einfache alte Skripte ... Unabhängig von der Anzahl der Sprachen der nächsten Generation, die wir entwickeln, verlassen wir uns immer noch stark auf Skripte. Die meisten alltäglichen Aufgaben können durch das Schreiben einiger weniger Skripte erledigt werden.

Stift und Whiteboard.

Sie können Low-Tech nicht schlagen, wenn Sie versuchen, etwas zu erklären.

ack . Es ist wie grep -r, aber es ist für das Durchsuchen Ihres Quellcodes konzipiert.

Perl und andere Skriptsprachen. Ideal für Aufgaben, die für GUI-Tools wie Agent Ransack etwas zu kompliziert sind.

Tastaturkürzel, die ein schnelles, häufiges und sicheres Refactoring ermöglichen. Das Erlernen des Extrahierens (oder Inline-Extrahierens usw.) von Variablen, Methoden, Konstanten oder Klassen beim Drücken einiger Tasten hat die Codierung grundlegend geändert. Sie werden nur häufig umgestalten (dh genug), wenn die Kosten minimal sind. Daher ist es für mich von wesentlicher Bedeutung, diese Verknüpfungen zur zweiten Natur zu machen, um guten Code zu schreiben und zu pflegen.

Verwenden Sie daher im Allgemeinen gute Tools (IDE / Editor) und lernen Sie, wie Sie die darin enthaltenen Funktionen optimal nutzen können.

Als Nächstes folgen Unit-Tests und TDD, um den Code testbar zu halten und die Angst vor Umgestaltungen zu vermeiden.

Wenn Sie diese verwenden, können Sie problemlos korrekten wartbaren Code schreiben, der dem DRY-Prinzip entspricht und selbstdokumentierend ist.

Unit Testing bietet folgende Vorteile:

• Entwickler werden die ersten Kunden des Codes. Je schneller ein Fehler entdeckt wird, desto günstiger ist die Behebung. Möglicherweise werden Fehler vor dem Erstellen, Installieren oder Bereitstellen abgefangen .
• Testen ändert Ihre Sicht auf den Code. Ist das Design klar? Behandelt es Eckfälle?
• Der Hawthorne-Effekt verbessert die Qualität, indem einfach angekündigt wird, dass ein Team Qualitäts- / Testmetriken veröffentlicht.
• Auch wenn Tests nicht in der Quellcodeverwaltung aktiviert sind, können sie eine großartige Möglichkeit sein, neues Terrain zu erkunden und zu erlernen.
• Eine hohe Wahrscheinlichkeit für weniger Bugs!

Codegeneratoren

Codegeneratoren können aus einer einfachen Definition eine große Menge an effizientem und fehlerfreiem Code erstellen. Die Verwendung von ORM- Typen ist für die Erstellung von Datenzugriffsklassen am offensichtlichsten, es gibt jedoch noch viel mehr Verwendungsmöglichkeiten.

Die Unterstützung für die Codegenerierung steckt aus Sicht des Programmierers und des Frameworks noch in den Kinderschuhen, aber ich glaube, wir werden mehr und mehr davon sehen. In .NET können Sie anfangen, mit dem CodeDOM- Zeug zu experimentieren .

Ich benutze AgentRansack stark. Dies ist eine enorme Hilfe beim schnellen Durchsuchen von Tausenden von Dateien. Es hat mir so viel Zeit gespart, aber ich kenne nicht viele Programmierer, die es kennen oder verwenden.

Formale Methoden.

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

Es ist schwer, ihre Bedeutung zu übertreiben. Jede Schleife und jede if-Anweisung beginnt als eine Idee, die eine Art "Beweis" erfordert. Die meisten Programmierer machen diesen Beweis die meiste Zeit in ihren Köpfen. Sie fragen, was die if-Anweisung bewirkt und was die Auswahlmöglichkeiten sind und warum die Auswahlmöglichkeiten vollständig, konsistent und exklusiv sind.

Aber manche scheinen zufällig zu raten. Sie brauchen mehr Hilfe und formale Methoden könnten die Art von Hilfe sein, die sie brauchen.

Es ist nur Algebra (und Kalkül) für Code. Nichts zu komplex oder raffiniert.

Physische Designmuster wie das Verlassen des Stuhls für ein schnelles Joggen im Sonnenlicht und frische Luft halten unser Gehirn auf Hochtouren.

Nun, es ist Half Life 2 (fügen Sie hier Ihr Lieblingsspiel ein). Wenn ich ein Problem habe, das ich nicht lösen kann, höre ich einfach auf und spiele mit meinem Lieblingsspiel, und plötzlich kommt mir die Lösung in den Sinn. Um ehrlich zu sein, ist es kein Spiel oder so, sondern etwas anderes . Ich sehe oft Leute, die stundenlang an einem Problem sitzen, ohne es zu lösen, und alles, was sie tun sollten, ist, ihr Gehirn für kurze Zeit auszuschalten.

Stapelüberlauf - schnelle Hilfe von Experten, wenn Sie nicht weiterkommen

Frage- und Antwortseite für professionelle und begeisterte Programmierer. Es wird von Ihnen als Teil des Stack Exchange-Netzwerks von Q & A-Sites erstellt und ausgeführt. Mit Ihrer Hilfe arbeiten wir zusammen, um eine Bibliothek mit detaillierten Antworten auf alle Fragen zur Programmierung zu erstellen ...

Ich denke, es ist Notepad / TextPad / einfache Textbearbeitungsprogramme. Jeder hat eine Zeit, in der er eine schnelle Lösung benötigt, die kein Öffnen einer IDE und nur eine schnelle Bearbeitung erfordert. Und alle Computer haben eine Art einfaches Textbearbeitungsprogramm.

Behauptungen und eine gute alwaysAssert() Funktion. IMHO sind diese wichtiger als Unit-Tests, da Unit-Tests Fehler nur in den speziellen Fällen finden können, die Sie zu testen dachten. Wenn derselbe Programmierer den Code und die Tests schreibt, wird er wahrscheinlich die gleichen Randfälle in beiden Fällen verpassen. Darüber hinaus ist das Testen von Einheiten manchmal unpraktisch, da die Umgebung, in der die Komponente funktioniert und / oder die Daten, mit denen sie arbeitet, zu kompliziert ist, um einen erfundenen Testfall für zu erstellen.

Die Schönheit von Behauptungen liegt in ihrer Fähigkeit, Annahmen zu dokumentieren und sie an nicht erfundenen Eingaben zu testen . Wenn eine dieser Annahmen falsch ist, schlägt Ihr Code laut fehl, anstatt zu "funktionieren", erzeugt aber subtil falsche Ergebnisse. Es scheitert auch näher an der Wurzel des Problems als ohne die Behauptungen. In der Praxis ist der Code normalerweise korrekt, wenn Sie explizit genügend Annahmen zu einem Codeteil angeben und alle diese Annahmen korrekt sind.

Ein häufiger Kritikpunkt an Asserts ist, dass sie deaktiviert werden können. IMHO sollte jede Sprache oder Standardbibliothek eine alwaysAssert()Funktion oder ein grobes Äquivalent haben, das dasselbe tut, assertaber nicht ausgeschaltet werden kann. Dies kann zum Überprüfen von Annahmen in nicht leistungskritischen Codebereichen verwendet werden, in denen die Vorteile des Deaktivierens von Asserts vernachlässigbar sind.

Die F1-Taste. - Nützlich für Programme, die Sie nicht kennen, und für Programme, an denen Sie arbeiten. (Angenommen, es ist eine große Anwendung.)

Ein Benutzer konnte Probleme herausfiltern, indem er Fehler auf der Grundlage seiner Interpretation der Funktionsweise der Software meldete. Natürlich könnte es sein, dass das Design selbst fehlerhaft war. Aber das ist eine andere Geschichte.

Verschiedene UNIX-Kerndienstprogramme, aber in erster Linie findund gelegentlich grepoder ed. Die Fähigkeit, Dinge in tiefen Nestern von Dateien zu finden, ist von unschätzbarem Wert, insbesondere wenn Sie plötzlich eine Codebasis erben und diese reparieren müssen. Selbst wenn der Code gut dokumentiert ist, müssen Sie wahrscheinlich nach etwas suchen, und Sie müssen genau wissen, wie man es findtötet.

Neugierde

Nennen wir es das "Rätsel der Programmierung". Was ist ein Werkzeug im Vergleich zu der Person, die es benutzt? Der Wunsch zu wissen, wie und warum etwas funktioniert oder nicht, erweitert das Wissen mehr als jedes andere Tool, und das geht über die Programmierung hinaus.

Ctrl + C    
Ctrl + V

Unzählige Stunden weltweit gespart!

Schwanz

Tail kann verwendet werden, um die Ausgabedatei des Programmprotokolls in Echtzeit zu überwachen. Es war eine große Hilfe bei der Entwicklung von Systemen, die keine anderen Möglichkeiten zum Lesen des Protokolls bieten.

Beispielprogramme sind;

• Tail für Unix.
• Schwanz für Mac.
• BareTail für Windows.

Ich habe einmal einen Perl Call Graph Generator zusammengeschoben. Es war äußerst nützlich, fiel aber bei nicht prozeduralem Code oder Out-of-File-Routinen schwer.