Haben wir aufgegeben die Idee der Wiederverwendung von code?

https://stackoverflow.com/questions/356275

21-08-2019
|

Frage

Vor ein paar Jahren waren die Medien voll mit allen möglichen Artikeln wie die Idee der Wiederverwendung von code war ein einfacher Weg, um die Produktivität zu verbessern und code-Qualität.

Aus den blogs und Seiten, die ich regelmäßig überprüfen es scheint, als ob die Idee von "code reuse" ist aus der Mode gekommen.Vielleicht ist der 'code Wiederverwendung " befürwortet haben alle trat in die SOA-Publikum statt?:-)

Interessanterweise, wenn Sie suchen, für "code-Wiederverwendung" in Google die zweite Folge trägt den Titel:

"Interne Wiederverwendung Von Code Als Gefährlich"!

Für mich die Idee der Wiederverwendung von code ist nur der gesunde Menschenverstand, nach der alle Blick auf der Erfolg des apache-commons-Projekt!

Was ich wissen möchte ist:

Haben Sie oder Ihr Unternehmen versuchen, die Wiederverwendung von code?
Wenn ja, wie und auf welcher Ebene, d.h.low-level-api, Komponenten oder shared business logic?Wie haben Sie oder Ihr Unternehmen die Wiederverwendung von code?
Funktioniert es?

Diskutieren?

Ich bin mir völlig bewusst, dass es viele open-source-Bibliotheken zur Verfügung und, wer hat, verwendet .NET oder Java wiederverwendet-code in irgendeiner form., Dass ist der gesunde Menschenverstand!

Ich bezog mich mehr auf die Wiederverwendung von code innerhalb einer Organisationen, sondern über eine Gemeinschaft, die über eine shared lib, etc.

Ich ursprünglich gefragt;

Haben Sie oder Ihr Unternehmen versuchen, die Wiederverwendung von code?
Wenn ja, wie und auf welcher Ebene, d.h.low-level-api, Komponenten oder shared business logic?Wie haben Sie oder Ihr Unternehmen die Wiederverwendung von code?

Von wo ich Sitze ich sehe nur sehr wenige Beispiel von Firmen, die versuchen, die Wiederverwendung von code intern?

Wenn Sie ein Stück von code, die möglicherweise geteilt werden, die über ein medium Größe Organisation wie würden Sie gehen über die anderen Mitglieder der Gesellschaft, die diese lib/api/etc existierte und von nutzen sein konnte?

Lösung

Der Titel des Artikels, den Sie sich beziehen, ist irreführend, und ist eigentlich ein sehr gutes Buch. Wiederverwendung von Code ist sehr vorteilhaft, aber es gibt Nachteile mit allem. Grundsätzlich, wenn ich mich richtig erinnere, der Kern des Artikels ist, dass Sie den Code in einem schwarzen Kasten abdichten und nicht erneuten Besuch, um die ursprünglichen Entwickler verlassen Sie das Wissen verlieren. Während ich den Punkt sehen, muß ich nicht damit einverstanden ist -. Zumindest nicht in einen „Himmel fällt“ regard

Wir haben eigentlich Gruppe die Wiederverwendung von Code in mehr als nur wiederverwendbare Klassen, schauen wir auf das gesamte Unternehmen. Dinge, die eher wie Rahmenverstärkung oder Adresse Querschnittsthemen sind in einen Entwicklungsrahmen setzen, die alle unsere Anwendungen sind (man denke an Dinge wie Pre- und Post-Validierung, Logging etc.). Wir haben auch die Geschäftslogik, die auf mehr als eine Anwendung anwendbar ist, so dass diese Art von Dingen zu einem BAL Kern erhalten bewegt, die überall zugänglich ist.

Ich denke, dass das Wichtigste ist, die Dinge nicht für die Wiederverwendung zu fördern, wenn sie nicht wieder verwendet, um wirklich sein werden. Sie sollten gut dokumentiert werden, so dass neue Entwickler eine Ressource kann bis sie ihre Geschwindigkeit kommen zu helfen, wie gut. Die Chancen stehen gut, wenn das Wissen nicht mit anderen geteilt wird, wird der Code schließlich woanders neu erfunden werden und wird zu Überschneidungen führen, wenn Sie in der Dokumentation und Wissensaustausch nicht streng sind.

