Awalnya tidak ada yang merencanakan pengembangan web. Bahkan dalam mimpi buruk. Secara umum, dengan dukungan perusahaan besar dan sains, orang menganggap penciptaan sistem IT yang mahal sebagai proses ilmiah yang dekat tersedia bagi para elit, di mana sangat penting untuk mengetahui tidak hanya dengan cepat dilupakan oleh sebagian besar algoritma (saya belajar prinsip mem-bypass kayu merah dan hitam 5 kali dengan selebaran - lihat pinggul yang bergoyang di awal musim semi benar-benar menghapus informasi yang diterima), tetapi juga bagian dalam setrika. Tindakan suci ini, tentu saja, harus dikontrol dengan baik (kemuliaan bagi
Deming besar), diukur dan diuji, dan diuji selamanya, amin. Tapi ada yang salah dan salah ...
Perjuangan untuk kebebasan berekspresi
Cukup cepat, pengembangan perangkat lunak mulai berubah menjadi graphomania algoritmik dan nymphomania, dan untuk banyak uang, untuk pelanggan. Situasi dengan penciptaan produk-produk perangkat lunak berskala besar dan komunitas pengembang di sekitar mereka mulai menyerupai keterlibatan dalam sekte-sekte keagamaan atas dasar kecintaan pada rekayasa penyiksaan diri.
Pergerakan perangkat lunak bebas dengan cepat menanggapi distorsi ini dari akal sehat, berkat yang sekarang kita miliki alat gratis, berkualitas tinggi dan sangat berguna dalam waktu luang dan bisnis kita yang biasa kita gunakan:
Linux ,
MySQL ,
PHP dan banyak lagi lainnya.
Baiklah, nilai perangkat lunak bebas terlihat dalam konteks larangan penggunaan Android di perangkat Huawei. Dan pengembangan aktif cryptocurrency modern menambah bahan bakar ke dalam api - bank crypto secara serius turun ke bisnis dan menarik tanah dari bawah kaki lembaga dan teknologi tradisional.
Punks dalam pengembangan - scripting
Ini bukan untuk mengatakan bahwa perangkat lunak itu ternyata buruk. Itu hanya dibuat untuk waktu yang lama, kemudian diuji untuk waktu yang lama, dan kemudian mereka menerima apa yang sudah usang. Namun, prosesnya berhasil. Evolusi: dalam jutaan jam pengujian, serangga akan hilang dan kadal dan kecoak akan tetap menjadi pengganti dinosaurus, tapi ... ulet. Orang-orang menghabiskan banyak waktu untuk menyelesaikan tugas sistem tingkat rendah, lupa tentang tujuan bisnis. Situasi ini diperburuk oleh keyakinan bahwa semakin banyak programmer, semakin cepat Anda dapat menulis suatu sistem. Keinginan untuk menyingkirkan penyajian kode demi kemuliaan penggunaannya untuk bisnis dihasilkan pada kehausan liar pertama, dan kemudian implementasi seluruh kelas bahasa pemrograman, yang tujuannya adalah keamanan, kecepatan pengembangan, kesederhanaan dan keringkasan: Python, PHP, Ruby, Lua, JavaScript. Terlepas dari keterbatasan teoretis: tidak adanya pengetikan statis, kehadiran kolektor runtime dan sampah, kemalasan langsung dan pemahatan semantik, teknologi secara aktif berkembang dan membawa lebih banyak manfaat daripada membahayakan.
Konsep bocor
Dengan cepat menjadi jelas bahwa mungkin untuk mengajar dengan tongkat, tetapi untuk menulis kode yang memecahkan masalah bisnis yang sederhana dan mudah dipahami oleh perwakilan Homo Sapiens lainnya jauh lebih sulit dan Anda benar-benar ingin melakukannya sendiri. Untuk menyuarakan ide sederhana ini, mereka hampir membakar Saint
Dijkstra hidup-hidup . Ini tentang cara menulis buku (Anda perlu keinginan besar untuk belajar dan pergi ke tujuan = bakat) dan menulis posting di Facebook (Anda memerlukan akun). Tetapi jauh dari semua orang telah diberikan pemahaman ini, karena lebih mudah untuk belajar tata bahasa dari pada belajar menulis hal-hal yang mengasyikkan di dalamnya, dan oleh karena itu perdebatan sengit masih berlangsung:
- bahasa pemrograman mana yang lebih baik
- sistem operasi mana yang lebih benar
- tulis tes sebelum, selama, atau setelah menikah
- kaki apa yang harus bangun di pagi hari, dll.
Konfrontasi tradisional antara penulis dan pustakawan, kritikus musik dan bintang panggung, pencipta perusahaan, dan manajemen menengah :-)
Di tangan seorang insinyur nyata, kodenya baik, didukung dan bebas kesalahan - dalam bahasa pemrograman apa pun. Dan pandangan singkat untuk mencari lingkungan pengembangan di mana Anda dapat mengantar siswa berlibur, perempuan, bir dan PS4 dan mengharapkan sesuatu sebagai balasannya.
Ternyata hidup itu sangat beragam dan tugas-tugas yang diselesaikan dengan bantuan pemrograman terkadang begitu orisinal sehingga beberapa konsepsi tradisional tidak bekerja secara langsung atau memunculkan “konsep berlubang” yang menghancurkan kesadaran:
- Pemrograman berorientasi objek bekerja dengan baik dalam permainan dan sistem grafis, tetapi dalam Python sangat tidak disukai sebagai konsep yang membatasi kebebasan. Saya ingat melihat di PHP kelas Tools memperluas kelas Utils
- Pemrograman fungsional melakukan pekerjaan yang baik dalam memproses aliran data dan pembatasan (Apache Spark), tetapi Haskell tidak pernah "lepas landas", karena hidup bukanlah abstraksi matematis, tetapi seringkali seperangkat kruk yang berserakan dan tertawa
- Skrip dalam PHP, Python, Ruby dengan sempurna menghubungkan berbagai teknologi dan komponen aplikasi yang berbeda, di Lua mereka menggambarkan skrip dalam gim, tetapi menulis layanan jaringan yang sangat baik lebih baik menembak diri Anda sendiri di kepala. Python bahkan tidak berpikir untuk menambahkan multithreading.
Secara umum, ternyata untuk menyelesaikan semua masalah dengan satu alat (Java Spring), dengan kata lain, tidak efisien dan lebih baik untuk memilih alat yang tepat untuk tugas daripada memalu paku dengan mikroskop. Namun, sayangnya, mereka tidak suka belajar ...
Kesulitan adalah musuh utama
Ketika sistem tumbuh, semakin jelas bahwa beberapa karyawan dengan mudah belajar, menerapkan konsep-konsep lanjutan, bahasa, teknologi, banyak membaca, dan beberapa, kadang-kadang, sayangnya, mayoritas, terus terang tidak punya waktu dan mulai memahami rekan-rekan yang maju. Modul-modul yang ditulis secara efektif, mula-mula tidak bisa dipahami oleh mayoritas, dan kemudian bagi para penulis sendiri, mulai menjalani kehidupan mereka sendiri dan mati, biasanya dengan kesendirian yang sombong. Menjadi jelas bahwa seluruh tim harus memiliki teknologi, jika tidak teknologi bisa lebih berbahaya daripada kebaikan.
Bahasa pemrograman yang bagus, berani, dan layak, dengan kurva entri yang curam, katakanlah,
Rust yang tampan, bisa menjadi minus dan risiko bagi proyek.
Orang-orang cantik
Berapa dekade telah mengembangkan bahasa dan teknologi pemrograman dalam arah yang sama:
- Kode efisien dan cepat dekat dengan perangkat keras. Kompiler yang bocor, tidak dirancang dengan baik, menggantikan pengembang. C / C ++.
- Pengumpul sampah, bahasa yang aman. Konsep yang kuat. Pengetikan yang cukup ketat. Tapi kami kehilangan kecepatan dan mengkonsumsi RAM. Terkadang kami menulis di bawah pengumpul sampah. Java, C #, Swift (ya saya tahu tentang RC).
- Bahasa yang sangat sederhana, entri cepat, pengembangan cepat. Namun kurangnya pengetikan (risiko) dan pengumpul sampah. PHP, Python, Ruby.
Dan kemudian sebuah ide besar muncul: “teman-teman, kita tidak mengambil jalan yang benar dari kata; dan mari kita buat kompiler lebih pintar? " Karat lahir, yang memenuhi hampir semua permintaan:
- Kode efisien dan cepat, abstraksi nol
- Kompiler pintar yang melindungi pengembang dari kesalahan mengerikan saat bekerja dengan memori
- Tidak ada pengumpul sampah, Carl. BUKANLAH!
Kemuliaan bagi pikiran dan keindahan!
Pengembangan web - bagaimana ini bisa terjadi?
Setelah mengumpulkan pengalaman yang diperlukan dan mengisi gundukan, umat manusia tiba-tiba menyadari bahwa jika Anda melewati
alat tata letak teks paling sederhana
, suatu bahasa ditemukan dalam satu malam
untuk mengotomatiskan tombol halaman web ,
aturan untuk menetapkan warna, dan dengan hati-hati, tanpa gerakan tiba-tiba, ikuti semua instruksi, tarik semua melalui Internet. menggunakan PHP, dengan pengetahuan yang menurut mereka, anak-anak sudah lahir - Anda bisa mendapatkan sinergi teknologi paling kuat dan mulai dengan cepat menyelesaikan masalah bisnis di sini dan sekarang:
- Buat antarmuka yang efisien menggunakan HTML / CSS. Ya, mereka tidak selalu sempurna, tetapi mereka efektif dan, terutama sekarang, sangat kuat.
- Simpan data aplikasi dengan aman di MySQL
- Berselancar di internet via linux
- Mentransfer pesan antar komponen menggunakan pola arsitektur yang matang seperti antrian
Sebenarnya, tidak ada yang mengerti mengapa revolusi ini terjadi, tetapi kenyataannya tetap ada - sinergi teknologi sederhana telah menghasilkan bom nuklir. Dan biarkan PHP terus mengejutkan untuk meminjam konsep lama dipoles dari bahasa lain, dan biarkan Python tidak pernah mengimplementasikan multithreading - itu adalah scripting, yaitu kesederhanaan, keringkasan dan abstraksi tingkat tinggi yang memungkinkan untuk merevolusi pemrograman dan memecahkan masalah bisnis dengan cepat, sederhana dan efisien dalam 3 -5 baris kode.
Sinergi Berlanjut - BigData dan Pembelajaran Mesin
Itu untuk alasan di atas bahwa Python lepas landas untuk tugas-tugas memproses dan menganalisis data. Matematikawan duduk, menulis pada alat
mengetik Bebek yang "mengerikan", diketik dengan lemah, yang menakutkan untuk diambil di tangan Anda - tidak ada kompiler, wow, sungguh merepotkan! Mereka menulis, menulis, dan ... menulis satu set perpustakaan kelas tertinggi:
- Numpy - pemrosesan array multidimensi berkecepatan tinggi, ini bukan dan tidak diharapkan dalam PHP
- Panda - Pemrosesan Data Relasional Yang Kuat dalam Memori
- Matplotlib , Seaborn - Alat Visualisasi Data Hebat
Saya mengunduh distribusi freeware
Anaconda , menginstal paket dan hanya itu, membuat bigdat, meluncurkan
neuron dan memprediksi masa depan! Gratis.
Namun, ini masih bunga. Berries adalah pengembangan interaktif interaktif dan lingkungan komunikasi yang sangat populer -
Jupiter Notebook . Kesan pertama adalah regresi. Nah, adakah IDE yang kuat? Tapi kemudian pemahaman datang - ini adalah langkah maju yang besar. Peran Jupiter hampir sama dengan pengembangan web pada saat kemunculannya: hasil yang cepat, komunikasi yang cepat, kemampuan kritis bisnis dan standar terbuka.
Studio Web dan Pemrogram Web - Suasana
Anda bertanya, mengapa saya menulis semua ini? Faktanya adalah bahwa tanpa masuk ke dalam atmosfer pengembangan web, Anda tidak dapat melihat cara terbaik untuk mengontrol kualitas saat membuat aplikasi web. Tanpa jatuh cinta dengan semangat ini, Anda tidak dapat berhasil di web. Pendekatan standar dan klasik tidak berfungsi di sini, dan inilah alasannya:
- Tidak seperti dunia C, C ++, di mana biasanya mengeluarkan 1-2 rilis per tahun, di sini mereka merilis seminggu sekali, yaitu. pengembangan terjadi pada kecepatan super-ringan
- Tidak seperti dunia C # dan Java, di mana biasanya terlibat dalam pemrograman berorientasi objek dan mencakup semuanya dengan tes unit dan integrasi, seringkali ada konsep dan tugas yang begitu rumit dan tidak standar sehingga skrip 10-baris dapat menyelesaikan tugas lebih cepat dan lebih indah daripada kerangka kerja 10-kelas. Pengujian tata letak dan skrip, sayangnya, secara otomatis sangat sulit dan mahal, sehingga sering diuji dengan mata dan pengguna :-)
- Tidak seperti dunia pemrograman fungsional dan keindahan ekspresi fungsional suatu masalah, di sini pendekatan penyelesaian dinyatakan melalui, dalam arti literal tapi bagus, keledai, dan ini dibenarkan - kelayakan ekonomi dari skrip prosedural mengerikan yang dapat Anda buang dan tulis yang baru (dan 10 kali)
- Tidak seperti perangkat lunak tradisional, di sini ide-ide dengan cepat diimplementasikan dalam kode, diperiksa, dibuang, dan dipilih dengan lebih baik. 90% dari kode - mati, 10% - pelanggan hidup dan senang. Lebih baik memiliki 10 jalur yang andal dan dapat dipahami, di sini dan sekarang, daripada 1000 jalur akademik di suatu tempat dalam fungsi dan kelas dengan kekakuan dan cakupan yang tidak ditentukan oleh autotests.
Tetapi yang utama adalah manusia. Di antara pengembang web, mereka spesial. Mereka bukan karena mereka tidak suka menulis kode, tetapi mereka membencinya. Objek kekaguman bagi pengembang web adalah kecepatan memecahkan masalah. Jika ada pilihan antara 2 baris kode PHP dan kerangka kerja 20 kelas, pilihan akan menuju solusi yang lebih seksual dengan singkatnya. Itulah sebabnya, jika Anda dapat memilih untuk menulis atau tidak menulis kode, seorang programmer web profesional akan memilih yang pertama dan menghabiskan lebih banyak waktu dengan gadis itu, misalnya, di ruang baca perpustakaan, mempelajari
epik India kuno , dan pendatang baru akan belajar yang kedua hingga ia menyadari bahwa semakin banyak kode, semakin banyak kesalahan yang mungkin ada di dalamnya, dan dalam autotest terhadap kode kesalahan akan ada lebih banyak dan oleh karena itu lebih baik untuk menulis 5 baris dan dengan cepat memeriksanya dengan mata Anda daripada menciptakan penampilan berkualitas dan memperbaiki kesalahan apa pun selama berminggu-minggu :-)
Bagaimana mengelola kualitas proyek web
Pada saat ini, Anda kemungkinan besar telah mengetahui bahwa pengembangan web adalah bidang pemrograman yang khusus, baru dan sangat menyerbu, dipenuhi dengan rekan kerja yang sangat berbeda dengan insinyur yang membenci kode dan memiliki hasrat yang membara untuk menyelesaikan masalah secepat mungkin dan dengan bantuan alat yang siap pakai dan sederhana. . Itulah sebabnya pengembang web sering tumbuh menjadi administrator sistem yang suka mendapatkan lebih dari pekerjaan. Dan ya, asosiasi lain, pengembang web lebih seperti kutu buku dengan senjata daripada samurai 8 dan dengan pedang, pita dan penuh buku-buku jari. Buat taruhan, siapa yang akan memenangkan pertarungan jalanan, TANPA aturan?
Tapi ini baru setengah pertempuran. Pelanggan bisnis yang menyadari bahwa menggunakan pengembangan web dapat dengan cepat menyelesaikan masalah yang rumit: membuat toko online yang dinamis dengan koneksi CRM dan pencarian built-in untuk katalog produk dalam 1 minggu, jika Anda membuat kembali setengah dari fungsi kotak, Anda dapat menulis sendiri buku berkualitas Pengembangan web, dari mana Deming cenderung terus-menerus berguling-guling
di neraka . Berikut adalah poin utama mereka yang mengguncang dasar-dasar QA klasik:
- Kecepatan memotong pesaing lebih penting daripada kualitas. Jika proyek web lepas landas dan berputar-putar (1 dari 10 atau kurang), maka Anda dapat menulis ulang "dengan benar", tetapi, anehnya, tidak ada yang menulis ulang mereka dan mereka hidup, dan seringkali berhasil dan nyaman, selama bertahun-tahun.
- Proyek ini dilakukan untuk tindakan, satu kali dan kualitas internal dapat dilupakan dengan hati nurani yang jelas. Probabilitas bahwa seseorang akan masuk ke dalam kode nanti adalah sama dengan 0,00001% (saya naik ke proyek seperti itu; pada Malam Tahun Baru mereka bisa menjadi populer lagi).
- Pelanggan tidak ingin menulis autotest yang meningkatkan biaya pengembangan sebanyak 2 kali dan mengembang arsitektur kelas menjadi serangkaian konsep abstrak dan mencuat. Tetapi kadang-kadang, untuk perpustakaan dan, dengan probabilitas tinggi, digunakan kembali, mereka setuju.
- Pelanggan siap membantu dalam menguji sistem web, sering kali menyadari (sayangnya, ada pengecualian) bahwa dengan periode pengembangan seperti itu (4 bulan untuk seluruh proyek turnkey) dan perjuangan melawan swa-uji dan inflasi kode pada tingkat kontrak, mustahil untuk mencapai kualitas yang sama dari semua komponen sistem .
- TK tidak diperlukan, karena itu terus berubah, menjadi usang dan Anda perlu menjaga departemen dokumentasi untuk memperbaruinya. Lebih mudah dibuat dengan cepat, lihat hasilnya dan putar roda Agile.
- Pekerjaan bodoh mencintai
Memahami hal ini, spesialis berkualitas baik terbang di atas naga dan tidak lagi kembali, ngeri dengan apa yang terjadi, atau menerima nilai-nilai pengembangan web, menembus mereka dan membangun sesuatu seperti ini:
- Pendekatan yang digunakan dalam desain, pengembangan, dan pengujian tidak boleh dilakukan dengan keyakinan, secara agama. Penting untuk menjadi Thomas . Jadi, Anda perlu menulis autotest, maka Anda harus melakukannya. Siapa yang butuh itu, eh? Bukti kelayakan ekonomi. Mengapa autotest ke situs kartu bisnis jika Anda dapat dengan cepat memeriksa semuanya dengan mata Anda? Mengapa menulis objek tiruan ke kerangka kerja yang Anda gunakan, jika itu menghasilkan banyak kode yang mungkin mengandung kesalahan dan yang perlu disertai. Bukankah lebih mudah untuk menulis 10 baris kode yang jelas tanpa DI?
- Sebenarnya, tidak mungkin untuk memperkirakan periode pengembangan proyek web dengan 3-5 hari untuk desain, sehingga penilaian diambil dari proyek web yang paling mirip
dan dikalikan dengan 666 - Terkadang, ketika layak secara ekonomi, Anda perlu menghilangkan risiko kritis pada prototipe, melakukan pengujian stres preventif
- Penting untuk memeriksa bahwa alat yang siap pakai, kerangka kerja, teknologi digunakan dan ada pemahaman yang jelas bahwa semakin banyak kode, semakin banyak kesalahan yang harus diperbaiki
- Adalah penting, sangat penting, untuk menyediakan komunikasi paling intensif yang memungkinkan Anda untuk sepenuhnya membenamkan diri dalam sistem web, merasakan gerakan dan arsitekturnya dan menciptakan efek "banyak mata melihat kode." Ingatlah bahwa di Linux, sistem operasi yang sukses, untuk waktu yang lama tidak ada pengujian otomatis, dan jika Test-Driven Design ada di sana segera, maka kemungkinan besar masih akan diluncurkan. Tetapi di sisi lain, Linux segera memiliki audit kode yang mendalam dan sistem penerimaan perubahan terpusat. Anda perlu merasakannya dengan baik.
- Dalam proyek semacam itu, Anda dapat mengurangi risiko secara signifikan jika Anda menghubungkan insinyur berpengalaman untuk merencanakan arsitektur tingkat rendah dan memutuskan perlunya prototipe. Segera setelah ada perasaan bahwa ada persyaratan dan anggaran mengipasi, untuk berada dalam masalah - Anda perlu membuat beberapa trik bunuh diri, taburkan darah di beberapa dinding dan papan Agile. Korban untuk kesuksesan proyek - apa yang bisa lebih keren?
Dengan demikian, kualitas sistem web masih dapat dikelola secara efektif jika Anda mendekati masalah ini dengan bijak, hemat, tanpa mengambil dogma rekayasa agama berdasarkan keyakinan, memeriksa ulang semuanya dan berusaha untuk kesederhanaan dan meminimalkan jumlah kode dan perpustakaan yang dibuat dari atas. Menekan kreativitas teknis yang cepat dalam tim dan mengarahkannya ke arah pencarian kesederhanaan, keringkasan, biaya rendah, dan transparansi - sangat membantu, terutama dalam menciptakan sistem web yang kompleks dan tidak standar.
Tapi yang paling sulit, sayangnya, kami tertinggal di belakang layar. Bagian tersulit adalah belajar bagaimana menyeimbangkan penekanan pada pisau cukur. Anda, seorang pengembang web, berdiri tanpa baju besi, dengan
anggota keluarga yang ketat dan kemeja dengan tulisan "Agile", dengan sling berputar di tangan Anda, di depan raksasa itu. Dan jika Anda memukulnya di dahi - proyek Anda. Tapi lewatkan beberapa kali berturut-turut - Anda akan diinjak-injak oleh pasukan samurai 8 dan dengan peregangan yang baik dan penuh buku-buku jari, yang, memakan mayat Anda, akan meludah dengan tulang dan tertawa: "Saya ingin menyelesaikan masalah dengan 50 kelas dan 7 kerangka kerja di PHP, gila" . Secara umum, jangan lewatkan, bawa senjata api, pelajari pengembangan web dan ... semoga berhasil!