Warum braucht ihr so lange um die neue Webseite zu bauen?

Damit ich sagen kann, was ich will, muss ich etwas ausholen:

Ich bin Software-Entwickler, seit fast 20 Jahren als Hobby, seit elf Jahren professionell. Zuerst war ich in einer Agentur tätig und habe sowohl Shops als auch Websites gebaut -- kleine, wie größere mit mehreren Tausend Bestellungen am Tag. Anschließend war ich für 17 Monate im Portal-Team von Chip Online u.A. für die mobile Website zuständig, die wir in dieser Zeit komplett neu entwickelt haben.

Ich kenne mich also sowohl mit E-Commerce in kleinen und mittleren Bereich als auch wirklich großen Websites aus. Daher wage ich es mir nun anzumaßen, dass Du bei der Anzahl an Shops und Seiten pro Jahr, eher kleinere Projekte gemacht hast und Dir die Erfahrung fehlt, wie umfangreich eine Seite wie gamestar.de sein kann. Chip.de wirkt auf den ersten Blick auch nicht gerade, als ob man damit an die 50 Entwickler beschäftigen könnte, aber glaub mir, dass so viele Leute nötig waren, um die Seite sinnvoll betreiben und weiterentwickeln zu können.

Man unterschätzt sehr schnell, was hier alles drinsteckt und das dahinter komplexe Prozesse stecken können, die sich nicht auf den ersten Blick erkennen lassen.

An Bereichen hätten wir hier: Home, News, Tests, Hardware, anderweitige Artikel, Videos, Community bzw. User generated Content, Forum, Preisvergleich, Spiele-Datenbank, Heftarchiv, Plus, Bilder-Galerien, Umfragen, Suche, Werbung und sicher noch ein paar Sachen, die mir gerade nicht einfallen. Jeder davon hat andere Anforderungen, teilweise überscheidend und sich gegenseitig integrierend. Dazu kommen Social-Media-Integrationen, SEO usw.

Das alles darf man dann auch noch gleich mal zwei rechnen, weil dasselbe Team auch für gamepro.de verantwortlich ist. Das für ist nicht mal zehn Leute eine verdammt große Aufgabe.

 

Weil 80% der Agenturen einfach keinen Plan haben und nur Müll im Web machen, kein Wunder das man immer so lange braucht und jeden Mist zwei mal anpacken muss weil man es beim ersten mal nicht richtig gemacht hat. Webdesigner ist nun mal kein Webentwickler und ich konzentriere mich nur auf Entwickeln, für Designkrams habe ich meine Designer. Diese Trennung gibt es oft nicht.

War ja schon klar das ja jetzt jemand kommt der 100 Jahre Entwicklung in allen Bereichen hinter sich hat und mir einreden will das meine Shops "kleine Projekte" waren. Nun, ich bin verdammt schnell in dem was ich tue, ich komme ursprünglich aus einem ganz anderen Bereich daher fällt mir Webshop Programmierung sehr einfach. Bei den Seiten würde ich dir ja noch zustimmen das es kleine Projekte waren, an den Webshops saß ich ca. ein Monat und wer in einem Monat keinen, selbst komplexen Shop, bauen kann hat in dem Bereich nichts zu suchen.

Ob ein Projekt komplex ist hängt ja wohl eher von den Kenntnissen des Entwicklers ab und nicht von der Realisierungsdauer und wenn du an Chip.de gearbeitet hast, was bitte war denn so komplex? Wir haben wohl einfache unterschiedliche Ansichten was komplex ist.

 

Du weißt doch gar nicht wie es hier intern aussieht, MadCat schon eher.
Ich glaube die Komplexität wird hier auch eher durch diverse Altlasten und schlechte Dokumentation kommen, zudem zu viele Subsysteme, aber gerade sowas macht es eben verdammt komplex. Schau dir allein mal an wie lange der RSS-Feed für den Plus-Podcast gedauert hat. Oder dass die Wertungskästen immer noch nicht aufs neue Design umgestellt sind.

 

Verwechsel nicht die Komplexität mit Aufräumarbeiten. Vieles wurde ja nicht mal selbst entwickelt, wie das Forum z.B.,was ja nicht verkehrt ist, ich finde es immer gut wenn auf durchdachte fertige Lösungen zurückgegriffen wird. Das spart viel Zeit und somit viel Geld.

