[WEBDESIGN] CMS vs. selber programmieren

Macht nur alle RoR, stürzt euch drauf wie die Geier. Lernt nur anhand vorgefertigter Frameworks.
Um so weniger Leute gibt es dann, die den PHP "pur" beherrschen und den ganzen Legacy-Code pflegen können, der sich über die Jahre so angehäuft hat und weiter anhäuft.
 
:D Den will doch niemand pflegen ...
Und wenn er mit Symfony oder 'nem CMS seine Seite aufzieht, dann hat er danach genau so wenig (oder bei einem CMS noch weniger) Ahnung von PHP und kann auch keinen Code pflegen.

Man wird als PHP Programmierer sehr gut bezahlt ... aber das wird man als Prostituierte auch. Spaß macht das sicherlich keinen, außer man hat eine masochistische Ader.

Ich würde lieber für 20€/Stunde weniger arbeiten und dabei Spaß haben und mich an der Schönheit meines Codes erfreuen ;)
 
Oder wie Kraftwerk sagten: "Sie sieht gut aus und Schönheit wird bezahlt." ?

Nein, das einzig wirklich üble an PHP Legacy Code ist, dass nicht wenig von diesem Legacy-Code sich an gar kein Muster hält. Da wird dann im allergrößten Stil HTML mit PHP gemischt. Ein klein wenig PHP-Code innerhalb der "HTML"-Templates kann einem System aber sogar gut tun, sieht man bei Contao. Es kann aber auch zu Schmerzen im Gulliver führen, siehe Magento. Da haste dann mal ne Template-phtml, deren einziger Inhalt sinngemäß <div class="blabla"><?php $this->template;?></div> ist.
 
Also das mit php und html mischen ist aber wieder im kommen. ich habs noch gelernt strikt alles zu trennen (mvc). nun ist aber in das neue typo3 wieder templateing mit html und php angesagt. ich bin auch schon etwas älter und ich kann diesen hype wegen oop und mvc und so weiter gar nicht nachvollziehen. leider finde ich aber auch sehr schlecht jobs deswegen. ich sehe die technik sehr gemischt. viele reden auch gerne sich selbst schön und man darf nicht vergessen das es sehr viele konkurrenz gibt. außerdem ist so ein informatiker und programmierer in der hierarchie sowieso ganz unten. ganz wenige werden sehr reich aber damit ist nicht unbedingt ein sozialer aufstieg verbunden.
 
Der "Informatiker" ist aber nicht wirklich ein Programmierer, also nicht zwangsläufig. Der studierte Herr Informatiker sollte natürlich Ahnung von der Programmierung haben, damit er weiß wie er welches Problem in welcher Sprache wie anzugehen hat. Bzw. sollte wissen welche Probleme man mit welchen Patterns am Besten erschlägt und wie man sie umsetzt. Aber grundsätzlich muss der Herr Informatiker keine Zeile Code schreiben können. An der Uni laufen nicht wenige Informatiker mit 1er Schnitt rum, die Stunden brauchen, um ein kleines Java-Programm zu lesen, aber dafür dir im Detail erklären können wie der Code arbeiten sollte damit er möglichst effizient mit den Ressourcen umgeht oder wie man welche Art von Daten am Besten sortieren sollte.

Einfach ausgedrückt: Der studierte Herr Informatiker entwirft dein Programm in mehr oder weniger theoretischer Form. D.h. (UML-) Diagramme, Texte und sonstige Bilder. Das können insgesamt gut und gerne 100-2000 Seiten sein. Diese Informationssammlung ist so vollständig und detailreich, dass jeder Idiot (hier nun der "Programmierer") sie in ein funktionierendes Programm umsetzen kann. Dabei können diese theoretischen Abhandlungen so generisch sein, dass das Programm wirklich Idiotensicher in x beliebigen Sprachen umgesetzt werden kann, ohne auch nur eine Sekunde nachdenken zu müssen.

Ich persönlich bin aber eher für den Zwischenweg: Wenn ich ein Programm theoretisch ausarbeite und dabei weiß um welche Sprache es sich handeln wird (und natürlich mich in der Sprache und den Frameworks auskenne), kann ich 1. viel präziser formulieren, 2. Optimierungen vornehmen, 3. bei Unklarheiten und Problemen helfen.
Die anderen sind dann eher die reinen Theoretiker, die Algorithmen entwerfen, bei denen dann jeder selbst schauen muss wie einfach oder schwer das in der jeweiligen Sprache zu meistern ist.

