Programmieren ist ein relativ hochspezialisierter technischer Beruf. Es gibt weltweit eine große Anzahl von Programmierern. Jeden Tag diskutieren die Leute darüber, welche Programmiersprache die beste ist, was einen guten Programmierer ausmacht und so weiter. Als Nächstes sehen wir uns die kontroversesten Meinungen zur Programmierung an.

1. Programmierer, die in ihrer Freizeit nicht aus Spaß programmieren, werden niemals mit denen mithalten können, die Freude am Programmieren haben.

Ich glaube, dass selbst die klügsten und talentiertesten Menschen niemals wirklich hervorragende Programmierer werden, wenn sie Programmieren nur als Job betrachten. Diejenigen, die Programmieren genießen, arbeiten in ihrer Freizeit an kleinen Projekten oder basteln mit verschiedenen Programmiersprachen und Programmierideen herum.

2.   Unit-Tests helfen nicht dabei, exzellenten Code zu schreiben.

Der einzige Grund, Unit-Tests zu schreiben, ist sicherzustellen, dass Code, der bereits funktioniert, nicht kaputtgeht. Tests zuerst zu schreiben oder Code zu schreiben, damit er Tests besteht, ist völlig absurd. Wenn Sie Tests vor dem Code schreiben, wissen Sie nicht, was die Edge Cases sind. Obwohl Sie den Code dazu bringen können, die Tests zu bestehen, treten in unvorhergesehenen Situationen trotzdem Probleme auf. Außerdem bemühen sich gute Entwickler, die Kopplung zu reduzieren, sodass neuer Code bestehenden Code nicht kaputt machen sollte.

3. Die einzige Best Practice, die überall gilt, ist "denke mit deinem Gehirn."

Zu viele Menschen jagen gerne trendigen Technologien nach und versuchen, verschiedene Methoden, Muster und Frameworks an ungeeigneten Stellen anzuwenden. Neue Technologien und die Meinungen berühmter Experten sind nicht gleichbedeutend damit, was in realen Situationen tatsächlich funktioniert.

4. Kommentare in den meisten Codebasen sind tatsächlich eine üble Manifestation von Code-Duplizierung.

Der größte Teil unserer Zeit wird damit verbracht, Code zu warten, der von anderen (oder von uns selbst) geschrieben wurde, und schlechte, falsche, veraltete und irreführende Kommentare gehören definitiv zu den frustrierendsten Dingen im Code. Viele Menschen löschen sie schließlich. Anstrengungen sollten darauf verwendet werden, die Lesbarkeit des Codes zu verbessern, bei Bedarf zu refaktorisieren und Idiome und clevere Tricks zu vermeiden. Darüber hinaus predigen viele Lehrbücher noch immer, dass Kommentare sogar wichtiger als Code seien, was zu großen Mengen weitschweifiger, sinnloser Kommentare führt.

5. Es ist nichts daran auszusetzen, sich auf Google zu verlassen.

Diese Art von Aussage wird die Gelehrten und Belesenen definitiv verärgern. Aber muss nicht jeder Dinge nachschlagen? Eine richtige Antwort ist eine richtige Antwort, ob sie aus irgendeinem geheimen Buch, aus privatem Unterricht oder von Google kommt. Worauf es ankommt, ist, wirklich zu verstehen und erfolgreiche Programmierlösungen zu liefern, die Kunden und Chefs zufriedenstellen.

6.  Programmierer werden nicht gleich geboren.

Manager denken oft, Programmierer A == Programmierer B, weil sie ähnlich viele Jahre Erfahrung haben. In Wirklichkeit kann ein Entwickler zehn- oder sogar hundertmal effektiver sein als ein anderer.

7. Ich kann wirklich nicht verstehen, warum Java die beste erste Sprache für den Universitätsunterricht ist.

Erstens glaube ich, dass eine erste Programmiersprache sich auf das Erlernen von Kontrollfluss und Variablen konzentrieren sollte, nicht auf Objekte und Syntax. Zweitens denke ich, dass Menschen, die noch nie C/C++-Speicherlecks debuggt haben, nie vollständig den ursprünglichen Zweck von Java verstehen können. Außerdem sollte die natürliche Entwicklung von "Wie mache ich das?" zu "Wie finde ich eine Bibliothek, die das macht?" führen, nicht umgekehrt.

8. Wenn du nur eine Sprache kennst, bist du, egal wie gut du sie beherrschst, immer noch kein exzellenter Programmierer.

Manche Leute denken, dass es ausreicht, wenn man in C#, Java oder welcher ersten Sprache auch immer, die man gelernt hat, versiert ist. Ich widerspreche. Jede neue Sprache, die ich lerne, vermittelt mir neue Programmiereinblicke, die ich in meine Arbeit einfließen lassen kann. Wer auf eine Sprache beschränkt ist, kann sein volles Potenzial nicht ausschöpfen. Außerdem sind mangelnde Neugier und mangelnde Bereitschaft zum Erkunden keine Eigenschaften eines exzellenten Programmierers.

