Das Schwierige an CSS ist, dass es so einfach ist. Obschon\u00a0leicht erlernt, ist es jedoch schwer zu strukturieren und wirkt oft undurchschaubar. Findet man keinen sauberen Weg, seinen Code zu organisieren, w\u00e4chst die Codemenge oft exponentiell zur Projektl\u00e4nge an.<\/p>\n
In Just Try and Do a Good Job<\/a><\/em> schreibt Chris Coyier, dass er weder Namenskonventionen noch andere spezielle Methodiken nutzt, um sein CSS zu schreiben. Vielmehr versucht er mithilfe seiner Erfahrung und weniger Richtlinien, immer gute Arbeit (a good job)<\/em> zu machen. Er schr\u00e4nkt dabei ein, dass er haupts\u00e4chlich alleine arbeitet und so seinen Stil leicht einhalten kann. F\u00fcr Teams reicht die Arbeitsanweisung \u00bbDo a good job<\/em>\u00ab selten aus. Zumal oft unterschiedliche Vorstellungen davon herrschen, was genau das denn bedeutet, trotz Coding Richtlinien<\/a>.<\/p>\n Das Entwicklungsteam von ZEIT ONLINE hat hier viele, oft schmerzliche Erfahrungen gesammelt. Zu Zeiten des Relaunch 2009 hatten wir f\u00fcr uns einen CSS-Schreibstil entwickelt, der unseren damaligen Arbeitsumst\u00e4nden sehr entgegen kam und am damaligen state of the art<\/em> orientiert war. Leider wissen wir heute, dass wir damit CSS gebaut haben, das zwar gut funktioniert, aber sehr schwierig zu warten ist. Die Weiterentwicklung der Seite f\u00fchrt zu immer mehr Code<\/a>. Da nie ganz klar ist, welcher Code wo noch in Gebrauch ist, ist es gef\u00e4hrlich, eigentlich \u00fcberfl\u00fcssigen Code zu entfernen. Der sogenannte code bloat<\/em> kann die Website-Performance aber schnell verschlechtern<\/a>. Wir haben nat\u00fcrlich immer wieder an dem Problem gearbeitet, aber die gew\u00fcnschten Performance-Werte letztlich nie erreichen k\u00f6nnen \u2013 oder auch nur unsere Entwickler besonders entlasten.<\/p>\n