Які технічні деталі повинен розглянути програміст веб-програми, перш ніж публікувати сайт загальнодоступним?

Які речі повинен розглянути програміст, що реалізує технічні деталі веб-програми, перш ніж публікувати сайт загальнодоступним? Якщо Jeff Atwood можна забути про HttpOnly печиво , сайтмепов , і запит підробки міжсайтових все в тому ж місці , яка важлива річ я міг би забути, а?

Я думаю про це з точки зору веб-розробника, таким чином, щоб хтось інший створював власне дизайн та контент для сайту. Тож зручність та вміст можуть бути важливішими, ніж платформа, але ви, програміст, у цьому мало сказали. Що потрібно турбуватися, - це те, що ваша платформа стабільна, працює добре, захищена та відповідає будь-яким іншим діловим цілям (як, наприклад, не надто багато витрат, створення занадто довго, а також рейтинг у Google, як вміст підтримує).

Подумайте про це з точки зору розробника, який провів певну роботу для додатків типу інтранет в досить надійному середовищі, і ось-ось здійснить свій перший знімок та розміщення потенційно популярного сайту для всієї великої поганої світової мережі.

Крім того, я шукаю щось більш конкретне, ніж просто розпливчасту відповідь "веб-стандартів". Я маю на увазі, HTML, JavaScript і CSS через HTTP - це дуже багато даних, особливо коли я вже вказав, що ви професійний веб-розробник. Отже, виходячи за рамки цього, які стандарти? За яких обставин і чому? Надайте посилання на специфікацію стандарту.

Ідея тут полягає в тому, що більшість з нас вже повинні знати більшість того, що є в цьому списку. Але просто може бути один або два предмети, які ви насправді не вивчали, не розумієте повністю або, можливо, ніколи навіть не чули.

Інтерфейс та досвід користувача

• Майте на увазі, що браузери несумісно застосовують стандарти та переконайтеся, що ваш сайт працює належним чином у всіх основних браузерах. Як мінімум тестування на останній движок Gecko ( Firefox ), двигун WebKit ( Safari та деякі мобільні браузери), Chrome , підтримувані вами браузери IE (скористайтеся програмою сумісності додатків VPC Images ) та Opera . Також розглянемо, як веб-переглядачі відображають ваш сайт у різних операційних системах.
• Поміркуйте, як люди можуть користуватися сайтом, окрім основних веб-переглядачів: мобільних телефонів, зчитувачів екранів та пошукових систем, наприклад. - Деякі відомості про доступність: WAI та Section508 , Мобільна розробка: MobiForge .
• Постановка: як розгорнути оновлення, не впливаючи на користувачів. Доступно одне або більше середовищ для тестування або інсценування, щоб впровадити зміни в архітектуру, код або зміст вмісту та забезпечити їх можливість розгортання контрольованим способом, нічого не порушуючи. Запропонуйте автоматизований спосіб розгортання затверджених змін на веб-сайті в реальному часі. Це найбільш ефективно реалізується спільно з використанням системи управління версіями (git, Subversion тощо) та автоматизованого механізму побудови (Ant, NAnt тощо).
• Не показуйте дружні помилки безпосередньо користувачеві.
• Не вводьте електронні адреси користувачів у звичайний текст, оскільки вони загрожують спамом.
• Додайте атрибут rel="nofollow"до створених користувачем посилань, щоб уникнути спаму .
• Вбудуйте добре продумані обмеження на свій сайт - Це також належить до розділу Безпека.
• Дізнайтеся, як зробити прогресивне вдосконалення .
• Перенаправити після POST, якщо цей POST був успішним, щоб запобігти повторному надсиланню оновлення.
• Не забудьте врахувати доступність. Це завжди гарна ідея, і в певних обставинах це юридична вимога . WAI-ARIA та WCAG 2 - хороші ресурси в цій галузі.
• Читайте Не змушуйте мене думати .

Безпека

