Pembaruan glitchy menunjukkan masalah yang lebih dalam


Windows 10 di Tokyo Presentation Juli 2015

Jelas, pembaruan Windows 10 Oktober 2018 bukanlah yang paling berhasil. Pesan tentang hilangnya file di komputer dengan cepat muncul, dan Microsoft berhenti mendistribusikan pembaruan. Sejak itu, bug telah diperbaiki , sekarang pembaruan baru sedang diuji sebelum dirilis kembali.

Ini bukan pembaruan Windows pertama yang mengalami masalah - dalam pembaruan sebelumnya kami melihat hal-hal seperti ketidakcocokan perangkat keras yang signifikan - tetapi jelas menjadi lebih buruk. Sebagian besar dari kita tahu tentang cadangan, tetapi pada kenyataannya, banyak data, terutama di komputer rumah, tidak memiliki cadangan, dan hilangnya mereka sangat tidak menyenangkan.

Windows sebagai layanan

Di Windows 10, direncanakan untuk secara radikal mengubah proses pengembangan. Microsoft ingin merespons kebutuhan pelanggan dan pasar dengan lebih baik - dan lebih sering merilis fitur baru. Windows 10 disajikan sebagai versi "terbaru" Windows. Seperti, semua perkembangan baru akan menjadi pembaruan Windows 10, disampaikan melalui sistem pembaruan beberapa kali setahun. Model pengembangan baru ini disebut Windows sebagai Layanan. Dan setelah beberapa kekacauan awal, Microsoft menetapkan dua pembaruan fungsional per tahun : pada bulan April dan Oktober.

Upaya ini telah berhasil. Microsoft merilis fitur baru yang berguna untuk model baru, tanpa memaksa pengguna untuk menunggu tiga tahun untuk memperbarui versi utama. Misalnya, fitur yang mudah digunakan telah dirilis untuk meluncurkan Edge di mesin virtual , yang memberikan perlindungan lebih besar terhadap situs web berbahaya. Windows Subsystem for Linux (WSL), yang memungkinkan Anda untuk menjalankan program Linux secara native pada sistem Windows, telah menjadi alat untuk pengembang dan administrator. Manfaat bagi pengguna biasa sedikit lebih sulit untuk diperhatikan, tetapi Anda dapat menyebutkan fitur VR yang kompatibel dengan SteamVR , peningkatan kinerja game dan tema gelap . Meskipun peningkatannya tidak begitu signifikan, secara umum, Windows 10 saat ini tentu lebih baik daripada yang keluar tiga tahun lalu.


Pada hari-hari ketika Windows diperbarui hanya setiap tiga tahun, sulit membayangkan bahwa WSL akan menjadi alat yang berguna.

Semua ini baik, dan beberapa hal hampir tidak dapat dilakukan (setidaknya dengan berhasil) tanpa pengenalan Windows sebagai model Layanan. Pengembangan WSL, misalnya, didasarkan pada umpan balik pengguna. Pengguna berbicara tentang ketidaksesuaian yang ditemukan dan membantu memprioritaskan pengembangan fitur baru. Saya tidak berpikir bahwa WSL akan menerima dorongan untuk pengembangan tanpa kemajuan pembaruan yang stabil setiap enam bulan - tidak ada yang mau menunggu tiga tahun untuk melihat koreksi kecil. Misalnya, agar paket penting untuk mereka mulai bekerja dengan benar. Pembaruan rutin menghargai orang-orang untuk pesan kesalahan karena semua orang benar-benar melihat kesalahan diperbaiki tepat waktu.

Masalah dengan Windows sebagai model Layanan adalah kualitas. Masalah sebelumnya dengan model ini dan pembaruan keamanan telah merusak kepercayaan terhadap kebijakan pembaruan Windows 10. Pengguna berpengalaman berpendapat bahwa kualitas pembaruan keamanan bulanan telah menurun di Windows 10, dan menginstal pembaruan fitur setengah tahunan segera setelah mereka dirilis adalah gila . Keluhan ini juga memiliki sejarah panjang. Pembaruan yang buruk menjadi keprihatinan segera setelah rilis Windows 10.

