Въпросите на тази тема са толкова широки и разнообразни във възможните подходи, че всеки реалистичен отговор на неизбежни въпроси може само да посочи цялостния път.
Много хора днес искат и се надяват да създадат динамични (базирани на данни) уеб присъствия, чиято архитектура лесно приспособява нови материали, преразглеждане и взаимодействие с посетителите. wikiHow например е динамичен уебсайт. Въпреки че целта на качествените проекти е достъпна за всички усърдни хора, би било грешка да се подценява това, което в крайна сметка е значително предизвикателна задача, особено в техническите обекти на всеки бъдещ проект. Дори и най -простите динамични уеб присъствия изискват достатъчни умения в различни дисциплини.
При постигането на незаменими цели никой не може да се отклони от добрия дизайн на базата данни. Подготовката на себе си само в тази дисциплина е значителен (но не изключителен) обем на работа. След като имаме обобщение на целите на проекта, трябва да си представим разумни средства за тяхното постигане. След това имаме езици за програмиране или инструменти за избор, базирани на визия за идеална архитектура на проекта.
Да видиш цялата картина от самото начало тогава е най -жизненото умение от всички.
Стъпки
Стъпка 1. Осъзнайте мозъка си какви инструменти и процеси ще постигнат вашите цели
Тъй като централното ядро на всяко динамично уеб присъствие е неговата база данни и обработка на данни, първата ни жизненоважна цел е да вземем широкомащабно решение относно механизма за бази данни. Не е добра идея да се надяваме случайно да вземем такова решение само по някакъв привидно, най -разумен първоначален начин.
- Жизненоважната цел на това първо решение е да планираме нашия проект по начин (с инструменти и механизми за бази данни), който да поддържа вашите нужди по целия път през бъдещето, в което, тъй като сте взели правилните първоначални решения, вие ще надграждайте ефективно върху първоначалната си основа, ефективно и без евентуални пречки. Това означава, че в идеалния случай например избраният от вас двигател на базата данни не е просто лесният или на пръв поглед лесен за инсталиране днес; от самото начало трябва да бъде двигател, който да поддържа вашите изисквания за обработка надолу по веригата.
- Понякога търговските съображения влияят допълнително на този избор. Какви двигатели са интензивни (и скъпи) за посещаемост? Какви двигатели са практически безплатни за присъствие в изпълнения, поддържащи целите за обработка, които вашият евентуален проект трябва да поддържа? Като цяло моделът, който трябва да следвате, е да изберете двигателя си въз основа на едно от двете възможни разположения.
- За да направите това, първо трябва да очертаете основните си нужди от таблицата. Професионалист дори няма да се налага да изгражда тази карта (независимо дали са включени стотици или хиляди таблици), защото обикновено веднага ще видят дали архитектурата и бъдещите нужди, които ще трябва да поддържате, са интензивни за четене или писане. След това ще изберете подходяща база данни въз основа на това цялостно разположение и може би по -нататък въз основа на личен вкус и опит, тъй като работата със съответните инструменти за разработка на софтуер може да предскаже. MySQL е обичайният избор за интензивни четения. Много разработчици се стремят към бази данни като PostgreSQL за надеждни внедрения, интензивни за запис. Ние развиваме нашите нагласи към такива жизненоважни инструменти чрез внимателно проучване и като използваме опита от общата индустрия за разработка на софтуер. По принцип разходите могат да бъдат избегнати, тъй като са налични безплатни внедрявания на много добри инструменти. Това, което търсим, е производителност в интензивна среда за четене или писане, надеждност, лекота и минимизиране на администрацията и готова интеграция с бъдещи инструменти за разработка на софтуер.
Стъпка 2. Изберете вашите инструменти за разработка на софтуер
Има два модела, които трябва да се вземат предвид при избора на инструменти за разработка на софтуер. Твърди се, че "лесни" инструменти рядко са всъщност лесни, когато проект неизбежно разчупва моделите за разработка и функционалност, "лесни" инструменти обикновено се ограничават до. Ако искате да направите нещо извън "лесните" инструменти, като например да включите език или параметър за превод в динамично генерирани URL адреси, може да бъде толкова по -трудно да се постигне в "лесните" инструменти, че може да отнеме изключително сложни умения за програмиране, за да колкото да излъжете лесния модел да правите по -сложни неща. Трябва да овладеем инструментите си за изграждане на добри проекти. Това не прави лесните инструменти най -добрият избор или най -сложните инструменти - трудно предложение. Капанът на "лесното" развитие обикновено включва ограничения, които стават много скъпи за преодоляване при неизбежното развитие на проектите. Като цяло възниква огромно разнообразие от такива инструменти, които привидно отговарят на такива нужди. Но моделът на постоянство на инструментите издава очевиден факт за постигането на тази цел; и така, като цяло откриваме, че най -сложните и мощни инструменти, следвайки добрите модели (или наличието на обекти и библиотеки), не само облекчават практически неизбежните препятствия пред лесни инструменти, но също така след това правят „достигането дотам“много по -ясен процес. Когато изследваме обхвата на наличните инструменти, като цяло по -малко изчерпателните модели са представени в първоначалните концепции за разработка, а по -добри концепции се предлагат от по -късно възникналите инструменти (или те няма да имат шанс да оцелеят на пазари, които вече са спечелени). Ако изберем уж лесен инструмент, това, което търсим, е модел на развитие, който е едновременно тромав и без евентуални пречки. Парадоксът за неофита тогава е трудността да видим толкова далеч по пътя, че можем да възприемем програмните препятствия за даден набор от инструменти. Някои хора вярват, че най -добрите инструменти са най -мощните и най -малко ограничаващи по отношение на подхода към проектите. Свободата да развиеш това, което искаш и имаш нужда, често означава разбиване на общия модел на привидно прости инструменти, чиито предизвикателства могат на практика да разбият мозъка на най -опитния и усъвършенстван софтуерен инженер, защото да успееш в такъв обект означава да направиш „простия“модел да направи нещо, което може да няма собствен капацитет за поддържане. Наистина ли "Ruby" например е по -лесен инструмент от основните C ++ или C#? Не. Не наистина, особено ако трябва да счупите простия модел на Ruby, за да осигурите жизненоважна функционалност. Подобно на Ruby, GCC е безплатен за Linux и OSX. Ruby също идва на OSX - просто трябва да го откриете във вашата система. От предполагаемо по -лесните инструменти моят личен избор е Ruby. От наистина сложните инструменти, C ++ и C# ще царуват върховно дълго в бъдещето; и истината е, че това са единствените средства за развитие без препятствия. Затова седнете изправени и се подгответе за сериозно проучване, защото независимо от пътя, който изберете, ще трябва да овладеете не само инструментите си, но и потенциално ограничаващите модели, с които тези инструменти в крайна сметка могат да ви натоварят. Ruby вероятно е много по -чист от почти всички свои "лесни" връстници. C ++ е инструментът за безпрецедентни постижения; и всъщност опитни гурута ще се окажат несравнени проекти вероятно с много по -малко трудности, отколкото биха могли да постигнат същите цели с уж лесен инструмент. В крайна сметка разработчиците, които се отклоняват от това наблюдение, плащат известна цена: или избират най -благоприятния „лесен“инструмент, или се притесняват по -малко за свободата от тежести в най -сложния инструмент. В последния случай овладявате Fast CGI обекти, вземате топката и бягате. Огромни концепции се прилагат често с малко код. Да, простите инструменти правят същото твърдение, но като абстрахират привидната трудност далеч от нас по такива начини, че отклонението от техния обикновено единичен модел поставя много трудни инженерни предизвикателства, в допълнение към недостатъците в производителността, които C ++ разрешава.
Стъпка 3. В хода на решаването на тези въпроси неизбежно трябва да разгледаме основните модели или модели на разработване на проекти от естеството, което желаем да се окажат
Това означава да вземете най -добрата литература за инструменти, които искаме да сравним, и поне да дадем на нашата концепция някаква форма, в която тя би могла да приеме в даден набор от инструменти, в сравнение с други. Преди да изберете Ruby например, може да вземете важни книги като „Езикът за програмиране на Ruby“и „Agile уеб разработка с Rails“. Вашето първоначално проучване трябва не само да овладее достатъчно инструментите, то трябва да предвиди как можете да стигнете до там - как можете да осигурите желаната функционалност с инструмента, който може да изберете. Това е трудна задача за посветения. Ако ще сравнявате предполагаемо лесна среда за разработка с най -доброто от най -добрите, ще трябва да оцените и най -добрите C инструменти. Ако наистина ще бъдете опитен инженер, ще изберете C за неговата свобода от ограничения. Наистина ли C е по -трудно? Не. Синтаксисът е синтаксис. В крайна сметка трябва да овладеете изразяването на същата функционалност; и в действителност, семейството на езиците C е отлично. Трудното при превъзходството в C ++ е да сложите ръце върху моделите, върху които може да се наложи да надграждате. Отлично начало от преди почти 15 години бяха оригиналните компоненти FastCGI, които бяха налични в CPPBuilder на Borland - вероятно все още най -добрият C ++ за Windows. Дори инициаторите на C могат да стигнат далеч с такива обектно -ориентирани подходи, защото общият модел на поддържане на функционалността е вграден в самите неща, с които работите. Вашата работа е далеч по-свободна, отколкото може да бъде в Ruby, например, когато можете да нарушите или надвишите модела Ruby в своя подход. От друга страна, техниките на скелето на Rails ускоряват много работа за неофита, ако и само ако проектът отговаря на общата форма на Ruby and Rails. Въведете например елементарни разпоредби за сигурност, разпознати във всички ваши Ruby интерфейси, и следващото нещо, което знаете, вие пренаписвате хиляда реда автоматично генериран Ruby код за всяка таблица, която вашето приложение договаря. Лесно ли е това? Е, правя го с редактор на Windows, наречен NoteTab Pro, работещ върху Ruby проекти, живеещи в OSX система; и сложните макроси правят ревизиите ми може би за секунда, като персонализират хиляда реда код почти в два пъти повече. Все пак това се отнася до относително проста, основна функционалност, до която един проект е ограничен. Факт е, че в C ++ можем да напишем наши собствени обекти, които се справят с тези задачи наистина универсално - никога няма да се наложи дори да повторите този процес. Така че това са компромисите. В крайна сметка обектно ориентираният C е най -мощният и ефективен. Което означава, че това е и най -малко работа.
Стъпка 4. Независимо от избора на инструменти за програмиране, няма начин да избегнете зависимост от разумно владеене на HTML и CSS
Като цяло опитни разработчици разчитат на W3C.org за жизненоважни материали. уеб страница
Видео - Използвайки тази услуга, може да се сподели част от информацията с YouTube
Съвети
- Тогава жизненоважна част от вашето търсене ще бъде да вземете най -добрите ресурси. Бих започнал с Ruby; и ако искате да превъзхождате, ще трябва да оцените обектно ориентираните езици на C и средите, в които добре написаните проекти ще надминат всички партньори.
- Следователно нищо не може да замени изчерпателното проучване и оценка.
Предупреждения
- Друга пречка за истинското овладяване на прости инструменти е непрофесионалното поведение на много форуми. Има огромна разлика между професионалното ноу-хау и престорено умение, което толкова често може да ви отклони от правия път. Най -добрите източници на информация обикновено са най -успешните връстници, а не мними майстори на уж прости инструменти, които просто се застъпват да се придържат към единствения модел, който им е на разположение. Основната причина, поради която ще изпращате въпроси към форумите, е, че ще трябва да надхвърлите (по този начин да прекъснете) модела, съставен от предполагаемо прост подход. Когато неизбежно се сблъскате с тези нужди, имате нужда от най -добрия съвет.
- Никога не си мислете, че привиден пряк път всъщност ускорява работата. МНОГО често обратното е вярно.
