Այս թեմայի հարցերն այնքան լայն են և բազմազան հնարավոր մոտեցումներում, որ անխուսափելի հարցերի ցանկացած իրատեսական պատասխան կարող է միայն ընդհանուր ճանապարհը ցույց տալ:
Այսօր շատ մարդիկ ցանկանում են և հույս ունեն կառուցել դինամիկ (տվյալների վրա հիմնված) վեբ ներկայություն, որի ճարտարապետությունը պատրաստ է տեղավորել նոր նյութեր, վերանայում և այցելուների փոխազդեցություն: wikiHow, օրինակ, դինամիկ կայք է: Թեև որակյալ նախագծերի նպատակը բոլոր ջանասեր մարդկանց հասանելիության սահմաններում է, սխալ կլիներ թերագնահատել այն, ինչ ի վերջո էապես դժվարին խնդիր է, հատկապես ցանկացած ապագա ծրագրի տեխնիկական օբյեկտներում: Նույնիսկ ամենապարզ դինամիկ վեբ ներկայությունը պահանջում է բավարար հմտություններ տարբեր ոլորտներում:
Հանդիպելով անփոխարինելի նպատակներին ՝ ոչ ոք չի կարող շեղվել տվյալների բազայի լավ ձևավորումից: Մեզ միայն այս կարգապահության մեջ նախապատրաստելը էական (բայց ոչ նախնական) աշխատանք է: Weրագրի նպատակների ամփոփումից հետո մենք պետք է պատկերացնենք դրանց հասնելու հիմնավոր միջոցներ: Այնուհետեւ մենք ունենք ծրագրավորման լեզուներ կամ գործիքներ, որոնք հիմնված են իդեալական նախագծի ճարտարապետության տեսլականի վրա:
Սկզբից ի վեր ամբողջ պատկերը տեսնելը ամենակարևոր հմտությունն է:
Քայլեր
Քայլ 1. Տեղեկացրեք ձեր ուղեղին, թե ինչպիսի գործիքներ և գործընթացներ են իրականացնելու ձեր նպատակները:
Քանի որ ցանկացած դինամիկ վեբ ներկայության կենտրոնական առանցքը տվյալների բազան է և տվյալների մշակումը, մեր առաջին կենսական նպատակը տվյալների բազայի շարժիչի վերաբերյալ հեռահար որոշում կայացնելն է: Լավ գաղափար չէ հույս ունենալ, որ պատահականորեն կկայացնենք նման որոշում ընդամենը ինչ -որ թվացյալ, ամենաիմաստուն սկզբնական եղանակով:
- Այս առաջին որոշման կենսական նպատակը մեր նախագիծն այնպես ծրագրելն է (գործիքներով և տվյալների բազայի շարժիչներով), որը կբավարարի ձեր կարիքները ապագայի ճանապարհին, որի ընթացքում, քանի որ ճիշտ նախնական որոշումներ եք կայացրել, արդյունավետորեն կառուցեք ձեր սկզբնական հիմքի վրա ՝ արդյունավետ և առանց վերջնական խոչընդոտների: Սա նշանակում է, որ, իդեալական օրինակ, ձեր ընտրած տվյալների բազայի շարժիչը ոչ միայն այսօրվա հեշտ կամ թվացյալ պարզ տեղակայումն է. ի սկզբանե այն պետք է լինի շարժիչ, որը կբավարարի վերամշակման ձեր պահանջները:
- Երբեմն առևտրային նկատառումներն ավելի են ազդում նման ընտրությունների վրա: Ո՞ր շարժիչներն են հաճախելի (և ծախսատար) հաճախում: Գործնականում ո՞ր շարժիչներն են անվճար մասնակցություն այն ծրագրերին, որոնք կպահպանեն ձեր վերջնական նախագիծը: Ընդհանրապես, օրինակին պետք է հետևել ՝ շարժիչն ընտրելը ՝ հիմնվելով երկու հնարավոր տատանումներից մեկի վրա:
- Դա անելու համար նախ պետք է գծեք սեղանի ձեր հիմնական կարիքները: Պրոֆեսիոնալին այս քարտեզը (նույնիսկ եթե հարյուրավոր կամ հազարավոր սեղաններ ներգրավված լինեն) կարիք չի լինի կառուցել, քանի որ նրանք սովորաբար անմիջապես կտեսնեն, թե ճարտարապետությունն ու ապագա կարիքները, որոնց պետք է աջակցել, կարդալո՞ւ են, թե՞ գրելու ինտենսիվ: Այնուհետև դուք կընտրեք համապատասխան տվյալների շտեմարան ՝ հիմնված այս ընդհանուր տրամադրվածության վրա, և գուցե այնուհետև ՝ հիմնված անձնական ճաշակի և փորձի վրա, քանի որ համապատասխան ծրագրաշարի մշակման գործիքների հետ աշխատանքը կարող է կանխորոշել: MySQL- ը սովորական ընտրությունն է ընթերցանության ինտենսիվ իրականացման համար: Շատ ծրագրավորողներ դիմում են տվյալների բազաների, ինչպիսիք են PostgreSQL- ը `գրելու հուսալի ինտենսիվ իրականացման համար: Մենք զարգացնում ենք մեր տրամադրվածությունը նման կենսական գործիքների նկատմամբ `մանրակրկիտ հետազոտությամբ և ծրագրերի մշակման ընդհանուր արդյունաբերության փորձի հիման վրա: Generallyախսերից, ընդհանուր առմամբ, կարելի է խուսափել, քանի որ մատչելի են շատ լավ գործիքների անվճար տեղակայումներ: Այն, ինչ մենք փնտրում ենք, կարդալու կամ գրելու ինտենսիվ միջավայրում կատարումն է, հուսալիությունը, կառավարման հեշտությունն ու նվազագույնի հասցնելը և ծրագրային զարգացման հեռանկարային գործիքների հետ պատրաստ ինտեգրումը:
Քայլ 2. Ընտրեք ձեր ծրագրաշարի մշակման գործիքները:
Softwareրագրաշարի մշակման գործիքների ընտրության ժամանակ պետք է հաշվի առնել երկու օրինաչափություն: Ենթադրաբար «հեշտ» գործիքներն իրականում հազվադեպ են հեշտ, երբ նախագիծն անխուսափելիորեն խախտում է զարգացման և ֆունկցիոնալության ձևերը ՝ «հեշտ» գործիքները հիմնականում սահմանափակվում են: Եթե ցանկանում եք ինչ -որ բան անել «հեշտ» գործիքներից այն կողմ, ինչպիսին է լեզուն կամ թարգմանության պարամետրը դինամիկ ձևավորված URL- ներում ներառելը, ապա «հեշտ» գործիքների մեջ դա կատարելը շատ ավելի դժվար կլինի, որ կարող է անհրաժեշտ լինել ծրագրավորման չափազանց բարդ հմտություններ: նույնքան խաբել հեշտ ձևին, որ ավելի բարդ բաներ անես: Մենք պետք է տիրապետենք մեր գործիքներին `լավ նախագծեր կառուցելու համար: Սա հեշտ գործիքները չի դարձնում լավագույն ընտրությունը, կամ ամենաբարդ գործիքները `բարդ առաջարկ: «Հեշտ» զարգացման ծուղակն ընդհանուր առմամբ ներառում է սահմանափակումներ, որոնք շատ ծախսատար են դառնում նախագծերի անխուսափելի էվոլյուցիայի հաղթահարման համար: Ընդհանրապես նման գործիքների հսկայական բազմազանություն է առաջանում ՝ իբր բավարարելով նման կարիքները: Բայց գործիքների համառության օրինակը մատնում է այս նպատակին հասնելու առերևույթ փաստը: Եվ այսպես, ընդհանուր առմամբ, մենք գտնում ենք, որ ամենաբարդ և հզոր գործիքները, որոնք հետևում են լավ օրինակին (կամ օբյեկտների և գրադարանների առկայությանը), ոչ միայն թեթևացնում են հեշտ գործիքների գործնականում անխուսափելի խոչընդոտները, այլ նաև «այնտեղ հասնելն» են դարձնում շատ ավելի պարզ գործընթաց: Երբ մենք ուսումնասիրում ենք առկա գործիքների շրջանակը, ընդհանուր առմամբ ավելի քիչ համապարփակ մոդելներ են ներկայացվում զարգացման սկզբնական հայեցակարգերում, իսկ ավելի լավ հասկացություններ են առաջարկվում հետագայում ծագող գործիքների միջոցով (կամ նրանք հնարավորություն չեն ունենա գոյատևել արդեն շահած շուկաներում): Եթե մենք ընտրում ենք ենթադրաբար հեշտ գործիք, ապա այն, ինչ մենք փնտրում ենք, զարգացման օրինաչափություն է, որը և՛ ծանր է, և՛ առանց վերջնական խոչընդոտների: Այնուհետև նորածնի պարադոքսը ճանապարհին այնքան հեռու տեսնելու դժվարությունն է, որ մենք կարող ենք ընկալել ծրագրավորման խոչընդոտները տվյալ գործիքի հավաքածուի նկատմամբ: Ոմանք կարծում են, որ լավագույն գործիքները ամենահզորն են և ամենաքիչն են սահմանափակում նախագծի մոտեցման առումով: Ազատություն ՝ զարգացնելու այն, ինչ ցանկանում և պետք է, հաճախ նշանակում է կոտրել առերևույթ պարզ գործիքների ընդհանուր մոդելը, որի մարտահրավերները կարող են գործնականում կոտրել ամենահմուտ և բարդ ծրագրային ճարտարագետի ուղեղը, քանի որ նման օբյեկտում հաջողության հասնելը նշանակում է «պարզ» դարձնել: մոդելն անի մի բան, որին կարող է օժանդակելու հայրենական կարողություն չունենալ: Օրինակ, «Ruby» - ն իրո՞ք ավելի հեշտ գործիք է, քան հիմնարար C ++ կամ C#: Ոչ: Իրականում, հատկապես, եթե կենսական ֆունկցիոնալություն ապահովելու համար հարկավոր է կոտրել Ruby- ի պարզ մոդելը: Ինչպես Ruby- ն, GCC- ն անվճար է Linux- ի և OSX- ի համար: Ruby- ն գալիս է նաև OSX- ով. Պարզապես պետք է այն հայտնաբերել ձեր համակարգում: Ենթադրաբար ավելի հեշտ գործիքներից իմ անձնական ընտրությունը Ռուբին է: Իսկապես բարդ գործիքներից C ++ և C# - ը գերիշխելու են երկար ժամանակ ապագայում. և ճշմարտությունն այն է, որ դրանք միակ խոչընդոտներն են զարգացման համար: Ուրեմն նստեք ուղիղ և պատրաստվեք լուրջ ուսումնասիրության, քանի որ անկախ ձեր ընտրած ճանապարհից, դուք ստիպված կլինեք տիրապետել ոչ միայն ձեր գործիքներին, այլև այն պոտենցիալ սահմանափակող մոդելներին, որոնցով այդ գործիքները կարող են ձեզ վերջապես ծանրաբեռնել: Ruby- ն, հավանաբար, շատ ավելի մաքուր է, քան իր գրեթե բոլոր «հեշտ» հասակակիցները: C ++ - ը չծանրաբեռնված գերազանցության գործիք է. և, ըստ էության, փորձառու գուրուները հավանաբար շատ ավելի դժվարությամբ կդառնան անզուգական նախագծեր, քան նրանք կարող են նույն նպատակներին հասնել ենթադրաբար հեշտ գործիքով: Ի վերջո, ծրագրավորողները, ովքեր շեղվում են այս դիտարկումից, որոշակի գին են վճարում. Վերջին դեպքում դուք տիրապետում եք Fast CGI օբյեկտներին, վերցնում եք գնդակը և վազում: Հսկայական հասկացություններ հաճախ իրականացվում են փոքր կոդով: Այո, պարզ գործիքները նույն պնդումն են անում, բայց մեզանից հեռացնելով առերևույթ դժվարությունը այնպես, որ իրենց սովորական ձևից շեղվելը շատ դժվար ինժեներական մարտահրավերներ է առաջացնում, ի լրումն C ++ լուծման կատարման թերությունների:
Քայլ 3. Այս հարցերի լուծման ընթացքում մենք անխուսափելիորեն պետք է քննենք այն բնույթի նախագծերի մշակման հիմնական մոդելները կամ օրինաչափությունները, որոնց մենք ցանկանում ենք հասնել:
Սա նշանակում է ձեռք բերել լավագույն գրականությունը այն գործիքների համար, որոնք մենք ցանկանում ենք համեմատել, և գոնե տալ մեր հայեցակարգին այն ձևը, որով այն կարող է ունենալ տրված գործիքների շարքում, համեմատած մյուսների հետ: Օրինակ ՝ Ruby- ին ընտրելուց առաջ կարող եք վերցնել այնպիսի կարևոր գրքեր, ինչպիսիք են «Ruby ծրագրավորման լեզուն» և «Արագաշարժ վեբ զարգացում երկաթգծերով»: Ձեր նախնական ուսումնասիրությունը ոչ միայն պետք է բավականաչափ տիրապետի գործիքներին, այլև պետք է պատկերացնի, թե ինչպես կարող եք հասնել այնտեղ, ինչպես կարող եք ապահովել ցանկալի ֆունկցիոնալությունը ձեր ընտրած գործիքով: Սա նախաձեռնողի համար սարսափելի խնդիր է: Եթե դուք պատրաստվում եք համեմատել ենթադրաբար հեշտ զարգացման միջավայրը լավագույնի հետ, ապա ստիպված կլինեք գնահատել նաև լավագույն C գործիքները: Եթե դուք իսկապես փորձառու ինժեներ կլինեք, ապա դուք կընտրեք C- ն `սահմանափակումներից ազատվելու համար: Իսկապե՞ս C- ն ավելի դժվար է: Ոչ. Շարահյուսությունը շարահյուսություն է: Ի վերջո, դուք պետք է տիրապետեք նույն ֆունկցիոնալությունը արտահայտելուն. իսկ ճշմարտությամբ, C լեզուների ընտանիքը գերազանց է: C ++ - ում անմիջապես դարպասից դուրս գալու դժվար բանն այն է, որ ձեռքդ դնես այն մոդելների վրա, որոնց վրա կարող ես կառուցվել: Գործնականում 15 տարի առաջ հիանալի սկիզբ հանդիսացավ FastCGI- ի օրիգինալ բաղադրիչները, որոնք առկա էին Borland- ի CPPBuilder- ում, հավանաբար, Windows- ի համար լավագույն C ++ - ն էր: Նույնիսկ C նախաձեռնողները կարող են հեռու գնալ նման օբյեկտային կողմնորոշված մոտեցումներով, քանի որ ֆունկցիոնալության պահպանման ընդհանուր մոդելը կառուցված է հենց այն բաների մեջ, որոնց հետ դուք աշխատում եք: Ձեր աշխատանքը շատ ավելի ազատ է, քան կարող է լինել Ruby- ում, օրինակ, ամեն անգամ, երբ ձեր մոտեցմամբ կարող եք կոտրել կամ գերազանցել Ruby մոդելը: Մյուս կողմից, Rails փայտամածի տեխնիկան արագացնում է շատ աշխատանք նորածինների համար, եթե և միայն այն դեպքում, եթե նախագիծը համապատասխանում է Ruby- ի և Rails- ի ընդհանուր ձևին: Ներկայացրեք, օրինակ, անվտանգության տարրական դրույթներ, որոնք ճանաչված են ձեր բոլոր Ruby ինտերֆեյսերում, և հաջորդ բանը, որ դուք գիտեք, դուք նորից գրում եք հազար տող ավտոմատ գեներացվող Ruby կոդ ձեր դիմումի համաձայնեցված յուրաքանչյուր սեղանի համար: Արդյո՞ք դա հեշտ է: Դե, ես դա անում եմ Windows խմբագրիչով, որը կոչվում է NoteTab Pro, որը գործում է Ruby նախագծերում, որոնք բնակվում են OSX համակարգում. և բարդ մակրոները գուցե մեկ վայրկյանում կատարեն իմ վերանայումը ՝ հարմարեցնելով հազար տող կոդի գրեթե երկու անգամ: Այնուամենայնիվ, սա վերաբերում է համեմատաբար պարզ, հիմնական գործառույթներին, որոնցով նախագիծը սահմանափակված է: Փաստն այն է, որ C ++ - ում մենք կարող ենք գրել մեր սեփական օբյեկտները, որոնք իրականում այս խնդիրներն իրականացնում են: Դուք երբեք ստիպված չեք լինի կրկնօրինակել այս գործընթացը: Այսպիսով, դրանք փոխզիջումներն են: Ի վերջո, օբյեկտին ուղղված C- ն ամենահզորն ու արդյունավետն է: Դա նշանակում է, որ դա նույնպես ամենաքիչ աշխատանքն է:
Քայլ 4. Անկախ ծրագրավորման գործիքների ընտրությունից, ոչ մի կերպ հնարավոր չէ խուսափել HTML- ի և CSS- ի ողջամիտ տիրապետումից կախվածությունից:
Ընդհանրապես, փորձառու մշակողները կենսական նյութի համար ապավինում են W3C.org- ին: ինտերնետային էջ
Տեսանյութ - Այս ծառայությունից օգտվելով ՝ որոշ տեղեկություններ կարող են կիսվել YouTube- ի հետ:
Խորհուրդներ
- Այդ դեպքում ձեր որոնման կարևոր մասն է լինելու ձեռք բերել լավագույն ռեսուրսները: Ես կսկսեի Ռուբիից; և եթե ցանկանում եք գերազանց լինել, դուք պետք է գնահատեք օբյեկտին ուղղված C լեզուները և այն միջավայրերը, որոնցում լավ գրված նախագծերը գերազանցում են բոլոր հասակակիցներին:
- Հետևաբար, ոչինչ չի կարող փոխարինել սպառիչ ուսումնասիրությանը և գնահատմանը:
Գուշացումներ
- Պարզ գործիքների իսկապես տիրապետման հետագա խոչընդոտը բազմաթիվ ֆորումներում ոչ պրոֆեսիոնալ վարքագիծն է: Չափազանց մեծ տարբերություն կա մասնագիտական նոու-հաուի և կեղծ հմտության միջև, որն այնքան հաճախ կարող է ձեզ շեղել ճիշտ ճանապարհից: Տեղեկատվության լավագույն աղբյուրներն, ընդհանուր առմամբ, ամենաարդյունավետ հասակակիցներն են, այլ ոչ թե ենթադրաբար պարզ գործիքների վարպետները, ովքեր պարզապես ջանում են հավատարիմ մնալ իրենց հասանելիք մեկ օրինակին: Հիմնական պատճառը, որ դուք պատրաստվում եք հարցեր ներկայացնել ֆորումներին, այն է, որ դուք պետք է գերազանցեք (դրանով իսկ կոտրեք) ենթադրաբար պարզ մոտեցմամբ կազմված մոդելը: Երբ դուք անխուսափելիորեն բախվում եք այս կարիքների հետ, ձեզ հարկավոր է լավագույն խորհուրդը:
- Այդ դեպքում երբեք մի մտածեք, որ թվացյալ դյուրանցումն իրականում արագացնում է աշխատանքը: Շատ հաճախ հակառակը ճիշտ է:
