Programmieren macht vielen Entwicklern Spaß, und als Entwickler wird einem garantiert nie langweilig: Jedes Jahr entstehen zahlreiche neue Sprachen, Technologien, Frameworks und Bibliotheken.
Entwickler spielen in jedem Projekt eine zentrale Rolle. Ihr Beitrag ist entscheidend, und gute Entwickler erhöhen die Erfolgschancen eines Projekts erheblich.
Doch was zeichnet einen guten Entwickler aus? Jemanden, der in kurzer Zeit sehr viel Code schreibt?
Jeder Entwickler weiß, dass mehr Code auch Folgendes bedeutet:
- mehr Fehler.
- mehr Code Smells.
- mehr Supportaufwand.
- mehr Dokumentationsaufwand.
Jede Codezeile kann ein neues Problem in die Codebasis einführen und die technischen Schulden erhöhen. Um die Zahl der Fehler zu reduzieren, ist weniger Code daher in der Regel besser.
Nehmen wir den Bubble-Sort-Algorithmus als Beispiel: Manche Entwickler benötigen 50 Codezeilen, weil sie ihn von Grund auf selbst implementieren, während andere mit nur zwei Zeilen auskommen, weil sie dafür eine bekannte Bibliothek verwenden.
Was ist der entscheidende Unterschied zwischen einer Eigenimplementierung und der Verwendung einer bekannten, ausgereiften Bibliothek?
Eine ausgereifte Bibliothek bietet folgende Vorteile:
- Sie wird von Tausenden Entwicklern eingesetzt.
- Sie ist sehr gründlich getestet.
- Sie wird kontinuierlich weiterentwickelt und unterstützt die Kompatibilität mit zahlreichen Betriebssystemen.
- Sie ist gut optimiert.
- Sie ist gut dokumentiert.
- Sie wird aktiv gepflegt.
Ein guter Entwickler sollte selbstverständlich nach bereits vorhandenen Lösungen suchen. Bevor Sie etwas Komplexes selbst implementieren, sollten Sie prüfen, ob eine bekannte Bibliothek diese Aufgabe bereits löst. In C++ gibt es wie in anderen Sprachen zahlreiche interessante Bibliotheken, etwa STL, Boost oder POCO.
Nach meiner Erfahrung ist ein guter Entwickler jemand, der weniger Code schreibt und effizient arbeitet. Das muss nicht unbedingt ein technischer Guru mit außergewöhnlichen Fähigkeiten sein, sondern vielmehr jemand, der weiß, wie man nach der passenden Bibliothek sucht und die richtige Lösung auswählt. Gerade technische Experten neigen manchmal dazu, alles selbst zu programmieren, was der Qualität der Codebasis schaden kann.
Doch wie wählt man die richtige Bibliothek aus?
Die Auswahl einer Softwarebibliothek ist nicht immer einfach, insbesondere wenn für einen bestimmten Anwendungsfall zahlreiche konkurrierende Lösungen existieren. Viele Faktoren können die Entscheidung eines Entwicklungsteams beeinflussen. Hier sind einige davon:
1. Lizenzierung
Die Lizenz der Bibliothek sollte als Erstes geprüft werden. Bevor Sie sich näher mit ihren Funktionen beschäftigen, müssen Sie sicherstellen, dass die Lizenz mit der geplanten Nutzung in Ihrem Projekt vereinbar ist.
http://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses
2. Erfüllt die Bibliothek Ihre Anforderungen?
Das klingt selbstverständlich, doch wie viele Entwickler erstellen tatsächlich einen kleinen Proof of Concept, um zu prüfen, ob die Bibliothek alle Anforderungen erfüllt? Oft zeigt sich dabei schon sehr früh, dass eine Bibliothek aus dem einen oder anderen Grund ungeeignet ist.
3. Ist die Community aktiv?
Bei der Nutzung einer Bibliothek können viele Probleme auftreten. Ist die Community aktiv, lässt sich meist schnell eine passende Lösung finden.
4. Wie entwickelt sich die Verbreitung der Bibliothek?
Es ist hilfreich zu wissen, ob eine Bibliothek an Popularität gewinnt oder verliert. Mit Google Trends können Sie beispielsweise nachvollziehen, wie sich das Interesse über die Jahre entwickelt hat.
Hier sehen Sie beispielsweise den Trend für die d3.js-API:
5. Gab es in der Vergangenheit Breaking Changes?
Bevor Sie eine Bibliothek übernehmen, lohnt sich eine kurze Websuche nach „LibraryName breaking changes“, um zu prüfen, ob bestimmte Versionen inkompatible Änderungen eingeführt haben.
Das ist aus folgenden Gründen hilfreich:
- Sie vermeiden Beispiele, die nur für ältere Versionen der Bibliothek gelten.
- Ein umfangreicher Breaking Change kann ein Warnsignal sein. Er kann darauf hindeuten, dass die Kompatibilität für bestehende Nutzer keine hohe Priorität hat und ähnliche Änderungen auch in zukünftigen Versionen auftreten könnten.
6. Einschränkungen und Grenzen der Bibliothek
Manchmal eignet sich eine Bibliothek hervorragend für einen bestimmten Zweck, besitzt jedoch eine entscheidende Einschränkung, die ihren Einsatz unmöglich macht.
Nehmen wir die Google Chart API als Beispiel: Sie ist eine sehr nützliche Diagrammbibliothek, hat jedoch eine störende Einschränkung – der Benutzer benötigt eine Internetverbindung.
Bevor Sie sich für eine Bibliothek entscheiden, sollten Sie sicherstellen, dass keine ihrer Einschränkungen Ihren Anwendungsfall beeinträchtigt. Eine einfache Websuche nach „LibraryName limitations“ kann dabei helfen.
7. Dokumentation
Eine gut dokumentierte Bibliothek erleichtert die Arbeit erheblich, insbesondere wenn die Dokumentation zahlreiche Anwendungsbeispiele enthält.
8. Ist Performance bei der Nutzung der Bibliothek wichtig?
Wenn Sie eine Bibliothek in einem Umfeld einsetzen möchten, in dem Performance besonders wichtig ist, sollten Sie sich nicht ausschließlich auf Benchmarks aus dem Web verlassen. Erstellen Sie besser einen Proof of Concept unter Ihren konkreten Rahmenbedingungen, um die tatsächliche Leistung in Ihrem Anwendungsfall zu beurteilen.
9. Ist Ihre Anwendung plattformübergreifend?
Wenn Ihre Anwendung auf mehreren Plattformen laufen muss, sollten Sie nicht hauptsächlich auf einer Plattform testen und die anderen erst nach Abschluss der Entwicklung berücksichtigen.
Testen Sie von Anfang an auf allen Zielplattformen. Manche Bibliotheken sind für ein Betriebssystem hervorragend implementiert, für andere jedoch deutlich schlechter.
10. Gibt es eine ernsthafte Alternative und Sie sind unsicher?
In manchen Fällen gibt es zwei ausgezeichnete Bibliotheken, die dieselben Anforderungen erfüllen, sodass die Entscheidung schwerfällt. In diesem Fall sollten Sie eine starke Kopplung Ihres Codes an die Bibliothek vermeiden. Verwenden Sie stattdessen Wrapper und das Facade-Pattern, um ihre Nutzung zu isolieren.
Natürlich können noch viele weitere Faktoren Ihre Entscheidung beeinflussen. Um das Risiko zu minimieren, eine Bibliothek später ersetzen zu müssen, empfiehlt es sich, ihre Verwendung mithilfe von Wrappern und Fassaden auf wenige Stellen im Code zu begrenzen.
Bewerten Sie die Kopplung Ihrer Anwendung an die verwendeten Bibliotheken, identifizieren Sie besonders stark gekoppelte Abhängigkeiten und versuchen Sie schrittweise, diese Kopplung so weit wie möglich zu reduzieren.
Mit verschiedenen Tools lässt sich die Kopplung an externe Bibliotheken leicht erkennen. Dazu gehörenJDepend and JArchitectfür Java,CppDependfür C/C++ undNDependfür .NET.