Gutes Tutorial. Ich habe gerade das Vergnügen, bereits Christian Clausens „5 Lines of Code“ lesen zu können. Das eine Sammlung von Refactoring-Rezepten mit Schritt für Schritt-Anleitungen, die auch ohne IDE-Unterstützung ein sicheres Refactoring gewährleisten. Im Video habe ich vieles wieder erkannt 👍 Ein bisschen schade an dieser Folge hier finde ich, dass auch an der Semantik geändert wurde und nicht nur die strukturellen Änderungen stattgefunden haben. Klar, es juckt einen in den Fingern. imho lernt man aber mehr davon, wenn man das stringent trennt. Ein großes 👍 an dieser Stelle für Eure Videos. Informativ, verständlich, von Relevanz.
Tolles Tutorial! Leider programmiere ich kaum noch und habe gerade dieses „Good Old Times“ Gefühl, da wir bereits vor einigen Jahren Refactoring eingesetzt haben um den Clean Code Gedanken zu leben. Kenntnisse zu Design Patterns und wie komme ich mit Refactoring dort hin, sollte nicht nur Teil der entsprechenden Ausbildung sein, sondern auch in Entwicklerteams zum Alltag gehören! Wenn ich heute noch sehe, dass hochpreisige Anwendungen im Industriesegment beim Versionsupdate immer wieder neue Fehler bei Funktionen liefern, die angeblich nicht geändert wurden, zeigt es mir, dass zu oft noch Code entwickelt wird, der nicht getestet (egal ob Unittests, Integrationtests, oder andere) wird. Image Schaden wird schnell teurer, als gut Qualität 😉
5:38 man könnte auch das IF innerhalb der Methode weglassen und die Bedingung direkt returnen. Aber Refactorn ist immer ein schwieriges Thema es gibt letztendlich kein richtig oder falsch
Sehr schönes Tutorial. Leider ist der Code in der Praxis oft viel komplexer und noch mehr Kraut und Rüben. Aber trotzdem, sehr schön gemacht, um mal die prinzipiellen Methoden zu zeigen.
Hallo David, danke für das Feedback. Der Code in der Praxis ist tatsächlich oft erstaunlich schlecht. Dann stellt sich die Frage, überarbeiten oder Neuentwicklung. Mit Refactoring ist oft noch was zu retten. Es gibt aber auch FUBAR (fouled up beyond all repair) Code, den man besser entsorgen sollte :-). Bei ganz üblem Code geht auch erst mal nur Extract Method und Inline Variable. Wenn man das oft genug gemacht hat, dann gehen plötzlich auch andere Refactorings.
Wenn ich so ein Refactoring machen würde, würde ich mein Job verlieren. - Komposition vs Vererbung - Factory pattern um switch-case aufzulösen - strategy pattern hätte auch an ein paar stellen sehr gut geholfen - SOLID Prinzipien nicht berücksichtigt
Nicht unbedingt kommt auf die Branche an, wenn ich Code Schreibe bei welchen viele Fachbegriffe vorkommen die nicht oder nur schwer übersetzbar sind dann nicht
@@florian2119 yea I sgree that domain names are a problem (especially in german) but you can keep the domain in german, which should be also encapsulated in certain modules, but here we saw just full blast in german all over the place which is not a good practice.
![Seungmin "그렇게, 천천히, 우리(As we are)" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/kAzmhLHePqU/mqdefault.jpg)
Bitte mehr zum Thema Refactoring. Außerdem würde ich mir Beispiele wünschen für sauberen Code bzw. halt Clean Code Konzepte
Klasse dargestellt!
Hallo Jan, danke für das Feedback.
Tolles video! Vielen Dank.
Gutes Tutorial.
Ich habe gerade das Vergnügen, bereits Christian Clausens „5 Lines of Code“ lesen zu können. Das eine Sammlung von Refactoring-Rezepten mit Schritt für Schritt-Anleitungen, die auch ohne IDE-Unterstützung ein sicheres Refactoring gewährleisten.
Im Video habe ich vieles wieder erkannt 👍
Ein bisschen schade an dieser Folge hier finde ich, dass auch an der Semantik geändert wurde und nicht nur die strukturellen Änderungen stattgefunden haben.
Klar, es juckt einen in den Fingern. imho lernt man aber mehr davon, wenn man das stringent trennt.
Ein großes 👍 an dieser Stelle für Eure Videos. Informativ, verständlich, von Relevanz.
Tolles Tutorial! Leider programmiere ich kaum noch und habe gerade dieses „Good Old Times“ Gefühl, da wir bereits vor einigen Jahren Refactoring eingesetzt haben um den Clean Code Gedanken zu leben.
Kenntnisse zu Design Patterns und wie komme ich mit Refactoring dort hin, sollte nicht nur Teil der entsprechenden Ausbildung sein, sondern auch in Entwicklerteams zum Alltag gehören!
Wenn ich heute noch sehe, dass hochpreisige Anwendungen im Industriesegment beim Versionsupdate immer wieder neue Fehler bei Funktionen liefern, die angeblich nicht geändert wurden, zeigt es mir, dass zu oft noch Code entwickelt wird, der nicht getestet (egal ob Unittests, Integrationtests, oder andere) wird. Image Schaden wird schnell teurer, als gut Qualität 😉
5:38 man könnte auch das IF innerhalb der Methode weglassen und die Bedingung direkt returnen. Aber Refactorn ist immer ein schwieriges Thema es gibt letztendlich kein richtig oder falsch
Kommt noch im Video;)
Klasse find ich: benutzt nur 10% des Hirns und entspannt euch.
Die BWLer mögen solche Aussagen
5:33 => better :
private boolean isMondschein(int stunde) {
return (stunde < 9 | stunde > 18) ;
}
Hallo Lisa, danke für den Vorschlag. Die Verbesserung kommt später im Video.
@@thomas-bayer ups.. ich habe video nicht weiter geschaut, danke
Sehr schönes Tutorial. Leider ist der Code in der Praxis oft viel komplexer und noch mehr Kraut und Rüben. Aber trotzdem, sehr schön gemacht, um mal die prinzipiellen Methoden zu zeigen.
Hallo David, danke für das Feedback. Der Code in der Praxis ist tatsächlich oft erstaunlich schlecht. Dann stellt sich die Frage, überarbeiten oder Neuentwicklung. Mit Refactoring ist oft noch was zu retten. Es gibt aber auch FUBAR (fouled up beyond all repair) Code, den man besser entsorgen sollte :-). Bei ganz üblem Code geht auch erst mal nur Extract Method und Inline Variable. Wenn man das oft genug gemacht hat, dann gehen plötzlich auch andere Refactorings.
Klingt nach einem sehr interessantem Video aber vermutlich vor allem für Anfänger?
Wenn ich so ein Refactoring machen würde, würde ich mein Job verlieren.
- Komposition vs Vererbung
- Factory pattern um switch-case aufzulösen
- strategy pattern hätte auch an ein paar stellen sehr gut geholfen
- SOLID Prinzipien nicht berücksichtigt
C# nehmen.
First of all, code in english
Nicht unbedingt kommt auf die Branche an, wenn ich Code Schreibe bei welchen viele Fachbegriffe vorkommen die nicht oder nur schwer übersetzbar sind dann nicht
@@florian2119 yea I sgree that domain names are a problem (especially in german) but you can keep the domain in german, which should be also encapsulated in certain modules, but here we saw just full blast in german all over the place which is not a good practice.
Das erzähl mal deinem Domain Experten, wenn Du weisst was das ist!
ja, für ausländischen Informatikern