nicht angemeldet
Halihallo Thomas
Ich versuche mal meine Gedanken zum Thema etwas zusammenzufassen. Die Antworten passen auch nicht immer zwingend auf deine Frage.
bei meinem Projekt komme ich langsam auf die Idee, mal nachzufragen, wieviele Programmzeilen IHR schon in PHP in einem Script inclusive der Includes gewagt habt.
Nun, mit PHP habe ich mich bisher an keine grösseren Projekte gewagt, aber vielleicht interessiert dich ein vergleichbares Projekt in Perl. Bei dem grössten Projekt ist die LOC ca. 44700 (an die 670 A4 Seiten Code), wobei ich mich hier lulu anschliessen kann und zugeben muss, dass wohl ca. 10000 LOC inaktiv sind (wie in der DNA). Es ist eine Kunst, ein Projekt über ein Jahr u. mehr umzusetzen und dann keine überflüssigen Zeilen zu haben; besonders wenn die Aufgabenstellung in der Entwicklungsphase noch ändert (was eigentlich (fast) immer der Fall ist und eine der grössten Gefahren hervorruft; nicht 100% durchdachte Schemata, sowohl in der Speicherung, als auch in der Verarbeitung).
Wo sollte man da die Grenze ziehen?
Eigentlich keine. Ich würde das Problem auf etwas anderes reduzieren: Die Gesamtmenge an LOC spielt keine Rolle, wichtig ist, dass jeder Prozess/Programm nur jene beansprucht, welche auch zwingend notwendig sind; dies erreicht man durch ein intelligentes splitten einzelner "Problemkreise" (modularer Aufbau, Klassen, Templates, ...). Christian hat mit seiner Argumentation recht, "So niedrig wie moeglich aber so hoch wie noetig.", einfach das laden, was auch notwendig ist, nicht mehr und nicht weniger; die gesamtsumme aller LOC des Projektes ist nicht relevant (ich bin sogar der Meinung, dass die Anzahl LOC einer Programminstanz nicht von grosser Relevanz ist [es sei denn, man übertreibt es]). Es ist klar, das bei einem grossen Projekt viele Module, viele Templates und und und geladen werden muss, aber um das kommt auch niemand herum, die Frage ("habe ich zuviel oder zuwenig LOC?") stellt sich eigentlich gar nicht.
Ich würde mal darauf tippen, dass es lediglich eine physikalische Grenze hat, sprich, Speicher voll...
---
Optimieren kann man später auch noch (Module verbessern, verweiste LOC vernichten, ...), aber schon am Anfang möglichst "spärlich" zu programmieren kann verherend sein (mit spärlich meine ich die "code&fix Umsetzung", also wenn DB-Verbindung, dann mach DB-Verbindung; aber kein Gedanke daran, dass die selbe Verbindung/Retrieval auch noch wo anders gebraucht wird und somit "separat" programmiert sein sollte). Eine Software "broken-by-design" ist wesentlich schlimmer, als eine gute Software, welche einfach einige LOC zu viel hat...
---
Bei meinem Projekt habe ich gemerkt, dass die grosse LOC Anzahl auch positiv sein kann. Nich im Bezug auf Performance, Statilität oder Funktionalität, sondern im Bezug auf den Menschen, der die Software überarbeiten/pflegen muss. Die relativ grosse LOC Anzahl meines Projektes rührt wohl daher, dass ich alle "Prozesse" getrennt halte, alles Modular, alles möglichst logisch getrennt. Man könnte sicherlich ca. 50% an LOC einsparen, aber ich tue es nicht. Warum? - Durch die "Gliederung/Modularisierung" hat man einen guten Überblick. Wenn ein Problem entsteht, weiss man, wo man zu suchen hat, da alle "Einheiten" auch gretrennt sind. Die Nachbearbeitung oder gar Redesign ist wesentlich einfacher, als wenn alles "gemischt" ist, da ein Problem/Neuerung an einer Stelle geändert werden muss und nicht bei jedem Auftreten desselben...
---
Abschliessend möchte ich sagen, dass nicht die Quantität, sondern die Qualität von Wichtigkeit ist. Mach dir keine Sorgen um die Quantität deiner Software, ich würde mal behaupten, dass es immer jemand gibt, der noch mehr programmiert (LOC) hat. Viel wichtiger ist, dass die LOC die du hast auch funktionieren ;-)
Eine ziemlich spärliche Aufführung meiner Gedanken zu "zu grossen Projekten". Meine Hauptaussage ist in etwa folgende "Die LOC ist, wenn nicht arg übertrieben oder durch schlechtes Programmieren verursacht, nicht relevant; andere Kriterien der Softwarebewertung sind wesentlich wichtiger" (ja, ich weiss, dass du nicht nach einer Bewertungsgrundlage gefragt hast; wollte dies hier nur kurz festhalten).
Viele Grüsse
Philipp