Wann spielt „richtige“ Programmierung keine Rolle mehr?

49

Ich habe in meiner Freizeit ein Android-Spiel entwickelt. Es benutzt die libgdx- Bibliothek, so dass ein Großteil der Arbeit für mich erledigt wird.

Während der Entwicklung habe ich für einige Verfahren achtlos Datentypen ausgewählt. Ich habe eine Hash-Tabelle verwendet, weil ich etwas in der Nähe eines assoziativen Arrays haben wollte. Vom Menschen lesbare Schlüsselwerte. An anderen Stellen verwende ich einen Vektor, um ähnliche Ergebnisse zu erzielen. Ich weiß, dass libgdx die Klassen vector2 und vector3 hat, aber ich habe sie nie benutzt.

Wenn ich auf seltsame Probleme stoße und nach Hilfe bei Stack Overflow suche, sehen ich viele Leute, die nur die Fragen reiben, die einen bestimmten Datentyp verwenden, wenn ein anderer technisch "richtig" ist. Wie die Verwendung einer ArrayList, da keine definierten Grenzen erforderlich sind, statt ein int [] mit neuen bekannten Grenzen neu zu definieren. Oder auch etwas Triviales wie dieses:

for(int i = 0; i < items.length; i ++)
{
    // do something
}

Ich weiß, dass item.length bei jeder Iteration ausgewertet wird. Ich weiß jedoch auch, dass es niemals mehr als 15 bis 20 Artikel geben wird. Sollte es mich also interessieren, ob ich items.length bei jeder Iteration auswerte?

Ich habe einige Tests durchgeführt, um die Leistung der App mit der soeben beschriebenen Methode im Vergleich zur richtigen zu ermitteln. Befolgen Sie das Lernprogramm und verwenden Sie die genauen Datentypen, die von der Community vorgeschlagen wurden. Das Ergebnis: Gleiches. Durchschnitt 45 fps. Ich habe jede App auf dem Handy und dem Galaxy Tab geöffnet. Kein Unterschied.

Ich schätze, meine Frage an Sie lautet: Gibt es eine Schwelle, bei der es nicht mehr darauf ankommt, richtig zu sein? Ist es in Ordnung zu sagen - "Solange es die Arbeit erledigt, ist es mir egal?"

Kai Qing
quelle
4
Es ist eine Frage der Größenordnung. Versuchen Sie, Multi-Terrabyte-Datenbanken mit Suchvorgängen und Aggregationen in Reaktionszeiten von weniger als einer Sekunde mit Tausenden von Anfragen pro Minute für die reale Welt bereitzustellen. Dein Problem ist nicht groß genug. Obwohl Ihr Ansatz in Ordnung ist, ist es schmerzhaft, diesen Weg zu beschreiten, dessen Erreichen einige Zeit in Anspruch nimmt.
Jimmy Hoffa
8
Wenn Ihre Sprache eine echte FOR-Schleife hätte, würde dieses Problem der Mehrfachbewertung nicht auftreten. Leider erfordert die C-Syntax dies, da es sich nicht wirklich um eine FOR-Schleife handelt. Es ist eine WHILE-Schleife, die eine Perücke und eine Brille mit großer Nase trägt, und es muss eine beliebige Bedingung (oder überhaupt keine) für die Beendigung der Schleife akzeptiert werden.
Mason Wheeler
2
Ich sehe deine Änderung, aber wenn du versuchst, zu behaupten, dass es in jedem Zusammenhang in Ordnung ist, betrunken und rücksichtslos zu sein, außer an einem Freitagabend mit einem bestimmten Fahrer zu feiern, bellt du wahrscheinlich den falschen Baum an.
Robert Harvey
17
Woher wissen Sie, dass item.length bei jeder Iteration ausgewertet wird? Compiler sind ziemlich schlau. Und selbst wenn es wiederholt item.length holt, so was? Ich würde es hassen, Code wie 'int itemsLength = items.length; für (; i <itemsLength; ...) ', es sei denn, es liegt ein gemessenes Leistungsproblem vor.
Kevin Cline
6
Ihre Artikel.Länge hat absolut nichts mit "richtiger Programmierung" zu tun. Es ist eine Mikrooptimierung, und gute Programmierer wissen es besser, als Zeit damit zu verschwenden, bis sie einen Profiler ausgeführt haben und wissen, wo die tatsächlichen Leistungsprobleme liegen. Mikrooptimierungen und ein guter Programmierstil sind oftmals Gegensätze, nicht dasselbe.
Michael Borgwardt

Antworten:

65

