In diesem letzten Abschnitt des PowerPoint-Teils möchte ich über Bezeichnung sprechen.
Bezeichner gehören nicht wirklich zu diesen Entwurfsprinzipien,
aber auch sie sind ganz wichtig für gute Änderbarkeit. Dafür,
dass wir Kot gut verstehen, dass wir das richtig zuordnen,
damit wir diese Trennung nach Zuständigkeiten, die lose Kopplung überhaupt machen können.
Ja, und Kohäsion zeigt sich unter anderem darin,
dass wir die Bezeichnung geeigneter Weise wählen. Jeder Entwickler,
und das möchte ich Ihnen auch nahelegen, hört immer,
bitte kümmere dich darum, dass wir gut,
verständliche Namen nimmst
Gut, verständlich bedeutet nicht unbedingt, welche, die dir als erstes einfallen,
sondern die, die von anderen besonders gut verstanden werden.
Sie hören von mir manchmal, Softwareentwicklung ist 30 Prozent Kommunikation,
kommunizieren Sie viel, dann merken Sie, was andere verstehen.
Dann merken Sie, welche Begriffe, welche Bezeichnung gut verstanden werden.
Und wenn man manchmal in eine Situation kommt,
es fällt einem nicht ein,
wie sie sich das Ding denn nennen sollte und dann macht man irgendwie sowas,
helper class oder Utility, Method,
dann ist das eine Idee,
dass dort vielleicht manches vermischt ist,
dass wir nicht
so gute Kollisionen haben
Oder wenn wir uns sowas einfällt,
wie wir machen das eine und das andere einfügen und berechnen,
statt da und Vermittler, dann ist das auch ein Indikator dafür,
da ist da vielleicht was nicht ganz sauberer bezüglich Kuission,
wir könnten das noch verbessern.
Extrem können wir das sogar so machen, wir sollten den Quelltext zuschreiben,
dass sie ihnen auch ein Nicht-Informatiker lesen kann.
Das ist natürlich ein bisschen übertrieben dargestellt,
aber die Bezeichner als solche sowie im Strukturierten programmieren,
das wäre doch ganz gut.
Ja, In diesem Zusammenhang tritt auch häufig die Frage auf,
ja, wir entwickeln doch ganz viel mit englischsprachigen Klassenbibliotheken.
Die bezeigt die typischen Bezeichner und die Schlüssel wird dort in
einer Programmiersprache sind Englisch. Ja, sollten wir unsere Klassen
und Methoden mit Englischen oder mit deutschen Namen versehen?
Das ist doch eine Frage, die immer mal wieder auftritt.
Und da kann man beide Positionen einnehmen. Ja,
ich könnte jetzt sagen, ja, englische Namen, cool.
Ja, oder, ja, wir sind doch alles
gebildete Leute, da können wir gut Englisch nehmen.
Ist doch
viel internationaler
Oder die Schlüsselworte sind alle in Englisch. Ja, alles gute Argumente für Englisch. Und dann,
das kann man natürlich so machen,
man kann einfach suchen, alles auf Englisch zu machen,
aber man sollte die Frage wirklich klar örtern und nicht von Befindlichkeiten abhängig machen,
wie haben wir schon immer so gemacht oder wir sind doch hier wie.
Manchmal ist es sinnvoll, die fachlichen Bezeichnungen in der Sprache zu lassen, aus der sie kommen. Wenn wir zum Beispiel in einem Umfeld arbeiten,
wo es komplizierte deutsche Begriffe gibt für die Fachlichkeit,
sei es im Steuerrecht, sei es in der Logistik,
sei es in einem großen Unternehmen,
wo die Sprache deutsch ist, dann wird es ja schwierig,
wenn wir diese Sachen alle ins Englisch übersetzen, ja,
also zum Beispiel eine Versicherung, wo alle fachlichen Begriffe auf Deutsch sind,
ja, irgendeinen Freibetrag oder irgendeine Bemessungsgrenze bei,
versuchen Sie mal Beitragsbemessungsgrenze in Englisch zu übersetzen,
das wird Ihnen bestimmt gelingen, aber wer weiß,
ob jemand in dem englischen Begriff,
in ihrer Übersetzung dann erkennt, das ist die Beitragsbemessungsgrenze,
dann ist es doch besser, wir lassen den deutschen Begriff,
ja, so, und wenn wir ein Projekt haben,
wo ganz viel internationale Partner dabei sind, dann sollten wir,
dass die englischen Begriffe natürlich bevorzugen,
aber wenn wir es klar trennen können oder das Trennen von Vorteile,
so Missverständnisse zu vermeiden, dann sollten wir das tun.
Sachen, die aus Frameworks kommen, die sowieso englischsprachig sind aus
dem technischen Umfeld, wo es sowieso Englisch etabliert ist,
da sollten wir auf jeden Fall immer das Englische nehmen.
Also wir haben manchmal hier solche Beispiele,
wo mein Get und Set für Gib und Schreiber und Gib und Sätze nehmen,
das ist sehr grenzwertig, das sollte man nur machen,
wo man lupenreines deutschsprachiges Projekt hat
Also deswegen, wenn ich das mische, kann es durchaus
gute Gründe geben, auch wenn das manche hässlich finden.
Wichtig wäre, dass wir es einheitlich machen.
Wichtig wäre, dass es für alle hilfreich ist.
Wenn wir in einem Projekt zwar diese deutschen fachlichen Begriffe haben,
aber die Hälfte der Entwickler sind englischsprachig und die müssen manchmal
das Zeug auch bearbeiten, dann ist es vielleicht doch besser.
Wir nehmen das, wir machen diese Mischung nicht oder wir brauchen es
auf jeden Fall hier, wie steht jetzt für manche hässlich?
Ja, wenn jemand sagt, okay,
ich möchte deutsche Sprache oder englische Sprache und richtig gut,
Ja, das, wenn wir so einen Bruch drin haben,
hier, wie bearbeiten, Button oder Get Medienart, Rückgabe-User in der Face.
Das ist, wenn wir es in eine klare Regel haben,
fachlich ist Deutsch und das Technische ist in Englisch,
dann ist so eine Mischung auch wieder sauber, auch wenn es manchen hässlich vorkommt.
Auf jeden Fall ist es sinnvoll, möglichst präzise, möglichst genauer Bezeichner zu wählen.
Wenn wir etwas zusammenlegen, ja, dann ist es leichter,
als es aufzuteilen und wir müssten manchmal versuchen Begriffe,
weil das Zusammenführen ist immer leichter, aber wenn wir differenzieren müssen,
ist es, wird es wieder später. Ja,
also zum Beispiel, wir haben hier CD-Verleih als Software,
ja, und wir modellieren natürlich die Klasse CD,
ja, aber wir stellen fest, okay,
in Wirklichkeit gibt es ja dann noch mehr beim Album,
gibt es das konkrete Exemplar der CD,
das ausgeliehen werden kann und das Album,
was von dem es 40 Exemplaren in unserer Bibliothek gibt,
was wären dann
gute Namen
Wissen Sie uns das als Quiz nehmen und lassen Sie
das uns in der interaktiven Fragerunde dann besprechen.
So, damit komme ich zum Schluss.
Ach nein, die Frage wollen wir natürlich noch anschauen.
Hier gibt es auch eine Frage dazu. Nein, gibt
es nicht. Also es ist einfach mit den Schnittstellen,
doch Sie können erwarten, dass vielleicht trotzdem eine Frage dazu gibt.
Und dann gehe ich doch nochmal zu dieser Zusammenfassungsfolie. Ja,
wir haben über Qualität gesprochen, Wartbarkeit, Portierbarkeit,
vor allen Dingen aber diese Wartbarkeit Maintenantability war wichtig für den Entwickler.
Und ist im Wesentlichen durch guten Entwurf.
Bestimmt, wir versuchen Entwurfsprinzipien Richtlinien zu verwenden, um das
gut zu machen und Kurission und Kopplung waren die wichtigsten davon.
Die sollen in Prinzipien fassen das noch in merkbarer Form in
so einer Abkürzung zusammen.
Soweit vielen Dank