Versteht mich nicht falsch, ich will hier niemanden ankacken, es war einfach eine Frage interessehalber.
Was ist so komplex? Warum dauert das so lange?

 

Wir hatten mal Steffi Heise, die Leiterin der Webentwickler, bei GameStar TV. Da erzählt sie ein bisschen von der Komplexität unter der Haube und wie der Relaunch vorgeht.
http://www.gamestar.de/videos/games...und-was-macht-ihr-team-gamestar-tv,92585.html

 

Wie willst du denn aufräumen wenn du die Systeme noch brauchst? Hier arbeitet nicht nur die Redaktion, hier arbeiten auch noch andere Abteilungen mit. Da kannst du nicht einfach Tabula Rasa machen.

 

Wir reden hier nicht von Agenturen. Webedia entwickelt gamestar.de und gamepro.de inhouse, eben aufgrund von sehr schlechten Erfahrungen mit gewissen Dienstleistern, die das CMS zu einer Code-Hölle gemacht haben, die Dantes Inferno entsprungen sein könnte. Das Design macht eine Agentur, aber nicht deren Umsetzung. Auch aus gutem Grund. Ich weiß, was Agenturen teils an HTML, CSS und JS verbrechen können -- darauf würde ich mich nie verlassen, sondern das immer Entwicklern überlassen, die auch den Anspruch haben, eine wartbare Lösung zu bauen.

Chip.de trennt UX/VX genauso. Zumindest zu meiner Zeit gab es ein separates UX/VX-Team, die sich um diese Dinge gekümmert haben. Die Team-Mitlieder waren ca. 50:50 in ihrem eigenen Team und zum anderen Teil auf die Entwicklungs-Teams aufgeteilt. Zum anderen waren nicht nur Designs, UX, VX und User-Testing ihre Aufgabe, sondern auch das bauen von HTML und CSS -- auf einem Niveau, das weit über die üblichen Agentur-Klitschen hinaus geht.

Was fällt bei Dir denn unter "Webshop Programmierung"? Eine beliebige Instanz von Magento, Oxid oder Shopware aufzusetzen und anzupassen, ist eine Sache, die in kurzer Zeit möglich ist. Bei Kunden, die aber wesentlich komplexere Anforderungen haben, wie z.B. die Anbindung eines proprietären ERP-Systems, für das es keine vorgefertigten Lösungen gibt oder das Anbinden von zusätzlichen Services im Bestellprozess, die z.T. Shop-Logik komplett umgehen müssen, sind eine ganz andere Baustelle.

Ich habe beides gemacht. Beliebige Standard-Shops, die wirklich in ein paar Wochen fertig waren und Shop-Projekte, die so umfangreich waren, dass bereits die Konzept- und Designphase mehrere Monate in Anspruch genommen haben, während ein oder zwei Kollegen samt mir und der IT-Abteilung des Kunden die Grundlagen für Kommunikation zwischen ERP, Shop und weiteren Drittsystemen zusammengebaut und eine skalierbare Infrastruktur aufgebaut haben. Selbst die Account-Mechanik der Shops musste in diesem Beispiel erweitert und an Services angebunden werden, damit die speziellen Kundenkarten-Daten verwaltet werden konnten -- lag alles im ERP-System.

Ein Shop, der nur einen Monat braucht, hat mit solchen Dingen nicht viel zu tun. Das ist Kleinkram.[/quote]

Projekt-Komplexität hängt vom Kunden und dessen Anforderungen ab. Code-Komplexität liegt in der Verantwortung der Entwickler. Unser Job ist es, für komplexe Probleme einfach Lösungen in Software zu gießen und uns dabei selbst nicht ins Knie zu schießen -- und das ist sehr viel einfacher man glaubt, wie Du sicher weißt. Wart- und skalierbare Lösungen schüttelt man nicht einfach so aus dem Ärmel.

Darf ich fragen, wie Du Deine Shops testest? TDD? BDD? Beides? Welches CI-System nutzt Du? Arbeitest Du an OSS-Projekten mit? Von welchen Programmiersprachen reden wir? PHP? Java?