Sie schreiben ein Programm, um ein Problem zu lösen. Mit diesem Problem gehen bestimmte Anforderungen zur Lösung des Problems einher. Wenn diese Anforderungen erfüllt sind, ist das Problem gelöst und das Ziel erreicht.

Das ist es.

Der Grund, warum Best Practices eingehalten werden, liegt darin, dass einige Anforderungen mit Wartbarkeit, Testbarkeit, Leistungsgarantien usw. zu tun haben. Folglich haben Sie solche nervigen Leute wie mich, die Dinge wie den richtigen Codierungsstil benötigen. Es erfordert nicht viel mehr Anstrengung, Ihre T's zu überschreiten und Ihre I's zu markieren, und es ist eine Geste des Respekts für diejenigen, die Ihren Code später lesen und herausfinden müssen, was er tut.

Bei großen Systemen ist diese Art von Zurückhaltung und Disziplin unabdingbar, da man mit anderen gut spielen muss, um alles zum Laufen zu bringen, und die technische Verschuldung so gering wie möglich halten muss, damit das Projekt nicht unter seinem eigenen Gewicht zusammenbricht.

Am anderen Ende des Spektrums befinden sich die einmaligen Dienstprogramme, die Sie zur Lösung eines bestimmten Problems schreiben und die Sie nie wieder verwenden werden. In diesen Fällen sind Stil und Best Practices völlig irrelevant. Sie hacken das Ding zusammen, führen es aus und fahren mit dem nächsten fort.

Also, wie bei so vielen Dingen in der Softwareentwicklung, kommt es darauf an.

