Von Anonymous Coward am Mi, 8. November 2006 um 01:57 #
Dokumentation ist zwar nice-to-have, wenn sie aktuell und akkurat ist, doch sehen viele diese nicht als notwendig fuer ein gutes Projekt an (mich eingeschlossen). Wenn der Code sehr gut dokumentiert und nach bestimmten Richtlinien gestrickt ist, und selbst das ist nicht immer einfach, dann benoetigt man zur Weiterentwicklung eigtl. keine zusaetzlichen Dokumente. Ein schoenes Beispiel ist GCC: vorbildliche Kommentare, sauberer Code, allerdings auch saubere externe Doku. Diese stimmt allerdings fast mit den Kommentaren im Code ueberein, wenn man das vergleicht. Ich bezweifle stark, dass dieses Dokumentationsprojekt des Kernels grosse Vorteile mit sich bringt, ausser vielleicht die Einstiegshuerde fuer Neulinge zu senken. Das wiederum ist sicherlich auch ein wichtiger Punkt fuer die Initiative. Persoenlich faend ich es besser, man wuerde konkret den Code des Kernels besser dokumentieren, sinnvolle ChangeLog-Eintraege verfassen (auch hier: siehe GCC!) und den ganzen Stil vereinheitlichen. Im Kernel stehen IMO zuviele inkonsistente Kommentare mit "wilder Umgangssprache" (swear-words) und Insider-Informationen/spaesschen, die nicht immer verstaendlich sind. *Das* macht die Entwicklung sicherlich nicht leichter...
Es geht dabei weniger um das Weiterentwickeln des Kernels, als vielmehr ihn zu verwenden zu können (programmierend). Ich will nur wissen was kann der Kernel und wie verwende ich das was er kann. Wenn die Doku aber noch zum Teil 2.2er Technik beschreibt, dann ist das wenig von Nütze und ich muß mich durch den Code hangeln um das zu finden, was ich benutzen will. Nicht jeder Linuxprogrammierer will gleich am Kernel mitarbeiten.
Von Michael Lehmeier am Mi, 8. November 2006 um 10:53 #
Das kann ich so nicht bestätigen. Überall, wo ich mit professioneller Softwareentwicklung in Berührung komme, wird gesagt, dass eine Stunde Dokumentation drei Stunden Entwicklungsarbeit spart. Leider wird auch in Unternehmen oft in Dokumentation gespart, weil das dort kurzfristigen Zeitgewinn bringt. Aber das rächt sich später. Immer.
Reine Codekommentierung bringt zwar etwas, aber nicht genug. Wenn sich später Entwickler wechseln, braucht man normalerweise mehr. Diagramme, Konzeptstudien und ähnliches. Wenn die hier auch nur ein viertel Zeit mehr inwestieren, hätten die bald doppelt bis dreimal so viele Entwickler, die sich für die Entwicklung am Kernel, den GNU Compiler und anderes interessieren.
Das Problem fängt ja schon da an, dass gängige Literratur über C total veraltet ist und man dann erst mal echt blöd guckt, wenn man die meisten Funktionen in Quelltexten nicht aus Büchern kennt. Es haben viel zu wenig Leute Ahnung (mich eingeschlossen) und so wirklich steigt ja fast Keiner mehr durch, ist ja erst gar nicht jede interressante Linuxtechnologie im Standardkernel drinn und was da ist und wie man das nutzt wissen wahrscheinlich > 10% aller Nutzer durchgängig.Volle Zustimmung, an der Dokumentation zu arbeiten ist immer gut.
Nicht jeder Linuxprogrammierer will gleich am Kernel mitarbeiten.
Überall, wo ich mit professioneller Softwareentwicklung in Berührung komme, wird gesagt, dass eine Stunde Dokumentation drei Stunden Entwicklungsarbeit spart. Leider wird auch in Unternehmen oft in Dokumentation gespart, weil das dort kurzfristigen Zeitgewinn bringt. Aber das rächt sich später. Immer.
Reine Codekommentierung bringt zwar etwas, aber nicht genug. Wenn sich später Entwickler wechseln, braucht man normalerweise mehr. Diagramme, Konzeptstudien und ähnliches. Wenn die hier auch nur ein viertel Zeit mehr inwestieren, hätten die bald doppelt bis dreimal so viele Entwickler, die sich für die Entwicklung am Kernel, den GNU Compiler und anderes interessieren.
Es haben viel zu wenig Leute Ahnung (mich eingeschlossen) und so wirklich steigt ja fast Keiner mehr durch, ist ja erst gar nicht jede interressante Linuxtechnologie im Standardkernel drinn und was da ist und wie man das nutzt wissen wahrscheinlich > 10% aller Nutzer durchgängig.Volle Zustimmung, an der Dokumentation zu arbeiten ist immer gut.