Apa rincian teknis yang harus dipertimbangkan oleh seorang programmer aplikasi web sebelum membuat situs publik?


2187

Hal-hal apa yang harus dipertimbangkan oleh seorang programmer yang menerapkan perincian teknis dari suatu aplikasi web sebelum membuat situs tersebut publik? Jika Jeff Atwood bisa melupakan HttpOnly cookies , sitemaps , dan pemalsuan permintaan lintas situs di situs yang sama , hal penting apa yang bisa saya lupakan juga?

Saya memikirkan hal ini dari sudut pandang pengembang web, sehingga orang lain membuat desain dan konten yang sebenarnya untuk situs tersebut. Jadi, sementara kegunaan dan konten mungkin lebih penting daripada platform, Anda programmer memiliki sedikit suara dalam hal itu. Yang perlu Anda khawatirkan adalah implementasi platform Anda stabil, berkinerja baik, aman, dan memenuhi semua tujuan bisnis lainnya (seperti tidak membutuhkan biaya terlalu banyak, butuh waktu terlalu lama untuk membangun, dan peringkat juga dengan Google sebagai konten mendukung).

Pikirkan ini dari sudut pandang pengembang yang telah melakukan beberapa pekerjaan untuk aplikasi tipe intranet di lingkungan yang cukup tepercaya, dan akan melakukan tembakan pertamanya dan mengeluarkan situs yang berpotensi populer untuk seluruh web yang luas.

Selain itu, saya mencari sesuatu yang lebih spesifik daripada sekadar respons "standar web" yang tidak jelas. Maksud saya, HTML, JavaScript, dan CSS melalui HTTP cukup banyak diberikan, terutama ketika saya sudah menentukan bahwa Anda adalah pengembang web profesional. Jadi melampaui itu, standar mana ? Dalam keadaan apa, dan mengapa? Berikan tautan ke spesifikasi standar.

Jawaban:


2645

Idenya di sini adalah bahwa sebagian besar dari kita harus sudah tahu sebagian besar dari apa yang ada di daftar ini. Tapi mungkin ada satu atau dua item yang belum pernah Anda lihat sebelumnya, tidak sepenuhnya mengerti, atau mungkin bahkan tidak pernah mendengarnya.

Antarmuka dan Pengalaman Pengguna

  • Ketahuilah bahwa browser menerapkan standar secara tidak konsisten dan memastikan situs Anda berfungsi dengan baik di semua browser utama. Pada uji minimum terhadap mesin Gecko ( Firefox ) baru-baru ini, mesin WebKit ( Safari dan beberapa peramban seluler), Chrome , peramban IE yang didukung (memanfaatkan Gambar Kompatibilitas Aplikasi VPC ), dan Opera . Juga pertimbangkan bagaimana browser merender situs Anda dalam sistem operasi yang berbeda.
  • Pertimbangkan bagaimana orang mungkin menggunakan situs selain dari browser utama: ponsel, pembaca layar dan mesin pencari, misalnya. - Beberapa info aksesibilitas: WAI dan Section508 , Pengembangan seluler: MobiForge .
  • Pementasan: Cara menyebarkan pembaruan tanpa mempengaruhi pengguna Anda. Sediakan satu atau lebih lingkungan pengujian atau pementasan untuk menerapkan perubahan pada arsitektur, kode, atau konten penyapuan dan memastikan bahwa mereka dapat digunakan dengan cara yang terkontrol tanpa merusak apa pun. Miliki cara otomatis untuk menyebarkan perubahan yang disetujui ke situs langsung. Ini paling efektif diimplementasikan bersamaan dengan penggunaan sistem kontrol versi (git, Subversion, dll.) Dan mekanisme pembangunan otomatis (Ant, NAnt, dll.).
  • Jangan tampilkan kesalahan tidak ramah langsung ke pengguna.
  • Jangan masukkan alamat email pengguna dalam teks biasa karena mereka akan dihukum spam.
  • Tambahkan atribut rel="nofollow"ke tautan yang dibuat pengguna untuk menghindari spam .
  • Buat batas yang dipertimbangkan dengan baik ke situs Anda - Ini juga termasuk dalam Keamanan.
  • Pelajari cara melakukan peningkatan progresif .
  • Redirect setelah POST jika POST itu berhasil, untuk mencegah penyegaran mengirimkan kembali.
  • Jangan lupa untuk mempertimbangkan aksesibilitas. Itu selalu merupakan ide yang baik dan dalam kondisi tertentu itu merupakan persyaratan hukum . WAI-ARIA dan WCAG 2 adalah sumber daya yang baik di bidang ini.
  • Baca Jangan Buatku Berpikir .

Keamanan

Performa

  • Menerapkan caching jika perlu, memahami dan menggunakan caching HTTP dengan benar serta HTML5 Manifest .
  • Optimalkan gambar - jangan gunakan gambar 20 KB untuk latar belakang yang berulang.
  • Kompres konten untuk kecepatan, lihat brotli , gzip / deflate ( deflate lebih baik ).
  • Gabungkan / gabungkan beberapa stylesheet atau beberapa file skrip untuk mengurangi jumlah koneksi browser dan meningkatkan kemampuan gzip untuk memampatkan duplikasi antar file.
  • Lihatlah situs Performa Luar Biasa Yahoo , banyak panduan hebat, termasuk meningkatkan kinerja front-end dan alat YSlow mereka (membutuhkan Firefox, Safari, Chrome atau Opera). Selain itu, kecepatan halaman Google (digunakan dengan ekstensi browser ) adalah alat lain untuk profil kinerja, dan juga mengoptimalkan gambar Anda.
  • Gunakan CSS Image Sprite untuk gambar kecil yang terkait seperti bilah alat (lihat titik "perkecil permintaan HTTP")
  • Gunakan sprite gambar SVG untuk gambar terkait kecil seperti bilah alat. Pewarnaan SVG agak sulit. Anda dapat membacanya di sini .
  • Situs web yang sibuk harus mempertimbangkan pemisahan komponen di seluruh domain . Secara khusus...
  • Konten statis (yaitu gambar, CSS, JavaScript, dan umumnya konten yang tidak memerlukan akses ke cookie) harus masuk dalam domain terpisah yang tidak menggunakan cookie , karena semua cookie untuk domain dan subdomainnya dikirim dengan setiap permintaan ke domain dan subdomainnya. Salah satu opsi yang baik di sini adalah menggunakan Jaringan Pengiriman Konten (CDN), tetapi pertimbangkan kasus di mana CDN mungkin gagal dengan memasukkan CDN alternatif, atau salinan lokal yang dapat disajikan sebagai gantinya.
  • Minimalkan jumlah total permintaan HTTP yang diperlukan browser untuk membuat halaman.
  • Pilih mesin template dan render / pra-kompilasi menggunakan pelari tugas seperti tegukan atau mendengus
  • Pastikan ada favicon.icofile di root situs, yaitu /favicon.ico. Browser akan secara otomatis memintanya , bahkan jika ikon tidak disebutkan dalam HTML sama sekali. Jika Anda tidak memiliki /favicon.ico, ini akan menghasilkan banyak 404s, menguras bandwidth server Anda.

SEO (Optimasi Mesin Pencari)

  • Gunakan URL "ramah mesin pencari", yaitu gunakan example.com/pages/45-article-titlealih-alihexample.com/index.php?page=45
  • Saat menggunakan #untuk konten dinamis, ubah #ke #!dan kemudian di server $_REQUEST["_escaped_fragment_"]yang digunakan Googlebot #!. Dengan kata lain, ./#!page=1jadilah ./?_escaped_fragments_=page=1. Juga, untuk pengguna yang mungkin menggunakan FF.b4 atau Chromium, history.pushState({"foo":"bar"}, "About", "./?page=1");Merupakan perintah yang hebat. Jadi meskipun bilah alamat telah mengubah halaman tidak memuat ulang. Ini memungkinkan Anda untuk menggunakan ?alih-alih #!menjaga konten dinamis dan juga memberi tahu server ketika Anda mengirim email tautan yang kami cari setelah halaman ini, dan AJAX tidak perlu membuat permintaan tambahan lainnya.
  • Jangan gunakan tautan yang mengatakan "klik di sini" . Anda membuang-buang peluang SEO dan itu membuat segalanya lebih sulit bagi orang-orang dengan pembaca layar.
  • Memiliki peta situs XML , lebih disukai di lokasi default /sitemap.xml.
  • Gunakan <link rel="canonical" ... />ketika Anda memiliki beberapa URL yang mengarah ke konten yang sama, masalah ini juga dapat diatasi dari Alat Webmaster Google .
  • Gunakan Google Webmaster Tools dan Bing Webmaster Tools .
  • Instal Google Analytics tepat di awal (atau alat analisis sumber terbuka seperti Piwik ).
  • Ketahui cara kerja robots.txt dan mesin pencari.
  • Redirect permintaan (menggunakan 301 Moved Permanently) meminta www.example.comke example.com(atau sebaliknya) untuk mencegah pemisahan peringkat google antara kedua situs.
  • Ketahuilah bahwa mungkin ada laba-laba berperilaku buruk di luar sana.
  • Jika Anda memiliki konten non-teks, lihat ke dalam ekstensi sitemap Google untuk video dll. Ada beberapa informasi bagus tentang ini dalam jawaban Tim Farley .

Teknologi

  • Memahami HTTP dan hal-hal seperti DAPATKAN, POST, sesi, cookie, dan apa artinya menjadi "tanpa negara".
  • Tuliskan XHTML / HTML dan CSS Anda sesuai dengan spesifikasi W3C dan pastikan validasi . Tujuannya di sini adalah untuk menghindari mode kebiasaan browser dan sebagai bonus membuatnya lebih mudah untuk bekerja dengan browser non-tradisional seperti pembaca layar dan perangkat seluler.
  • Memahami bagaimana JavaScript diproses di browser.
  • Pahami bagaimana JavaScript, style sheet, dan sumber daya lain yang digunakan oleh halaman Anda dimuat dan pertimbangkan pengaruhnya terhadap kinerja yang dirasakan . Sekarang secara luas dianggap tepat untuk memindahkan skrip ke bagian bawah halaman Anda dengan pengecualian pada hal-hal seperti aplikasi analitik atau shim HTML5.
  • Pahami cara kerja kotak pasir JavaScript, terutama jika Anda bermaksud menggunakan iframe.
  • Ketahuilah bahwa JavaScript dapat dan akan dinonaktifkan, dan karena itu AJAX adalah ekstensi, bukan garis dasar. Bahkan jika sebagian besar pengguna normal membiarkannya sekarang, ingatlah bahwa NoScript menjadi lebih populer, perangkat seluler mungkin tidak berfungsi seperti yang diharapkan, dan Google tidak akan menjalankan sebagian besar JavaScript Anda saat mengindeks situs.
  • Pelajari perbedaan antara pengalihan 301 dan 302 (ini juga merupakan masalah SEO).
  • Pelajari sebanyak mungkin tentang platform penempatan Anda.
  • Pertimbangkan untuk menggunakan Reset Style Sheet atau normalize.css .
  • Pertimbangkan kerangka kerja JavaScript (seperti jQuery , MooTools , Prototype , Dojo atau YUI 3 ), yang akan menyembunyikan banyak perbedaan browser saat menggunakan JavaScript untuk manipulasi DOM.
  • Dengan menggabungkan kinerja yang dirasakan dan kerangka kerja JS, pertimbangkan untuk menggunakan layanan seperti Google Libraries API untuk memuat kerangka kerja sehingga browser dapat menggunakan salinan kerangka kerja yang sudah di-cache daripada mengunduh salinan duplikat dari situs Anda.
  • Jangan menemukan kembali roda. Sebelum melakukan APA SAJA, cari komponen atau contoh tentang cara melakukannya. Ada kemungkinan 99% seseorang telah melakukannya dan merilis versi kode OSS.
  • Sebaliknya, jangan mulai dengan 20 perpustakaan bahkan sebelum Anda memutuskan apa kebutuhan Anda. Terutama di web sisi klien di mana hampir selalu pada akhirnya lebih penting untuk menjaga hal-hal ringan, cepat, dan fleksibel.

Memperbaiki bug

  • Pahamilah bahwa Anda akan menghabiskan 20% dari waktu Anda coding dan 80% dari itu mempertahankan, jadi kode sesuai.
  • Siapkan solusi pelaporan kesalahan yang baik.
  • Memiliki sistem bagi orang untuk menghubungi Anda dengan saran dan kritik.
  • Dokumentasikan cara kerja aplikasi untuk staf pendukung masa depan dan orang-orang yang melakukan pemeliharaan.
  • Sering buat cadangan! (Dan pastikan cadangan itu berfungsi). Memiliki strategi pemulihan, bukan hanya strategi cadangan.
  • Gunakan sistem kontrol versi untuk menyimpan file Anda, seperti Subversion , Mercurial atau Git .
  • Jangan lupa untuk melakukan Tes Penerimaan Anda. Kerangka kerja seperti Selenium dapat membantu. Terutama jika Anda mengotomatiskan pengujian sepenuhnya, mungkin dengan menggunakan alat Integrasi Berkelanjutan, seperti Jenkins .
  • Pastikan Anda memiliki pencatatan yang memadai menggunakan kerangka kerja seperti log4j , log4net atau log4r . Jika ada yang salah di situs langsung Anda, Anda akan perlu cara untuk mencari tahu apa.
  • Saat masuk, pastikan Anda menangkap kedua pengecualian yang ditangani, dan pengecualian yang tidak ditangani. Laporkan / analisis output log, karena akan menunjukkan kepada Anda di mana masalah utama berada di situs Anda.

Lain

  • Melaksanakan pemantauan dan analitik sisi-server dan sisi klien (satu harus proaktif daripada reaktif).
  • Gunakan layanan seperti UserVoice dan Intercom (atau alat serupa lainnya) untuk terus berkomunikasi dengan pengguna Anda.
  • Ikuti Vincent Driessen 's Git bercabang Model

Banyak hal yang dihilangkan tidak selalu karena mereka bukan jawaban yang berguna, tetapi karena mereka terlalu rinci, di luar jangkauan, atau terlalu jauh bagi seseorang yang ingin mendapatkan gambaran tentang hal-hal yang harus mereka ketahui. Silakan mengedit ini juga, saya mungkin melewatkan beberapa hal atau membuat beberapa kesalahan.


7
Beberapa saran SEO Anda buruk. Tidak masalah jika Anda menggunakan tabel atau div (Google mengonfirmasi ini sendiri). URL SEF URL itu ... Saya benci "URL palsu" itu, di mana ID adalah satu-satunya hal yang benar-benar menentukan halaman. "45-bla" akan menjadi halaman yang sama. Itu juga tidak ramah pengguna.
DisgruntledGoat

152
Kemudian edit. Saya tidak menulis sebagian besar dari ini: Saya hanya mempertahankannya - pekerjaan yang saya warisi karena saya mengajukan pertanyaan, meminta jawaban yang lebih besar ini secara khusus, dan saya benar-benar tertarik untuk melihat apa yang bisa kita buat dengan . Semakin banyak kontribusi semakin baik.
Joel Coehoorn

327
Satu lagi catatan: jika Anda kembali dan mengedit ini, cobalah untuk menghormati apa yang ditulis. Jangan hanya menghapus bagian yang tidak Anda setujui: sebenarnya luangkan waktu untuk membahas kedatangan singkat dan memberikan sesuatu yang lebih baik.
Joel Coehoorn

16
Satu hal yang saya sarankan Anda tambahkan ke bagian keamanan Anda, adalah bahwa semua file yang Anda layani harus dibandingkan dengan daftar putih folder yang diizinkan, atau untuk "memenjarakan" server web. Ini menghentikan seseorang menggunakan http://server/download.php?file=../../etc/password. Jangan pernah memaparkan jalur file ke pengguna.
Philluminati

10
Sebagai contoh, Anda tidak hanya melompat ke dalam mobil dan mulai mengemudi. Alih-alih, Anda mengambil kelas untuk pengoperasian yang benar dari mobil itu dan akhirnya harus lulus ujian yang membuktikan bahwa Anda dapat mengemudi. Bagi sebagian orang, itu membutuhkan banyak, banyak, banyak jam belajar . Dan ya, saya akan menyamakan belajar bagaimana membangun aplikasi web dengan benar dengan belajar mengendarai mobil karena kegagalan membangun aplikasi dengan benar tentu saja dapat menghasilkan tingkat gangguan yang lebih besar pada kehidupan masyarakat daripada penyok fender sederhana, termasuk yang jauh lebih besar kerugian keuangan. Kematian? baik, tergantung pada jenis aplikasi yang dikacaukan pengembang.
NotMe
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.