Viele nehmen Personen, die so handeln und denken, wie ich es hier tue, als kleinkariert wahr. Aber sei es drum. Mich hat es tatsächlich durchgängig etwas gestört, dass so häufig "refactoring" als "refacturing" ausgesprochen wurde. Also ab dem "t" wie in "nature". Das schadet dem Stream insgesamt aber zugegebenermaßen nur wenig oder gar nicht, sofern man dafür die entsprechende Gleichgültigkeit mitbringt. Ich habe das Video ansonsten recht genossen. Danke!
Ich finde das Thema total wichtig und werde mir das Buch sehr wahrscheinlich alleine deshalb kaufen, um die Strategien mit griffigen Bezeichnungen weitergeben zu können. Danke Euch für die Vorstellung. Das Beispiel Reading Order ( th-cam.com/video/6M0yK3T_VpM/w-d-xo.html ) fand ich allerdings leider fast schon schädlich. Ich versuche seit Jahren zu vermitteln, dass Code verständlicher ist, wenn eine gute Reihenfolge eingehalten wird. Gut ist die Reihenfolge IMHO dann, wenn der Fokus zuerst erzählt wird. Erst wenn ich als Leser den highlevel Kontext verstanden habe, möchte ich mich den lowlevel Details widmen. Leider sehe ich mehrheitlich Code, der genau anders herum sortiert ist. Im Beispiel "Reading Order" wurde die Reihenfolge von highlevel Fokus (start_engine) und lowlevel Details (check_battery) verdreht und dann als Verbesserung dargestellt Erst start_engine+check_battery dann check_battery+start_engine Schade. Aus meiner Sicht wäre ein anderes Beispiel besser gewesen. Dieses Beispiel hätte ich anders aufgeräumt: indem ich den Methodennamen von check_battery geändert hätte: check_battery -> is_battery_healthy. Und ich hätte die Implementierung der Methode geändert, damit auf einen Blick klar wird, was sie tut: def check_battery: current_year = datetime.datetime.now().year car_age = current_year - self.year return car_age < 5 Wie seht Ihr das? Stört es sonst niemanden, sich erst mit Implementierungsdetails auseinanderzusetzen, bevor man verstanden hat, was der eigentliche Einsatzzweck ist?
Ich bin da grundsätzlich bei Dir - was Du beschreibst ist das sogenannte "Newspaper-Metapher", bei dem es vom Groben (Headlines) ins Feine geht. Insofern hab ich das Beispiel tatsächlich einfach schlecht gewählt. Was ich damit zeigen wollte ist aber ein ganz anderer Aspekt: Ich hatte es glaub im Stream auch angemerkt, dass hier ein Renaming auch helfen würde. Die Idee vom Tidying ist aber hier mit chirurgisch kleinen Änderungen vorzugehen um das Risiko klein zu halten. Bei einem Rename müssten potentiell andere Stellen mitgeändert werden (evtl. verlässt man sich hier auf die IDE). Die Reihenfolgenänderung macht nichts kaputt und ich würde argumentieren, es ist auf jeden Fall verständlicher als vorher, auch wenn das Kernproblem natürlich ein anderes ist. Noch anders ausgedrückt: mit genügend Zeit und Bereitschaft mehr zu investieren, ist die Lösung, die Du vorschlägst, genau die, die ich auch bevorzugen würde. Um wirklich schnell (< 5 min) und ohne Risiko voranzukommen hilft aber das Tidying. Vielleicht finde ich noch ein anderes Bsp, das nicht gleichzeitig das Newspaper-Metapher verletzt 😅
@@marcoemrich7873 Danke für Dein Feedback. Newspaper Metapher ist ebenfalls schön griffig. Nehme ich in meinen Wortschatz auf ;) Das Problem mit Usages dieser Methode bei Umbenennung leuchtet mir ein. Das muss man natürlich fallweise entscheiden.
Mein Haupteinwand gegen das besprochene Buch ist, dass es bessere gibt. Zwei davon hat Kent Beck selbst geschrieben, nämlich "Smalltalk Best Practice Patterns" (1997) und "Implementation Patterns" (2008). Außerdem "The Art of Readable Code (2011) von Dustin Boswell & Trevor Foucher.
Ich finde diese Pattern-Herangehensweise spannend. Ist es wirklich so schwierig, diese Dinge intuitiv zu machen? Also klar, man hat dann einen Namen um darüber zu sprechen. Aber was passiert, wenn ich eine Änderung vornehmen will, die jetzt nicht im Buch steht? Mache ich etwas falsch?
@@i-am-the-slime Das ist IMHO die versteckte Nachricht: Wenn man ein Buch drüber schreiben kann bzw muss, dann ist es eben nicht klar. Das bedeutet, es gibt da fundamentale Probleme bei den Skills der Entwickler:innen - so würde ich das zumindest interpretieren.
Viele nehmen Personen, die so handeln und denken, wie ich es hier tue, als kleinkariert wahr. Aber sei es drum. Mich hat es tatsächlich durchgängig etwas gestört, dass so häufig "refactoring" als "refacturing" ausgesprochen wurde. Also ab dem "t" wie in "nature".
Das schadet dem Stream insgesamt aber zugegebenermaßen nur wenig oder gar nicht, sofern man dafür die entsprechende Gleichgültigkeit mitbringt. Ich habe das Video ansonsten recht genossen. Danke!
Ich finde das Thema total wichtig und werde mir das Buch sehr wahrscheinlich alleine deshalb kaufen, um die Strategien mit griffigen Bezeichnungen weitergeben zu können. Danke Euch für die Vorstellung.
Das Beispiel Reading Order ( th-cam.com/video/6M0yK3T_VpM/w-d-xo.html ) fand ich allerdings leider fast schon schädlich.
Ich versuche seit Jahren zu vermitteln, dass Code verständlicher ist, wenn eine gute Reihenfolge eingehalten wird.
Gut ist die Reihenfolge IMHO dann, wenn der Fokus zuerst erzählt wird.
Erst wenn ich als Leser den highlevel Kontext verstanden habe, möchte ich mich den lowlevel Details widmen.
Leider sehe ich mehrheitlich Code, der genau anders herum sortiert ist.
Im Beispiel "Reading Order" wurde die Reihenfolge von highlevel Fokus (start_engine) und lowlevel Details (check_battery) verdreht und dann als Verbesserung dargestellt
Erst start_engine+check_battery dann check_battery+start_engine
Schade.
Aus meiner Sicht wäre ein anderes Beispiel besser gewesen.
Dieses Beispiel hätte ich anders aufgeräumt: indem ich den Methodennamen von check_battery geändert hätte: check_battery -> is_battery_healthy.
Und ich hätte die Implementierung der Methode geändert, damit auf einen Blick klar wird, was sie tut:
def check_battery:
current_year = datetime.datetime.now().year
car_age = current_year - self.year
return car_age < 5
Wie seht Ihr das?
Stört es sonst niemanden, sich erst mit Implementierungsdetails auseinanderzusetzen, bevor man verstanden hat, was der eigentliche Einsatzzweck ist?
Ich bin da grundsätzlich bei Dir - was Du beschreibst ist das sogenannte "Newspaper-Metapher", bei dem es vom Groben (Headlines) ins Feine geht. Insofern hab ich das Beispiel tatsächlich einfach schlecht gewählt. Was ich damit zeigen wollte ist aber ein ganz anderer Aspekt: Ich hatte es glaub im Stream auch angemerkt, dass hier ein Renaming auch helfen würde. Die Idee vom Tidying ist aber hier mit chirurgisch kleinen Änderungen vorzugehen um das Risiko klein zu halten. Bei einem Rename müssten potentiell andere Stellen mitgeändert werden (evtl. verlässt man sich hier auf die IDE). Die Reihenfolgenänderung macht nichts kaputt und ich würde argumentieren, es ist auf jeden Fall verständlicher als vorher, auch wenn das Kernproblem natürlich ein anderes ist.
Noch anders ausgedrückt: mit genügend Zeit und Bereitschaft mehr zu investieren, ist die Lösung, die Du vorschlägst, genau die, die ich auch bevorzugen würde. Um wirklich schnell (< 5 min) und ohne Risiko voranzukommen hilft aber das Tidying. Vielleicht finde ich noch ein anderes Bsp, das nicht gleichzeitig das Newspaper-Metapher verletzt
😅
@@marcoemrich7873 Danke für Dein Feedback. Newspaper Metapher ist ebenfalls schön griffig. Nehme ich in meinen Wortschatz auf ;) Das Problem mit Usages dieser Methode bei Umbenennung leuchtet mir ein. Das muss man natürlich fallweise entscheiden.
Mein Haupteinwand gegen das besprochene Buch ist, dass es bessere gibt. Zwei davon hat Kent Beck selbst geschrieben, nämlich "Smalltalk Best Practice Patterns" (1997) und "Implementation Patterns" (2008). Außerdem "The Art of Readable Code (2011) von Dustin Boswell & Trevor Foucher.
The Art of Readable Code ein geniales Buch wie ich finde
Ich finde diese Pattern-Herangehensweise spannend. Ist es wirklich so schwierig, diese Dinge intuitiv zu machen? Also klar, man hat dann einen Namen um darüber zu sprechen. Aber was passiert, wenn ich eine Änderung vornehmen will, die jetzt nicht im Buch steht? Mache ich etwas falsch?
@@i-am-the-slime Das ist IMHO die versteckte Nachricht: Wenn man ein Buch drüber schreiben kann bzw muss, dann ist es eben nicht klar. Das bedeutet, es gibt da fundamentale Probleme bei den Skills der Entwickler:innen - so würde ich das zumindest interpretieren.