9. Es ist in Ordnung, ab und zu Müllcode zu schreiben.

Manchmal reicht für bestimmte Aufgaben schneller und schmutziger Code aus. Vergiss Muster, ORM, SRP (Single Responsibility Principle) und all das.

10. Print-Anweisungen sind eine effektive Debugging-Methode.

Ich finde, Ausgabeanweisungen wie System.out.println zum Debuggen von Code zu verwenden, ist völlig in Ordnung. Es ist oft schneller als formales Debugging, und man kann die Ausgabeergebnisse verschiedener Läufe vergleichen. Aber stelle sicher, dass du diese Anweisungen vor dem Produktivbetrieb entfernst oder sie in Logging-Anweisungen umwandelst.

11. Deine Aufgabe ist es, dich selbst ersetzbar zu machen.

Die Software, die du schreibst, sollte für jeden anderen Entwickler mit ein wenig Zeit verständlich und wartbar sein. Software sollte elegant entworfen sein, der Code klar und konsistent, die Formatierung sauber, die Dokumentation angemessen, tägliche Builds, ordnungsgemäße Versionsverwaltung. Wenn du von einem Auto angefahren, gefeuert oder kündigst, sollte das Unternehmen schnell jemanden haben, der dich ersetzt. Wenn nicht, dann bist du wirklich zu bedauern. Interessanterweise gilt: Je mehr du das tust, desto wertvoller bist du für das Unternehmen.

Jemand kommentierte unter dem ursprünglichen Beitrag: Wenn du nicht ersetzt werden kannst, kannst du auch nicht befördert werden.

12. Getter und Setter werden extrem überstrapaziert.

Tausende Leute sagen, öffentliche Felder seien böse und sollten privat sein, mit Gettern und Settern. Ich denke, es gibt wirklich keinen Unterschied, es sei denn, das Programm ist multithreaded oder die Zugriffsmethoden enthalten Geschäfts- oder Präsentationslogik (was seltsam wäre). Ich befürworte keine öffentlichen Felder; ich bin nur dagegen, so zu tun, als ob das Umhüllen mit Zugriffsmethoden oder Properties Kapselung oder Informationsverbergung sei.

13. SQL ist auch Code, behandle es bitte genauso.

SQL unterscheidet sich nicht von C#, Java oder anderen objektorientierten oder prozeduralen Sprachen. Achte auf Formatierung, Lesbarkeit und Wartbarkeit.

14. UML-Diagramme werden überbewertet.

Einige Diagramme sind sicherlich nützlich, zum Beispiel Klassendiagramme für das Composite-Muster. Aber viele UML-Diagramme sind wertlos.