Robert Harvey
quelle
1
Ich neige dazu, zuzustimmen. Bei der Arbeit stelle ich keine Fragen, es ist gekreuzt und gepunktet. Aber denken Sie daran, dass viele Dinge, die ich für die Arbeit mache, einmalig sind und nicht unbedingt gewartet werden müssen. Vorbei an Trend-Dingen. Geburtstags-Apps, Dinge, die kommen und gehen. Alles in Ordnung, aber das müssen sie wirklich nicht sein.
Kai Qing
21
Man kann sagen, dass es jederzeit einfacher ist, diszipliniert zu sein, wenn man diszipliniert sein muss. Einige Leute stellen Fragen zu Stack Overflow, ohne jemals die Umschalttaste zu drücken. Dabei wird die Begründung zugrunde gelegt, dass sie ihre Ideen ohne die Umschalttaste angemessen vermitteln können und dass die englische Sprache sowieso eine fließende und sich entwickelnde Sache ist. Ich finde nichts ärgerlicher, außer vielleicht Virenautoren, die meinen, meine CPU-Zeit sei frei.
Robert Harvey
2
@KaiQing Jemand muss Ihnen eine 5-ml-Altanwendung aushändigen, die in Pascal geboren und in die Zukunft portiert wurde, da Sie beim ersten Versuch, Funktionen in dieser Anwendung hinzuzufügen oder zu ändern, sofort erkennen, warum es Best Practices gibt und aufgeklärt werden.
Jimmy Hoffa
5
@KaiQing, Angry Birds muss auf mehreren Plattformen laufen und wenn das Spiel 2 Sekunden lang hängt, geben x% des Publikums es auf, was für die Angry Birds-Leute weniger Geld bedeutet. Ich wette, es wurde sehr, sehr sorgfältig geschrieben. Vielleicht beantwortet dies Ihre Frage. Wenn der Code nur für Sie ist, wen interessiert es, was Sie tun? Wenn es um Geld oder die Zeit anderer geht, sollten Sie sehr, sehr vorsichtig sein.
Charles E. Grant
2
@KaiQing Niemand kann Ihnen die Schwelle dafür sagen, sie ist von Projekt zu Projekt und für jedes Projekt im Laufe der Zeit unterschiedlich. Die Anzahl der Variablen, die den Schwellenwert zwischen wartbarem und nicht abhängigem System beeinflussen: LOC, Benutzerbasis, Entwicklerbasis, Art der Anwendung (Kryptografie vs. Unterstützte Plattformen, Technologiestapel, Menge der Daten, die verarbeitet oder analysiert werden, historische Prüfungsbeschränkungen und vieles mehr wirken sich darauf aus, wie schlecht Code sein kann
Jimmy Hoffa
18

Es gibt ein altes weises Zitat: "Tritt nicht in die Fußstapfen der alten Weisen. Suche, was sie suchten." Es gibt Gründe für alle Regeln der "richtigen" Codierung. Es ist wichtiger zu wissen, warum diese Regeln existieren, als zu wissen, was diese Regeln sind.

Es gibt eine Regel, dass Sie einen Test, der wiederholt in einer for-Schleife wie dieser neu berechnet werden kann, nicht einfügen sollten. In den Fällen, in denen die Regel erfunden wurde, um Abhilfe zu schaffen (wo die Leistung wirklich anders wäre), ist dies sinnvoll. In diesem Fall gibt es nur eine richtige Antwort. In Ihrem Beispiel ist bekannt, dass es keinen Leistungsunterschied gibt und dass es nicht mehr als ein paar Dutzend Iterationen geben kann. In diesem Fall gibt es zwei richtige Antworten, entweder um die Regel trotzdem anzuwenden, da sie einfach ist und nichts verletzt und dabei helfen kann, gute Gewohnheiten zu entwickeln, oder um die Regel zu ignorieren, da es keinen Leistungsunterschied gibt, über den man sich Sorgen machen muss.

Ich bevorzuge die erste richtige Antwort und Sie scheinen die zweite zu bevorzugen. Da irren Sie sich nicht. Ich denke, Sie sind falsch in Ihrer Vorstellung, worum es bei "richtiger" Programmierung geht. Es geht nicht darum, einem zufällig ausgewählten Regelsatz zu folgen, der Ihnen nicht hilft und keinen Zweck hat. Wenn Sie die for-Schleife im Beispiel nicht korrigieren, gilt eine sehr gute Regel gegen vorzeitige Optimierung.

Beim richtigen Programmieren geht es darum, gute Regeln zu befolgen, die auf intelligente Weise Sinn machen.

Michael Shaw
quelle
Ich würde nicht sagen, ich bevorzuge die zweite. Jemand hat meinen Beitrag bearbeitet, um den Teil zu entfernen, in dem es darum ging, dass ich dieses Android-Spiel fast ausschließlich betrunken gemacht habe (nur zum Spaß). Daher bin ich überrascht, dass meine betrunkenen Entscheidungen keinen Einfluss auf die Leistung hatten. Ich habe einige seltsame Klassen durch geeignete ersetzt, um sie zu testen. Ich stimme jedoch zu, dass es wichtiger ist, die Regeln zu kennen, als zu wissen, welche Regeln gelten ...
Kai Qing,
Darüber hinaus ist meine Vorstellung von "korrekter" Programmierung ein Ergebnis der sich wiederholenden Meinungen der Stackoverflow-Community sowie der Sammlung von Programmierern, die in der Firma, für die ich arbeite, hin und her gegangen sind. Einige haben einen CI-Abschluss, andere Autodidakt. Es gibt eine gemeinsame Meinung, auf die man sich stützen kann, und ich stimme dem zu, was alle zusammen sagen, bevor ich nur entscheide, dass ein Weg richtig und ein Weg falsch ist. Vielen Dank für Ihre Teilnahme.
Kai Qing
1
Wenn es sich anhörte, als hätte ich Sie wegen Verstoßes gegen die Regeln angeklagt, dann habe ich es schlecht formuliert. Keine der Dinge, über die Sie gesprochen haben, sind Dinge, gegen die ich Einwände erheben würde. Ich wollte darauf hinweisen, dass der "Geist des Gesetzes" wichtiger ist als der "Brief des Gesetzes".
Michael Shaw
Heh, nein, ich hätte nicht gedacht, dass du mich verraten hast. Ich war nur kommunikativ. Ich habe diese Frage aus einem bestimmten Grund gestellt, und ich bin froh, dass so viele Menschen geantwortet haben, ohne sie geschlossen zu haben.
Kai Qing
10

Die richtige Betrachtungsweise ist die Minderung der Rendite: Vergleichen Sie den zusätzlichen Nutzen der Programmentwicklung mit den Kosten der zusätzlichen Entwicklung.

Eine nachlassende Rendite setzt ein, wenn der Grenznutzen geringer ist als der Grenzaufwand.

Können Sie ein Geschäftsmodell erstellen items.length, um den forKreislauf zu verlassen? Kann diese Änderung in wirtschaftlicher Hinsicht sogar die Zeit rechtfertigen, die für die Rechtfertigung aufgewendet wurde? Da es keinen Unterschied in der Benutzererfahrung gibt, erhalten Sie auch für die Zeit, die Sie mit dem Messen verbracht haben, nie etwas (außer einer nützlichen Lektion, die Sie sich merken sollten). Die Benutzer werden das Programm nicht mehr mögen als sie, und infolge dieser Änderung werden keine weiteren Exemplare verkauft.

Dies ist nicht immer einfach zu bewerten, da Geschäftsfälle mit Unbekannten und Risiken behaftet sind und daher leicht unüberlegten Faktoren ausgesetzt sind, die erst im Nachhinein offensichtlich werden. Vorgeschlagene Änderungen können völlig untrivial sein, so dass sie einen großen Unterschied machen.

Die Art des Denkens mit sinkenden Renditen kann eine Jagd nach Ausreden darstellen, keine Maßnahmen zu ergreifen, und es kann vermieden werden, Risiken einzugehen, die sich im Nachhinein als eine Reihe verpasster Möglichkeiten erweisen könnten.

Aber manchmal ist es offensichtlich, wenn man etwas nicht tut. Wenn ein Teil der Entwicklung ein Wirtschaftswunder erfordert, um die Entwicklungskosten zu decken (Break Even), ist dies wahrscheinlich eine schlechte Idee.

Kaz
quelle
Sehr gut geschrieben. In meinem Fall war eine Rückkehr nie geplant. Jede Rückkehr mag zufällig sein, sollte aber nicht abgewiesen werden, da einige der größten Erfolge meiner Meinung nach als Flukes begannen. In Bezug auf die Kundenarbeit, bei der nicht so viel Geld auf dem Spiel steht, wie es möglicherweise nur Ärger gibt, wenn die App hängt oder etwas zu einer kleinen Unannehmlichkeit wird, ist es eine dickere Schwelle. Wenn die Benchmarks gut aussehen, der Code jedoch bekanntermaßen nicht die effizienteste ist, wird niemand vor dem Fortschritt des Codes mitkommen, um ihn zu überprüfen und möglicherweise eine Migration zu fordern. Schwer zu sagen.
Kai Qing
Tatsächlich. Wir können nicht immer objektive Argumente vorbringen. Nicht jeder schätzt das Programm gleich. Angenommen, das Hauptwerkzeug im Programm ist das Vergnügen, daran zu arbeiten. Das mag für niemanden von Vorteil sein und niemand wird für die Verbesserungen aufkommen (selbst wenn es außer dem Programmierer noch andere Benutzer gibt), aber es ist genug, um eine Verbesserung in irgendeiner Weise zu rechtfertigen.
Kaz
Zwei nützliche Worte, die Sie zu Ihrer sehr gut geschriebenen Antwort hinzufügen sollten: "Spekulative Investition" - Sie tun dies, weil Sie spekulieren, dass es in Zukunft eine Rendite geben wird.
Mattnz
@mattnz - was du sagst, ist darin wahr, dass niemand etwas für keine Rückkehr tut, selbst wenn die Rückkehr ein gutes Lachen ist. Fast alle meine persönlichen Projekte sind für den Humor gemacht. Fast alle von ihnen machen genug, um ihre Anforderungen zu rechtfertigen. Keiner von ihnen hat es mir ermöglicht, aufzuhören.
Kai Qing
Genau, jeder. Zuerst legen wir fest, was wir vom Schreiben dieses Programms erwarten oder weiterhin tun möchten. Das könnte sein, "die Zeit so zu vertreiben, dass es Spaß macht". Aber selbst dann können wir denken: Ist es der beste Weg, an so und so etwas in so und so einem Programm zu arbeiten, um den meisten Spaß zu erzielen, oder verwenden wir die Zeit für etwas anderes?
Kaz
3

Wenn Sie sich nicht darum kümmern sollten, dass Ihr Code "richtig" ist

  • Wenn Sie es schaffen, das Geschäftsziel zu erreichen und es mit geringem Overhead über die Zeit zu halten. (Nutzer sehen die Quelle erst an, wenn sie sie bezahlt haben.)
  • MVP / POC - Wenn das Schreiben von richtigem Code die Verschwendung von Zeit für ein Konzept bedeutet, bevor Sie wissen, wie Sie damit Geld verdienen können (wenn Sie Jahre und 45 Millionen Dollar damit verbringen, Ihre App zu schreiben und den Shop zu schließen, weil es keinen Markt gibt, kümmert sich niemand darum, wie richtig war der Code)
  • In einer lebensbedrohlichen Situation (z. B. war der Iron Man-Prototyp 1 ein schmutziger Hacker, aber er hat ihn aus der Höhle geholt, oder?)
  • oder wenn Sie einfach nicht wissen, wie man richtigen Code schreibt (wenn es jemand schafft, seinen Lebensunterhalt damit zu verdienen, nicht richtigen Code zu schreiben, ist es bei der heutigen Arbeitslosigkeit besser, schlechten Code zu schreiben, als obdachlos zu sein)
  • Wenn du einfach weißt, was du tust oder denkst, dass du damit durchkommst, als würdest du es tun

Wann ist der richtige Code zu schreiben?

  • Wenn sich dies erheblich auf das Geschäft auswirkt, wirkt sich z. B. die Leistung auf den Umsatz aus oder verhindert den Verkauf
  • Wenn es so nicht richtig ist, dass die Pflege des Codes zu einem geschäftlichen Problem wird (hohe Wartungskosten)
  • Wenn Sie ein bekannter Programmierer sind, der an einem großen Open-Source-Projekt arbeitet
  • Dasselbe gilt für ein großes Unternehmen, das der Welt eine eigene Bibliothek zur Verfügung stellt
  • Wenn Sie Ihre Arbeit in zukünftigen Interviews als Portfolio zeigen möchten
Eran Medan
quelle
1
Leider gibt es in der Liste der nicht fürsorglichen Fälle eine andere, die viele Menschen nicht kennen sollten: Wenn ein Kunde ein altes System in Ihre Obhut spuckt und Ihnen mitteilt, dass es in einer Woche erledigt werden muss. Manchmal lassen sich Zeit und / oder Budget nicht richtig programmieren, und Ihre Aufmerksamkeit für das Projekt ist eher eine Gnade als eine Geschäftstransaktion. Zum Beispiel, wenn ihr Code weitgehend veraltete Methoden verwendet, aber einige Patches benötigt (in einem Web-Szenario). Kann das Ganze nicht reparieren. Muss schmutzig werden.
Kai Qing
"Wenn es so nicht richtig ist, dass die Pflege des Codes zu einem geschäftlichen Problem wird (hohe Wartungskosten)." Diese Schwelle ist tatsächlich erheblich niedriger als die meisten unerfahrenen Entwickler glauben. Das Schreiben von solidem Code zahlt sich oft innerhalb von Stunden und nicht Tagen oder Monaten aus.
PeterAllenWebb
2

Ist Leistung Ihr Hauptanliegen? Versuchen Sie das zu maximieren?

Wenn ja, gibt es eine grundlegende Lektion zu lernen, und wenn Sie dies tun, werden Sie einer der wenigen sein.

Überlegen Sie nicht, was Sie tun sollten, um es schneller zu machen - das ist zu vermuten. Wenn Sie sich fragen: "Soll ich diese oder jene Containerklasse verwenden?" Oder "Soll ich lengthin die Endlosschleife gehen?", Dann sind Sie wie ein Arzt, der einen Patienten sieht und versucht, zu entscheiden, welche Behandlung er ohne ihn geben soll Befragung oder Untersuchung des Patienten.

Das ist zu raten. Jeder macht es, aber es funktioniert nicht.

Lassen Sie sich stattdessen vom Programm selbst mitteilen, wo das Problem liegt. Hier ist ein detailliertes Beispiel.

Siehst du den unterschied

Mike Dunlavey
quelle
Ich würde sagen, meine einzige Sorge war, dass ich bei meinen Tests keine Leistungsunterschiede zwischen der unsachgemäßen und ordnungsgemäßen Verwendung von Datentypen für das angegebene Szenario festgestellt habe. Wie in Ihrem Vorschlag, habe ich die Klasse mit mehr Daten überladen, um festzustellen, ob es einfach zu wenig war, um einen Unterschied zu bewirken. Am Ende schnitten beide gleich gut ab. Zugegeben, ich mache nur ein einfaches RPG-Spiel. Es ist nicht wie Bankensoftware oder etwas Komplexes. Aber ich habe mich gefragt, ob es besser wäre, wenn das Geschäft nicht immer so gut läuft.
Kai Qing
Da Leistung Ihr Anliegen ist, sollten Sie dem Programm die Frage stellen, worauf Sie achten sollten, und nicht, ob Ihre vorgefasste Frage einen Unterschied macht. Bitte klicken Sie auf diesen Link und machen Sie, was es sagt. Sie erfahren, worauf sich das Programm wirklich konzentriert, und wie Sie es beschleunigen können.
Mike Dunlavey
Nun, die Leistung war meine Grundlage für das Befragungsverfahren, nicht unbedingt ein Problem. Ich bin nicht auf der Suche nach Benchmark per say. Nur zu beobachten, dass ineffizienter Code keinen Leistungsunterschied machte. Es ist für den Benutzer im Wesentlichen transparent, wie effizient oder ineffizient das Programm war, weshalb die Sorge um eine solche Profilerstellung irrelevant ist. Zugegeben, ich musste mir zuerst einige Sorgen um das Benchmarking machen, aber es war größtenteils Neugier. Und wenn das Produkt fertig ist und es merklich langsam ist, dann macht ein Profiler Sinn. Vielen Dank für den Link
Kai Qing
2

Ihre Frage ist "solange es die Arbeit erledigt, ist es mir egal?"

Meine Antwort lautet: "Sie wissen nie, was mit Ihrem Code passieren wird." Ich war an so vielen Projekten beteiligt, die mit dem Motto "Hey, lass mich dieses schnelle Ding schreiben, um das Problem eines Benutzers zu lösen" begannen. Schreibe es, lege es da raus, denke nie wieder darüber nach.

Einmal verwandelte sich das, was ich geschrieben habe, in "Oh, jetzt möchte die gesamte Abteilung des Benutzers diesen Code verwenden". Bevor ich mich umdrehen konnte, verwendete das gesamte Unternehmen diesen Code und jetzt muss ich nachweisen, dass er eine Prüfung übersteht und für morgen ist eine Codeüberprüfung für 20 Personen geplant, die bereits von einigen Vizepräsidenten an unsere Kunden verkauft wurde. "

Mir ist klar, dass Sie "in Ihrer Freizeit nur ein Android-Spiel schreiben", aber Sie wissen nie, ob sich dieses Spiel durchsetzen und zu Ihrer Eintrittskarte für Ruhm und Reichtum werden wird. Schlimmer noch, dieses Spiel könnte Ihre Eintrittskarte für Infamie werden, weil es die Telefone der Leute immer wieder zum Absturz bringt. Möchten Sie die Person sein, die ein Jobangebot erhält, weil die Kinder eines anderen nicht aufhören können, Ihr Spiel auf ihren Handys zu spielen, oder möchten Sie die Person sein, die auf Nachrichtenbrettern wie diesem verunglimpft wird?

Dan Perkins
quelle
1

Die Antwort ist, dass es nie darauf ankommt und es immer darauf ankommt ....

Es spielt keine Rolle, denn Programmieren, ob richtig oder nicht, ist ein Weg, ein Ziel zu erreichen, kein Ziel an sich. Wenn dieses Ziel ohne "richtige" Programmierung erreicht wird, ist das in Ordnung (aus geschäftlicher Sicht ist es oft am besten, wenn das Ziel ohne Programmierung erreicht werden kann).

Es ist immer wichtig, denn eine korrekte Programmierung ist ein Werkzeug, mit dem Sie Ihre Ziele erreichen können. Die richtige Vorgehensweise ist lediglich die Erkenntnis, dass eine andere Vorgehensweise auf lange Sicht mehr Schmerzen verursacht als spart.

Was die Frage beantwortet, wann Sie es ignorieren können - wenn Sie sicher sind, dass ein anderer Weg auf lange Sicht einfacher sein wird (möglicherweise, weil es auf lange Sicht keinen geben wird).

Einmalige Tools werden in der Regel so schnell und schmutzig wie möglich ausgeführt, mit wenig oder gar keiner Fehlerprüfung oder anderen Überprüfungen, ohne Protokollierung von Ausnahmen, Ausschneiden und Einfügen von Code mit geringfügigen Änderungen oder gar keinen Änderungen anstelle von generischen Funktionen und so weiter .

Pass auf: Manchmal haben diese schnellen und schmutzigen Apps ihre eigene Ausstrahlung, was bedeutet, dass dich alle Abkürzungen in den ...

jmoreno
quelle
1
"nie" und "immer" kündigen sich gegenseitig. Machen Sie Ihre Antwort sowohl gut als auch schlecht.
Tulains Córdova
@ user1598390: Ihr gegenseitiges Aufheben war der Punkt. Brechen Sie das Dogma ab, und Sie werden belassen, wie es nützlich erscheint. Und du wirst es falsch verstehen und daraus lernen.
Jmoreno
Ich möchte sagen, dass ich Ihnen zustimme, aber ich hätte es nicht zu solchen Extremen gebracht. Ich glaube nicht, dass Einzelstücke oft nur ausgespuckt werden, um dem Testen oder Debuggen zu entgehen. Nur weil es nicht optimiert und perfekt designt ist, macht es es nicht weniger zu einem Produkt, wenn die Leistung und Stabilität nicht durch das Shortcust beeinträchtigt werden. Was letztendlich mein Punkt ist und warum ich mich frage, warum jeder so nach Codebeispielen stinkt, die nicht auf dem neuesten Stand sind. Beim Stackoverflow kommt es häufig vor.
Kai Qing
@KaiQing: Tests und Debugging finden natürlich statt, sind jedoch im Allgemeinen auf das beschränkt, was derzeit vorhanden ist - beispielsweise, wenn der Prozess bei einer Datei mit UTF-Codierung fehlschlägt und bei keiner der Dateien, an denen Sie gerade arbeiten Sie testen das nicht. Die Optimierung sollte durchgeführt werden, wenn ein Leistungsproblem festgestellt wurde. Was den Grund angeht, warum es bei SO-Codierungsbeispielen nicht gerade erstklassig ist - ich denke, das hängt von den Zielen der Website ab. Es soll eine permanente Ressource sein, Code in Antworten (und sogar Fragen) werden so betrachtet, als ob sie eine Vorlage sind, die andere verwenden.
Jmoreno
1

Oder auch etwas Triviales wie dieses:

for(int i = 0; i < items.length;i ++) {
     // do something 
}

Ich weiß, dass item.length bei jeder Iteration ausgewertet wird. Ich weiß jedoch auch, dass es niemals mehr als 15 bis 20 Artikel geben wird. Sollte es mich also interessieren, ob ich items.length bei jeder Iteration auswerte?

Tatsächlich wird items.length im endgültigen Code nicht bei jeder Iteration ausgewertet, da der Compiler es optimiert. Und selbst wenn dies nicht der Fall wäre, ist length ein öffentliches Feld im Array-Objekt. Der Zugriff darauf kostet nichts.

Ich schätze, meine Frage an Sie lautet: Gibt es eine Schwelle, bei der es nicht mehr darauf ankommt, richtig zu sein? Ist es in Ordnung zu sagen - "Solange es die Arbeit erledigt, ist es mir egal?"

Es hängt wirklich davon ab, was Sie von Ihrem Endprodukt erwarten. Der Unterschied zwischen einem durchschnittlichen Produkt und einem großartigen Produkt liegt im Detail. Ein Auto wie Tata Nano und ein Auto wie Mercedes S "erledigen die Arbeit" - es bringt Sie von einem Ort zum anderen. Der Unterschied hängt in Details ab: Motorleistung, Komfort, Sicherheit und andere. Dies gilt auch für alle vorhandenen Produkte, einschließlich Softwareprodukte. Warum sollte zum Beispiel jemand an Oracle, IBM oder Microsoft für Oracle-Datenbanken, DB2 oder MS SQL Server zahlen, da MySQL und Postgre kostenlos sind?

Wenn Sie auf die Details achten und ein qualitativ hochwertiges Produkt erhalten möchten, sollten Sie sich um dieses Zeug (und natürlich auch um andere Sachen) kümmern.

m3th0dman
quelle
Ich glaube aber nicht, dass ich damit einverstanden bin. In meinem Beitrag erwähne ich keinen Leistungsunterschied. Das würde darauf hindeuten, dass es kein durchschnittliches oder großartiges Produkt gibt, sondern ein ausgewogenes Verhältnis trotz der Mängel eines. Ich würde Ihrer Aussage jedoch zustimmen, wenn es ein bestimmtes Projekt von großer Bedeutung gäbe, das wir alle als Vergleich herangezogen haben. Aber abstrakt ist die allgemeine Beobachtung, dass in diesem anonymen Projekt eine ausgesprochen ineffiziente Klasse gleichermaßen mit einer optimierten durchgeführt wird. Also, ist es in Ordnung, diesbezüglich eine lockere Haltung einzunehmen oder jedes Mal für Perfektion einzutreten?
Kai Qing
@ Kai Qing Eine einzelne Klasse macht keinen großen Unterschied. Ich sagte es: Wenn Sie erwarten, dass Ihr Produkt ein qualitativ hochwertiges Produkt ist, achten Sie auf Details (auch wenn dies eine mögliche kleine Optimierung oder ein sorgfältiges Design bedeutet). auf der anderen Seite, wenn das einzige, was Sie wollen, ein funktionierendes System ist, dann sollten Sie wahrscheinlich nicht viel auf winzige Details achten.
m3th0dman
Ja, Sie haben Recht, es sollte keinen Unterschied machen, auch wenn nur ein wenig Sorgfalt in das Design gelegt wird. Aber es kann einen Unterschied machen, abhängig von seinem Zweck oder wenn sich sein Zweck im Allgemeinen im Laufe der Zeit verändert hat und etwas wurde, was es nicht sein sollte. Ich habe das schon mal gesehen, aber ich gehe hier nur auf einen Tangens. Um fair zu sein, kann ein Produkt von hoher Qualität sein, ohne mehr als funktional zu sein.
Kai Qing
1

Wenn Sie zu Hause für sich selbst programmieren, können Sie vielleicht ein paar Ecken abschneiden. und wenn Sie experimentieren und Dinge ausprobieren, ist dies völlig gerechtfertigt.

Aber pass auf dich auf. In dem Beispiel, das Sie angeben, müssen Sie diese Ecke nicht wirklich abschneiden, und Sie müssen vorsichtig sein. Dies könnte einen Trend auslösen und schlechte Angewohnheiten, die Sie zu Hause machen, könnten sich bei der Arbeit in Ihren Code einschleichen. Es ist weitaus besser, zu Hause gute Gewohnheiten zu üben und zu verbessern und sie bei der Arbeit in Ihren Code einfließen zu lassen. Es wird dir helfen und es wird anderen helfen.

Jedes Programmieren, das Sie tun und jedes Denken, das Sie über das Programmieren machen, ist Übung. Lohnt es sich, sonst kommt es zurück und beißt dich.

Schauen Sie aber auf die gute Seite. Sie haben danach gefragt, vielleicht wissen Sie ja schon, worauf ich hinaus will.

Daniel Hollinrake
quelle
1
Ja, mir ist bewusst, aber der springende Punkt ist meistens, dass es im kleineren, geschlossenen Kontext keinen Grund zu geben scheint, so richtig zu sein. In all meinen Jahren des Programmierens hat sich wirklich nicht viel zurückgeschlichen, um uns zu beißen. Ich bezweifle, dass wir so richtig sind. Ich denke, Sprachen und Erwartungen ändern sich wie bei normaler Software. Einige weniger als andere. Letztendlich kann die Ineffizienz eines Projekts jedoch nur realisiert werden, wenn das Projekt in der Vergangenheit liegt und nicht mehr wesentlich ist. Es macht es schwer, die Kopfschmerzen zu rechtfertigen, so starr zu sein.
Kai Qing
Das ist ein fairer Punkt. Die Regeln von heute können die Einschränkungen von morgen sein. Mir gefällt es nicht, gesagt zu werden, was zu tun ist, aber ich habe Respekt vor anderen, die zuvor gegangen sind und den harten Weg gelernt haben. Manchmal kann es jedoch interessant sein, herauszufinden, welche Regeln nützlich sind und welche nicht mehr gültig sind.
Daniel Hollinrake
1

Wenn ein Möbelhersteller ein Möbelstück für die Verwendung herstellt, bei dem die Qualität nicht von größter Bedeutung ist oder bei dem die Qualität möglicherweise unbemerkt bleibt, sollten sie dann trotzdem versuchen, ihre Schnitte gerade zu machen und die Teile ordnungsgemäß zusammenzufügen?

Viele Menschen sehen Software als Handwerkskunst. Was wir bauen, sollte nicht nur eine Funktion erfüllen, sondern auch zuverlässig, wartbar und robust sein. Das Erstellen einer solchen Software erfordert Fachwissen, das aus der Praxis stammt.

Auch wenn die Wahl eines Schleifenkonstrukts für das, woran Sie heute arbeiten, keine Rolle spielt, wird die Tatsache, dass Sie immer danach streben, die richtigen Konstrukte zu verwenden, Sie mit der Zeit zu einem besseren Programmierer machen.

Bryan Oakley
quelle
Bei der Programmierung sind Fälle aufgetreten, in denen der Code nicht gewartet werden oder außerhalb der Anforderungen ausgeführt werden musste. Wie Kiosk-Dienstprogramme für Messen oder Veranstaltungen, die sehr spezifisch sind und wahrscheinlich nicht wiederverwendet werden. Im Falle meines eigenen Spiels bin ich der einzige, der es aufrechterhält, so dass dieses Argument möglicherweise nicht das zutreffendste ist. Ich habe immer noch Zweifel an der gemeinsamen Perspektive eines "besseren Programmierers", da die strikte Einhaltung von Richtlinien, Wartbarkeit und der ordnungsgemäße Gebrauch von Datentypen entmutigend genug sein kann, um das Projekt nicht abzuschließen. Wenn der Code wie erwartet funktioniert, warum sollte er dann perfektioniert werden?
Kai Qing
Auch wenn die Software, die Sie gerade erstellen , nicht gewartet werden muss, stärkt das Schreiben der Software Ihre Codierungsfähigkeiten. Wenn Sie endlich wartbaren Code schreiben müssen, können Sie dies einfacher tun.
Bryan Oakley
Ich muss ständig wartbaren Code schreiben. Nur in einigen Fällen muss es nicht sein. Da ich jedoch viel Erfahrung habe, weiß ich in der Regel, wann und wo Abstriche gemacht werden müssen. Der Zweck dieses Beitrags bestand darin, die Konversation über die Schwelle von Richtig und Schlampig für jeden Zweck zu schüren. Mein Beispiel streicht nur leicht darüber, da das angegebene Beispiel in einer kleineren Anwendung meist harmlos ist. Wenn ich jedoch Banksoftware schreibe, wäre ich niemals so nachlässig.
Kai Qing