Andere Tipps

Wir reuse-code - in der Tat, unsere Entwickler explizit code schreiben, können in anderen Projekten wiederverwendet werden.Dies hat sich ausgezahlt, sehr schön - wir sind in der Lage zu starten neue Projekte schnell, und wir iterativ verhärten unsere core-Bibliotheken.

Aber man kann nicht einfach nur code schreiben und erwarten, dass es wieder verwendet werden; die Wiederverwendung von code erfordert Kommunikation zwischen den Teammitgliedern und andere Benutzer, damit die Leute wissen, was code ist, und wie es zu benutzen.

Folgende Dinge sind notwendig für die Wiederverwendung von code, um effektiv zu arbeiten:

Den code oder die Bibliothek selbst
Die Nachfrage für den code über mehrere Projekte oder Bemühungen
Kommunikation des code-Funktionen/Fähigkeiten
Anweisungen auf wie zu verwenden die code
Eine Verpflichtung zur Aufrechterhaltung und Verbesserung der code im Laufe der Zeit

Wiederverwendung von Code ist von wesentlicher Bedeutung. Ich finde, dass es zwingt mich auch so viel wie möglich zu verallgemeinern, auch anpassungsfähiger an unterschiedliche Situationen machen Code. Im Idealfall sollten Sie fast jede untere Ebene Bibliothek schreiben der Lage sein, eine neue Reihe von Anforderungen für eine andere Anwendung anzupassen.

Ich denke, die Wiederverwendung von Code durch Open-Source-Projekte zum größten Teil getan. Alles, was wiederverwendet werden kann oder erweitert wird über Bibliotheken durchgeführt. Java hat eine erstaunliche Anzahl von Open-Source-Bibliotheken für eine Vielzahl von Dingen zu tun. Vergleichen Sie das mit C ++, und wie früh auf alles werden müsste von Grund auf neu implementiert MFC oder die Win32-API.

Wir Wiederverwendung Code.

Im kleinen Maßstab versuchen wir Code-Duplizierung so viel wie posible zu vermeiden. Und wir haben eine komplette Bibliothek mit vielen häufig verwendeten Code.

Normalerweise Code wird für eine Anwendung entwickelt. Und wenn es allgemein genug ist, wird es in die Bibliothek gefördert. Das funktioniert ausgezeichnet.

Die Idee der Wiederverwendung von Code ist nicht mehr eine neue Idee ... daher auch der scheinbare Mangel an Interesse. Aber es ist immer noch sehr gute Idee. Der gesamte .NET-Framework und die Java API sind gute Beispiele für die Wiederverwendung von Code in Aktion.

Wir haben auf die Entwicklung OO Bibliotheken von Code für unsere Projekte gewöhnt und sie in anderen Projekten wiederzuverwenden. Es ist ein Teil des natürlichen Lebenszyklus einer Idee. Es wird heiß für eine Weile diskutiert und dann jeder akzeptiert und es gibt keinen Grund für die weitere Diskussion.

Natürlich wieder verwenden wir Code.

Es gibt eine nahezu unendliche Menge an Paketen, Bibliotheken und gemeinsame Objekte zur Verfügung für alle Sprachen, mit ganzen Gemeinden von Entwicklern Behing sie zu unterstützen und aktualisiert werden.

ich glaube, der Mangel an „Aufmerksamkeit der Medien“ auf die Tatsache zurückzuführen ist, dass jeder es tut, so ist es nicht mehr wert zu schreiben. Ich höre nicht so viele Menschen das Bewusstsein für Objektorientierte Programmierung Anheben und Unit-Tests, wie ich entweder verwendet. Jeder ist bereits bekannt, diese Konzepte (ob sie sie nutzen oder nicht).