Anmerkung der CSDN-Redaktion: Ich erinnere mich, dass Robert Martin in „Agile Software Development (C# Edition)“ bei der Diskussion von UML im Grunde ein Diagramm zeigte und dann sagte, es scheine nicht nützlich zu sein, ich habe es nicht viel verwendet ... Unter derselben Frage gab es auch eine verwandte Antwort: code == design. Darin wurde argumentiert, dass Code in Hochsprachen effektiver ist als UML-Diagramme und Dokumentation.

15. Lesbarkeit ist der wichtigste Aspekt von Code.

Noch wichtiger als Korrektheit. Lesbarer Code lässt sich leicht reparieren, optimieren, ändern und verstehen. Auch andere Entwickler können davon profitieren.

16. XML wird stark überbewertet.

Viele Leute, die auf den XML-Zug aufgesprungen sind, haben nicht gründlich nachgedacht. XML ist für Webanwendungen in Ordnung, denn dafür wurde es ursprünglich entworfen. Bei anderen Problemdefinitionen und Designideen sollte XML möglichst vermieden werden.

17. Softwareentwicklung ist nur ein Job.

Ich liebe Softwareentwicklung. Ich arbeite derzeit bei einem Startup, 60 Stunden pro Woche, bei geringer Bezahlung, nur weil das Team großartig und die Arbeit interessant ist. Aber aus einer höheren Perspektive ist es immer noch nur ein Job. Er ist nicht so wichtig wie Familie, meine Freundin, andere Freunde, Glück usw. Wenn ich genug Geld hätte, würde ich lieber Motorrad fahren, Yachten fahren oder Snowboarden gehen. Viele Entwickler vergessen, dass Programmieren nicht das endgültige Ziel ist; es bietet uns nur die Bedingungen, um die wichtigsten Dinge im Leben glücklich zu tun.

Anmerkung der CSDN-Redaktion: Dieser Punkt scheint Punkt 1 zu widersprechen.

18. Entwickler sollten Code schreiben können.

Letztes Jahr habe ich viele Interviews geführt. Ich teste hauptsächlich das Denken der Leute und wie sie relativ einfache Algorithmen auf einem Whiteboard implementieren. Ich beginne oft mit einer Frage wie dieser:

Angenommen, Pi kann mit der Funktion 4 * (1 – 1/3 + 1/5 – 1/7 + …) berechnet werden, wobei mehr Terme mehr Genauigkeit liefern, schreiben Sie eine Funktion, die Pi auf 5 Dezimalstellen berechnet.

Dies ist ein Problem, das sich in 10 Zeilen C# lösen lässt. Aber viele Interviewte haben überhaupt keine Ahnung. Also muss ich solche Fragen stellen:

Da die Fläche eines Kreises Pi mal dem Quadrat des Radius ist, schreiben Sie eine Funktion, die sie berechnet.

Überraschenderweise konnte mehr als die Hälfte der Leute diese Funktion in keiner Sprache schreiben! Ach, Entwickler sollten Code schreiben können, und jetzt ist sogar das zu einer kontroversen Meinung geworden ...

19. Entwurfsmuster richten mehr Schaden an als Nutzen.

Softwaredesign, insbesondere gutes Softwaredesign, ist extrem vielfältig und lässt sich nicht sinnvoll durch Muster zusammenfassen, schon gar nicht durch die wenigen Muster, an die sich alle erinnern. Außerdem sind diese Muster zu abstrakt; tatsächlich erinnern sich nur wenige Menschen wirklich an viele davon. Entwurfsmuster sind also nicht besonders nützlich. Andererseits sind zu viele Menschen vom Konzept der Entwurfsmuster fasziniert und versuchen, sie überall einzusetzen – was zu Code führt, der oft fast kein Design enthält, außer einigen bedeutungslosen Singletons und abstrakten Fabriken.

20. Weniger Code ist besser.

Wenn Benutzer Ihre Arbeit nicht sehen können, ist das genau richtig. Der Ruhm liegt woanders.

Weitere beliebte Antworten sind:

21. Performance ist wirklich wichtig.

22. Unternehmensanwendungen sind lächerlich. n Jahre Erfahrung zu verlangen, ist Unsinn. Informatikstudiengänge sind reine Täuschung.

23. Unit-Tests helfen nicht, guten Code zu schreiben, und die meisten sogenannten Best Practices im Software Engineering dienen nur dazu, schlechte Programmierer daran zu hindern, zu viel Schaden anzurichten.

24. Jeder Programmierer sollte mit moderner Computerarchitektur vertraut sein.

25. Schreibe kleine Methoden.

26. PHP ist wirklich mies!

27. C++ ist eine der schlechtesten Sprachen überhaupt.

28. Die meisten professionellen Programmierer sind schlecht.

29. Um Programmierer zu werden, muss man zuerst Tippen lernen.

30. Je mehr Prozessregeln außerhalb der Programmierung, desto schlechter die Codequalität.

Der leitende Spieleprogrammierer James Hague (vom berühmten Blog Prog21) sah diesen Artikel ebenfalls und fand diese Meinungen nicht besonders kontrovers. Er schrieb einen Blogbeitrag und stellte Ansichten vor, die er für kontroverser hielt, von denen sich viele auf seine anderen zuvor veröffentlichten Artikel bezogen.

31. Informatik sollte nur als Nebenfach angeboten werden.

32. Neue Programmierer in objektorientierte Programmierung einzuführen, bevor sie verstehen, wie man Probleme zerlegt und Lösungen in Code umsetzt, ist ein großer Fehler.

33. Komplexe Compiler-Optimierungen sind nahezu wertlos, selbst wenn sie schnelleren Code erzeugen. Sie verlangsamen die Kompilierung stark und führen wahrscheinlich zu schwer zu behebenden Fehlern, was die Fehlersuche bei Leistungsproblemen zusätzlich erschwert.

34. Erlaube Personen mit weniger als zehn Jahren Programmiererfahrung nicht, Bibliotheken zu schreiben, die andere verwenden sollen. Ignoriere diese Regel und du wirst es dein Leben lang bereuen.

35. Ob der Code hässlich ist oder nicht, spielt keine Rolle. Ob er formatiert ist oder nicht, hat wenig damit zu tun, ob der Code funktioniert und zuverlässig ist; automatisierte Tools können die Formatierung übernehmen.

36. Reine funktionale Programmierung ist nicht sehr nützlich. Aber etwas davon in imperativen Code zu mischen, funktioniert recht gut.

37. Die etablierte Denkweise der Softwaretechnik wird dich tatsächlich daran hindern, großartige Werke zu schaffen.