haengt auch stark davon ab; bei groesseren projekten fuer kunden lastenheft -> pflichtenheft, bei mittleren und kleineren ueberlege ich mir mal die teile, in die ich die aufgabe unterteilen kann, versuche, die dann soweit zu verfeinern, bis ich eine struktur mit klaren schnittstellen habe, woraus sich die datenstruktur haeufig schon automatisch ergibt. Dabei bin ich gerne dazu bereit, mit komplexeren datenstrukturen zu arbeiten, wenn die logik darauf dafuer einfacher ist.
dann beginne ich, die einzelnen teile mit code zu fuellen, schreibe je nachdem testroutinen dafuer, die ich nach jeder groesseren aenderung drueberlaufen lasse, wobei ich versuche, die daten dafuer moeglichst schraeg und realitaetsnah zu gestalten.
use strict und warnings ist eh klar, bei Bedarf auch -T
Die Code-doku mache ich normalerweise immer in POD, und zwar dann, wenn ich eine Funktion fertig habe. Kommentare nebenbei (meistens bevor ich eine Zeile oder einen Block code; globale Kommentare teilweise auch am Anfang, wenn ich die Subroutinenhierarchie oder aehnliches aufstelle...

Wie macht ihr das mit datenbanken? Nehmt ihr lieber Dateien oder MySQL?
Oder Suchfunktionen? Bei grossen Datenbanken ist das doch Wahnsinn! Entweder man durchsucht eine halbe ewigkeit alle dateien oder man macht eine indexierung. Was wiederrum viel speicherplaty frisst :(

Datenbanken, wenns geht...
Bei einfachen Dingen dürfens dann aber auch schomma Dateien sein.
Vorallem bei Datenbanken in verbindung mit CGI hat sich bei mir so langsam ein System eingestellt. Ich baue dann pro Sheet eine eigene .pl welche alle verschiedene Module einbinden wie das design.pm, das db.pm oder das function.pm
die db.pm wird jedoch mit der Zeit ziemlich lange, wesshalb ich ned weiss ob dies so wahnsinnig optimal ist.
Ich hab auch nie professionell einen Programmierkursus oder so gemacht, wesshalb ich beim Programmieren nicht wirklich Theoretisch was davon versteh. Ich hab ne Idee, eine Vision und dann wird darauflosprogrammiert.
Wenn ich so richtig drin bin, dann muss man auch nicht mit Doku oder so kommen, dafür hab ich dann keine Zeit nebenher, was ich dann am Ende bereue :D
Vorallem bei Tk mag ich es, die verschiedenen Objekte von TK alles in das selbe Hash zu schmeissen. So im Sinne von:
$gui->{LABEL}->{SUCHFUNKTION}->{SUCHTEXT}->{OBJEKT}
wird vielleicht bissel unübersichtlich, aber zum Programmieren und vom Theoretischen Prinzip her, ists überschaulicher. Der Code selber wird dabei halt unansehlich :D
Naja...

Ein wichtiges Prinzip, das ich mir angewöhnt habe, lautet: "Erst mal im CPAN nachschauen". Ich will auf keinen Fall das Rad neu erfinden, daher setze ich stark auf CPAN-Module. Für HTML-Seiten Template oder HTML::Template, für Datenbanken Class::DBI, für CGI-Scripts CGI::Application, CGI::Session::Auth usw.

Damit kann ich mich beim Projekt auf das Wesentliche konzentrieren, nämlich die funktionalen Wünsche des Kunden.

Was mir eben bischen Sorgen macht:
Ich bin an einem Forum dran deren DB aus Dateien besteht.
Es funktioniert bis jetzt wunderbar. Aber wie wird es sein, wenn da mal 20 Leute gleichzeitig drauf zugreifen würden oder eine Suchanfrage starten würden??

PS: Hab mir das programmieren auch selber beigebracht. Meine Ausbildung geht eher Richtung Elektronik

[quote=Free Faq,30.09.2003, 16:35]Ich bin an einem Forum dran deren DB aus Dateien besteht.
Es funktioniert bis jetzt wunderbar. Aber wie wird es sein, wenn da mal 20 Leute gleichzeitig drauf zugreifen würden oder eine Suchanfrage starten würden??[/quote]
worum geht es dir jetzt genau?
ein forum kann wunderbar in dateien abgespeichert sein, die frage
ist, wie es programmiert ist. zum einen musst du natürlich die datei(en)
locken, damit nicht zwei programme gleichzeitig drauf zugreifen, zum anderen
musst du dir überlegen, bei suchanfragen auf einen index zuzugreifen, wenn
du befürchtest, dass das programm zu langsam wird.

Das "betterworld"-Phänomen kenne ich eigentlich nicht, weil ich die grobe Programmstruktur schon mit meinen Testdaten "beschieße" und so erste systematische Fehler finde.

Außerdem lege ich sehr viel Wert auf aussagefähige Fehlermeldungen. Und so finde ich auch recht schnell die Stelle des Übels. Immer nach dem Motto, wo es ein "if" gibt wird es auch immer ein "else" geben, auch wenn man es nicht wahrhaben will.

Daten, die Schnittstellen zwischen Programmteilen passieren, sollten soweit geprüft werden, daß sie keinen Schaden anrichten können.

***

Ich kenne Programmierer, die für alles Datenbanken einsetzen, auch wenn man es in einem simplen File speichern könnte. Man sollte nicht sagen: "entweder File oder Datenbank", sondern für beides offen sein und abwägen. Ich denke, wenn man mit Index-Files anfängt, schreibt man fast schon ein Datenbanksystem, dort sehe ich eine sinnvolle Grenze. Außerdem - Datenbanken verwalten ihre Daten auch nur in Files. Mit Perl kann man sehr gut Daten aus Files parsen, deswegen liebäugeln Perl-Programmierer vielleicht eher mit einem File. In Files lassen sich mehrdimensionale Datenstrukturen weitaus besser speichern, als in Tabellen einer relationalen Datenbank, dort ist es oft nur ein Kompromiß.

[quote=steffenw,30.09.2003, 20:28]In Files lassen sich mehrdimensionale Datenstrukturen weitaus besser speichern, als in Tabellen einer relationalen Datenbank, dort ist es oft nur ein Kompromiß.[/quote]
Ich habe komplexere Datenstrukturen auch schon serialisiert in einem Text- oder Binaerfeld einer Datenbank abgespeichert (z.B. mit Data::Dumper oder Storable), um sie so sehr einfach an mehrere Programme, die auf verschiedenen Maschinen liefen, weitergeben zu koennen...  ;-)\n\n

<!--EDIT|Strat|1064953354-->