Masalah terakhir dengan menghapus file membuat para ahli beralasan bahwa mungkin ada terlalu banyak dua pembaruan fitur per tahun . Redmond harus mengurangi jumlahnya menjadi satu, dan Microsoft harus menangguhkan pengembangan fitur baru dan hanya memperbaiki bug . Beberapa khawatir bahwa perusahaan hampir mendekati hilangnya kepercayaan yang serius pada pembaruan, dan bagi sebagian pengguna Windows kepercayaan ini sudah hilang.

Ini bukan panggilan pertama ke Microsoft untuk memperlambat pembaruan fitur - ada kekhawatiran bahwa semua ini sulit dicerna untuk departemen TI dan pengguna biasa, tetapi dengan masalah yang jelas dari pembaruan terbaru, panggilan ini menjadi sangat relevan.

Ini bukan masalah frekuensi, tetapi BAGAIMANA pembaruan sedang dipersiapkan

Tetapi orang-orang yang bersikeras pada satu pembaruan per tahun, bukannya dua, melewatkan intinya. Masalahnya bukan frekuensi output. Masalahnya adalah dalam proses pengembangan Microsoft.

Mengapa masalahnya bukan dari segi? Kita dapat melihat jadwal pembaruan OS lain.

Di satu sisi, macOS, iOS, dan Android lebih jarang diperbarui, sehingga Anda mungkin mendapat kesan bahwa Microsoft terlalu bersemangat. Di sisi lain, ada preseden untuk pembaruan yang berhasil pada frekuensi seperti itu: untuk Ubuntu, ada dua rilis per tahun, dan ChromeOS dari Google, seperti browser Chrome-nya, menerima pembaruan setiap enam minggu. Jika Anda melampaui OS, maka program Microsoft Office Insider menjalankan saluran bulanan di mana fitur baru dirilis untuk pengguna Office setiap bulan - dan pengembang melakukan pekerjaan tanpa menimbulkan terlalu banyak keluhan dan pada saat yang sama menyediakan aliran fitur dan perbaikan baru. Tim Visual Studio juga sering merilis pembaruan untuk lingkungan pengembangan dan layanan interaktif mereka. Jelas, Microsoft memiliki tim yang telah beradaptasi dengan baik dengan kenyataan, di mana aplikasi mereka diperbarui secara berkala.

Kami akan melampaui lingkup perangkat lunak lokal dan melihat layanan jaringan dan cloud. Di sana, Microsoft dan perusahaan lain semakin memperkenalkan pengiriman berkelanjutan . Setiap pembaruan dalam sistem secara otomatis digunakan untuk server produksi setelah melewati sejumlah tes otomatis yang memadai.

Tentu saja, tak satu pun dari proyek ini dapat dibandingkan dalam kompleksitas dengan Windows. Ubuntu mungkin memiliki beragam paket, tetapi dalam banyak kasus, banyak di antaranya dikembangkan secara independen. Faktanya tetap: skala Windows luar biasa besar - dan komponen belum pernah terjadi sebelumnya diintegrasikan ke dalam basis kode tunggal. Di beberapa tempat, kode Windows sangat tua.

Tentu saja, faktor-faktor ini menyulitkan pengembangan Windows, tetapi apakah benar-benar mustahil untuk mengalahkan dua pembaruan setahun? Ini bukan intinya sama sekali. Anda hanya perlu proses pengembangan yang tepat.


Windows 10 sekitar waktu rilis pada tahun 2015 (Di mana semua ikon saya dan menu Mulai?)

Sebuah proses yang berakar pada sejarah

Microsoft tidak mengungkapkan rincian spesifik dari proses pengembangan Windows 10, tetapi ada karakteristik yang dapat diamati dari proses ini (bagaimana fitur baru dikirim ke orang dalam, jenis kesalahan dalam pembuatan orang dalam), dan ada beberapa informasi dari dalam perusahaan. Semua fakta tidak langsung ini menunjukkan inferioritas proses pembangunan. Dia mempertahankan beberapa kesamaan dengan proses pengembangan yang digunakan perusahaan selama rilis tiga tahun Windows. Waktu telah jatuh, tetapi pendekatan dasarnya tidak berubah.



Di masa lalu, ketika antara dua dan tiga tahun berlalu antara rilis besar, Microsoft datang ke proses dibagi menjadi beberapa tahap:

1. desain dan perencanaan;
2. pengembangan komponen;
3. integrasi;
4. stabilisasi.

Sekitar 4-6 bulan perencanaan dan desain, 6-8 minggu pengkodean intensif, dan kemudian 4 bulan integrasi (masing-masing fungsi biasanya dikembangkan di cabang sendiri, sehingga semuanya perlu dikumpulkan dan dikombinasikan bersama-sama) dan stabilisasi (pengujian dan koreksi kesalahan). Selama pengembangan produk, siklus ini diulang dua atau tiga kali; Windows akan memiliki tiga iterasi, yang pertama adalah prototipe, dan dua berikutnya nyata. Durasi fase dapat bervariasi, tetapi struktur dasar banyak digunakan di perusahaan.

Beberapa hal jelas dari proses ini. Mungkin hal yang paling mengejutkan adalah sedikit waktu yang dihabiskan secara langsung untuk mengembangkan kode baru: untuk rilis Windows, ini adalah dua interval 6-8 minggu selama periode tiga tahun. Banyak waktu berlalu antara tahap perencanaan / desain dan produk yang benar-benar berfungsi. Ini adalah faktor utama mengapa proses ini tidak dapat digambarkan sebagai "pengembangan fleksibel": fungsi-fungsi baru tertanam kuat dalam produk akhir, sehingga sulit untuk mengubahnya dalam menanggapi umpan balik.

Pemisahan pengembangan dan perbaikan bug dari satu sama lain juga merupakan masalah: pada tahap pengembangan dan integrasi, keandalan dan stabilitas perangkat lunak sangat timpang. Fungsi terintegrasi tidak diuji secara fundamental (karena pengujian terjadi kemudian) dan tidak pernah digunakan satu sama lain (karena semuanya dikembangkan secara terpisah di cabang mereka sendiri sebelum fase integrasi). Kekacauan perangkat lunak kemudian dibawa ke tingkat yang dapat diterima melalui pengujian, pelaporan kesalahan, dan koreksi kesalahan selama fase stabilisasi yang panjang. Dalam proses ini, Anda perlu meningkatkan keandalan produk berulang kali.


Nadella memperkenalkan dunia ke Windows 10 pada 2015

Dunia baru tidak begitu baru

Di dunia baru, kita melihat bahwa dibutuhkan tujuh atau delapan bulan untuk siklus perusahaan penuh. Meskipun hanya ada enam bulan antara rilis, awal siklus berikutnya terjadi sebelum yang sebelumnya selesai - untuk orang dalam ini terlihat dari pembukaan grup Skip Ahead.

Sebagai aturan, setiap pembaruan dimulai dengan periode yang agak sunyi dengan beberapa perubahan yang terlihat, dan kemudian muncul beberapa bulan dengan diperkenalkannya perubahan besar - dan sejumlah besar bug. Sekitar sebulan sebelum pembaruan, kami melihat perlambatan tajam dalam jumlah perubahan yang dilakukan dan penekanan kuat pada perbaikan bug, dan bukan pada fitur baru.

Seperti yang dijelaskan oleh karyawan Microsoft sendiri, beberapa bulan terakhir pengembangan termasuk fase "kirim", kemudian satu bulan dari fase "minta izin". Pada tahap "beri tahu", manajemen Windows diberitahu tentang perubahan yang dibuat dengan kebijakan menerima perubahan ini secara default. Pada tahap “minta izin”, hanya perubahan yang sangat signifikan diperbolehkan, sebagai aturan, hanya beberapa perubahan per hari.

Misalnya, versi pertama pembaruan Oktober (codename RS5) dirilis ke orang dalam pada tanggal 14 Februari, dan versi stabil pembaruan April (RS4) terjadi dua bulan kemudian pada tanggal 16 April. RS5 tidak menerima fitur baru yang signifikan hingga 7 Maret. Banyak fitur ditambahkan selama Mei, Juni, dan Juli, dan kemudian hanya perubahan kecil yang dilakukan pada bulan Agustus dan September. Beberapa fitur kecil bahkan dihapus pada bulan Agustus, karena sulit untuk mempersiapkan rilis mereka pada bulan Oktober.

Tentu saja, prosesnya telah sedikit berubah. Misalnya, fitur baru muncul dalam pra-pembangunan selama berbulan-bulan. Ini menunjukkan bahwa integrasi fungsi-fungsi baru tampaknya terjadi jauh lebih awal - karena fungsi dikembangkan, dan tidak dalam satu paket gabungan besar pada akhirnya.

Penurunan kualitas

Tetapi ada kesamaan kunci. Yang paling penting, kode kereta sengaja diintegrasikan ke dalam database umum, dan fase pengujian dan stabilisasi digunakan untuk menyelesaikan masalah. Momen ini bahkan secara eksplisit diakui: mengumumkan majelis pendahuluan baru , Microsoft memperingatkan: "Seperti biasa pada awal siklus pengembangan, majelis dapat berisi bug yang bisa menyakitkan. Jika ini menyebabkan Anda merasa tidak nyaman, Anda dapat mempertimbangkan untuk beralih ke siklus pembaruan lambat (Lambat dering). Di sana, majelis masih akan memiliki kualitas yang lebih tinggi. "

Kami melihat ini dalam praktek di RS5. Pada Oktober tahun lalu, dengan pembaruan, mereka memperkenalkan fitur baru untuk OneDrive: placeholder, yang menampilkan file di cloud yang tidak diunduh secara lokal. Setiap kali suatu aplikasi mencoba untuk membuka file, OneDrive secara transparan mengekstrak file dari penyimpanan cloud dan menyimpannya secara lokal, dan aplikasi itu bahkan tidak tahu bahwa file itu awalnya tidak dapat diakses secara lokal. RS5 build mengimplementasikan fungsi membersihkan file cloud yang direplikasi dari penyimpanan lokal jika ruang disk habis.

Ini adalah fitur yang sangat cerdas dan berguna yang meningkatkan integrasi dengan penyimpanan cloud. Ini adalah kode baru; Ada driver kernel yang menyediakan tautan antara kode sinkronisasi cloud (digunakan untuk mengunggah file dan mengunduh perubahan) dan ikon di sistem file. Ada juga API (tampaknya pihak ketiga juga dapat menggunakan fitur ini untuk layanan sinkronisasi mereka).


Windows pre-build menggunakan "layar kematian" hijau, bukan biru, sehingga mudah dibedakan

Masuk akal untuk berasumsi bahwa Microsoft akan melakukan serangkaian tes untuk kode baru ini: membuat file, memeriksa sinkronisasi, menghapus salinan lokal dengan menyimpan ikon, membuka ikon dengan mengunduh file nyata, menghapus file sepenuhnya, dan seterusnya dan seterusnya. Ada beberapa operasi dasar untuk memanipulasi file dan direktori, dan dalam setiap proses pengembangan yang fleksibel, ada tes untuk memverifikasi bahwa semua operasi bekerja seperti yang diharapkan, dan API melakukan apa yang seharusnya dilakukan.

Selain itu, masuk akal untuk mengasumsikan bahwa setiap perubahan kode yang merusak tes akan ditolak dan tidak diizinkan untuk diintegrasikan. Kode harus diperbaiki, harus lulus pengujian sebelum sampai ke cabang utama Windows, dan terlebih lagi untuk penguji beta.

Namun demikian, ada bug di banyak bangunan awal: sistem menutup ketika menghapus direktori yang disinkronkan dengan OneDrive. Bug ini tidak hanya diintegrasikan ke dalam kode Windows, tetapi juga dirilis ke pengguna akhir.

Uji perangkat lunak sebelum rilis, bukan setelahnya

Ini menyarankan beberapa prinsip dasar pengembangan Windows. Entah tidak ada tes sama sekali untuk kode ini (saya diberitahu bahwa ya, diizinkan untuk mengintegrasikan kode tanpa tes, meskipun saya berharap ini bukan norma), atau kegagalan pengujian dianggap dapat diterima, masalah non-pemblokiran, dan pengembang diizinkan untuk mengintegrasikan kode yang jelas tidak berfungsi dengan baik. Di luar, kita tidak bisa mengatakan dengan tepat apa yang sebenarnya terjadi - mungkin bahkan kombinasi dari kedua pendekatan - tetapi tidak ada yang bisa disebut baik.

Untuk bagian Windows yang lebih lama, ini dapat dianggap lebih dimaafkan - setelah semua, mereka dikembangkan sebelum era pengujian otomatis, dan mungkin benar-benar tidak ada tes. Tetapi lencana OneDrive bukan bagian lama Windows, ini adalah fitur yang sepenuhnya baru. Tidak ada alasan bagus mengapa tidak ada serangkaian pengujian untuk menguji fungsionalitas dasar untuk kode baru. Dan kode cacat yang diketahui pasti tidak boleh dimasukkan dalam basis kode sampai diperbaiki, belum lagi mengirimnya ke penguji.

Akibatnya, pengembangan Windows 10 masih mengikuti prinsip lama. Fitur-fitur baru dituangkan ke dalam basis data dengan degradasi stabilitas dan keandalan. Diasumsikan bahwa basis kode akan dibawa ke tingkat yang dapat diterima pada tahap pengujian dan stabilisasi.

Pengujian otomatis yang tidak memadai dan / atau mengabaikan kesalahan pengujian, pada gilirannya, berarti bahwa pengembang Windows tidak dapat memastikan bahwa perubahan dan koreksi tidak akan menyebabkan efek riak. Di sinilah fase pengembangan "meminta izin": ketika pembaruan selesai, jumlah perubahan perlu diminimalkan karena Microsoft tidak yakin bahwa ruang lingkup dan dampak dari setiap perubahan terisolasi. Keyakinan ini hanya datang dengan infrastruktur besar pengujian disiplin: Anda tahu bahwa perubahan itu aman karena semua tes lulus dengan sukses. Apa pun jenis pengujian yang dilakukan perusahaan untuk Windows, jelas tidak cukup untuk mendapatkan kepercayaan diri seperti itu.

Namun dalam hal lain, Microsoft bertindak seolah-olah memiliki kepastian itu. Perusahaan memiliki banyak tes; Saya diberitahu bahwa siklus pengujian lengkap untuk Windows membutuhkan waktu berminggu-minggu. Siklus penuh ini benar-benar dilakukan, tidak hanya pada rakitan yang benar-benar masuk ke produksi. Contohnya adalah pembaruan Oktober 2018: kodenya dirakit pada 15 September, dan pada 2 Oktober, majelis menjadi publik. Terlepas dari mana RS5 membangun melewati siklus pengujian penuh, ini bukan yang kami benar-benar terima, karena siklus pengujian penuh membutuhkan terlalu banyak waktu.

Ini adalah posisi yang kontroversial. Jika perubahan selanjutnya pada kode dibuat dengan tingkat kepercayaan yang tinggi bahwa mereka tidak merusak apa pun, Anda dapat memulai siklus pengujian penuh pada perakitan sebelumnya. Tetapi jika Microsoft memiliki kepercayaan diri yang tinggi sehingga perubahan ini tidak akan merusak apa pun, itu tidak harus mencekik mereka begitu banyak pada tahap "meminta izin".


Windows 10 benar-benar dapat bekerja seperti mesin yang andal

Bagaimana cara melakukannya dengan benar

Kami melihat perbedaan yang signifikan dengan proyek Agile nyata. Misalnya, proses pengembangan yang digunakan Google untuk server pengiriman iklannya. Ini adalah bagian penting dari infrastruktur untuk perusahaan, tetapi pengembang baru di perusahaan menggambarkan bahwa mereka membuat perubahan untuk menutup kesalahan kecil - dan perubahan masuk ke produksi pada siang hari. Ketika suatu perbaikan dikirimkan ke repositori, itu secara otomatis dibangun kembali dan dikenai serangkaian tes. Pemelihara bagian kode ini kemudian mempertimbangkan perubahan, menerimanya dan menggabungkannya dengan basis kode utama, yang diuji ulang dan digunakan dalam produksi.

Tentu saja, sedikit tidak adil untuk membandingkan ini dengan Windows: setelah semua, jauh lebih mudah bagi layanan cloud untuk mengembalikan perubahan ketika kesalahan terdeteksi. Memodifikasi Windows dengan layar biru pada startup sistem jauh lebih sulit untuk dibatalkan dan dikembalikan.Namun demikian, server iklan adalah layanan Google yang penting, pada akhirnya perusahaan menghasilkan uang, pada akhirnya, dan pembaruan yang tidak berhasil dapat dengan mudah menyebabkan kerugian jutaan dolar. Tetapi pengujian otomatis dan seluruh proses yang ditetapkan memungkinkan bahkan magang di perusahaan untuk menyebarkan perubahan dalam produksi dalam beberapa jam, dan melakukannya dengan percaya diri.

Mentalitas perkembangan pada dasarnya berbeda. Fitur baru mungkin tidak stabil selama pengembangan, tetapi ketika ditambahkan ke cabang utama, itu harus sesuai dengan tingkat kualitas yang tinggi. Pendekatan Microsoft adalah "menggabungkan semua kesalahan sekarang, kami akan memperbaikinya nanti", dan dalam proses yang tepat, bug dihilangkan sebelum fungsi baru dituangkan ke cabang utama.


Chrome , , —

Meskipun aplikasi cloud menawarkan fleksibilitas, metode Agile juga cocok untuk perangkat lunak desktop. Misalnya, Google memiliki proses serupa untuk Chrome. Versi beta dari Chrome memiliki bug langka, tetapi secara umum, kodenya dekat dengan kualitas rilis. Memang, prinsip pengembangan Chrome adalah bahwa bahkan bangunan terbaru harus berkualitas rilis. Anda dapat menggunakan Chrome versi dev sebagai browser biasa - dan hanya dengan ikon Anda akan mengerti bahwa ini adalah alpha, bukan saluran stabil. Ini dimungkinkan berkat otomatisasi pengujian dan validasi yang luas: selama proses pengembangan, kode Chrome berkualitas tinggi, tanpa penurunan kualitas dengan pengeditan berikutnya yang kita lihat di Windows.

Untuk melakukan ini, Google telah berinvestasi dalam infrastruktur. Dia memiliki sistem build terdistribusi yang membangun Chrome secara paralel di atas seribu core, sehingga build lengkap dapat diselesaikan hanya dalam beberapa menit. Percabangan yang disiplin telah dibentuk untuk membuat merger mudah dan dapat diprediksi. Google memiliki berbagai tes fungsional dan kinerja untuk mendeteksi kesalahan dan regresi sedini mungkin. Semua ini tidak gratis, tetapi penting bagi Google untuk merilis rilis Chrome secara berkelanjutan dan berkelanjutan.

Proses pengembangan Windows selalu buruk

Dalam proses pengembangan baru, Microsoft secara proporsional mengalokasikan lebih banyak waktu untuk menulis fungsi baru dan sedikit waktu untuk menstabilkan dan memperbaiki fungsi-fungsi ini. Semuanya akan baik jika kualitas fungsinya tinggi sejak awal, dengan infrastruktur pengujian dan standar yang lebih tinggi sebelum mengintegrasikan kode baru. Tetapi pengalaman dengan Windows 10 sejauh ini adalah bahwa Microsoft belum mengembangkan proses dan sistem yang diperlukan untuk mendukung pendekatan baru ini.

Masalah mengurangi jumlah masalah dari dua menjadi satu per tahun tidak akan memperbaiki masalah. Seringkali bagi saya orang melihat pengembangan Windows sebelumnya melalui kacamata merah muda. Tetapi jika Anda mengingat masa Windows 7 dan sebelumnya, maka kita akan melihat masalah yang sangat mirip. Dan kemudian saran yang biasa adalah jangan meng-upgrade ke versi Windows yang baru sampai Service Pack 1 dirilis. Mengapa? Karena rilis pertama selalu bermasalah dan tidak stabil - dan lebih baik menunggu sampai Paket Layanan 1 menyelesaikan sebagian besar masalah ini.

Perbedaannya bukanlah bahwa pendekatan baru untuk mengembangkan Windows jauh lebih buruk daripada sebelumnya, atau bahwa proses lama memberikan hasil yang lebih baik. Tidak semuanya.Sekarang kita melihat hal yang sama seperti itu, hanya saat "tunggu Paket Layanan 1" datang dua kali setahun. Setelah setiap pembaruan baru, ada saatnya Microsoft percaya bahwa kode ini cukup baik untuk pengguna korporat - biasanya tiga hingga empat bulan setelah rilis awal. Ini adalah Paket Layanan "baru" kami 1.

Dengan demikian, kami mendapatkan yang terburuk dari kedua dunia: dari pendekatan lama hingga pengembangan Windows, ada rilis buruk yang perlu diperbaiki. Dari pendekatan baru - rilis dua kali setahun, dan tidak setiap tiga tahun sekali. Dengan demikian, ketidakstabilan hingga rilis Paket Layanan tetap ada hampir sepanjang tahun.

Kelemahan utama adalah destabilisasi basis kode dengan mengintegrasikan fungsi-fungsi yang tidak diuji dengan harapan memperbaikinya nanti. Ini adalah proses yang buruk. Ini buruk pada saat Windows dirilis setiap tiga tahun, dan itu buruk ketika dirilis setiap enam bulan.

Ini bukan pekerjaan orang dalam

Masalah kedua adalah sifat dari tes. Microsoft dulunya memiliki sejumlah besar penguji, dan sejumlah pengembang dan penguji ditugaskan untuk setiap fungsi. Banyak dari mereka dipecat atau dipindahkan ke pos lain pada tahun 2014. Idenya adalah bahwa lebih banyak tanggung jawab pengujian akan diberikan kepada pengembang yang membuat fitur ini. Program Windows Insider juga menyediakan sejumlah besar pengujian informal - dengan jutaan peserta (orang dalam). Ini jauh lebih banyak daripada program Windows beta sebelumnya.

Tidak yakin apakah pendekatan lama akan mendeteksi bug kehilangan data. Mungkin penguji profesional tidak akan menguji skenario tertentu di mana data dihapus. Tetapi jelas bahwa Microsoft tidak menangani aliran pesan kesalahan dari orang dalam. Kehilangan data dicatat tiga bulan sebelum pembaruan. Banyak pesan kesalahan tampaknya memiliki kualitas buruk, mereka tidak memiliki rincian yang diperlukan atau terminologi yang benar, tetapi jika perusahaan tidak memperhatikan masalah selama tiga bulan, maka sama sekali tidak jelas bahwa masa pengembangan yang lebih lama penting. Periode pengembangan yang lebih lama akan berarti bahwa kesalahan diabaikan selama enam bulan, bukan tiga.

Microsoft berjanji untuk mengubah proses umpan balik dengan orang dalam sehingga mereka menunjukkan tingkat keparahan masalah dan menarik lebih banyak perhatian pada masalah semacam ini. Ini dapat membantu jika orang dalam menggunakan indikator keparahan dengan benar, tetapi tampaknya tidak cukup untuk menyelesaikan masalah utama: terlalu banyak laporan kesalahan dengan kualitas terlalu rendah.

Ini merujuk pada masalah kualitas kode. Kekuatan sebenarnya dari Insider adalah beragam perangkat keras dan perangkat lunak. Orang dalam dapat mengidentifikasi bug kompatibilitas paling eksotis, masalah dengan driver, dan sebagainya. Tetapi orang dalam tidak seharusnya melakukan pengujian fungsi dasar. Namun seringkali ada perasaan bahwa Microsoft menggunakannya sebagai penguji penuh waktu.

Selain itu, jika kualitas kode menurun selama pengembangan, maka pra-build biasanya tidak cocok untuk penggunaan sehari-hari pada PC biasa. Mereka tidak cukup dapat diandalkan. Pada gilirannya, ini merongrong nilai pengujian oleh orang dalam: mereka tidak menginstalnya pada PC utama dan tidak membuat perakitan berbagai perangkat keras dan perangkat lunak. Mereka menggunakan PC sekunder dan mesin virtual.

Anda harus berinvestasi dalam alat Anda

Mengembangkan infrastruktur pengujian seperti Chrome untuk proyek raksasa seperti Windows adalah tugas yang sangat serius. Meskipun beberapa bagian Windows memungkinkan pengujian offline, yang lain hanya dapat diuji secara efektif pada sistem yang terintegrasi dan terintegrasi. Beberapa di antaranya, seperti fitur sinkronisasi file OneDrive, bahkan bergantung pada pengoperasian layanan jaringan eksternal. Ini bukan tugas sepele.

Perubahan besar akan menjadi penerapan prinsip bahwa kode Windows harus memberikan kualitas rilis setiap saat - bukan "setelah beberapa bulan koreksi", tetapi "sekarang, setiap saat". Tetapi ini adalah kondisi yang perlu. Microsoft harus mencapai situasi di mana setiap pembaruan baru memiliki kualitas rilis sejak hari pertama. Situasi di mana memperbarui ke versi terbaru tidak menjadi masalah - dan pilihan ini dapat diterima dengan aman. Pembaruan fitur harus tidak terlihat oleh pengguna. Mengurangi jumlah rilis menjadi satu per tahun atau satu dalam tiga tahun tidak akan memberikan situasi ini, dan tidak pernah terjadi. Prosesnya sendiri harus berubah, bukan waktunya.