Re: Re: Planera projekt
nitro2k01 skrev:
Qimen skrev:
o Bör man ha en speciell mappstruktur och finns det någon slags standard?
Man bör väl ha bilder, stilmallar och html/php-dokument för sig i varsin katalog.
Om du inte använder PHP (eller ASP) + databaser genom querystrings, så kan det vara en idé att skapa mappar med grupper av html-dokument.
Du bör även tänka på att använda absoluta och relativa sökvägar rätt, t ex i en fil:
[url]http://www.doman.se/info1/html/index.html:[/url]
...
<link rel="stylesheet" href="/globalcss/body.css" />
<a href="dokument1.html">Länk</a>
<img src="../images/bild.gif" />
...
Sen vet jag dock inte om det finns nån "officiell" standard, men det tror jag inte, och det har jag aldrig hört talas om.
Okej. Tror min nurvarande mappstruktur är tillräckligt bra då. Brukar köra med: archive_in/ut (för filer som man laddar in, ex plugins samt om man packar upp de så hamnar de i ut), services (där har jag script som körs som service/cron), source (här har jag alla klasser, "drivrutiner" till olika databaser..), logs (lagrar alla loggar som webbprojektet genererar), html (alla grafik som inte ingår i templatedesignen, dvs smilies, gubbar osb..), tmp (sedan en mapp för varje olika templateval, ex. standard, fotbollstema. Sedan i varje sådan mapp har jag mapparna css, images, flash, javascript, templates (själva tmp-filerna) och template_c (de kompilerade template-filerna)).
Qimen skrev:
o Bör man använda något speciellt program?
Vad du använder för program är upp till dig, men om du arbetar professionellt bör det ha ftp-stöd så du kan kolla på det du skapar online, i sin rätta miljö.(Edit: Om det handlar om html i någon form. Det verkar nästan som att det du håller på med är java från din beskrivning) Själv använder jag mest en texteditor med färgkodning, t ex xk, textpad eller emacs.
Okej, mitt fel. Jag menade något program som man kan hålla reda på allt i, ex. buggar/funktioner man tänkt göra osv. Utveckklingsprogram har jag redan skaffat mig favoriter av (dw, zend, eclipse, textpad).
Qimen skrev:
o Hur bör man dokumentera det hela? Ändringslogg?
Detta är något jag har varit dålig själv, men det är en bra idé, och du kommer tacka dig själv senare. Och framför allt: Ta säkerhetskopior med jämna mellanrum!
Jo säkerhetskopier tar jag regelbundet. Själv lägger jag alltid med ett par textfiler i rooten utanför själva projektet. Filer som Changes (med alla ändringar från version till version), Readme (med lite allmän info om projektet och om det är något speciellt man bör tänka på, en fil med vilka som medverkat i projektet, en fil med information om hur accessnivåer fungerar i systemet osv. Tror det duger bra.
Qimen skrev:
o Finns det något smart sätt som man kan lagra/rapportera buggar/säkerhetsfixar/patchar på så att man sedan enkelt att kolla vad som hänt innan och vad de innebar?
Jag har tyvärr aldrig använt något sådant, även om jag borde, men det finns något som heter CVS som du kan kolla närmare på:
http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1
CVS har man hört talas om rätt mycket men aldrig satt sig in. Det får jag nog ta och titta på. Verkar intressant, finns dessutom en bra introduktion där. :) Men innebär CVS att hela projektet är Open-source?
Qimen skrev:
o Hur bör man kommentera i sina filer? har sett att man ibland har /** bla bla */ och ibland bara /* */. Vad innebär dessa?
// är en enradskommentar i C-liknande språk. /* ... */ är en flerradskommentar. /** */ är också en flerradskommentar, med skillnaden att du i java kan använda verktyget javadoc för att skapa en dokumentation, som då skapas utifrån det som står mellan /** och */.
Ah där ser man. Har alltid trott det varit någon slags standard, vet att i java kan man skapa en smart dokumentation men har även använt /** i mina phpscript.
Qimen skrev:
o När man kommenterar funktioner/metoder, någon speciell info man bör ha med?
Jag brukar ha som regel att skriva kort vad metoden tar för input-data och vad den returnerar. Dessutom brukar jag skriva en förklarande kommentar då jag har använt "ad hoc"-lösningar. (Lösningar som innefattar oväntade tekniker)
Det är bra att ha som påminnelse när man tittar på koden en månad senare och inte förstår vad man själv menade.
Att förklara sin kod tycker jag är viktig så att man kommer ihåg vad man gjort samt om någon annan ska kolla på koden och ev. ändra något så att de förstår. Brukar man skriva något speciellt om inputvariabler osv? Har sett i en hel del script där man använder param. :)
Tack för svaren nitro2k01!
Lasp: Jadu, det blir nog inte tyst iaf. :e
