Какви неща трябва да вземе предвид програмистът, който изпълнява техническите детайли на уеб приложение, преди да направи сайта публичен? Ако [Джеф Атууд](https://softwareengineering.stackexchange.com/users/37/jeff-atwood) може да забрави за [HttpOnly cookies](http://www.codinghorror.com/blog/archives/001167.html), [sitemaps](http://www.codinghorror.com/blog/archives/001174.html), *и* [cross-site request forgeries](http://www.codinghorror.com/blog/archives/001171.html) *всичко това в един и същи сайт*, какво важно нещо мога да забравя и аз?


Мисля за това от гледна точка на уеб разработчика, така че някой друг създава действителния дизайн и съдържание на сайта. Така че, макар че ползваемостта и съдържанието може да са по-важни от платформата, вие, програмистът, нямате голяма дума за това. Това, за което трябва да се притеснявате, е дали вашата реализация на платформата е стабилна, дали работи добре, дали е сигурна и дали отговаря на всички други бизнес цели (като например да не струва твърде скъпо, да не отнема твърде много време за изграждане и да се класира толкова добре в Google, колкото поддържа съдържанието). 


Помислете за това от гледната точка на разработчик, който'е свършил някаква работа за приложения от интранет тип в доста надеждна среда и е на път да направи първия си опит и да пусне потенциално популярен сайт за цялата голяма лоша световна мрежа.


Също така, търся нещо по-конкретно, а не просто неясен "уеб стандарти" отговор. Искам да кажа, че HTML, JavaScript и CSS по HTTP са почти даденост, особено когато вече съм уточнил, че сте професионален уеб разработчик. И така, ако продължим отвъд това, *Кои* стандарти? При какви обстоятелства и защо? **Посочете линк към спецификацията на стандарта.**


Какви технически подробности трябва да вземе предвид програмистът на уеб приложение, преди да направи сайта публично достояние?
===============================================================================================================================


Идеята тук е, че повечето от нас *вече* знаят *повечето* от това, което е включено в този списък. Но може да има само един или два елемента, които не сте разглеждали преди, не разбирате напълно или може би дори не сте чували за тях.
**Интерфейс и потребителски опит**


* Имайте предвид, че браузърите прилагат стандартите непоследователно, и се уверете, че сайтът ви работи сравнително добре във всички основни браузъри. Като минимум тествайте срещу скорошен [Gecko](https://en.wikipedia.org/wiki/Gecko_%28layout_engine%29) енджин ([Firefox](https://firefox.com/)), WebKit енджин ([Safari](https://www.apple.com/safari/) и някои мобилни браузъри), [Chrome](https://www.google.com/chrome), поддържаните от вас [IE браузъри](https://en.wikipedia.org/wiki/Internet_Explorer) (възползвайте се от [Application Compatibility VPC Images](https://www.microsoft.com/Downloads/details.aspx?FamilyID=21eabb90-958f-4b64-b5f1-73d0a413c8ef&displaylang=en)) и [Opera](https://www.opera.com/). Вземете предвид и начина, по който [браузърите визуализират сайта ви](http://www.browsershots.org) в различните операционни системи.
* Помислете как хората могат да използват сайта по друг начин, освен чрез основните браузъри: например мобилни телефони, екранни четци и търсачки. — Някои данни за достъпността: [WAI](https://www.w3.org/WAI/) и [Section508](https://www.section508.gov/), Разработване на мобилни устройства: [MobiForge](http://mobiforge.com/).
* Постановка: Как да разгърнете актуализациите, без да засегнете потребителите си. Разполагайте с една или повече среди за тестване или постановка на разположение, за да прилагате промени в архитектурата, кода или съдържанието за почистване и да гарантирате, че те могат да бъдат внедрени по контролиран начин, без да се наруши нищо. Разполагайте с автоматизиран начин за последващо внедряване на одобрените промени в реалния сайт. Това се прилага най-ефективно в съчетание с използването на система за контрол на версиите (git, Subversion и др.) и механизъм за автоматизирано изграждане (Ant, NAnt и др.).
* Не показвайте недружелюбни грешки директно на потребителя.
* Не поставяйте имейл адресите на потребителите в обикновен текст, тъй като те ще бъдат спамени до смърт.
* Добавете атрибута `rel="nofollow"` към генерираните от потребителите връзки [за да избегнете спам](https://en.wikipedia.org/wiki/Nofollow).
* [Вградете добре обмислени ограничения в сайта си](http://www.codinghorror.com/blog/archives/001228.html) - Това също спада към раздел "Сигурност".
* Научете как да правите [прогресивно подобрение](https://en.wikipedia.org/wiki/Progressive_enhancement).
* [Пренасочване след POST](https://en.wikipedia.org/wiki/Post/Redirect/Get), ако този POST е бил успешен, за да се предотврати повторното подаване на информация.
* Не забравяйте да вземете под внимание достъпността. Това винаги е добра идея, а при определени обстоятелства е [законово изискване](https://www.section508.gov/). [WAI-ARIA](https://www.w3.org/WAI/intro/aria) и [WCAG 2](https://www.w3.org/TR/WCAG20/) са добри източници в тази област.
* Прочетете [Don't Make Me Think](http://www.sensible.com/dmmt.html).
**Сигурност**
* Много е трудно да се усвои, но [Ръководство за разработване на OWASP](https://www.owasp.org/index.php/Category:OWASP_Guide_Project) обхваща сигурността на уебсайтовете от горе до долу.
* Знайте за инжектирането, особено за [SQL injection](https://en.wikipedia.org/wiki/SQL_injection), и как да го предотвратите.
* Никога не се доверявайте на потребителския вход, нито на всичко друго, което идва в заявката (което включва бисквитки и стойности на скрити полета на формуляра!).
* Хешвайте паролите с помощта на [сол](https://security.stackexchange.com/q/21263/396) и използвайте различни соли за редовете си, за да предотвратите дъговите атаки. Използвайте бавен хеширащ алгоритъм, като bcrypt (проверен от времето) или scrypt (още по-силен, но по-нов) ([1](https://www.tarsnap.com/scrypt.html), [2](https://it.slashdot.org/comments.pl?sid=1987632&cid=35149842)), за съхраняване на пароли. ([Как безопасно да съхраняваме парола](http://codahale.com/how-to-safely-store-a-password/)). [NIST също одобрява PBKDF2 за хеширане на пароли](https://security.stackexchange.com/q/7689/396)" и е [FIPS одобрен в .NET](https://security.stackexchange.com/a/2136/396) (повече информация [тук](https://security.stackexchange.com/questions/211/how-to-securely-hash-passwords)). *Избягвайте* директното използване на фамилията MD5 или SHA.
* Не се опитвайте да измисляте своя собствена фантастична система за удостоверяване](<https://stackoverflow.com/questions/1581610/how-can-i-store-my-users-passwords-safely/1581919#1581919>). Толкова е лесно да сбъркате по фини и непроверими начини и дори няма да разберете това, докато не ви хакнат.
* Запознайте се с [правилата за обработка на кредитни карти](https://www.pcisecuritystandards.org/). ([Вижте и този въпрос](https://stackoverflow.com/questions/51094/payment-processors-what-do-i-need-to-know-if-i-want-to-accept-credit-cards-on-m))
* Използвайте [SSL/TLS](https://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt)/[HTTPS](https://en.wikipedia.org/wiki/Session_hijacking#Prevention) за всички сайтове, в които се въвеждат чувствителни данни (като идентификационни данни, лична информация, информация за кредитни карти). [Let's Encrypt](https://letsencrypt.org) е безплатен орган за издаване на сертификати, който може да ви помогне.
* [Предотвратяване на отвличането на сесии](https://en.wikipedia.org/wiki/Session_hijacking#Prevention).
* Избягване на [cross site scripting](https://en.wikipedia.org/wiki/Cross-site_scripting) (XSS).
* Избягване на [cross site request forgeries](https://en.wikipedia.org/wiki/Cross-site_request_forgery) (CSRF).
* Избягване на [Clickjacking](https://en.wikipedia.org/wiki/Clickjacking).
* Поддържайте системата(ите) си в актуално състояние с най-новите пачове.
* Уверете се, че информацията за връзката ви с базата данни е защитена.
* Поддържайте се информирани за най-новите техники за атаки и уязвимости, засягащи вашата платформа.
* Прочетете [The Google Browser Security Handbook](https://code.google.com/archive/p/browsersec/).
* Прочетете [The Web Application Hacker's Handbook](http://amzn.com/0470170778).
* Разгледайте [Принцип на най-малката привилегия](https://en.wikipedia.org/wiki/Principle_of_least_privilege). Опитайте се да стартирате сървъра на приложението си [като некоренен потребител](https://security.stackexchange.com/questions/47576/do-simple-linux-servers-really-need-a-non-root-user-for-security-reasons). ([пример с tomcat](https://tomcat.apache.org/tomcat-8.0-doc/security-howto.html#Non-Tomcat_settings))
* Поставете `rel="noopener noreferrer"` на всички връзки, предоставени от потребителя, с `target="_blank"`, за да предотвратите пренасочването на JavaScript на целевата страница към друго място, например към фалшива страница за вход. [Повече информация](https://dev.to/phishing)
* Обмислете използването на [строга политика за сигурност на съдържанието](https://csp.withgoogle.com/docs/index.html).
**Производителност**
* Приложете кеширане, ако е необходимо, разберете и използвайте правилно [HTTP кеширане](https://www.mnot.net/cache_docs/), както и [HTML5 манифест](https://www.w3.org/TR/2011/WD-html5-20110525/offline.html).
* Оптимизирайте изображенията - не използвайте изображение с размер 20 KB за повтарящ се фон.
* Компресирайте съдържанието за по-голяма скорост, вижте [brotli](https://www.smashingmagazine.com/2016/10/next-generation-server-compression-with-brotli/), [gzip/deflate](https://developer.yahoo.com/performance/rules.html#gzip "gzip content") ([deflate е по-добър](https://stackoverflow.com/questions/1574168/gzip-vs-deflate-zlib-revisited)).
* Комбинирайте/конкатенирайте множество таблици със стилове или множество файлове със скриптове, за да намалите броя на връзките с браузъра и да подобрите способността на gzip да компресира дублиранията между файловете.
* Разгледайте сайта [Yahoo Exceptional Performance](https://developer.yahoo.com/performance/), където има много добри насоки, включително за подобряване на производителността на предния край и техния инструмент [YSlow](https://developer.yahoo.com/yslow/) (изисква Firefox, Safari, Chrome или Opera). Също така [Google page speed](https://developers.google.com/speed/docs/best-practices/rules_intro) (използвайте с [browser extension](https://developers.google.com/speed/pagespeed/insights_extensions)) е друг инструмент за профилиране на производителността, който оптимизира и изображенията ви.
* Използвайте [CSS Image Sprites](http://alistapart.com/articles/sprites) за малки свързани изображения, като например ленти с инструменти (вижте точката "минимизиране на HTTP заявките")
* Използвайте [SVG image sprites](https://24ways.org/2014/an-overview-of-svg-sprite-creation-techniques/) за малки свързани изображения като ленти с инструменти. Оцветяването на SVG е малко сложно. Можете да прочетете за него [тук](http://tympanus.net/codrops/2015/07/16/styling-svg-use-content-css/).
* Натоварените уеб сайтове трябва да обмислят [разделяне на компонентите между домейни](https://developer.yahoo.com/performance/rules.html#split). По-конкретно...
* Статичното съдържание (т.е. изображения, CSS, JavaScript и като цяло съдържание, което не се нуждае от достъп до бисквитки) трябва да се намира в отделен домейн *[който не използва бисквитки](https://blog.stackoverflow.com/2009/08/a-few-speed-improvements/)*, тъй като всички бисквитки за даден домейн и неговите поддомейни се изпращат с всяка заявка към домейна и неговите поддомейни. Един добър вариант тук е да се използва мрежа за доставка на съдържание (CDN), но да се обмисли случаят, когато тази CDN може да се провали, като се включат алтернативни CDN или локални копия, които могат да бъдат обслужвани вместо това.
* Намалете до минимум общия брой на HTTP заявките, необходими на браузъра да визуализира страницата.
* Изберете двигател за [шаблони](https://garann.github.io/template-chooser/) и го визуализирайте/предварително компилирайте, като използвате програми за изпълнение на задачи като gulp или grunt
* Уверете се, че в корена на сайта има файл `favicon.ico`, т.е. `/favicon.ico`. [Браузърите ще го поискат автоматично](https://mathiasbynens.be/notes/rel-shortcut-icon), дори ако иконата изобщо не е спомената в HTML. Ако нямате файл `/favicon.ico`, това ще доведе до много 404 съобщения, които ще източат честотната лента на сървъра ви.
**SEO (оптимизация за търсачки)**
* Използвайте URL адреси, удобни за търсещите машини, т.е. използвайте `example.com/pages/45-article-title` вместо `example.com/index.php?page=45`.
* Когато използвате `#` за динамично съдържание, променете `#` на `#!` и след това на сървъра `$_REQUEST["_escaped_fragment_"]` е това, което googlebot използва вместо `#!`. С други думи, `./#!page=1` става `./?_escaped_fragments_=page=1`. Също така, за потребителите, които може да използват FF.b4 или Chromium, `history.pushState({"foo": "bar"}, "About", "./?page=1");` е чудесна команда. Така, въпреки че адресната лента се е променила, страницата не се презарежда. Това ви позволява да използвате `?` вместо `#!`, за да запазите динамичното съдържание, а също така да кажете на сървъра, когато изпращате връзката по имейл, че сме след тази страница, и AJAX не трябва да прави още една допълнителна заявка.
* Не използвайте връзки, които казват ["кликнете тук"](https://ux.stackexchange.com/questions/12100/why-shouldnt-we-use-the-word-here-in-a-textlink). Пропилявате възможност за SEO оптимизация и това затруднява хората с екранни четци.
* Имайте [XML карта на сайта](http://www.sitemaps.org/), за предпочитане в местоположението по подразбиране `/sitemap.xml`.
* Използвайте , когато имате множество URL адреси, които сочат към едно и също съдържание, като този въпрос може да бъде разгледан и от [Google Webmaster Tools](https://www.google.com/webmasters/).
* Използвайте [Google Webmaster Tools](https://www.google.com/webmasters/) и [Bing Webmaster Tools](https://www.bing.com/toolbox/webmaster).
* Инсталирайте [Google Analytics](https://www.google.com/analytics/) още в самото начало (или инструмент за анализ с отворен код като [Piwik](https://piwik.org/)).
* Да знаете как работят [robots.txt](https://en.wikipedia.org/wiki/Robots_exclusion_standard) и паяците на търсачките.
* Пренасочвайте заявките (с помощта на `301 Moved Permanently`) с искане за `www.example.com` към `example.com` (или обратното), за да предотвратите разделянето на класирането в Google между двата сайта.
* Знайте, че може да има паяци с лошо поведение.
* Ако имате нетекстово съдържание, разгледайте разширенията на картата на сайта на Google за видео и др. Има добра информация за това в [отговора на Тим Фарли](https://stackoverflow.com/questions/72394/what-should-a-developer-know-before-building-a-public-web-site#167608).
**Технология**
* Разберете [HTTP](https://www.ietf.org/rfc/rfc2616.txt) и неща като GET, POST, сесии, бисквитки и какво означава да бъдеш "без състояние".
* Напишете вашите [XHTML](https://www.w3.org/TR/xhtml1/)/[HTML](https://www.w3.org/TR/REC-html40/) и [CSS](https://www.w3.org/TR/CSS2/) в съответствие със [спецификациите на W3C](https://www.w3.org/TR/) и се уверете, че те се [валидират](https://validator.w3.org/). Целта тук е да се избегнат странните режими на браузърите и като бонус да се улесни работата с нетрадиционни браузъри, като екранни четци и мобилни устройства.
* Разберете как JavaScript се обработва в браузъра.
* Разберете как се зареждат JavaScript, таблици със стилове и други ресурси, използвани от вашата страница, и вземете предвид тяхното въздействие върху *възприеманата* производителност. В момента се счита за подходящо да [преместите скриптовете в долната част](https://developer.yahoo.com/blogs/ydn/high-performance-sites-rule-6-move-scripts-bottom-7200.html) на вашите страници, като изключения обикновено са неща като приложения за анализ или HTML5 шаблони.
* Разберете как работи пясъчникът на JavaScript, особено ако възнамерявате да използвате iframe.
* Имайте предвид, че JavaScript може да бъде и ще бъде деактивиран и че следователно AJAX е разширение, а не базова линия. Дори ако повечето нормални потребители го оставят включен сега, не забравяйте, че [NoScript](https://noscript.net/) става все по-популярен, мобилните устройства може да не работят според очакванията, а Google няма да изпълнява повечето от вашите JavaScript при индексирането на сайта.
* Научете [разликата между 301 и 302 пренасочвания](http://www.bigoakinc.com/blog/when-to-use-a-301-vs-302-redirect/) (това също е въпрос на SEO оптимизация).
* Научете колкото е възможно повече за вашата платформа за внедряване.
* Обмислете използването на [Reset Style Sheet](https://stackoverflow.com/questions/11578819/css-reset-what-exactly-does-it-do) или [normalize.css](https://necolas.github.com/normalize.css/).
* Обмислете JavaScript рамки (като [jQuery](https://jquery.com/), [MooTools](http://mootools.net/), [Prototype](http://www.prototypejs.org/), [Dojo](https://dojotoolkit.org) или [YUI 3](https://developer.yahoo.com/yui/3/)), които ще скрият много от разликите между браузърите при използването на JavaScript за манипулиране на DOM.
* Като вземете предвид възприетата производителност и JS рамки заедно, помислете за използване на услуга като [Google Libraries API](https://developers.google.com/speed/libraries/devguide) за зареждане на рамки, така че браузърът да може да използва копие на рамката, което вече е кеширал, вместо да изтегля дублиращо копие от вашия сайт.
* Не изобретявайте отново колелото. Преди да направите каквото и да било, потърсете компонент или пример как да го направите. Има 99% вероятност някой да го е направил и да е пуснал OSS версия на кода.
* От друга страна, не започвайте с 20 библиотеки, преди дори да сте решили какви са нуждите ви. Особено в уеб от страна на клиента, където в крайна сметка почти винаги е по-важно нещата да са леки, бързи и гъвкави.
**Поправяне на грешки**
* Разберете, че ще прекарвате 20% от времето си в програмиране и 80% в поддръжка, така че програмирайте съответно.
* Създайте добро решение за докладване на грешки.
* Разполагайте със система, чрез която хората да се свързват с вас с предложения и критики.
* Документирайте начина на работа на приложението за бъдещите служители по поддръжката и хората, извършващи поддръжка.
* Правете често резервни копия! (И се уверете, че тези резервни копия са функционални) Имайте стратегия за възстановяване, а не само стратегия за резервно копие.
* Използвайте система за контрол на версиите, за да съхранявате файловете си, като например [Subversion](https://subversion.apache.org/), [Mercurial](http://mercurial.selenic.com/) или [Git](http://git-scm.org).
* Не забравяйте да извършите тестовете за приемане. Рамки като [Selenium](http://seleniumhq.org/) могат да ви помогнат. Особено ако напълно автоматизирате тестването си, може би чрез използване на инструмент за непрекъснато интегриране, като [Jenkins](https://jenkins-ci.org/).
* Уверете се, че сте въвели достатъчен брой регистри, като използвате рамки като [log4j](https://logging.apache.org/log4j/), [log4net](https://logging.apache.org/log4net/) или [log4r](http://log4r.rubyforge.org/). Ако нещо се обърка на вашия сайт в реално време, трябва да имате начин да разберете какво се случва.
* Когато регистрирате, уверете се, че улавяте както обработените, така и необработените изключения. Отчитайте/анализирайте резултатите от дневника, тъй като те ще ви покажат къде са основните проблеми в сайта ви.
**Други**
* Извършвайте мониторинг и анализ както от страна на сървъра, така и от страна на клиента (единият трябва да е проактивен, а не реактивен).
* Използвайте услуги като UserVoice и Intercom (или други подобни инструменти), за да поддържате постоянна връзка с потребителите си.
* Следвайте [модела за разклоняване на Git](http://nvie.com/posts/a-successful-git-branching-model/) на [Vincent Driessen](http://nvie.com/about/).
Много неща са пропуснати не непременно защото не са полезни отговори, а защото са или твърде подробни, или извън обхвата, или отиват твърде далеч за някой, който иска да получи общ поглед върху нещата, които трябва да знае. Моля, чувствайте се свободни да редактирате и това, вероятно съм пропуснал някои неща или съм допуснал някои грешки.
