Back to the Roots - fuer Code mit weniger Frameworks

Back to the Roots - fuer Code mit weniger Frameworks

Als ich meine Ausbildung beendet hatte, war es durchaus noch nicht ungewöhnlich, dass Menschen mit Computern überhaupt nicht umgehen konnten oder mehr als "Texte schreiben" noch gar nicht ging. Damals war jeder, der unter MS-DOS eine Datei kopieren konnte, schon eine IT-Fachkraft. Das hat sich natürlich geändert. Meine Kinder wachsen mit Computern auf und kennen eben auch Linux durch den Raspi, der im Wohnzimmer als Medienserver fungiert. Außerdem kennen die Kids natürlich Android-Tablets und wissen ganz genau, wie man hier an Youtube ran kommt. Oma und Opa gucken dann immer sehr erstaunt, weil die Kids völlig selbstverständlich mit der IT umgehen.

In der Jobwelt hat sich durch den permanenten Umgang mit Computern natürlich auch einiges geändert. Überall schreien Unternehmen nach Fachkräftemangel und während man früher mit MS-DOS-Kenntnissen schon eine coole Sau war, hat sich das heute geändert. Einfach nur Webentwicklung reicht oft nicht mehr. Es muss mindestens eines der folgenden Frameworks beherrscht werden können: Laravel, Symfony oder Zend. Für die Frontend-Programmierung muss es jQuery sein.

Ich persönlich finde diese Entwicklung besorgniserregend. Natürlich ist es wichtig, die Frameworks bedienen zu können. Es ist auch wichtig, über Paketmanagement Programmteile nachinstallieren zu können, damit man nicht das Rad neu erfinden muss, aber ich bin ganz klar ein Anhänger der plain-Lösungen: Ich habe es bereits erlebt, dass zum Ausblenden eines DIV-Containers Jquery in das Projekt mit eingebaut wurde, obwohl die Seite komplett ohne Javascript funktioniert hatte. Der Kundenwunsch legte halt fest, dass ein Info-DIV nach dem Klick auf eine Grafik verschwindet.

Dafür wurden dann die 23kb jQuery geladen. Ein einfacher Befehl wie dieser hier reicht aber auch:

document.getElementByID('infotext').style.display='none';

Und so etwas passiert immer wieder und immer häufiger. Die Programmierer lesen keine Paypal-API mehr, es wird über composer einfach eine entsprechende Klasse nachinstalliert.

Aus wirtschaftlicher Sicht scheint dies erst einmal die logische und richtige Vorgehensweise zu sein. Als Entwickler spart man sich locker zwei bis drei Tage Arbeit, wenn man eine fertige Klasse lädt. Der Projektaufwand lässt sich sicherlich so auch besser einschätzen. Mir stellen sich aber die Nackenhaare hoch, wenn ich an die Abhängigkeiten denke, die mit solchen Aufbauten immer mitgeschleift werden.

Bitte versteht mich nicht falsch: Die Werkzeuge sind vorhanden, also kann und sollte man diese Werkzeuge auch wirklich benutzen. Dennoch kann es nicht schaden, wenn man PHP, SQL, HTML und eben auch Javascript händisch programmieren kann. Denn wirklich oft reicht die Onboard-Lösung von PHP wirklich aus. Die Sprache entwickelt sich ja permanent weiter. Früher mussten wir alle einen RegEx zum Validieren einer Emailadresse benutzen, heute reicht dafür der PHP-Befehl filter_var dafür völlig aus. Dasselbe gilt für IP-Adressen und so weiter.

Worauf möchte ich hinaus? Zuerst sollte man überlegen, ob man das Framework für eine bestimmte Funktion überhaupt benötigt.


Getagged unter: coding,

Kommentare


Ich sehe das wie du. Es sollte öfter vorher geschaut werden, ob es sich lohnt eine große Bibliothek einzubauen. Also ob der Mehrwert gegeben ist. Abgesehen davon, dass Google längere Ladezeiten bestraft, ist es immer gut zu wissen, was da genau passiert. Also nicht einfach Erweiterung xyz installieren, sondern wirklich überlegen: Wird die Arbeit dadurch wirklich weniger oder habe ich nachher ggf. sogar mehr zu tun, weil zu viele Köche öhm Erweiterungen den Brei verderben?
Unterstütze mich:

Willst Du meine Arbeit unterstützen? Sehr schön. Dann rufe doch die folgende Seite auf:
Support Trancefish!

Mixcloud:
Anzeige:
Ähnliche Posts:
login