Stufe der Aufmerksamkeit der Medien auf ein Thema wenig mit seiner Bedeutung zu tun, ob wir Software-Entwicklung oder Politik reden! Es ist wichtig, Entwicklungsaufwand zu vermeiden Verschwendung von neu zu erfinden (oder wieder Aufrechterhaltung!) Das Rades, aber das ist so bekannt, inzwischen, dass ein Redakteur wahrscheinlich von einem anderen Artikel über das Thema nicht aufgeregt in Gang zu bringen.

Anstatt auf die Anzahl der aktuellen Artikel und Blog-Posts als Maß für die Wichtigkeit (oder Dringlichkeit) auf der Suche Blick auf die Konzepte und Buzz-Phrasen, die Klassiker oder trat in den Jargon (eine andere Form der Wiederverwendung!) Geworden sind, zum Beispiel, Google für die Nutzung des DRY Akronym für eine gute Diskussion über die vielen Formen der Redundanz, die in Software und Entwicklungsprozesse beseitigt werden können.

Es gibt auch eine Rolle für die reife Urteil in Bezug auf Kosten der Wiederverwendung vs. wo die Vorteile erreicht werden. Einige Autoren befürworten warten um die Wiederverwendung zu sorgen, bis eine zweite oder dritte Anwendung tatsächlich entsteht, anstatt Aufwand Ausgaben wenig Code zum ersten Mal zu verallgemeinern es geschrieben wird.

Meine persönliche Ansicht, auf der Grundlage der Praxis in meiner Firma:

Haben Sie oder Ihr Unternehmen versuchen und Code wiederverwenden?

Selbstverständlich, wenn wir noch ein Stück Code haben, der bereits unsere Bedürfnisse passt werden wir es wieder verwenden. Wir gehen nicht von unserem Weg, obwohl quadratische Pflöcke in runden Löchern zu verwenden.

Wenn ja, wie und auf welcher Ebene, das heißt niedriges Niveau api, Komponenten oder gemeinsam genutzten Business-Logik? Wie tun Sie oder Ihr Unternehmen Wiederverwendung Code?

Auf jeder Ebene. Es ist in unsere Coding-Standards geschrieben, die Entwickler immer ihr Code wird wiederverwendet annehmen sollten - auch wenn in Wirklichkeit, die höchst unwahrscheinlich ist. Siehe unten

Wenn Ihr OO-Modell ist gut, Ihr API spiegelt wahrscheinlich Ihren Business-Bereich, so dass wieder verwendbare Klassen entsprechen vermutlich wieder verwendbare Business-Logik ohne zusätzlichen Aufwand.

Für tatsächliche Wiederverwendung, ein wichtiger Punkt ist, zu wissen, welchen Code bereits vorhanden ist. Wir können dieses Problem beheben, indem sie alles in einer zentralen Stelle dokumentiert hat. Wir brauchen nur ein wenig Disziplin, um sicherzustellen, dass die Dokumentation ist up-to-date und durchsuchbare in einer sinnvollen Art und Weise.

Funktioniert es?

Ja, aber nicht wegen der möglichen oder tatsächlichen Wiederverwendung! In Wirklichkeit jenseits einigen Kernbibliotheken und UI-Komponenten, gibt es nicht eine große Menge an Wiederverwendung.

In meiner persönlichen Meinung nach, der reale Wert ist, den Code bei der Herstellung von wieder verwendbaren . Dabei abgesehen von einer hoffentlich Reiniger API, wird der Code (a) ausreichend für einen anderen Entwickler dokumentiert werden es zu verwenden, ohne den Quellcode zu Schleppen , und (b) es wird auch sein austauschbar . Diese Punkte sind ein großer Vorteil für die laufende Software-Wartung.

