Warum PHP?

5 Kommentare

Diese Frage habe ich mir letztens gestellt, nach dem ich einige Kritiken über PHP gelesen habe.
Zum Beispiel ist PHP keine echte Objektorientierte Programmiersprache und wird es auch nicht sein, die wahre Stärke von PHP ist das „Templating“ / erstellen von HTML usw.
Naja, an dem Tag war ich auf jeden Fall etwas deprimiert, weil ich PHP doch irgendwo gern gewonnen hab.

Trotz der Argumente dagegen, ist PHP immer noch eine der verbreitetsten Programmiersprachen. Nicht das damit diese Sprache automatisch „gut“ ist, aber das hat schon mal einen gewissen „Community“ Vorteil.

Das wichtigste Argument FÜR PHP ist meiner Meinung nach die grundlegende Einfachheit:
– man kapiert schnell, wie aus dem Code das Ergebnis wird
– man kann auch mit wenig Kenntnissen mal was zusammen stricken

Naja und Einfachheit hat schon immer seinen Reiz. Siehe zum Beispiel das KISS Prinzip: „Keep it simple, stupid“. Ein Prinzip auf das zum Beispiel auch Apple großen Wert legt und damit Erfolg hat.
Genau das ist es, was so eine Sprache verbreitet macht und den ein oder anderen User dann auch mal dazu anregt PHP und CCD unter einen Hut zu bringen.

Mein Fazit – auch wenn PHP nicht die leistungsfähigste, schönste und eleganteste Sprache ist – es macht meistens einfach Spaß damit zu programmieren.
Cheers.

Advertisements

persönliche CCD Reflektion Nr.1

Hinterlasse einen Kommentar

Ich hab schon vor einiger Zeit mir mal die CCD Armbänder bestellt und trage jetzt seit etwa 3 Wochen das rote Band an meinem Arm. Ehrlich gesagt hilft dieses Band wenig, mich während der Arbeit an die Regeln zu erinnern – eher ist es schlechter Code der mich daran erinnert. Ich find die Bänder aber ein bisschen stylisch und hab deshalb auch das schwarze Band ständig an meinem Arm. :-)

Auf jeden Fall bin ich gerade mal die Liste der Prinzipien und Praktiken für den Roten Grad durch gegangen und dabei ist mir mein fatalster Fehler aufgefallen: Ich reflektiere nicht! Das ist auch der Grund, warum ich das Prinzip Favour Composition over Inheritance (FCoI) total unter den Tisch habe fallen lassen. Kein Wunder, dass mir in meinem Posts „private Methoden vermeiden“ nicht aufgefallen ist, dass Vererbung in vielen Fällen gar nicht angebracht ist.

Ansonsten kann ich im Nachhinein sagen, dass ich die anderen Regeln gut einhalten konnte:

  • DRY: Ich liebe dieses Prinzip und es ist mir ins Blut übergegangen. Da muss ich eher aufpassen, dass ich es nicht übertreibe! ;)
  • KISS: Das mach ich meiner Meinung nach sowieso, da ich nicht so der akademische Typ bin und ich zufrieden bin, wenn der Code funktioniert und gut aussieht. Obwohl ich mir vielleicht manchmal mehr Gedanken über eine Lösung machen sollte, anstatt einfach alles auszuprogrammieren. Dies endet nämlich oft in verschachtelten Schleifen die nur noch anhand Ihrer Kommentare zu entziffern sind.
  • Vorsicht vor Optimierung: Davon lass ich generell die Hände weg. Die Gründe sind ähnlich wie im vorherigen Punkt. Die einzige gern gesehene Optimierung ist bei mir Refaktorisierung!
  • Favour Composition over Inheritance (FCoI): Wie schon im einleitenden Text erwähnt, hatte ich diesen Punkt total übersehen. Aber ich denke, dass genau hier zu oft strukturelle Fehler entstehen. Zumindest konnte ich das so bei mir feststellen.
  • Pfadfinderregel beachten: Meiner Meinung nach die beste Regel um alle Praktiken und Prinzipen zu üben: Dreckigen Code aufräumen. Damit gewöhnt man sich schnell ab, selber ekligen Code zu schreiben. Zumindest tut es ganz arg im Hirn weh, wenn man man doch schnell mal etwas hinhackt! ;)
  • Root cause analysis: Das ist eine Sache, an der ich noch einiges arbeiten muss. Denn schneller ist ein Workaround gebaut, als der eigentliche Bug entfernt. Liegt aber auch daran, dass ich in der Dienstleistung und nicht in der Entwicklung arbeite. Da hab ich einfach kein Zeit mit meinem lahmen Rechner die Dependency Projekte zu debuggen, den Fehler zu beheben und dann alles noch hoch zu laden. Wenn es auch noch ganz schlecht läuft, bin ich dann für die Folgefehler verantwortlich und es geht noch mehr Zeit drauf! Meine Alternative: Workaround bauen und den Bug ins Tracking System eintragen.
  • Ein Versionskontrollsystem einsetzen: SVN ist cool! Mehr hab ich nicht zu sagen. Zum Glück darf ich es einfach nur verwenden. (Danke Edu)
  • Erste Refaktorisierungsmuster anwenden: Im roten Grad bedeutet das nur Methoden extrahieren (=> DRY) und Umbenennen. Beides habe ich sehr oft gemacht in letzter Zeit und bin daher ziemlich zufrieden mit mir.
  • Täglich reflektieren: Hatte ich bisher leider vergessen. Vor allem, wenn ich kurz vor Feierabend noch schnell was machen muss und dann einfach keine Lust mehr hab länger zu bleiben. Aber ich denke, dass ich es damit nachgeholt hab. Mal sehen, ob ich es zukünftig besser umsetzen kann.

Mein Fazit: Diese Woche noch roter Grad – nächste Woche widme ich mich dann dem orangenen zu.

es gibt noch viel zu lernen

2 Kommentare

Ich hab schon lange nichts mehr geschrieben. Finde es echt beeindruckend, wie man einen Blog täglich mit neuem Inhalt füllen kann. Geht mit Co-Autoren natürlich einfacher und ist von da her eine super Idee!
Was mich anbetrifft: Zur Zeit hab ich wieder mehr mit Java zu tun und auch hier so manches dazu gelernt. Dazu in meinen folgenden Posts mehr. In PHP hab ich nicht mehr so viel programmiert, mich beschäftigt aber zur Zeit ein Problem, dem ich auch einen eigenen Post widmen möchte.
Damit das mit den neuen Beiträgen aber nicht wieder so ewig daurt, hab ich mir vorgenommen, ab jetzt kurze Posts zu schreiben. Sollte ein größeres Interesse an einem Post bestehen, kann ich ja noch einmal darauf eingehen.