Zu chip.de: mein Team war zuständig für die Home, News, Artikel, Bilder-Galerien sowie die damals noch getrennten Mobilversionen davon. Das klingt nun zuerst nach Kleinkram. Ist's aber nicht. Dahinter steckt ein riesiges CMS, das in Zusammenarbeit mit dessen Hersteller betrieben wird. Alleine die Möglichkeiten für die Redakteure, in News und Artikeln diverse Features wie dynamische Links zum Preisvergleich, Videos, Bildergalerien usw. einzubinden, ist enorm komplex, weil sie gestalterische Freiheit beim Artikelaufbau brauchen. Das ist kein simples Wordpress. Dazu kamen Anforderungen wie das Anbinden des CMS an ein zentrales Content-Repository, das von einem anderen Team entwickelt wurde, um sich zukünftig vom CMS entkopplen zu können, so dass jedes andere Team ohne Umwege über uns, Zugriff auf alle Daten hat, diese beliebig abfragen und filtern kann usw.

Zwischenrein kommen neue Features, Bug-Fixes, CDN-Anbindungen im CMS (Assets automatisiert hochladen, updaten etc.), interne Umstellungen, Konzern-Bürokratie inkl. Dingen wie "ein hohes Tier von Burda hat einen Vertrag mit einer Social-Media-Agentur aus den USA geschlossen, deren spezielle Facebook-Anbindung muss schnellstens in die News und Artikel eingebunden werden" usw. usw. -- nebenbei haben wir die mobile Website auf ein komplett neues Gerüst gestellt. Später wurde dem Team noch der Preisvergleich aufs Auge gedrückt und im Gegensatz zu den meisten Seiten, die zu diesem Zwecke einfach nur einen Dienst von Günstiger etc. einbinden, ist der Chip-Preisvergleich eine komplette Eigenentwicklung, die vorher ein ganzes Sechs-Mann-Team beschäftigt hat.

Ich kenne Dich nicht und will Dir nicht zu nahe treten, aber anhand Deiner Posts, gewinne ich nicht den Eindruck, dass Du schon mal etwas mit wirklich großen Projekten zu tun hattest.

Ich habe Dir aufgezählt welche Bereiche gamestar.de umfasst und das waren nur die offensichtlichen. Wenn Du anhand dessen immer noch meinst, dass das hier ein kleine Website wäre, die man mal eben so macht, kann ich Dir leider auch nicht mehr helfen.

 

Weniger als früher. Man braucht sich einfach nur mal durchklicken, wie viele unterschiedliche Bereiche die Seite hat. Da sollte eigentlich jeder sehen, wie umfangreich gamestar.de ist.

Die eigentliche Entwicklungszeit für den RSS-Feed wird recht kurz gewesen sein. Großer Vorlauf war da auch nicht nötig. Das Thema ist die Priorisierung und Einplanung von Aufgaben. Das obliegt in dem Fall aber selten den Entwicklern selbst. Entweder hat man einen Kunden, der sagt, was er wann will oder es gibt einen internen Project Owner samt Stakeholdern, die festlegen, welche Tasks wichtig sind und welche ggf. etwas liegenbleiben.

Ich kann heute auch nicht zu meinem Kunden sagen, dass mir Feature A gerade am Hinterteil vorbeigeht und ich jetzt erstmal den Prototypen für eine neue Single Page App baue, weil ich das für wichtiger halte und es mehr Spaß macht.

 

Zudem kann man Gamestar.de ganz sicher auch nicht einfach "platt machen -> relaunchen" so ganz neben dem normalen Betrieb

 

Vollkommen richtig. Der monolitische Ansatz eine solche Seite neuzumachen, ist kompletter Irrsinn. Es dauert zig Monate überhaupt alles umzusetzen und solange betreibt man quasi zwei Seiten gleichzeitig, auch wenn eine davon nicht öffentlich erreichbar ist. Ggf. müssen einige Arbeiten doppelt erledigt werden, weil sie sowohl auf der alten als auch neuen Seite gemacht werden müssen.

Dann kommt Tag X, alles wird umgestellt und die User mögen es nicht, Fehler usw.. Es folgen viele Baustellen gleichzeitig, von Bugs bishin zu Design-Enscheidungen, die negativ aufgenommen werden. Pures Chaos.