Während ich die Wiederverwendung von Code denken wertvoll ist, kann ich sehen, wo dieses Gefühl wurzelt. Ich habe an vielen Projekten gearbeitet, wo viel zusätzliche Pflege genommen wurde wiederverwendbaren Code zu erstellen, die dann nie wieder verwendet. Natürlich Wiederverwendung ist sehr bevorzugt, Code zu duplizieren, aber ich habe eine Menge sehr extenisve Objektmodelle mit dem Ziel, mit Hilfe der Objekte im gesamten Unternehmen in mehreren Projekten (Art der Art und Weise der gleiche Dienst in SOA in verschiedenen kann verwendet werden, erstellt gesehen Apps), aber haben die Objekte eigentlich nie mehr als einmal verwendet gesehen. Vielleicht habe ich einfach nicht Teil der Organisationen war gut Vorteil des Prinzips der Wiederverwendung nehmen.

Die beiden Software-Projekte, die ich auf langfristige Entwicklung haben beide gewesen gearbeitet habe. Eine davon ist etwa 10 Jahre alt, der andere gibt es schon seit mehr als 30 Jahren neu geschrieben in ein paar Versionen von Fortran auf dem Weg. Beide machen umfangreiche Wiederverwendung von Code, aber beide verlassen sich sehr wenig auf externe Tools oder Code-Bibliotheken. DRY ist ein großes Mantra auf dem neueren Projekt, das in C ++ und eignet sich leichter an, dass in der Praxis zu tun.

Vielleicht ist die bessere Frage ist, wann wieder verwenden Code, den wir nicht in diesen Tagen? Wir sind entweder in einem Zustand auf den Aufbau mit jemand anderem beobachtet „best practices“ oder prediscovered „Design Patterns“ oder einfach nur tatsächlich bauen auf Legacy-Code, Bibliotheken oder Kopieren.

Es scheint den Grad, in dem Code A wiederverwendet wird, um Code B zu machen oft um basierte, wie sehr die Ideen in Code A, Code B genommen werden abstrahiert in Design Patterns / Idiome / Bücher / flüchtige Gedanken / Ist-Code / Bibliotheken. Der schwierige Teil ist all diese guten Ideen zu Ihrem eigentlichen Code in der Anwendung.

Nicht-technische Typen übereifrig über die Wiederverwendung Sache. Sie verstehen nicht, warum alles kann nicht kopier eingefügt werden. Sie verstehen nicht, warum der greemelfarm einen speziellen Adapter benötigt die gleichen Informationen zu kommunizieren, dass es früher zum alten System auf das neue System, und das können wir leider auch nicht aufgrund einer Unmenge von anderen Gründen ändern.

Ich denke, Techies von Tag 1 in der gleichen Art und Weise Musiker Wiederverwendung wurden von Tag 1. Sein eine laufende organischen Entwicklung und sythesis Wiederverwendung wurden die laufenden halten.

Wiederverwendung von Code ist ein äußerst wichtiges Thema -., Wenn der Code nicht wiederverwendet wird, Projekte dauern länger und härter für neue Teammitglieder in erhalten
Jedoch wieder verwendbaren Code zu schreiben dauert länger.

Ich persönlich versuche, meinen Code alle in einer wieder verwendbaren Weise zu schreiben, dauert dies länger, aber es ergibt sich die Tatsache, dass die meisten meiner Code offiziellen Infrastrukturen in meiner Organisation und neue Projekte auf der Grundlage dieser Infrastrukturen nehmen deutlich weniger Zeit geworden ist. < br>
Die Gefahr Code in der Wiederverwendung, ist, wenn der wiederverwendet Code nicht als Infrastruktur geschrieben - in einer allgemeinen und verkapselt Weise mit möglichst wenig Annahmen und so viel wie möglich Dokumentation und Unit-Tests, dass der Code kann bis zu tun unerwartete Dinge beenden.
Auch, wenn Fehler gefunden und behoben oder Funktionen hinzugefügt, werden diese Änderungen nur selten auf den Quellcode zurück, in verschiedenen Versionen des wiederverwendeten Code führt, dass niemand weiß oder versteht.

