it-swarm.com.de

Warum ist die Verwendung von Abstraktionen (wie LINQ) so tabu?

Ich bin ein unabhängiger Auftragnehmer und interviewe daher 3-4 Mal im Jahr für neue Auftritte. Ich bin jetzt mitten in diesem Zyklus und wurde für eine Gelegenheit abgelehnt, obwohl ich das Gefühl hatte, dass das Interview gut verlaufen ist. Das gleiche ist mir dieses Jahr ein paar Mal passiert.

Jetzt bin ich kein perfekter Typ und ich erwarte nicht, dass er zu jeder Organisation passt. Trotzdem ist mein Schlagdurchschnitt niedriger als gewöhnlich, also habe ich meinen letzten Interviewer höflich um konstruktives Feedback gebeten, und er hat geliefert!

Die Hauptsache laut dem Interviewer war, dass ich mich eher zu sehr auf die Verwendung von Abstraktionen (wie LINQ) als auf untergeordnete, organisch gewachsene Algorithmen zu konzentrieren schien.

An der Oberfläche macht dies Sinn - tatsächlich machten es auch die anderen Ablehnungen Sinn, weil ich auch in diesen Interviews über LINQ geredet habe und es schien, dass die Interviewer nicht viel über LINQ wussten (obwohl sie .NET waren Jungs).

Nun bleibt mir also die Frage: Wenn wir "auf den Schultern von Riesen stehen" und Abstraktionen verwenden sollen, die uns zur Verfügung stehen ( wie LINQ), warum halten es dann einige Leute für so tabu? Ist es nicht sinnvoll, Code "von der Stange" zu ziehen, wenn er dieselben Ziele ohne zusätzliche Kosten erreicht?

Es scheint mir, dass LINQ, selbst wenn es ist eine Abstraktion ist, einfach eine Abstraktion aller gleichen Algorithmen ist, die man schreiben würde, um genau dasselbe zu erreichen Ende. Nur ein Leistungstest kann Ihnen sagen, ob Ihr benutzerdefinierter Ansatz besser war, aber wenn so etwas wie LINQ die Anforderungen erfüllt, warum sollten Sie sich dann überhaupt die Mühe machen, Ihre eigenen Klassen zu schreiben?

Ich möchte mich hier nicht auf LINQ konzentrieren. Ich bin mir sicher, dass die Java Welt etwas Vergleichbares hat. Ich möchte nur wissen, warum es einigen Leuten so unangenehm ist, eine Abstraktion zu verwenden, die sie selbst nicht geschrieben haben.

AKTUALISIEREN

Wie Euphoric betonte, es gibt nichts Vergleichbares zu LINQ in der Welt Java. Wenn Sie also auf dem .NET-Stack entwickeln, warum versuchen Sie es nicht immer Ist es möglich, dass die Leute einfach nicht ganz verstehen, was es tut?

60
Matt Cashatt

Ich denke nicht, dass die Verwendung von Abstraktionen an sich zu beanstanden ist. Es gibt zwei weitere mögliche Erklärungen. Eine ist, dass Abstraktionen alle ndicht zu der einen oder anderen Zeit sind. Wenn Sie den Eindruck erwecken, richtig oder nicht, dass Sie die zugrunde liegenden Grundlagen nicht verstehen, kann dies in einem Interview schlecht wiedergegeben werden.

Die andere mögliche Erklärung ist der Fanboy-Effekt. Wenn Sie aufgeregt über LINQ sprechen und es wiederholt in einem Interview mit einem Unternehmen ansprechen, das es nicht verwendet und derzeit keine Pläne dazu hat, entsteht der Eindruck, dass Sie mit älteren Technologien unzufrieden oder sogar verärgert wären. Es kann auch den Eindruck erwecken, dass Ihre Begeisterung für ein Produkt Sie für Alternativen blind gemacht hat.

Wenn Sie wirklich glauben, dass Sie in einem Nicht-LINQ-Shop glücklich wären, fragen Sie, was sie verwenden , und passen Sie Ihre Antworten entsprechend an. Zeigen Sie ihnen, dass Sie zwar LINQ bevorzugen, aber mit allen verfügbaren Tools kompetent sind.

74
Karl Bielefeldt

Einige .NET-Programmierer, insbesondere solche mit einem klassischen VB/ASP- oder C++ - Hintergrund, mögen keine neuen Inhalte wie LINQ, MVC und Entity Framework.