Daher hat man sich ja auch entschieden, hier erstmal den Video-Bereich umzustellen, Feedback zu sammeln usw., bevor man überhaupt begann den die restlichen Bereiche umzustellen.

In meinem Projekt haben wir letztes Jahr einen ähnlichen Ansatz verfolgt: die Seite unterteilt sich in einen Portal- und einen Login-Bereich. Aus diversen Gründen, teils merkwürdigen Entscheidungen des Kunden (von denen wir abrieten), war das Portal mobil eine komplett eigene Seite mit eigenen Templates, Styles und Scripts, während der Login-Bereich bereits einen responsiven Ansatz verfolgte. Der Portal-Bereich war außerdem teils in den Styles ausgekoppelt und verfolgte auch im Markup andere Ansätze. Das waren alles Altlasten aus einer unglaublich zeitkritischen und stressigen Launch-Phase, gepaart mit einem Product Owner auf Kundenseite, der im alten Rom vermutlich einer der fiesesten Sklaventreiber überhaupt gewesen wäre.

Kurz gesagt: eine unwartbare Hölle.

Zum Glück gab es inzwischen einen neuen Product Owner, der es uns erlaubt hat, alles neu zu machen. Es fing mit einer neuer Login-Seite an, die den Grundstock für das neue, vereinheitlichte Markup bzw. CSS gelegt hat und wurde Stück für Stück, Seite pro Seite, ausgebaut. Insgesamt hat die Umstellung etwas über ein halbes Jahr gedauert. Dadurch haben wir nun eine solide technische Basis, full responsive mit Flexbox. Einfach zu warten, einfach zu erweitern und besserem Tooling, um schnell neue Kundenwünsche im Frontend umsetzen zu können. Einfach nur neues HTML und CSS zu schreiben, tut's in solchen Fällen aber nicht. Z.T. mussten aufgrund eines höheren Automatisierungsgrades des Markups diverser Seiten, im Backend einige Umstellungen vorgenommen, GUI-Tests anpassen, bishin zu größeren Anpassungen am JavaScript-Teil des Frontends, z.B. vereinheitlichte Direktiven für Layer, Modal-Fenster usw.

Nebenbei wurde Coffeescript zu ES6 umgestellt, das komplette Frontend-Tooling von Gulp auf Webpack umgeschrieben usw. -- immer schön eines nach dem anderen.

Außerdem bedient dieses System insgesamt drei unterschiedlichen Marken des Kunden. Zwei davon sind quasi nur unterschiedliche Skins, die Dritte dagegen hat andere Anforderungen und muss separat bedient werden (ließe sich vereinheitlichen, aber der Kunde will das nicht).

 

Ich habe mal im Berufskolleg rudimentäres Webdesign erlernt, das ist aber viele Jahre her. So eine Seite wie Gamestar baut sich nunmal nicht innerhalb von 2 Tagen auf.
@TitusPullo zeig doch mal ein paar Referenzprojekte?

 

Komisch, du bist selbst keinen Deut besser wenn du hier behauptest du hast schon zig Shop-Seiten in diesem Jahr hochgezogen.
Wer im Glashaus sitzt...

DU hast keine Ahnung was hier alles hinter steckt. ICH habe auch keine Ahnung was hier alles hinter steckt, maße es mir aber nicht an zu sagen, dass das alles doch so einfach wäre.

Und wie mik81 schrieb: Hast du mal Referenzen? ansonsten kann hier ja jeder x-beliebige daher kommen, einen auf dicke Hose machen und sagen was er schon alles so tolles geleistet hat.

 

Ehrlich gesagt, ich habe echt keine Lust darüber zu diskutieren. Ich habe eine einfache Frage gestellt warum es so lange dauert.

Mögliche Antworten wären:

Das dauert so lange weil wir auch das komplette Backend neu machen müssen....
Das dauert so lange weil....
usw.

Stattdessen kommen hier User und wollen eine Diskussion anfangen die so überhaupt nichts mit der Frage zu tun hat. Von ich bin BigPlayer
und habe schon alles mögliche umgesetzt bis hin zu das jemand auch schon rudimentäres HTML gemacht hat. Interessiert mich nicht und wollte ich auch nicht wissen.