• Дайджест багато, але посібник з розробки OWASP висвітлює безпеку веб-сайтів зверху вниз.
• Знайте про ін'єкцію, особливо про ін'єкцію SQL та про те, як запобігти.
• Ніколи не довіряйте введенню користувача, ні чому іншому, що входить у запит (що включає файли cookie та приховані значення поля форми!).
• Зберігайте паролі за допомогою солі та використовуйте різні солі для своїх рядків, щоб запобігти нападам веселки. Використовуйте алгоритм повільного хешування, наприклад bcrypt (перевірений часом) або scrypt (ще сильніший, але новіший) ( 1 , 2 ), для зберігання паролів. ( Як безпечно зберігати пароль ). NIST також стверджує PBKDF2 хеш пароля », і це FIPS затвердженої в .NET (докладніше тут ). Уникайте використання MD5 або SHA сім'ї безпосередньо.
• Не намагайтеся придумати власну систему фантазії аутентифікації . Це така проста річ , щоб отримати так в тонкому і непроверяемую шляху і ви навіть не знаєте, поки після ви зламали.
• Знати правила оформлення кредитних карток . ( Дивіться також це питання )
• Використовуйте SSL / TLS / HTTPS для будь-яких сайтів, де вводяться конфіденційні дані (наприклад, облікові дані, особиста інформація, інформація про кредитну карту). Let's Encrypt - це безкоштовний сертифікат, який може допомогти.
• Запобігання викрадення сеансу .
• Уникайте сценаріїв міжміських сайтів (XSS).
• Уникайте підроблених підписів на веб-сайті (CSRF).
• Уникайте натискань .
• Слідкуйте за оновленнями вашої системи з останніми виправленнями.
• Переконайтеся, що інформація про підключення до вашої бази даних захищена.
• Будьте в курсі останніх методів атаки та вразливості, що впливають на вашу платформу.
• Прочитайте Посібник з безпеки браузера Google .
• Прочитайте посібник з хакера веб-додатків .
• Розглянемо принцип найменшої пільги . Спробуйте запустити свій сервер додатків як некореневий . ( приклад tomcat )
• Розмістіть rel="noopener noreferrer"усі надані користувачем посилання, target="_blank"щоб запобігти переадресації JavaScript на сторінку призначення на інше місце, наприклад, на підроблену сторінку входу. Більше інформації
• Подумайте про використання суворої політики безпеки вмісту .

Продуктивність

• Реалізуйте кешування, якщо необхідно, зрозумійте та використовуйте кешування HTTP належним чином, а також HTML5 Manifest .
• Оптимізуйте зображення - не використовуйте зображення в 20 Кб для повторюваного фону.
• Стисніть вміст для швидкості, див. Brotli , gzip / deflate ( дефляція краще ).
• Поєднайте / об'єднайте кілька таблиць стилів або декілька файлів скриптів, щоб зменшити кількість підключень браузера та покращити можливість gzip стискати дублювання між файлами.
• Ознайомтеся з веб-сайтом виняткової продуктивності Yahoo , безліччю чудових рекомендацій, серед яких поліпшення продуктивності та їх інструмент YSlow (необхідні Firefox, Safari, Chrome або Opera). Також швидкість сторінки Google (використання з розширенням браузера ) є ще одним інструментом для профілювання продуктивності, який також оптимізує ваші зображення.
• Використовуйте графічні спрати CSS для невеликих пов’язаних зображень, таких як панелі інструментів (див. Пункт "мінімізувати запити HTTP")
• Використовуйте SVG зображення спрайтів для невеликих пов’язаних зображень, таких як панелі інструментів. Фарбування SVG трохи складне. Про це можна прочитати тут .
• Зайняті веб-сайти повинні розглянути питання про розподіл компонентів між доменами . Зокрема ...
• Статичний вміст (тобто зображення, CSS, JavaScript і взагалі вміст, який не потребує доступу до файлів cookie) повинен переходити в окремий домен , який не використовує файли cookie , оскільки всі куки для домену та його субдоменів надсилаються з кожним запитом до кожного запиту домен та його піддомени. Одним з хороших варіантів тут є використання мережі доставки вмісту (CDN), але врахуйте випадок, коли цей CDN може вийти з ладу, включивши альтернативні CDN або локальні копії, які можуть подаватися замість цього.
• Зведіть до мінімуму загальну кількість запитів HTTP, необхідних браузеру для надання сторінки.
• Виберіть двигун шаблону та візуалізуйте / попередньо компілюйте його за допомогою завдань, таких як gulp або grunt
• Переконайтеся, що favicon.icoв корені сайту є файл, тобто /favicon.ico. Браузери автоматично запитують його , навіть якщо піктограма зовсім не згадується в 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 не потрібно робити ще один додатковий запит.
• Не використовуйте посилання з написом "натисніть тут" . Ви витрачаєте можливість SEO, і це ускладнює роботу людей із читачами екранів.
• Майте файл Sitemap XML , бажано в місці за замовчуванням /sitemap.xml.
• Якщо <link rel="canonical" ... />у вас є кілька URL-адрес, які вказують на один і той же вміст, цю проблему також можна вирішити з Інструментів Google для веб-майстрів .
• Використовуйте Інструменти Google для веб-майстрів та Інструменти для веб-майстрів Bing .
• Встановіть Google Analytics прямо на початку (або інструмент аналізу з відкритим кодом, наприклад, Piwik ).
• Знайте, як працюють робочі павуки robots.txt та пошукова система.
• Перенаправляти запити ( з використанням 301 Moved Permanently) просити , www.example.comщоб example.com(або навпаки) , щоб запобігти розколу Google Рейтинг між двома сайтами.
• Знайте, що там можуть бути павуки з поганим поводженням.
• Якщо у вас є нетекстовий контент заглянути в розширення карти сайту Google, для відео і т.д. Існує багато корисної інформація про це в відповіді Тім Фарел .

