Facebook
Twitter
Google+
Kommentare
23
Willkommen bei "the web hates me". Mittlerweile hat unser Team ein tolles neues Monitoringtool für Agenturen gelauncht. Unter dem Namen koality.io haben wir einen Service geschaffen, der er Agenturen ermöglicht mit sehr geringen Kosten alle Ihre Webseiten zu überwachen.

Wo liegt euer Qualitätsfokus?

Umfrage! Jap es ist wieder so weit. Ich will wieder was über euch wissen. Und zwar geht es heute um Qualitätskriterien eurer Software, auf die ihr besonders wert legt. Natürlich kann das von Projekt von Projekt verschieden sein, aber ich denke jeder von uns hat da so sein Steckenpferd auf das er besonders achtet. Den Rest machen dann die Kollegen. Falls man Glück hat.

Ich denke mal, dass ich ein paar Kriterien aufschreibe und ihr kommentiert dann, wo ihr euch drauf stürzt, wenn es darum geht ein neues Projekt aus dem Boden zu stampfen.

  • Testbarkeit – Wie sehr achtet ihr drauf, dass ihr eure Software auch mit einer hohen Testabdeckung versehen könnt.
  • Wartbarkeit – Bei langen Projektlaufzeiten muss viel gewartet werden. Wie sieht’s also aus? Starker Fokus hier?
  • Erweiterbarkeit – Wie wichtig ist es euch, dass man neue Funktionalitäten andocken kann?
  • Performance – Das Teil muss fliegen! Ist das so?

Sicherlich gibt es noch eine Menge weiterer Kriterien. Ihr dürfte gerne ergänzen. Aber wichtiger ist  mir noch, ob eine allgemeine Tendenz zu spüren ist. Also schreibt mir euren Fokus.

Über den Autor

Nils Langner

Nils Langner ist der Gründer von "the web hates me" und auch der Hauptautor. Im wahren Leben leitet er das Qualitätsmanagementteam im Gruner+Jahr-Digitalbereich und ist somit für Seiten wie stern.de, eltern.de und gala.de aus Qualitätssicht verantwortlich. Nils schreibt seit den Anfängen von phphatesme, welches er ebenfalls gegründet hat, nicht nur für diverse Blogs, sondern auch für Fachmagazine, wie das PHP Magazin, die t3n, die c't oder die iX. Nebenbei ist er noch ein gern gesehener Sprecher auf Konferenzen. Herr Langner schreibt die Texte über sich gerne in der dritten Form.
Kommentare