Die Lösung lautet:
1. Zur Gestaltung und den Code nicht nur ein Projekt im Sinne zu schreiben, aber die zukünftigen Anforderungen zu denken und versuchen, das Design flexibel genug, um sie mit einem minimalen Codeänderung zu decken.
2. Um den Code in Bibliotheken einschließen, die verwendet werden sollen, wie sie ist und nicht innerhalb von mit Projekten modifiziert.
3. Damit Benutzer den Code der Bibliothek withing seine Lösung (nicht innerhalb des mit Projekt-Lösung) anzuzeigen und zu ändern.
4. Um zukünftige Projekte zu entwerfen auf der Basis der bestehenden Infrastrukturen werden, um die Infrastrukturen wie nötig Änderungen vornehmen.
5. Laden Sie die Infrastruktur für alle Projekte aufrechterhalten wird, damit die Infrastruktur zu halten finanziert.

Haben Sie oder Ihr Unternehmen versuchen und Code wiederverwenden? Wenn ja, wie und in welcher Ebene, das heißt niedriges Niveau api, Komponenten oder gemeinsam genutzten Business-Logik? Wie macht Sie oder Ihr Unternehmen Wiederverwendung Code?

habe ich in einer Code-Basis mit uber der Wiederverwendung von Code zu arbeiten, aber es war schwierig, zu halten, weil der wiederverwendet Code instabil war. Es war anfällig Änderungen zu entwerfen und deprecation in einer Weise, die alles kaskadiert es zu benutzen. Davor arbeitete ich in einem Code-Basis ohne die Wiederverwendung von Code, wo die Senioren tatsächlich das Kopieren und Einfügen als eine Möglichkeit ermutigt, auch anwendungsspezifischen Code wiederverwenden, so habe ich die beiden Extremitäten zu sehen und ich muss sagen, dass man nicht unbedingt viel ist besser als die andere, wenn auf die Spitze genommen.

Und ich habe eine uber Bottom-up Art von Programmierer zu sein. Sie fragen mich, etwas Bestimmtes zu bauen und ich am Ende den Aufbau verallgemeinert Werkzeuge. Dann diese Tools verwenden, ich komplexeren generali Werkzeuge bauen, dann starten DIP Abstraktionen Aufbau der Design-Anforderungen für die untergeordneten Werkzeuge zum Ausdruck bringen, dann baue ich noch komplexere Werkzeuge und wiederholen, und irgendwann ich Code Schreiben beginnen, die tatsächlich funktioniert Was willst du, das ich mache. Und als kontraproduktiv, wie das klang, war ich ziemlich schnell auf sie und konnte komplexe Produkte in einer Weise, Schiff, das wirklich überraschen Menschen.

Das Problem war die Wartung im Laufe der Monate, Jahre! Nachdem ich Schichten und Schichten dieser verallgemeinerten Bibliotheken gebaut und wiederverwendet die Hölle aus ihnen, wollte jeder einen viel größeren Zweck als dienen, was Sie mich gebeten, zu tun. Jede Schicht wollte die Welt Hunger Bedürfnisse lösen. So war jeder sehr ehrgeizig: eine mathematische Bibliothek, die erstaunlich sein will und lösen den Hunger Bedarf der Welt. Dann etwas auf der Mathematik-Bibliothek wie eine Geometrie-Bibliothek aufgebaut, die erstaunlich sein will und die Hunger Bedarf der Welt zu lösen. Sie wissen, dass etwas falsch ist, wenn Sie versuchen, ein Produkt zu versenden, aber dein Geist grübelt, wie gut Ihr uber-verallgemeinert Geometriebibliothek arbeitet für die Darstellung und Modellierung, wenn man eigentlich gerade arbeiten Animation werden, weil die Animation Code, den Sie gerade arbeiten auf Bedürfnisse ein paar neue Geometriefunktionen.

Balancing alle Bedürfnisse