Технологія

• Зрозумійте HTTP і такі речі, як GET, POST, сеанси, файли cookie та те, що означає бути без громадянства.
• Напишіть свої XHTML / HTML та CSS відповідно до специфікацій W3C і переконайтесь, що вони підтверджені . Мета полягає в тому, щоб уникнути режимів вигадок у веб-переглядачах і, як бонус, полегшити роботу з нетрадиційними браузерами, такими як зчитувачі екрану та мобільні пристрої.
• Зрозумійте, як обробляється JavaScript у браузері.
• Зрозумійте, як завантажуються JavaScript, таблиці стилів та інші ресурси, використовувані вашою сторінкою, і врахуйте їх вплив на сприйняті показники. Зараз широко вважається доцільним переміщення скриптів у нижню частину сторінок, за винятком випадків, таких як програми для аналітики або прошивки HTML5.
• Зрозумійте, як працює пісочниця JavaScript, особливо якщо ви маєте намір використовувати рамки iframes.
• Майте на увазі, що JavaScript може і буде відключений, і тому AJAX - це розширення, а не базовий рівень. Навіть якщо більшість звичайних користувачів зараз залишають це, пам’ятайте, що NoScript стає все більш популярним, мобільні пристрої можуть працювати не так, як очікувалося, і Google не буде запускати більшість вашого JavaScript при індексації сайту.
• Дізнайтеся про різницю між переадресаціями 301 та 302 (це також проблема SEO).
• Дізнайтеся якнайбільше про платформу розгортання.
• Подумайте про використання таблиці скидання стилів або normalize.css .
• Розгляньте рамки JavaScript (наприклад, jQuery , MooTools , Prototype , Dojo або YUI 3 ), які приховають багато відмінностей браузера при використанні JavaScript для маніпуляцій з DOM.
• Збираючи спільно сприйняті показники продуктивності та рамки JS, подумайте про використання сервісу, такого як API бібліотек Google, для завантаження фреймів, щоб браузер міг використовувати копію рамки, яку він уже кешував, а не завантажувати копію з вашого сайту.
• Не винаходити колесо. Перш ніж робити щось, шукайте компонент або приклад того, як це зробити. Є 99% шансів, що хтось це зробив і випустив версію коду OSS.
• З іншого боку, не починайте з 20 бібліотек, перш ніж ви навіть вирішили, які ваші потреби. Зокрема, в Інтернеті, де майже завжди важливіше зберігати речі легкими, швидкими та гнучкими.

Виправлення помилок

• Зрозумійте, ви витратите 20% часу на кодування і 80% його на підтримку, тому кодуйте відповідно.
• Створіть гарне рішення щодо повідомлення про помилки.
• Створіть систему, щоб люди могли звертатися до вас із пропозиціями та зауваженнями.
• Документуйте, як працює програма для майбутніх служб підтримки та людей, які виконують технічне обслуговування.
• Робіть часті резервні копії! (І переконайтеся, що ці резервні копії функціональні)
• Використовуйте систему контролю версій для зберігання файлів, таких як Subversion , Mercurial або Git .
• Не забудьте зробити тестування на прийняття. Такі рамки, як Selenium, можуть допомогти. Особливо, якщо ви повністю автоматизуєте тестування, можливо, використовуючи інструмент безперервної інтеграції, наприклад Дженкінс .
• Переконайтеся, що у вас є достатня кількість журналів за допомогою фреймів, таких як log4j , log4net або log4r . Якщо на вашому прямому веб-сайті щось піде не так, вам знадобиться спосіб з’ясувати, що.
• Під час реєстрації переконайтеся, що ви записуєте як оброблювані винятки, так і необроблені винятки. Повідомте / проаналізуйте вихід журналу, оскільки він покаже, де є ключові проблеми на вашому сайті.

Інший

• Запровадьте моніторинг та аналітику як на стороні сервера, так і на стороні клієнта (один повинен бути активним, а не реактивним).
• Використовуйте такі послуги, як UserVoice та Intercom (або будь-які інші подібні інструменти), щоб постійно підтримувати зв’язок зі своїми користувачами.
• Дотримуйтесь Вінсент Дріссен «s Git розгалуження модель

Багато речей пропущено не обов'язково тому, що вони не є корисними відповідями, а тому, що вони або занадто деталізовані, поза межами сфери дії, або заходять занадто далеко, щоб хтось шукає, щоб отримати огляд речей, які вони повинні знати. Будь ласка, не соромтесь також редагувати це, я, певно, пропустив деякі речі або допустив деякі помилки.