BROADCASTS.com

Schepp, Peter, Hans und Anselm haben in dieser Revision zwar keinerlei News oder\nLinks zu vermelden, geben aber daf\xfcr ihr bestes, um ein bisschen in die Zukunft\nzu sehen und Methoden zur Refakturierung von Code zu analysieren.\n\n\nSCHAUNOTIZEN\n\n[00:00:23] SIMPLIFIZIERUNG\n\nNach Jahren des Aufr\xfcstens sehen wir einen Trend zur Simplifizierung des\nFront-End Workflows. Hans kl\xe4rt in seinem anf\xe4nglichen Pl\xe4doyer auf, was der\naktuelle Status ist, was die Probleme und Unterschiede zwischen klassischen\nPr\xe4prozessoren und Postprozessoren sind und fragt sich, ob ein Tool wie Pleeease\nvielleicht sogar Sass abl\xf6sen k\xf6nnte? Wir diskutieren und orakeln gemeinsam, wie\ndie Zukunft aussehen kann und kommen zum Schluss, dass das Programmier-Business\nmanchmal durchaus mit der Mode-Industrie zu vergleichen ist.\n\n[00:30:20] CODE REFACTORING METHODEN\n\nAnselm fragt den Rest, wie sie an Refactoring von Code herangehen. Peter ist der\nfesten \xdcberzeugung, dass es hier nur eine einzige M\xf6glichkeit gibt: Die alten\nTests nehmen und darauf den Code neu schreiben. Gibt es keine Tests, m\xfcssen\nandere Prinzipien herhalten, wie sie Hans und Schepp pflegen. So muss man oft\nauf Grund verschiedener Gegebenheiten leider auf bestehende Tests verzichten und\nsich selbst eine L\xf6sung ausdenken. Schepp nutzt dabei auch oft Tools wie seine\nIDE PHP Storm, JSHint und Code-Style-Checker f\xfcr halbautomatisiertes Anpassen an\nCodestandards. Immer hilft jedenfalls der direkte Vergleich des alten Stands zum\nneuen. Auch visuelle Regression Tests mit Hilfe von Screenshots und Diff-Tools\nk\xf6nnen vor allem CSS und HTML Refactorings unterst\xfctzen. Und zu guter letzt\nw\xfcnschen wir uns noch einen HTML Regression-Checker als Tool f\xfcr\nMarkup-Refactorings.