Basierend auf dem, was ich beobachtet habe, verwenden die Ex-VB'er in dieser Gruppe wahrscheinlich immer noch Datenzugriffsschichten und anderen Code, der ursprünglich vor mehr als 10 Jahren geschrieben wurde. Sie verwenden auch alte Schlagworte wie "n-Tier" und dergleichen und verstehen überhaupt nichts über etwas anderes als .NET Framework 2.0 und möchten auch nichts darüber lernen.

Die C++ - Benutzer sind in der Regel akademisch orientierte Programmierer, die es lieben, coole Algorithmen zu programmieren, auch wenn dies bedeutet, das Rad neu zu erfinden. Sie hassen es, abhängig von allem, was sie selbst nicht codiert haben. Einige dieser Personen freuen sich auch darüber, dass sich die Befragten minderwertig fühlen, insbesondere diejenigen mit einem weniger traditionellen Hintergrund.

Sie werden wahrscheinlich auf solche Organisationen stoßen, wenn Sie ein Interview führen. Sie werden aber auch auf einige stoßen, die neuere Methoden verwenden. Lassen Sie sich nicht von ein paar schlechten Interviews abschrecken.

29
jfrankcarr

Microsoft hat eine lange Tradition darin, heiße neue Technologien herauszubringen und sie dann 5, 10 oder 20 Jahre später zu vergessen. LINQ könnte für manche Leute wie ein anderer aussehen. Sie werden feststellen, dass Microsoft SQL nicht verwerfen kann , aber LINQ könnte folgen Silverlight . Sie könnten also Paranoia sehen, die aus harten Erfahrungen resultiert, oder nur Menschen, die von moderner Technologie zurückgelassen wurden und sich darüber ärgern.

16
RalphChapin

Ist es nicht sinnvoll, Code "von der Stange" zu ziehen, wenn er dieselben Ziele ohne zusätzliche Kosten erreicht?

Es fallen immer zusätzliche Kosten an.

Die Lernkurve für Standardprodukte ist immer da. Der Schmerz, Updates (und Abhängigkeiten) zu erhalten, ist immer da. Die Unfähigkeit, mit den Eingeweiden herumzuschrauben, ist immer da.

Für LINQ gilt das erste nur wirklich. Viele Leute halten den "seltsam" aussehenden Code für schwer lesbar und schwerer zu debuggen. Die SQL-ähnliche Syntax ist bei jedem professionellen Auftritt, an dem ich seit dem Erscheinen gearbeitet habe, so ziemlich eine Persona-non-grata. LINQ to SQL (und andere Datenquellen) verfügen über eine Reihe von Fallstricken und eingeschränkte Optimierungsoptionen.

Dies sind die allgemeinen Argumente gegen Tools von Drittanbietern und speziell gegen LINQ. Alles in allem ist LINQ ein verdammt nützliches Werkzeug und sollte in den meisten Situationen bevorzugt werden. Weinen hier nicht erfunden, und Abstraktionen sollten nicht bevorzugt werden. Es riecht stark nach Cognative Dissonance .

Sie kennen/können LINQ nicht lernen, aber sie sind "offensichtlich" gute Entwickler, daher darf sich LINQ nicht lohnen. Es ist eine häufige Falle.

15
Telastyn

Etwas anderes, das Sie berücksichtigen sollten, ist, dass Ihre Begeisterung für eine coole neue Technologie einfach dazu führen kann, dass sich Menschen unwohl fühlen und Sie nicht in der Nähe haben möchten. Sie "befähigen" sie nicht, weil Sie diese Technologie kennen, nicht sie. Selbst wenn sie es selbst nicht merken, suchen sie möglicherweise Kandidaten, die das verstärken, in das sie bereits so viel Zeit investiert haben.

Sie möchten eine Haltung präsentieren, die besagt: "Was auch immer Sie tun, ich möchte Ihnen dabei helfen, es zu erreichen", anstatt einen Untertext anzugeben, der besagt: "Sie tun die Dinge möglicherweise schlecht, und wenn Sie mich bei sich haben, wird sich dies beweisen." es."

13
John Wiegley

Meine Meinung dazu (und TBH Ich vermute, weil keiner von uns sagen kann, was diese Interviewer gedacht haben) ist, dass Sie oft zu einem Interview gehen, um zu erklären, warum sie Sie einstellen sollten m in ihr Team, ihre Arbeitsweise zu passen.

Sie können der perfekte Entwickler sein, ein Rock-Start-Code-Gott, aber das bedeutet absolut nichts, wenn das, was Sie tun möchten (betont, dass Sie übermäßig und zu enthusiastisch über einige coole Technologie-Gubbins sprechen), ihnen einfach von Ihnen erzählt und Sie dies nicht tun würden passen zu dem, was sie wollen. Wenn sie über ein Datenzugriffssystem alten Stils verfügen, das aus irgendeinem Grund nicht aktualisiert werden kann, benötigen sie niemanden, der vergessen hat, wie es zu warten ist. Wenn sie neue Dinge entwickeln und Sie diese coole neue Technologie wirklich überall einsetzen möchten, ist es offensichtlich, dass sie ein großes Problem mit der zukünftigen Code-Wartung und/oder der Schulung der Mitarbeiter haben werden.

Als Freiberufler ist dies ein viel größeres Problem, als wenn sie eine Permie einstellen würden. Mit einer Erlaubnis sind Training und Entwicklung neuer Arbeitsweisen im Rahmen des vorhandenen Codes und der vorhandenen Praktiken keine schlechten Dinge - Sie werden lange Zeit da sein, um die Dinge besser zu machen. Mit einem Freiberufler geben sie wirklich keinen Schrei, was Sie wollen, Sie sind nur da, um ihre Arbeit so zu erledigen, wie sie es wollen, und es ist nicht Ihre Aufgabe, etwas anderes zu tun. (nicht einverstanden - fester Mitarbeiter werden)

Es hat wahrscheinlich nichts mit LINQ selbst zu tun. Ich habe einen Kandidaten abgelehnt, der aufgetaucht ist und erklärt hat, wie viel besser alles in Haskell geschrieben werden würde. Wir machen kein Haskell. Gleiches gilt für alle Technologien, die nicht von der Firma verwendet werden. Normalerweise ist dies kein Problem, wenn Sie sie als etwas Gutes bezeichnen. Das Problem tritt auf, wenn Sie zu enthusiastisch und scharf darauf sind.

12
gbjbaanb

Dieser wurde ein bisschen lang, aber er könnte für jemanden hilfreich sein, also lasse ich es sein.

Ich bin tatsächlich auf etwas Ähnliches gestoßen, als ich letzten Monat etwas mehr als 20 Interviews durchlaufen habe (eine Mischung aus Telefon und persönlichem Gespräch). Es war definitiv etwas Unerwartetes los, auf das ich nicht ganz eingehen konnte.

Eines der Dinge, die mir jedoch aufgefallen sind, war, dass die Dinge, die normalerweise im Mittelpunkt der Interviewzyklen der letzten fünf oder sechs Jahre standen, entschieden nicht besprochen oder kurz zusammengefasst wurden. Dinge wie die Grundlagen von OOP Analyse/Design, Muster (sowohl Design als auch Architektur), einige der fortgeschritteneren/abstraktionsorientierten .net-Funktionen (einschließlich Lambdas oder LINQ speziell, Generika, Serialisierung/Daten) verbindlich und ähnlich) und sogar das normalerweise heiße Thema der bevorzugten Methodik (niemand schien sich viel um Agilität oder Wasserfall zu kümmern oder welche Art von Agilität) und Tools oder die Wahl von ORM oder bevorzugten Mitteln für die Zusammenarbeit oder das Quellcodeverwaltungsmanagement Fälle überhaupt nicht erwähnt, in fast allen Fällen anscheinend nicht von Belang.