1. Gehe ich vom momentanen Stand aus dasa die Seite lediglich responsive gemacht wird.
2. Ich kann natürlich nicht wissen was noch im Hintergrund geändert wird DARUM FRAGE ICH JA
3. Der Vergleich meiner Projekte war darauf bezogen das lediglich Punkt 1 momentan umgesetzt wird.

Wer etwas zur Frage beitragen kann, gerne antworten ansonsten macht euch ein Thread auf und diskutiert dort.

 

Die einfache Antwort weil Gamestar noch Altlasten von vorletzten Design noch hat und Gamestar komplett auf einer Datenbank basiert, zudem wen ich richtig recherchiert hatte die 6 Leute im Webdev die bei Gamestar arbeiten für die Webseiten Gamestar, Gamepro und MeinMMO zuständig sind.

Reicht dir das als einfache Antwort.

 

Die Frage warum es so lange dauert darf man schon stellen. Gerade da es um so wichtige Bereiche wie die Hauptseite geht und die Zeitspanne wirklich schwer zu tolerieren ist. Eine Antwort wird man freilich nicht bekommen.

 

Die Antwort gab es doch schon längst?!
Verhältnismäßig kleines Team für die komplexität und größe der Website. Nicht schön, aber ändern kann es auch keiner der Redaktion oder dergleichen.

 

Dass hier immer nur die Redaktion antwortet, obwohl die Technik der Website eigentlich nicht in ihre Verantwortung fällt, ist auch ein oft geäußerter Kritikpunkt hier im Forum Transparent wäre, wenn ein tatsächlich Verantwortlicher entweder aus dem Entwicklungsteam (wie es in diversen Threads bereits begonnen und dann wieder ohne Ankündigung aufgehört wurde) oder von Webedia eine Roadmap vorlegt.

Stattdessen muss die Redaktion hier immer die Scapegoat spielen, was letztlich keiner Seite weiterhilft...

 

Aber das ändert ja nichts an der Problematik, dass das Entwicklerteam schlicht zu klein ist um diesen Berg Arbeit in einer für die User adäquaten Zeit zu erledigen.

Und wenn ich ehrlich bin, wäre ich Webentwickler und wüsste vom Ton der mir dann hier im Forum von vielen Usern entgegenschlagen würde, ich würde es mir auch zweimal überlegen hier was zu posten. Jeder angekündigte Termin der nicht gehalten wird würde einem doch ständig um die Ohren gehauen werden (siehe das Sales-Team im Forum, auch wenn da sicher noch anderes schiefgelaufen ist). Da schenk ich mir das lieber und stecke die Zeit in was anderes.

 

Stimmt das denn mit den 6 Leuten? 6 Leute für die ganzen Portale, das würde es natürlich erklären
Ihr seid jetzt fast 2 Jahre dran oder?

 

Wieso? Schreib "A Chris Roberts Website" drauf und alles ist geregelt

 

Also als die Gamestar TV Folge Lief waren es 5 Läute das war vor knapp 10 Monaten und dann gab es glaub ich mal eine stellen Ausschreibung im Sommer wo einer gesucht und wen es richtig mitbekommen habe auch gefunden wurde also ja 6 Leute sollten so ungefähr stimmen.

Kann aber auch nur das wieder geben was ich hier so im Forum und aus der einen Gamestar TV Folge mitbekommen habe meine Schlussfolgerungen ziehen also es muss nicht zu 100% stimmen.

 

Dein Erster Post kam so dermaßen plump und aggressiv rüber...
Glaubst du ernshaft da denkt man mit dir noch über eine ordentliche Diskussion nach oder denkt drüber nach dir eine Antwort zu geben?
Man kann das auch vernünfitg formulieren.

Du hast immerhin angefangen von wegen "big Player". Oder warum hast du gleich im ersten Satz erwähnt, dass du ach so toll ein paar Shops und Websites dieses Jahr alleine aufgestellt hast?
Interessiert hier auch niemanden so wirklich.
Die darauffolgenden Antworten haben das dann aufgegriffen...

Solltest echt mal erst an die eigene Nase fassen bevor du hier um die schlägst.

Kann da die Leute aus der Redaktion / dem Webdev team schon verstehen, dass hier keine Antwort kommt wenn man so provokant einen Thread erstellt.

 