fand ich diese uber-verallgemeinert Bibliotheken bei der Gestaltung, die ich mit den Bedürfnissen jedes einzelnen Teammitglied besessen werden musste, und ich musste lernen, wie Raytracing gearbeitet, wie Flüssigkeiten Dynamik gearbeitet, wie das Netz Motor gearbeitet, wie inverse Kinematik arbeitete, wie Charakter-Animation gearbeitet, etc. etc. etc. ich musste lernen, wie so ziemlich jeder Job im Team zu tun, weil ich alle ihre spezifischen Bedürfnisse in der Gestaltung dieser uber generali Bibliotheken, die ich zurückgelassen balancieren, während ein Fuß Drahtseilakt Design Kompromisse von allen der Wiederverwendung von Code Ausgleich (versuchen, die Dinge besser zu machen für Bob arbeitet an Raytracing, die eine der Bibliotheken verwendet, aber ohne zu verletzen John zu viel, die auf Physik arbeitet, die sie auch mit, aber ohne das Design verkomplizieren von der Bibliothek zu viel, sie beide glücklich zu machen).

Es kam zu einem Punkt, wo ich Begrenzungskästen mit politischen Klassen zu parametrisieren versuche, so dass sie entweder als Zentrum und halbe Größe gespeichert werden könnten, wie eine Person wollte oder min / max Ausmaße wie jemand andere wollte, und die Umsetzung war immer sehr schnell gefaltet versucht, mit allen Bedürfnissen hektisch zu halten.

Entwurf durch Ausschuß

Und weil jede Schicht eine so breite Palette von Bedürfnissen zu dienen versucht (viel breiter als wir tatsächlich erforderlich), fanden sie Designänderungen viele Gründe, zu verlangen, die manchmal durch Ausschuss angeforderten Designs (die in der Regel grobe Art sind). Und dann würden diese Designänderungen Kaskade nach oben und wirken sich auf alle übergeordneten Code es, und die Wartung eines solchen Codes begann eine echte PITA zu werden.

Ich glaube, Sie können möglicherweise mehr Code in einer gleichgesinnten Team teilen. Unseres war nicht gleichgesinntenüberhaupt. Dies sind keine echten Namen, aber ich habe Bill hier, der ist ein High-Level-GUI-Programmierer und Scripter, die netten User-End-Design, aber fragwürdigen Code mit vielen Hacks schafft, aber es neigt dazu, für diese Art von Code in Ordnung zu sein. Ich habe hier Bob, der ein Oldtimer ist, die seit der Lochkarte Ära Programmierung wurde die 10.000 Linienfunktionen mit gotos in sie schreiben mag und noch nicht den Punkt der objektorientierten Programmierung bekommt. Ich habe hier Joe, der wie ein mathematischer Assistent ist aber schreibt Code sonst niemand verstehen kann und immer Vorschläge machen, die mathematisch ausgerichtet sind, aber nicht unbedingt so effizient aus einem rechnerischen Standpunkt. Dann habe ich Mike hier, die im Weltraum ist, die uns in den Hafen will die Software auf iPhones und meint, wir sollten alle folgen Apples Konventionen und technischen Standards.

Der Versuch, die Bedürfnisse aller hier zu befriedigen, während sie mit einem anständigen Design kommen war, wahrscheinlich im Nachhinein unmöglich. Und in jeder versucht jeder des anderen Code zu teilen, ich glaube, wir wurden kontraproduktiv. Jede Person war kompetent in einem Gebiet, sondern versucht, mit Motiven zu kommen und Standards, die alle mit nur alle Arten von Instabilität führen glücklich sind und verlangsamte alle nach unten.

Abwägungen

So in diesen Tagen habe ich festgestellt das Gleichgewicht ist die Wiederverwendung von Code für die untersten Ebene Dinge zu vermeiden. Ich benutze einen Top-down-Ansatz aus der mittleren Ebene, vielleicht (etwas nicht zu weit geschieden von dem, was Sie mich fragen, zu tun), und bauen dort eine unabhängige Bibliothek, die ich noch in einem kurzen tun kann Höhe der Zeit, aber die Bibliothek nicht die Absicht, Mini-libs zu produzieren, die versuchen, den Welthunger Bedürfnisse zu lösen. Normalerweise sind solche Bibliotheken sind ein wenig eng in Zweck als den untergeordneten diejenigen (zB: eine Physik-Bibliothek im Gegensatz zu einer allgemeinen Geometrie-Kreuzung Bibliothek).