In mehreren Interviews und verschiedenen unabhängigen Unternehmen in unabhängigen Branchen wurde Folgendes in den Mittelpunkt gerückt:

  • Eine seltsame Fixierung auf veraltete/veraltete Konventionen und Einschränkungen "Zurück in die Steinzeit". Wie die Entwicklung einer primitiven Web-App in VS2003 mit einer Liste absurder Einschränkungen, die die Verwendung expliziter Funktionen in dieser Ära von .net weiter verbietet ... als ob dies ein echtes Maß für die Fähigkeit moderner Entwickler wäre ... die Fähigkeit, sich zu erinnern Das Paradigma und die Grenzen von vor 9 Jahren wurden durch unrealistische/willkürliche Zwänge weiter verkrüppelt. Ein anderer Ort war sehr hartnäckig in Bezug auf benutzerdefinierte Sammlungen, etwa vorgenerische Sammlungen. Ein anderer Ort hat ein Codebeispiel eines Klassenmodells erstellt, das ich herausgezeichnet habe, weil ich keine kaskadierten Konstruktoren verwendet habe (sie schienen sich der Unterstützung für die Eigenschaftsinitialisierung bei der Deklaration nicht bewusst zu sein, die für die Notwendigkeit ausreichend war). Ein anderer Ort war groß für Delegierte und mochte meine Antwort nicht, dass ich sie häufig deklariert habe, aber ich muss sie dank Action <> und Func <> praktisch nie mehr deklarieren.

  • Extremer Fokus auf bestimmte Implementierungsdetails in einem Mikrokosmos und/oder Konfigurationseinstellungen, selbst bei Technologien, die sich darauf konzentrieren, plattform- oder protokollunabhängig zu sein (dh der springende Punkt ist, NICHT auf eine bestimmte Implementierung oder bestimmte Verwendung fixiert zu werden, sondern vielmehr bei Wiederverwendung/Wiederverwendung/Erweiterbarkeit/nach Bedarf Integration).

  • Bereitschaft zur Spezifikation/Überwachung/Codeüberprüfung/und anderweitige Abspaltung der Arbeit an und von einem Offshore-Team sowie damit verbundene nicht-codierende Fähigkeiten.

  • Verwendung bestimmter Versionen von Produkten/Plattformen/Modulen/usw. In einem manchmal absurden Ausmaß; "Also ... Sie haben die Versionen 1, 2 und 4 verwendet? Aber nicht 3, wie? Hmmm ... {kommentiert Ihren Lebenslauf mit" no v3 !!!} ". Der Nutzungsgrad schien keine Rolle zu spielen. nur, dass Sie etwas verwendet haben oder nicht überhaupt und die spezifische Sache, nach der sie auch fragen ... keine Substitutionen schienen zu zählen, selbst bei einem weiter verbreiteten und voll ausgestatteten Konkurrenzprodukt.

  • Ein weitaus größerer Fokus auf "Wie gut passen Sie in unser Team?" Über "Sind Sie eigentlich ein guter Softwareentwickler?" Oder "Haben Sie die Fähigkeiten und die Erfahrung, um dem Unternehmen einen Mehrwert zu verleihen und uns zu helfen, eine Qualität zu liefern?" Produkt "oder sogar" sind Sie ein gefährlicher Idiot, der hereinkommt und den Laden ruiniert ". In einigen Fällen wurde mein Lebenslauf nur als gegeben angesehen, und selbst der sogenannte "Tech Screen" oder das technische Interview war weit mehr eine Beurteilung der Persönlichkeit als eine Beurteilung der Fähigkeiten. Selbst für relativ kurzfristige Vertragspositionen, bei denen Sie vor zwei Spielzeiten wieder da wären.

  • Diesmal schienen sich die Unternehmen weniger darauf zu konzentrieren, bestimmte technische Probleme zu lösen, neue Green-Field- oder große 2.0-Entwicklungsprojekte zu starten oder ein bestimmtes Produkt auf den Markt zu bringen, um von einem aufkommenden Trend oder einer sich bietenden Gelegenheit oder den üblichen großen Kickoffs zu profitieren . Ein sich wiederholendes Thema, das mir an mindestens 15 Stellen aufgefallen ist, war, dass eine kleine Gruppe von 3-5 Entwicklern, hauptsächlich Überlebende des Marktcrashs im Jahr 08, in den letzten 3 Jahren ein Produkt mahlen konnte und fanden einige Erfolge oder ihr Unternehmen als Ganzes boomt und sie stellen neue Leute ein, um mit den steigenden Anforderungen an Funktionen Schritt zu halten oder die Designfehler, die sie in diese Systeme eingebaut haben, zu beheben/zu überwinden oder die oben genannten Plattformen kostenlos zu übernehmen das Kernteam aufbauen, das es für "andere Projekte" aufgebaut hat. Die Details waren unterschiedlich und es gab Ausnahmen, aber diesmal war dies die allgemeine Lage des Landes.

Aber ... wenn ich etwas über dieses Geschäft weiß, dann ist es, dass es zyklisch ist. Wenn ich das nächste Mal nach einem neuen Auftritt suche, bin ich nicht überrascht, wenn sich das Spiel noch einmal geändert hat. Sie müssen nur mental flexibel bleiben, aktiv zuhören, absolute Aussagen vermeiden, wenn sie unnötig sind, aber auch kein Wiesel sein, und nicht als eindimensional abschneiden (Sie kommen als Idiot oder ein Eiferer, weder wünschenswert) noch auch gut (es kann bedrohlich sein und dich einen Auftritt kosten).

Passen Sie einfach Ihren Ansatz an und versuchen Sie, beim nächsten Mal eine maßvollere Antwort zu geben ... erwähnen Sie einige verschiedene Möglichkeiten, wie Sie sich einem Problem nähern könnten ... aber selbst wenn es auswendig ist, tun Sie so, als würden Sie tatsächlich darüber nachdenken und es sofort zu überlegen. Auf diese Weise wirkt es bescheidener und weniger einschüchternd oder abstoßend.

Natürlich ist Murphys Gesetz das, was es ist. Das nächste Interview, nachdem Sie aufgehört haben, "leidenschaftlich über meinen aktuellen Lieblingstechnologietyp" zu sein und eine ausgeglichenere/bartstreichelnde Haltung einnehmen, ist der Auftritt, den Sie würden Haben Sie bekommen, wenn Sie der verrückte Eiferer gewesen wären. ;)

Es gibt eine berechtigte Sorge, die ich von denen gehört habe, die Linq nicht verwenden, und die ich mir zu Herzen nehme: "Nur weil Sie die Implementierung nicht sehen können, heißt das nicht, dass sie nicht teuer ist.".

Nehmen Sie den folgenden Ausschnitt:

var resultList = inputList.Where(i=>otherInputList.Count(o=>o.Property == i.OtherProperty) > 0);

Die hier initiierten LINQs kriechen. Warum? Denn nur weil dieser Code schön und elegant aussieht, heißt das nicht, dass er nicht schrecklich ineffizient ist. Count () wertet mit einem Prädikat jedes Element seiner übergeordneten Aufzählung aus und fasst die Zeiten zusammen, zu denen das Prädikat true zurückgegeben hat. Dies ist also nicht nur N ^ 2 (wenn inputList und otherInputList ungefähr die gleiche Kardinalität N haben), es ist auch der absolute Worst-Case N ^ 2; JEDES Element von otherInputList wird für JEDES Eingabeelement durchlaufen. Stattdessen besteht der erste Schritt darin, Any () anstelle von Count zu verwenden, da dies wirklich das ist, was Sie wissen möchten, und es wird beendet, sobald bekannt ist, dass die Antwort "Ja" lautet. Einrichten eines HashSet, in dem unterschiedliche Werte von otherInputListObject.OtherProperty könnte dir auch helfen; Der Zugriff wird zu O(1) anstelle von O (N). Für anfängliche lineare Einrichtungskosten reduzieren Sie die gesamte Operation auf linear Worst-Case Komplexität statt quadratisch Best-Case Komplexität.

Wir sehen also, dass diese eleganten Methoden von Nice erhebliche Kosten verursachen. Wenn Sie nicht wissen, wie hoch diese Kosten sind, können Sie ganz einfach ein O codieren (my GD) -Komplexitätsalgorithmus in den leistungsstarken zentralen Dateiservicer oder die Hauptzielportalseite Ihres potenziellen Arbeitgebers, wenn dieser das nächste Mal eine Optimierung benötigt. Wenn Sie entlassen werden, nachdem Sie dies getan haben, wird das, was Sie getan haben, nicht rückgängig gemacht, aber wenn Sie nicht eingestellt werden, wenn sie glauben, dass Sie es tun würden, würde dies verhindert. Um dies zu vermeiden, müssen Sie ihnen das Gegenteil beweisen. Besprechen Sie, was diese Methoden bewirken (was bedeutet, dass Sie sich selbst kennen müssen) und wie komplex sie sind und wie Sie in einer effizienten Zeit (NlogN oder besser) zur Antwort gelangen.

Ein weiteres Problem ist das gute alte Argument "Wenn Ihr einziges Werkzeug ein Hammer ist". Stellen Sie sich an die Stelle des Interviewers, der diesen Linq-Fanboy interviewt. Der Kandidat mag Linq, will es benutzen, findet es das Beste, was es je gab. Es könnte sogar scheinen, dass der Kandidat ohne ihn nicht codieren könnte, da jedes gegebene Programmierproblem mit Linq gelöst wurde. Was passiert, wenn es nicht verwendet werden kann? Es gibt immer noch viel .NET 2.0-Code, der bei einem Upgrade schmerzhafte Upgrades auf Server, Benutzerarbeitsstationen usw. usw. erfordern würde, damit Sie Ihre ausgefallenen Erweiterungsmethoden verwenden können. Als Interviewer würde ich versuchen, Sie dazu zu bringen, zu zeigen, dass Sie eine effiziente Sortierung codieren oder die 2.0-Sortiermethoden verwenden könnten, wenn Sie müssten, egal wie sehr ich Ihnen zustimmen könnte, dass die Linq-Bibliotheken und ähnliche Erweiterungsmethoden hübsch sind Süss. Ein Interviewer, der den Punkt nicht versteht, könnte sich nicht einmal die Mühe machen, Sie dazu zu bringen, Eignung für etwas anderes zu zeigen. Sie werden annehmen, dass Sie es nicht haben und weitermachen.

10
KeithS

Ich denke, Sie ziehen eine falsche Schlussfolgerung, weil Ihre Stichproben zu begrenzt sind. Obwohl ich einen fairen Anteil von IT-Shops mit starker Abneigung gegen alles gesehen habe, was "dort nicht erfunden" wurde.1Keiner von ihnen würde Kandidaten aufgrund ihrer Präferenzen im Technologie-Stack disqualifizieren: Sie waren zu Recht davon überzeugt, dass sie den richtigen Kandidaten für die Nutzung ihrer eigenen Bibliotheken unterrichten könnten.

Ich bezweifle ernsthaft, dass das Unternehmen die Verwendung von LINQ vollständig verboten hat. Wahrscheinlicher wollten sie, dass Sie ihnen Ihre Fähigkeiten auf einer tieferen Ebene zeigen.

Eine Möglichkeit, um herauszufinden, ob Sie Ihre Hash-Tabellen kennen, besteht darin, Sie zu bitten, eine primitive Tabelle auf einem Whiteboard zu implementieren. Diese einfache Übung enthüllt dem Prüfer eine überraschende Menge an Daten über Ihr Wissen: Er erfährt sofort, ob Sie über Hash-Code/Equals Bescheid wissen und was Sie über Hash-Kollisionen wissen. Gleichzeitig ist es schwer vorstellbar, dass jemand, der bei klarem Verstand ist, eine Hash-Tabelle erneut implementiert, weil Microsoft so gute Arbeit geleistet hat. Gleiches gilt für viele Algorithmen wie Sortieren und Suchen: Interviewer möchten häufig wissen, ob Ihr Hintergrund ausreicht, um Interaktionen auf niedriger Ebene zu verstehen, anstatt zu überprüfen, ob Sie über Kenntnisse in .NET-Bibliotheken verfügen.

Es ist nahezu sicher, dass sie darauf bestehen darauf, dass Sie Bibliotheksimplementierungen anstelle Ihrer eigenen verwenden, sobald Sie eingestellt werden, um für ihr Unternehmen zu arbeiten. Aber während des Interviews würden sie Sie in Richtung des Low-Level-Codes drängen, um ein besseres Verständnis Ihrer wahren Fähigkeiten zu erlangen.


1
6
dasblinkenlight

Ich denke, Sie machen dort einige verrückte Verallgemeinerungen vom Typ "Ich habe eine schwarze Kuh in Schottland gesehen, also sind alle schottischen Kühe schwarz".

Wenn ich Sie interviewen würde, wäre ich enttäuscht, wenn Sie meine Linq-Fragen nicht beantworten könnten.

Linq ist allerdings eine heikle Angelegenheit, viele Leute sehen es als Voodoo an, was unfair ist, da es eigentlich sehr einfach und umso klüger ist.

4
Ian

Um Devil's Advocate zu spielen, ist der Grund, dass sich viele Entwickler einfach nicht um neue Dinge kümmern und denken, dass alles mit hausgemachten (normalerweise minderwertigen) Tools gelöst werden muss. Es ist nichts Falsches daran, Abstraktionen zu verwenden. Zur Hölle, normalerweise gibt es keinen guten Grund nicht diese Abstraktionen zu verwenden.

Es hört sich so an, als hätten Sie gerade ein Interview mit einem armen Entwickler geführt, der nicht auf dem neuesten Stand ist und bei allem den Hammer-und-Nagel-Ansatz verfolgt. Dies sind die Entwicklertypen, die nichts über hilfreiche Open Source-Tools wie NUnit oder NHibernate oder die verschiedenen IoC-Container wissen. diejenigen, die versuchen, jedes Problem mit einem massiven gespeicherten Prozess in der Datenbank zu lösen; diejenigen, die absolut nichts über MVC wissen, obwohl es seit einigen Jahren nicht mehr erhältlich ist.

3
Wayne Molina