Wenn du im Baukastenformat etwas Neues hoch ziehst, hier und da ein paar Anpassungen machst, ansonsten alles beim Alten läßt und die Anforderungen überschaubar sind, sich nicht ändern, keine neuen Infos mitten in der Implementierungsphase hinzu kommen - dann sind Softwareprojekte gleich welcher Art (bin ebenfalls Entwickler, aber nicht fürs Web) überschaubar.

Wenn du aber dem begegnest, was klassisch für Softwareentwicklung ist, nämlich den sogenannten "ist historisch so gewachsen"-Prinzip, wenn Infos mitten in der Implementierungsphase kommen, teilweise auch so gewollt, um Userfeedback peu a peu zu haben, wenn du Chaos in der Datenbank vorfindest und der Versuch sie zu normalisieren dem Entwirren eines gordischen Knotens (also ohne Schwert, wie in der Sage!) enspricht oder der Quadratur des Kreises - dann sitzt du da und denkst dir, warum zur Hölle du dir diesen Job ausgesucht hast ;-)

Stell dir vor Microsoft würde bei Win beschließen eine "Kleinigkeit" zu ändern.
Nur eine Winzigkeit, nämlich das Separationszeichen für Verzeichnisse im Unix-Linux-Stil einzuführen, also so, wie es vor (und nach) ihnen war: Ein Slash, statt eines Backslashes. Kannst du überblicken, was für einen Rattenschwanz an Folgen dies mit sich brächte? Vor allem dann, wenn eine Abwärtskompatibilität gewährleistet werden sollte? Selbst wenn übersetzend-emulierende Mechanismen dazu ausgedacht werden würden, gibt es wegen "ist historisch so gewachsen" eine Unmenge an hard-gecodeten Sachen, wo sie versagten. Am Ende würde nichts mehr funktionieren. Die Sache selbst würde für einen Aussenstehenden aber trivial bis banal erscheinen.

Dasselbe bei Bugs:
Der wahrscheinlich häufigste Bug in jedweder Art von Software ist ein Indexfehler.
Also die Frage, ob man bei 0 oder 1 anfängt zu zählen und ob dann bei 9 oder 10 Schluss ist. Die Sache selbst ist banal, dennoch wird er immer wieder übersehen, geschieht immer wieder - und führt zu Crashes to Desktop, wenn nicht abgefangen. Man erkennt ihn, wenn man z.B. in einer Liste in einem Game auf das letzte Element klickt - und das Game abstürzt. Weil dieses Element das z.B. 17te war, aber den Index 16 hatte bei einer 0-basierten Identifizierung. Die weitere "Logik" vergisst das aber, greift zum menschlichen Zählen (1-basiert) - und das erzeugt den unlösbaren Widerspruch. Das Programm soll etwas tun, was es nicht kann, nämlich das 17te Element highlighten mit dem Index 17, wo der letzte aber 16 ist - und bricht zusammen.

Die Dinge sind scheinbar klein, aber in ihrer Wirkung groß. Und wenn es dann noch viele "kleine" Dinge gibt, dann sind sie äquivalent mit einer gigantischen Sache. Ich fing 1998 mit dem Coden professionell an, würde es mir aber nicht anmaßen die Arbeit der GS-Coder aus der Ferne beurteilen zu können. Ich kann mir aber vorstellen, dass es weder wenig, noch simpel ist.

 

Genau so ist es. Der Post kam so rüber "Ihr seid zu blöd, die Seite gescheit zu programmieren. Guckt mal hier, ich mach das hobbymäßig und hab dieses Jahr schon 10 Webseiten gemacht. Kommt mal in die Pötte!". Arroganter geht es kaum.

DAS. Wenn da jemand so dermaßen dämlich ankommt hätte ich auch keinen Bock mehr, auf irgendwas zu antworten.

 

DU kamst hier als Proll an und meintest, du hättest dieses Jahr 8 Webseiten mal kurz hochgezogen. Na dann zeig doch mal her? Jetzt natürlich auf einmal keine Lust mehr haben zu diskutieren. So funktioniert das nicht und über Gegenwind darfst du dich echt nicht wundern.

 

Ok, krass Weisst du wie lange die schon dran sind? Ich bin jetzt von Thread ausgegangen:

http://www.gamestar.de/xenforo/threads/webseiten-entwicklung-up-date.450819/

Also März 2016, kommt das hin?

 

kommt glaube ich gut hin wobei ich glaube das der Relaunch schon vorher rumgegeistert ist, ich würde locker sagen das von der ersten Idee bis heute mindestens schon 3 Jahre rum sind.

Ich hoffe du fragst nicht auch noch nach der app die kannst du nämlich komplett abschreiben.

 

PHP ist keine Sprache, sondern ein Unfall :P
Es ist die einzige, die ich kenne, die es ernsthaft schafft ein ungeschriebenes Gesetz zu brechen. Der objektorientierte Zugriffsoperator ist mWn überall ein Punkt, der dot-Operator eben. Nur in PHP nicht. Dort steht der Punkt für Konkatenation (!) und der Zugriffsoperator ist das superintuitive " -> " , geklaut vom Referenzzeiger von C. Natürlich muss auch Überladung in PHP nicht nur anders funktionieren, als beim Rest, sondern auch was anderes sein

 

Ich halte von PHP auch nur noch eins: Abstand.

Wobei die ja den Concat-Operator auch nur von Perl geklaut haben, aber anstatt mit der Einführung von OOP in PHP 5 (gut, eigentlich 4, aber da waren Objekte ja nur glorifizierte assoziative Arrays), das mal aufzuräumen, genauso wie so viele andere Unzulänglichkeiten nie oder nur sehr sparsam angegangen wurden. Hab mich vor fast fünf Jahren komplett von PHP verabschiedet und bereue es keine Minute.

Die sprachlichen Unzulänglichkeiten sind eine Sache, dazu kommt die Community. Auf der einen Seite die Frickler, auf der anderen schon fähige Leute, die aber oft sehr arrogant sind. Gerade im Symfony-Umfeld kommt man sich gerne als was besseres vor, dabei ist das Ding auch nur ein überkomplizierter Rails-Klon.

Aber gut, überall gibt's Irre. Die Java-Entwickler abstrahieren in dutzenden Layern sich gerne zu Tode und die Node-Szene benutzt tausende Einzeiler-Module, damit npm auch brav das halbe Internet an Dependencies runterlädt.

 

Code-Obfuscation

 

Perl, die einzige Programmiersprache, die nach einer RSA-Verschlüsselung genauso aussieht wie vorher.

 

Welche Sprache bevorzugst du für Webentwicklung MadCat?

 

Im aktuellen Projekt verwenden wir JRuby, das nativ über die JVM mit dem Java-Teil der Anwendung kommunizieren kann. Klingt cool, ist's aber nur teilweise. Ruby ist eigentlich eine sehr angenehme Sprache, aber die dynamische Typisierung geht mir zunehmend auf den Wecker. Zudem tut sich in der Szene abseits von Rails nicht viel und Rails ist ... bäh. Meta-Programmierung zur Laufzeit gehört verboten. Macht nur Ärger.

Wir planen für nächstes Jahr eine Umstellung von Kotlin. Der vereint die Vorteile einer angenehmen Syntax mit der JVM, Interoperabilität mit Java und einem vernünftigen Typen-System. Außerdem ist's genauso gut in IntelliJ integriert wie Java.

Mein Fokus verschiebt sich jedenfalls zunehmend komplett weg von Script-Sprachen. Geht mir einfach zu sehr auf die Nerven. Wenn ich einfach nur 'ne REST-API oä. schreiben will, würde ich Go nehmen.

Für den Client: ES6 mit Babel. Build über Webpack 3. Wird aber auch neu gemacht, wahrscheinlich mit TypeScript. ES6 mit Flow ist nett, aber so ganz das Wahre ist das IMO nicht.

Die Entscheidung, ob Angular, React oder Vue, ist noch nicht gefallen, aber die Tendenz geht von Angular weg. Ich war letztes Jahr auf der AngularConnect und dieses Jahr auf der Fullstack Conf in Toronto, wo auch Angular eines der Themen war. Google macht das Ding viel zu komplex. Wir erleben in der Firma gerade, dass die Entwickler zunehmend keine Lust mehr auf Angular haben und bei den Kunden verschiebt sich das Interesse auch zunehmend hin zu React.