YMMV, aber wenn es alles, was ich im Laufe der Jahre in den härtesten Wegen gelernt möglich, dann ist es, dass es ein Balanceakt und ein Punkt sein, wo wir bewusst die Wiederverwendung von Code möchten vielleicht irgend granulare Ebene in einer Team-Einstellung vermeiden , eine gewisse Allgemeingültigkeit für die niedrigste-Level-Code für Entkopplung verlassen, mit formbar Code, den wir Form besser können spezifischere anstatt generali Bedürfnisse zu dienen und so weiter - vielleicht sogar nur jeder lässt, ein wenig mehr Freiheit, Dinge zu tun haben, ihre eigenen Weg. Aber natürlich ist das alles mit dem Ziel, immer noch eine sehr wiederverwendbar, generali Bibliothek produzieren, aber der Unterschied ist, dass die Bibliothek nicht in die teeniest verallgemeinern Bibliotheken zersetzen könnte, weil ich festgestellt, dass eine bestimmte Schwelle überschreiten und versuchen, machen zu viele teeny, generali Bibliotheken beginnt tatsächlich eine äußerst kontraproduktiv Fangen auf lange Sicht zu werden - nicht in der kurzfristig, aber auf lange Sicht und breit Schema der Dinge

Wenn Sie ein Stück Code, die möglicherweise über ein gemeinsam genutzt werden könnten mittlere Größe Organisation wie würden Sie andere gehen zu informieren Mitglieder der Gesellschaft, dass diese lib / api / etc existiert und könnte von profitieren?

Ich bin eigentlich mehr in diesen Tagen nur ungern und finden es verzeihlich, wenn Kollegen etwas redundante Arbeit tun, weil ich, dass Code sicher etwas tut, ziemlich nützlich und nicht-trivial und ist auch wirklich gut getestet und entwickelt, um machen möchte, bevor ich versuche, es mit Menschen zu teilen, und eine Reihe von Abhängigkeiten sie akkumulieren. Das Design sollte sehr, sehr wenige Gründe hat alle Änderungen ab diesem Zeitpunkt zu verlangen, wenn ich es mit dem Rest des Teams teilen.

Sonst könnte es mehr Schmerz verursachen, als es tatsächlich spart.

habe ich von Redundanz so intolerant zu sein (im Code oder Bemühungen), weil es schien, ein Produkt zu übersetzen, die sehr buggy und explosiv in Speicher zu verwenden war. Aber ich zu viel gezoomt auf Redundanz als Schlüsselproblem, wenn wirklich das eigentliche Problem war schlechte Qualität, hastig geschriebener Code und einMangel an festen Tests. Gut getestet, zuverlässig, würde effizienter Code nicht leiden, dieses Problem zu fast so groß von einem Grad, auch wenn einige Leute duplizieren, sagen sie, einige mathematischen Funktionen hier und da.

Eine der gesunde Menschenverstand die Dinge zu betrachten und denken Sie daran, dass ich nicht an der Zeit ist, wie wir nicht eine gewisse Redundanz etwas dagegen, wenn wir eine sehr solide Dritten Bibliothek verwenden. Die Chancen stehen gut, dass euch eine dritte Partei-Bibliothek verwenden oder zwei, die mit dem, was Ihr Team dabei einige redundante Arbeit hat. Aber wir haben nichts dagegen in den Fällen, weil die Dritte Bibliothek ist groß und gut getestet. Ich empfehle die gleiche Einstellung zu Ihrem eigenen internen Code der Anwendung. Das Ziel sollte etwas genial und gut getestet zu schaffen, nicht hier ein wenig Redundanz zu bemuttern und dort, wie ich vor irrtümlich lange habe.

So in diesen Tagen habe ich meine Intoleranz gegenüber einem Mangel an Tests statt verschoben. Statt verärgert über redundante Anstrengungen zu bekommen, finde ich es viel produktive aufzuregen über andere Leute Mangel an Einheit und Integrationstests! :-D

Maven hat die Wiederverwendung von Code gelöst. Ich bin ganz ernst.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow