Inhalt
Topic:.DevlpProc.
Topic:.DevlpProc..
Last changed: 2015
Hier nur einige Notizen.
Wasserfallmodell, konservativ, nur dort wo notwendig.
Software muss langjährig laufen.
Fortlaufende Entwicklung: Ständige Verbesserung in Details, für den Anwender of nicht sichtbar wenn er nicht genau dieses feature bewusst nutzt. Continous Delivery - muss auch fortlaufend dem Anwender geliefert werden.
DevOps: Development and Operation als Prozess, der die fortlaufende Entwicklung (nach entsprechenden Tests) zeitnahe in die Anwendung bringt, Software-Update-Installation.
Feature toggle: Neue features die noch nicht endgültig getestet sind, werden in die Software eingebaut aber noch nicht freigeschaltet. Man kann sie bei Bedarf im Anwendungsumfeld freischalten, um dieses Features im Feld zu testen..
Topic:.DevlpProc...
Last changed: 2015
A) Debug-, Test- und Loggingunterstützung verbessert - bei allen identisch nachrüstbar.
B) Breitere Testabdeckung
Wenn ein Fehler bei Anweder x auftritt dann können folgende Aussagen bei Ursachenforschung helfen:
Warum tritt Fehler bei Anwender y nicht auf, andere Bedingungen
Wenn der Fehler bei Anwender x gefixt ist, sollte die Fehlerwahrscheinlichkeit bei Anwender y damit gleichzeitig reduziert sein.
Topic:.DevlpProc...
Last changed: 2015
Software ist nie fertig. Sie ist genau dann fertig, wenn sie in der Rückschau nicht mehr geändert wurde. Sei es, sie wird nicht mehr benötigt, die Softwareentwickler sind nicht mehr verfügbar, oder haben selbst keine Intension der Änderung.
Folglich muss Software, wenn sie gebrauchsfähig sein soll, im relativen Zustand 'fertig' gehalten werden. Änderungen sollen so erfolgen, dass nach kürzerer Zeit (ein Sprint) die Software wieder das tut, was schonmal ging, vielleicht etwas besser. Man darf aber nicht den Anspruch der Perfektion vertreten (perfekt =^ fertig).
Topic:.DevlpProc...
Last changed: 2015
Wünschenswert ist es, dass eine Änderung nur genau für diesen Zweck und an einer Stelle wirkt. Das ist realisierbar in einer oberen Schale der Software, nahe in der Anwendersoftwareschicht.
Je tiefer in der Software gearbeitet wird, je näher am Kern, desto eher wirkt sich eine Änderung an sehr vielen Stellen aus.
Man muss daher die Änderung nicht für den momentanen Zweck bedenken, sondern in ihrer gesamten Systematik. Möglicherweise sollte eine notwendige Änderung den Start eines gesamten Refactoring bewirken, wenn die Änderung sonst eine Systematik durchbricht. Ansonsten ist das Resultat eine diffuse Software.
Topic:.DevlpProc...
Last changed: 2015
Software enthält häufig kleine nicht entdeckte Fehler, die sich aber in unerwarteten Situationen zeigen. Sie wurden beim systematischen Test nicht entdeckt .....
Korrigiert man diese Fehler nun mit dem Software mit Breitenwirkung über längere Zeit, dann wird die Software immer besser. Nur dann gilt die Regel: Eine gut ausgetestete bzw. langjährig in Benutzung befindliche Software sollte weitgehend fehlerfrei sein.
Woran liegen viele kleine Fehler:
Oft läuft eine Software trotz Fehler weil die Fehler sich aufheben und nicht entdeckt werden.
Topic:.DevlpProc.srcDsgn.
Last changed: 2019-03
Notizen zur Quelltextbearbeitung und Softwaredesign
Topic:.DevlpProc.srcDsgn.NoPhenom.
Last changed: 2019-03
Software wird oft an den Anforderungen ausgerichtet (nicht an den Requirements, sondern nach den unmittelbaren Erwartungen). Negativ ausgedrückt: "Es wird solange daran herumgepopelt, bis es stimmt" (Zitat aus Kollegenkreis).
Nein! Die Software muss immer so gebaut werden, dass ihre interne Organisation und Struktur stimmig ist. Wenn damit nicht die erwarteten Testresultate erfüllt werden, dann muss überlegt werden, warum die Softwareorganisation nicht mit den Funktionserwartungen übereinstimmt.
Wenn ein offensichtlicher Bug entdeckt wird, und dessen Korrektur harmoniert mit der Softwareorganisation, dann ist alles gut nach der Korrektur. Wird die Testerwartung nicht erfüllt, dann ist dort wohl noch ein anderer Bug. Es kommt manchmal auch vor, dass sich zwei Bugs gegenseitig auslöschen. Wird einer gefunden und korrigiert, dann gibt es äußerlich gesehen eine "Verschlimmbesserung" - weil nun der zweite Bug nach außen hervortritt. Bitte Bug suchen und korrigieren und nicht herumpopeln! (Sorry für die direkte Sprache, ist nur ein Kollegenzitat).
Topic:.DevlpProc.srcDsgn.CyclRefact.
Last changed: 2019-03
Als das Wasserfallmodell noch Lasten- und Pflichtenheft hieß, war die Welt in Ordnung. Man hat genau vorgegeben bekommen, was zu realisieren war, Softwaredesign und Implementierung, Test als Abschluss - fertig. Problem ist nur, die Softwarefeautures entsprechen nicht mehr den Kundenvorstellungen. Entweder, der Kunde hat die Anforderungen mittlerweile modifiziert, oder Sichtweisen haben sich geändert, oder die notierten Kundenvorstellungen sind falsch verstanden worden. ...
Die Agile Softwareentwicklung wird in der Praxis oft so verstanden, dass es Sprints für je 4 Wochen gibt, aber die Lasten- und Pflichtenheft-Denkweise wird nicht so leicht den Gewohnheiten weicht. Man erwartet also, dass der Chef oder das Projektboard neue Vorgaben macht, die man, weil schon wieder ganz anders, widerstrebend einbaut.
Ich sage nicht, dass die Welt immer schnell-lebiger wird, sondern dass der Umfang der Dinge, die heute (meist in Software) realisierbar sind, wächst. Die Anpassung des jeweils Existierenden an die damit gewonnenen Erfahrungen macht die Natur frei nach Charles Darwin sein Jahrmillionen. Der Mensch, der Schmied der Eisenzeit, hat seine Technologien verbessern, konnte dann Damaszener Klingen schmieden, und heute interessante Verbundwerkstoffe herstellen. Das hat zwar einige Jahrhunderte gedauert, aber es war immer ein Spiel zwischen Realisieren und Verbessern.
Dieses Schema lässt sich auf große in ihren Detaileigenschaften noch nicht klar fassbare (Software-)Projekte anwenden. Es muss nicht zeitlich gedehnt werden. Jede Realisierungsphase wird bewertet und überlegt, was gut ist, was verbessert werden muss und welcher Ansatz falsch war. Das ist Agile Softwareentwicklung.
Für die Software ergibt sich damit häufig die Notwendigkeit eines Refactoring - Umstrukturieren . Das Design wurde ja auf vorläufigen Grundlagen entwickelt. Die Bedingungen ändern sich. Die Größe der Software ändert sich, ein Modul muss aufgeteilt werden. Die ursprüngliche Bedeutung einer Schnittstelle passt nicht mehr zum Rahmen usw. usf.
Topic:.DevlpProc.srcDsgn.CyclRefact.CyclRefact.
Variablen-Bezeichner, als Elemente einer Struktur, als lokale Variable oder Argumentnamen von Operations werden meist intuitiv erstmal bezeichnet. Nicht alles ist im Softwaredesign so detailliert festgelegt.
Die erste Umbenennung ergibt sich schon, wenn mit dem Fertigstellungsgrad sich die Bedeutung der Variablen etwas ändert.
Die zweite Umbenennungsnotwendigkeit kann sich daraus ergeben, dass mit der Diskussion der Software im Review der Name schlecht erklärbar ist und andere Kollegen bessere Vorschläge haben.
Möglicherweise gibt es dann im Projektfortschritt gewisse Richtlinien der Bezeichnung.
Das Umbenennen von Variablen ist meist kein Problem:
Dagegen spricht, dass man sich an den bisherigen Namen gewöhnt hat, auch wenn er falsch ist. Geht das Umbenennen mit einer funktionalen Änderung einher, dann ist dieser Punkt entschäft.
Spielt der Bezeichner nur in den Softwarequellen eine Rolle, läuft also nur durch einen Compiler, dann ist es sehr einfach. Entweder die IDE stellt schon eine 'Rename'-Funktionalität bereit, oder man ändert zunächst nur den Bezeichner (Identifier) an der Definitionsstelle. Der Compiler meldet schon alle Vorkommnisse. Der Arbeitsaufwand ist mit gezieltem Search&Replace nicht übergroß.