23 Comments

  1. Also ich versuche alles abzubilden, dass ist m.M. auch gar nicht so schwer, weil vieles ineinander verzahnt ist, achte ich auf Testbarkeit kann ich leichter die Performance profilen, ist es wartbar, so ist es nicht schwer darauf zu achten zu erweitern und wenn es wartbar ist, macht das wiederum auch die Performance Optimierung einfach 😀

    Wenn ich es gewichten sollte, von der Wichtigkeit, würde ich Performance > Testbarkeit > Wartbarkeit > Erweiterbarkeit einordnen, denn am Ende des Tages steht da i.d.R. der Kunde/Chef der ein schnelles & funktionierendes System will, alles andere kommt eh danach.

    Reply
  2. Also bei mir wäre die Reihenfolge eher:
    Performance > Wartbarkeit > Erweiterbarkeit > Testbarkeit

    Performance ist mein Ding, ist aber in 95% meiner Projekte leider völlig egal 🙂 Wartbarkeit ist sehr wichtig (Kommentare, Kommentare, Kommentare!). Erweiterbarkeit ist wohl auch wichtig, wobei ich es so halte: Nur Features einbauen, die gebraucht werden. Niemals welche einbauen, die gebraucht werden KÖNNTEN.
    Und Testbarkeit ist so ein Ding. Dummerweise sind die Timings so eng und die Features werden in der Entwicklung so oft geändert, dass Unit-Tests nicht mal ansatzweise machbar wären. Dafür gibt’s am Ende zumindest eine eingeplante Testzeit für die üblichen Funktions-Tests. Auch wenn diese Testzeit auch gerne mal wegfällt. 🙁

    Reply
  3. im ersten Moment wollte ich Christoph zustimmen, jedoch mit weiterlesen wurde mir klar, das eigentlich die „Erweiterbarkeit“ eine „Wartbarkeit“ mit einschließt (jedenfalls bei mir setz es das voraus).

    Somit ergibt sich für mich eigentlich

    Erweiterbarkeit -> Performance -> Testbarkeit

    Testbarkeit steht glaub ich nicht mal im Duden, Testmöglichkeit würde ich es nennen 😉

    Reply
  4. Schließe mich der allgemeinen Meinung an. Wobei mE Wartbarkeit und Testbarkeit doch schon eine ziemlich große Überdeckung besitzt. Was man nicht mehr pflegen kann, kann man schon garnicht mehr testen. Gilt anders rum nicht unbedingt 😉

    Reply
  5. Testbarkeit > Wartbarkeit > Erweiterbarkeit > Performance.

    Testbarkeit ist für mich das Schlüsselelement um guten Code zu entwickeln. Dabei geht es jedoch, wie man bereits ahnt, nicht um das Schreiben der Tests selbst, sondern um das API-Design. Wenn die API in diesem Sinne testbar ist, dann kann man jeder Funktion/Methode/Klasse klar definierte Eigenschaften zuweisen. Aufbauend auf diesen Eigenschaften kann man weitere Funktionen/Methoden/Klassen schreiben, die wiederum neue Eigenschaften besitzen. Randomisierte Tests werden dann lediglich verwendet, Vertrauen über die Einhaltung der Eigenschaften aufzubauen.

    Wenn Code in diesem Sinne testbar ist, ist er zu gewissem Grad wartbar und erweiterbar. Sollte die Performance der verwendeten Algorithmen eingebrochen sein, so kann in den meisten Fällen entweder eine neue Implementation mit denselben Eigenschaften schreiben oder die Implementation um Optimierungsmaßnahmen erweitern, welche die Eigenschaften nicht beeinflussen.

    Reply
  6. Das ist sicherlich eine gute Frage / Aufgabe, wenn man ein neues Entwicklerteam zusammen stellt.
    Dann weiß man erst mal wie der eine so in etwa vor geht und
    man schaut was für das Projekt am sinnvollsten ist.

    Meine grundsätliche Meinung:
    Erweiterbarkeit/Wartbarkeit -> Performance -> Testbarkeit

    @Niels:
    welche Reihenfolge bevorzugst du?

    Reply
  7. Es kommt im Grunde immer auf die Anwendung an. Ganz allgemein könnte ich da kaum eine Reihenfolge nennen. Aber „durchschnittlich“ komme ich am ehesten dann wohl doch zu diesem Ergebnis (auch wenn das dann wahrscheinlich keine klare Aussagekraft mehr hat):
    Wartbarkeit > Performance > Testbarkeit > Erweiterbarkeit

    Reply
  8. Erweiterbarkeit > Wartbarkeit > Testbarkeit > Performance

    Ich denke am Anfang eines Projektes ist es wichtig den Code flexibel zu halten, da es für gewöhnlich zu Anpassungen und neuen Anforderungen kommt. Wartbarkeit und Testbarkeit gehen für mich Hand in Hand und sollten vor Performanceoptimierung kommen. Diese macht mMn erst Sinn wenn man wirklich an den Punkt gekommen ist wo die ersten, kleineren Geschwindigkeitprobleme auftreten.

    Reply
  9. Da frage ich mich gerade. Geht’s eigentlich darum, wie wir glauben, dass es sein müsste, oder wie es tatsächlich bei der täglichen Arbeit ist?

    Reply

Leave a Comment.

Link erfolgreich vorgeschlagen.

Vielen Dank, dass du einen Link vorgeschlagen hast. Wir werden ihn sobald wie möglich prüfen. Schließen