Also z.B. für einen Sortieralgorithmus kann auf dem Papier stehen: Jetzt müssen die Elemente A und B getauscht werden (wobei nicht definiert ist, ob diese "Elemente" als Pointer oder Integer oder sonst wie realisiert sind). Oder man macht es konkret für den Anwendungsfall und schreibt: Jetzt müssen die Integer-Werte von A und B die Speicherzellen tauschen.

----

Bzgl. OOP und MVC. Die beiden Konzepte haben erstmal nichts(!) miteinander zu tun. Dieser OOP "Hype" geht schon seit 20 Jahren so ;) Und diese Art der Programmierung hat im Normalfall riesige Vorteile für die Strukturierung der Programme. Also prinzipiell macht es keinen großen Unterschied, ob du in C++ eine Klasse schreibst, oder in C ein Struct, das mit ein paar Pointern auf Funktionen ausgestattet ist ... außer dass die C Version umständlicher in der Handhabung ist.
In Webangelegenheiten (also PHP, Rails, etc.) kann ich dir sogar zum Teil zustimmen. Da würde man vermutlich auch ohne OOP auskommen. Aber sobald das Programm größer wird und es "ähnliche" Datenstrukturen gibt, da will man nicht mehr ohne Vererbung arbeiten. Und sich auch nicht mehr kümmern, ob die aktuelle Funktion zum Datentyp passt oder nicht.

Und MVC (wie auch MVP) sind äußerst praktische Konventionen. Stell dir vor, du hättest eine riesige HTML Seite, an jedem Button würde im "onclick"-Attribut direkt der JavaScript-Code eingebettet sein, den er ausführt und zusätzlich natürlich auch im Style-Attribut der CSS-Code. Also je nach Button könnten da schon gut und gern 10-30 Zeilen Code bei entstehen. Das will niemand (und ist der häßliche Extremfall ;) ).
Der Grund warum es heute so beliebt ist:
1. Du kannst einen Webdesigner hinsetzen, der das Layout übernimmt und CSS schreibt und daneben einen Webprogrammierer, der den JavaScript Code schreibt und beide arbeiten an verschiedenen Dateien und doch an derselben Seite ohne sich in die Quere zu kommen oder durch den Code des anderen behindert zu werden.
2. Angenommen dein MVC Code ist fertig und er stellt eine GUI für einen Desktop PC dar. Und nun willst du noch eine GUI für ein Smartphone bauen. Dank MVC veränderst du ausschließlich den View-Code. Der Controller stellt nämlich schon die passenden Daten bereit und den interessiert es nicht welche du davon nutzt und wie häufig und wo.
3. Dank MVC kann ich mich in fremde Projekte wesentlich schneller einlesen (da ich mich meist ausschließlich für Model und Controller interessiere). Ich schau mir das Model an und stelle fest: Ah, da steht ein Int statt eines Boolean, kein wunder, dass das seltsamen Output produziert. Oder ich schau mir die Methoden im Controller an, ohne dabei von irgendwelchem Markup belästigt zu werden ;)

Natürlich schreibt man sowohl durch OOP als auch durch MVC im Endeffekt meist 5% mehr Code, dafür ist er aber überaus sauber strukturiert (natürlich ein gewisses Maß an Kompetenz vorausgesetzt) und man findet sich unabhängig von der Sprache ziemlich einfach und schnell zurecht.
 
Ich habe BWL an der Fachhochschule studiert und habe mal als HIWI für die UNI programmiert. Das mit dem Informatiker ist doch alles nur Theorie. UML-Diagramme entwerfen.... langweilig. Da muß noch nicht mal was funktionieren. Es muß nur für den Chef schön aussehen. So ähnlch wie Powerpoint-Präsi. Der Untergebene hat das dann zu programmieren (wie ist im ja überlassen). Wegen OOP und MVC naja klingt ja schön und Vererbung ist nichts anderes als total Hierarchie... was genau soll da toll sein?? Meiner Meinung nach ist MVC einfach ein strikte Trennung von Design und Daten und Programm. Wie das genau umgesetzt ist doch egal und eigentlich interessiert es doch auch niemand. Jedenfalls ich finde es okay wenn es einem Informatiker gibt der mir 200 Seiten Diagramme zeichnet solange der Job interessant ist und das Geld stimmt. Die Chefs gucken eh nur auf das Geld und ich glaube auch es gibt sehr viel Totgeburten.
 
Eben. In der realen Welt geht es selten um "wer schreibt den hübschesten Code" sondern "wer setzt das Projekt am schnellsten mit den geforderten Bedingungen um".
Wenn keine der Bedingungen "Wartbarkeit" lautet, dann schreibt man halt sogar mal Spaghetti-Code.
 
Zurück
Oben