Spørgsmålene i dette emne er så brede og varierede i mulige tilgange, at ethvert realistisk svar på uundgåelige spørgsmål kun kan pege på den overordnede vej.
Mange mennesker i dag ønsker og håber at opbygge dynamiske (datadrevne) webpræsentationer, hvis arkitekturer let kan rumme nyt materiale, revision og interaktion fra besøgende. wikiHow er for eksempel et dynamisk websted. Selvom målet om kvalitetsprojekter er inden for rækkevidde for alle flittige mennesker, ville det være en fejl at undervurdere, hvad der i sidste ende er en væsentligt udfordrende opgave, især i de tekniske formål med ethvert potentielt projekt. Selv de enkleste dynamiske webpræsentationer kræver tilstrækkelige færdigheder inden for en række forskellige discipliner.
Når man opfylder uundværlige mål, kan ingen afvige fra godt databasedesign. At forberede os på denne disciplin alene er en betydelig (men ikke en udelukkende) arbejdsgruppe. Når vi har en oversigt over projektmål, skal vi forestille os gode midler til at nå dem. Så har vi programmeringssprog eller værktøjer at vælge, baseret på en vision om ideel projektarkitektur.
At se hele billedet fra begyndelsen, er den vigtigste evne af alle.
Trin
Trin 1. Få din hjerne omkring, hvilken slags værktøjer og processer der vil nå dine mål
Fordi den meget centrale kerne i enhver dynamisk webtilstedeværelse er dens database og behandling af data, er vores første vitale mål at træffe en vidtrækkende beslutning om en databasemotor. Det er ikke en god idé at håbe på tilfældigt at træffe en sådan beslutning på bare en tilsyneladende, mest rimelig indledende måde.
- Det vitale formål med denne første beslutning er at planlægge vores projekt på en måde (med værktøjer og databasemotorer), der vil understøtte dine behov hele vejen igennem en fremtid, hvor du, fordi du tog de rigtige indledende beslutninger, vil bygge effektivt på dit første fundament, effektivt og uden eventuel forhindring. Det betyder, at for eksempel ideelt er den database -motor, du vælger, ikke bare den lette eller tilsyneladende enkle at implementere i dag; fra begyndelsen skal det være en motor, der understøtter dine efterfølgende behandlingskrav.
- Nogle gange påvirker kommercielle hensyn yderligere sådanne valg. Hvilke motorer er tilstedeværelseskrævende (og dyre)? Hvilke motorer er praktisk talt gratis til stede i implementeringer, der opretholder de behandlingsmål, som dit eventuelle projekt skal opfylde? Generelt er det mønster, der skal følges, at vælge din motor baseret på en af to mulige dispositioner.
- For at gøre dette skal du først kortlægge dine grundlæggende bordbehov. En professionel behøver ikke engang at bygge dette kort (uanset om der er involveret hundredvis eller tusinder af tabeller), fordi de normalt umiddelbart vil se, om arkitekturen og fremtidige behov, du skal understøtte, enten er læse- eller skriveintensive. Du vil derefter vælge en passende database baseret på denne overordnede disposition og måske yderligere baseret på personlig smag og erfaring, som arbejde med respektive softwareudviklingsværktøjer kan forudsige. MySQL er det sædvanlige valg til læseintensive implementeringer. Mange udviklere ser til databaser som PostgreSQL for pålidelige skriveintensive implementeringer. Vi udvikler vores dispositioner mod sådanne vitale værktøjer ved omhyggelig forskning og ved at trække på puljen af erfaringer fra den generelle softwareudviklingsindustri. Udgifter kan generelt undgås, fordi der er gratis implementering af meget gode værktøjer. Det, vi leder efter, er ydeevne i enten læse- eller skriveintensive miljøer, pålidelighed, lethed og minimering af administration og klar integration med potentielle softwareudviklingsværktøjer.
Trin 2. Vælg dine softwareudviklingsværktøjer
Der er to mønstre at overveje ved valg af softwareudviklingsværktøjer. Angiveligt er "lette" værktøjer sjældent i virkeligheden lette, når et projekt uundgåeligt bryder udviklingen, og funktionalitetsmønstre er "lette" værktøjer generelt begrænset til. Skulle du have lyst til at gøre noget ud over de "lette" værktøjer, f.eks. At indarbejde et sprog eller en oversættelsesparameter i dynamisk genererede URL'er, kan det være så meget vanskeligere at opnå i de "lette" værktøjer, som det kan tage ekstremt sofistikerede programmeringsevner til som meget som at narre det lette mønster til at gøre mere komplekse ting. Vi skal mestre vores værktøjer til at bygge gode projekter. Dette gør ikke lette værktøjer til det bedste valg eller de mest sofistikerede værktøjer til et vanskeligt forslag. Fælden med "let" udvikling omfatter generelt begrænsninger, som bliver meget dyre at overvinde i den uundgåelige udvikling af projekter. Generelt opstår der et stort udvalg af sådanne værktøjer, der tilsyneladende opfylder sådanne behov. Men mønsteret for værktøjernes vedholdenhed forråder en tilsyneladende kendsgerning ved at have nået dette mål; og derfor finder vi generelt ud af, at de mest sofistikerede og kraftfulde værktøjer, der følger gode mønstre (eller tilgængelighed af objekter og biblioteker), ikke kun afhjælper praktisk talt uundgåelige forhindringer for lette værktøjer, men gør ligeledes derefter "at komme dertil" en langt mere ligetil proces. Når vi undersøger omfanget af tilgængelige værktøjer, præsenteres generelt mindre omfattende modeller i indledende udviklingskoncepter, og bedre koncepter tilbydes af senere opståede værktøjer (eller de ville ikke have en chance for at overleve på markeder, der allerede er vundet). Hvis vi vælger et angiveligt let værktøj, er det, vi leder efter, et udviklingsmønster, der er både besværligt og uden eventuel forhindring. Paradokset for neofyten er så vanskeligheden ved at se så langt hen ad vejen, at vi kan opfatte programmeringshindringer for et givet værktøjssæt. Nogle mennesker mener, at de bedste værktøjer er de mest kraftfulde og de mindst restriktive med hensyn til projekttilgang. Frihed til at udvikle det, du ønsker og har brug for, betyder ofte at bryde den generelle model for tilsyneladende enkle værktøjer, hvis udfordringer praktisk talt kan bryde hjernen hos den mest rutinerede og sofistikerede softwareingeniør, fordi det lykkes med et sådant objekt at gøre det "enkle" model gør noget, den muligvis ikke har nogen indbygget kapacitet til at understøtte. Er "Ruby" for eksempel virkelig et lettere værktøj end grundlæggende C ++ eller C#? Nej. Ikke rigtigt, især hvis du skal bryde den simple model af Ruby for at levere vital funktionalitet. Ligesom Ruby er GCC gratis til Linux og OSX. Ruby kommer også på OSX - du skal bare opdage det på dit system. Af de angiveligt lettere værktøjer er mit personlige valg Ruby. Af de virkelig sofistikerede værktøjer vil C ++ og C# regere øverst længe i fremtiden; og sandheden er, at disse er de eneste redskaber til udvikling uden hindring. Så sæt dig lige op og forbered dig på seriøs undersøgelse, for uanset hvilken vej du vælger, bliver du nødt til ikke kun at beherske dine værktøjer, men de potentielt restriktive modeller, som disse værktøjer i sidste ende kan besværliggøre dig med. Ruby er sandsynligvis langt mere ren end næsten alle sine "lette" jævnaldrende. C ++ er redskabet til ubesværet ekspertise; og faktisk vil garvede guruer vise sig uoverskuelige projekter sandsynligvis med langt mindre besvær, end de kan nå de samme mål med et angiveligt let værktøj. I sidste ende betaler udviklere, der afviger fra denne observation, en vis pris: enten vælger det mest befordrende "lette" værktøj, eller bekymrer sig mindre om friheden for behæftelse i det mest sofistikerede værktøj. I sidstnævnte tilfælde mestrer du hurtige CGI -objekter, tager bolden og løber. Kæmpe koncepter implementeres ofte med lidt kode. Ja, enkle værktøjer gør den samme påstand, men ved at abstrahere tilsyneladende vanskeligheder væk fra os på en sådan måde, at afvigelse fra deres normalt entydige mønster udgør meget vanskelige tekniske udfordringer, udover præstationshandicap, som C ++ løser.
Trin 3. I løbet af at løse disse spørgsmål er vi uundgåeligt nødt til at undersøge de grundlæggende modeller eller mønstre for at udvikle projekter af den art, vi ønsker at vise
Dette betyder at få fat i den bedste litteratur efter værktøjer, vi vil sammenligne, og i det mindste give vores koncept en eller anden form, hvor det kan tage et givet sæt værktøjer i forhold til andre. Inden du f.eks. Vælger Ruby, kan du hente vigtige bøger som "The Ruby Programming Language" og "Agile Web Development with Rails". Din indledende undersøgelse skal ikke kun beherske værktøjerne tilstrækkeligt, den skal forestille dig, hvordan du kan komme dertil - hvordan du kan levere den ønskede funktionalitet med det værktøj, du måtte vælge. Dette er en skræmmende opgave for den indviede. Hvis du vil sammenligne et angiveligt let udviklingsmiljø med det bedste af det bedste, bliver du også nødt til at evaluere de bedste C -værktøjer. Hvis du virkelig vil være en erfaren ingeniør, vælger du C for sin frihed fra begrænsning. Er C virkelig sværere? Nej. Syntaks er syntaks. I sidste ende skal du mestre at udtrykke den samme funktionalitet; og i sandhed er sprogfamilien C fremragende. Det svære ved at udmærke sig lige ud af porten i C ++ er at lægge hænderne på de modeller, du måske skal bygge videre på. En glimrende start for næsten 15 år siden var de originale FastCGI -komponenter, der var tilgængelige i Borlands CPPBuilder - sandsynligvis stadig den bedste C ++ til Windows. Selv C -indviede kan nå langt med sådanne objektorienterede tilgange, fordi den generelle model for opretholdelse af funktionalitet er indbygget i de ting, du arbejder med. Dit arbejde er langt mere fritflydende, end det f.eks. Kan være i Ruby, når du måske bryder eller overskrider Ruby-modellen i din tilgang. På den anden side fremskynder Rails -stilladsteknikker meget arbejde for neofyten, hvis og kun hvis projektet passer til den generelle form af Ruby and Rails. Indfør f.eks. Rudimentære sikkerhedsbestemmelser, der er genkendt i alle dine Ruby-grænseflader, og den næste ting, du ved, skriver du om tusind linjer automatisk genereret Ruby-kode til hver tabel, din applikation forhandler. Er det let? Nå, jeg gør det med en Windows -editor kaldet NoteTab Pro, der fungerer på Ruby -projekter, der er bosat på et OSX -system; og sofistikerede makroer foretager mine revisioner på måske et sekund og tilpasser tusind linjer kode til næsten det dobbelte. Alligevel vedrører dette forholdsvis enkel, grundlæggende funktionalitet, som et projekt er begrænset til. Faktum er, at i C ++ kan vi skrive vores egne objekter, der håndterer disse opgaver virkelig universelt - du ville aldrig engang skulle gentage denne proces. Så det er afvejningerne. I sidste ende er objektorienteret C den mest kraftfulde og effektive. Hvilket betyder, at det også er det mindste arbejde.
Trin 4. Uanset dit valg af programmeringsværktøjer, er der ingen måde at undgå afhængighed af en rimelig beherskelse af HTML og CSS
Generelt er erfarne udviklere afhængige af W3C.org for vigtigt materiale. hjemmeside
Video - Ved at bruge denne service kan nogle oplysninger blive delt med YouTube
Tips
- En vigtig del af din søgen vil derefter være at få fingrene i de bedste ressourcer. Jeg ville starte med Ruby; og hvis du vil udmærke dig, skal du evaluere objektorienterede C-sprog og de miljøer, hvor velskrevne projekter vil udføre alle jævnaldrende.
- Intet kan derfor erstatte udtømmende undersøgelse og evaluering.
Advarsler
- En yderligere hindring for virkelig at mestre simple værktøjer er den uprofessionelle adfærd på mange fora. Der er en enorm forskel mellem professionel knowhow og foregivet dygtighed, som så ofte kan føre dig langt på afveje fra den rigtige vej. De bedste informationskilder er generelt de mest gennemførte jævnaldrende, ikke foregavede mestre i angiveligt simple værktøjer, der simpelthen går ind for at holde sig til det eneste mønster, de har til rådighed. Hovedårsagen til, at du vil stille spørgsmål til fora, er, at du bliver nødt til at overskride (dermed bryde) modellen, der består af den angiveligt simple tilgang. Når du uundgåeligt støder på disse behov, har du brug for det bedste råd.
- Tro aldrig, at en tilsyneladende genvej faktisk fremskynder arbejde. MEGET ofte er det omvendte sandt.
