Apa hubungannya Star Wars, grup Tatu, dan kombinasi Ctrl-Alt-Del dengan kode Legacy? Apa yang harus dilakukan ketika Anda datang ke proyek besar dan menemukan jurang kode lama yang tidak bisa dipahami? Dan bagaimana cara lebih efisien untuk menyampaikan kepada pihak berwenang bahwa biaya tenaga kerja untuk menghilangkan utang teknis terbayar?
Laporan
Dylan Beatty bukan tanpa lelucon, tetapi lelucon ini menyertai diskusi yang cukup serius tentang masalah pembangunan utama. Ini sangat cocok untuk akhir konferensi: ketika penonton sudah mendengar banyak hardcore dan tidak bisa lagi melihat slide kode, saatnya untuk pertanyaan yang lebih umum dan presentasi yang cerah. Dan ketika konferensi DotNext 2018 Moscow .NET kami selesai dengan pidato Dylan tentang kode Legacy, penonton paling menyukainya.
Oleh karena itu, sekarang untuk Habr, kami telah membuat versi terjemahan teks pidato ini: untuk donor, dan untuk semua orang. Selain teks, di bawah potongan ada rekaman video berbahasa Inggris asli.
Halo, nama saya Dylan Beatty. Topik pembicaraan sangat dekat dengan saya dan, menurut saya, sangat penting bagi semua orang yang terlibat dalam pengembangan perangkat lunak: kita akan berbicara tentang kode warisan.
Pertama, saya akan mengatakan beberapa kata tentang diri saya. Saya mulai mengembangkan situs web pada tahun 1992, dengan standar industri kami, pada zaman prasejarah. Sekarang saya CTO dari perusahaan London, SkillsMatter. Saya mulai bekerja di sana tahun ini, dengan demikian mewarisi basis kode: 75 ribu baris kode yang tidak saya tulis menjadi tanggung jawab saya. Bagian dari laporan saya didasarkan pada pengalaman ini. Selain itu, saya adalah Microsoft MVP dan kepala kelompok pengguna .NET London.
Apa kesamaan yang dimiliki Doctor Who, Star Wars, Sherlock, dan Paddington? Saat mengerjakannya, kode lawas digunakan. Saya tahu ini karena selama 15 tahun saya bekerja di Spotlight. Ini adalah perusahaan yang berbasis di London yang menyediakan alat online untuk aktor profesional yang bertindak dalam film dan di televisi. Perangkat lunak, yang ditulis oleh saya dan tim saya, digunakan dalam pekerjaan pada semua proyek yang disebutkan dan banyak lainnya.
Dalam Star Wars baru, beberapa tidak suka aktor, yang lain tidak suka plot. Tapi tidak ada yang keluar dari bioskop dengan kata-kata "Saya tidak suka ASP klasik digunakan dalam penciptaan!"
Karena itu tidak masalah. Basis kode ini telah diproduksi untuk waktu yang sangat lama, dan ya, ada ASP klasik - kode yang lebih tua dari keseluruhan .NET - yang masih digunakan sampai sekarang dalam casting untuk film dan acara TV. Penting untuk menempatkan penekanan dengan benar: film dan acara TV inilah yang penting, dan kode itu hanya ada untuk menyelesaikan masalah. Sampai Anda menjalankannya, kode itu sendiri tidak berarti apa-apa. Nilai hanya muncul ketika Anda meluncurkannya dan melakukan sesuatu dengannya. Itulah yang orang bayar - Netflix atau DVD. Masalahnya adalah sangat mudah untuk melupakannya.
Secara umum, hari ini saya ingin, antara lain, untuk berbagi dengan Anda pengalaman saya dengan basis kode yang sama selama bertahun-tahun. Saya menyaksikan bagaimana itu berkembang, dan bagaimana orang lain mengetahuinya dan belajar bagaimana menggunakannya. Dan sisi lain dari persamaan ini adalah pekerjaan baru saya, yang memungkinkan saya untuk melihat proses yang sama dari sisi lain, ketika saya sendiri harus berkenalan dengan kode orang lain.
Tapi pertama-tama, mari kita bicara tentang seberapa cepat hal-hal berubah di IT.
Lihatlah iPhone pertama - hari ini terlihat sangat kuno dan tebal. Dan model ini baru berusia 11 tahun, muncul pada 2007, dan harganya $ 800. Jika Anda membeli mesin cuci, gitar atau sepeda pada 2007, hari ini Anda masih bisa menggunakannya. Tetapi iPhone pertama tidak lagi berfungsi - bahkan jika Anda berhasil menemukan salinan dengan baterai dan pengisi daya, semua hal yang membuat smartphone seperti perangkat yang luar biasa tidak akan berfungsi di dalamnya.
Anda tidak akan dapat membuka peta karena server peta tidak ada lagi. Anda tidak akan dapat pergi ke Twitter karena versi terbaru dari aplikasi Twitter memerlukan versi iOS yang tidak dapat diinstal pada iPhone 1. Klien Twitter hanya akan menjawab Anda: "endpoint not found". Intinya, Anda akan memiliki fosil di tangan Anda. Dan satu-satunya hal yang akan berfungsi di dalamnya adalah fungsi telepon biasa, Anda masih bisa memanggilnya. Karena di bidang ini, tidak seperti IT, standar selama 11 tahun tidak berubah.
Mari kita jalan-jalan sebentar. Ingat yang ini?
Apakah Anda ingat tahun berapa itu? Tatu tampil di Kontes Lagu Eurovision pada tahun 2003. Dan pada tahun 2003, saya menulis kode ASP, yang sekarang masih digunakan dalam produksi.
Tampaknya bagi kita ini sudah lama sekali, tetapi kode ini masih berfungsi. Pabrikan ponsel berhasil membuat orang membeli telepon baru setiap dua tahun, sehingga mereka mampu menyingkirkan perkembangan lama, menonaktifkan API, titik akhir, layanan. Tetapi banyak perusahaan tidak memiliki kesempatan seperti itu, dan oleh karena itu mereka terus mendukung kode yang ditulis ketika Tatu tampil di Eurovision. Kode ini penting karena masih menjalankan fungsi-fungsi penting, menghasilkan pendapatan - yaitu kode warisan.
Dan meskipun kita semua sepakat bahwa Legacy ada, pertanyaannya tetap: apa sebenarnya itu? Berikut ini contoh kode:
Lihat, pikirkan: apakah itu warisan atau bukan? Apa yang kamu pikirkan
Saya menemukan perangkat, saya ingin menjual tahun depan. Anda memasukkannya ke port USB, pilih sepotong kode, dan perangkat memberi tahu Anda apakah itu warisan atau bukan!
Kode yang baru saja Anda lihat bukan warisan. Itu ditulis oleh
Andrey Akinshin (
DreamWalker ) empat hari lalu. Ini
diambil dari BenchmarkDotNet.
Faktanya adalah bahwa tidak mungkin untuk menentukan apakah kode tersebut adalah Legacy hanya dengan melihatnya. Selain itu, kode itu sendiri tidak ada hubungannya dengan itu. Yang penting adalah apa yang terjadi di sekitarnya: orang, budaya, proses, ujian, dan sebagainya.
Jika Anda membuka artikel "Kode lama" di Wikipedia bahasa Inggris, Anda dapat membaca yang berikut: "Ini adalah kode sumber yang terkait dengan sistem operasi atau teknologi komputer lainnya, dukungan atau produksi yang telah dihentikan. Kami seperti: "Oke." Dan kemudian tertulis: "Istilah ini pertama kali digunakan oleh George Olivetti sehubungan dengan kode yang didukung oleh administrator yang dirinya sendiri tidak menulis kode ini."
Di akhir kalimat ini ada tautan ke blog seorang Samuel Mullen tertentu. Kami berpikir, "Menarik, kita lihat saja nanti." Tetapi jika kita membuka
posting , kita akan melihat bahwa Mullen ini, pada gilirannya, merujuk ke Wikipedia!
Dan, tampaknya, tidak ada orang lain yang tahu siapa George Olivetti ini. Jadi sepertinya kita harus mencari definisi yang lebih baik.
Salah satu definisi paling populer dalam industri ini diberikan oleh Michael Faethers: "Legacy hanyalah kode tanpa tes." Dan Michael menulis
seluruh buku tentang hal ini, jadi dia pasti tahu apa yang dia bicarakan. Tapi tetap saja, saya tidak sepenuhnya setuju dengan definisinya.
Karena itu, saya telah menggunakan definisi saya selama beberapa tahun: "Kode bawaan adalah kode yang terlalu menakutkan untuk diperbarui, tetapi terlalu menguntungkan untuk dihapus."
Kemudian ternyata definisi yang sangat mirip sudah
diberikan secara independen dari saya: "kode yang sangat menguntungkan yang kita takut untuk ubah." Saya ingin tahu dari mana rasa takut ini berasal. Apa yang ada tentang tes yang mengubah kode tanpa menjadi warisan?
Salah satu alat bisnis tertua di dunia adalah sistem akuntansi entri ganda. Berumur ratusan tahun, dan di dalamnya setiap transaksi bank atau perusahaan dihitung dua kali: dalam satu kolom saya menuliskan berapa banyak uang yang saya bayarkan, dan di yang lain - nilai yang saya terima untuk mereka. Selain itu, jumlah kedua kolom harus sama, jika ada perbedaan, kesalahan terjadi di suatu tempat.
Tampak bagi saya bahwa ide mendasar dari pendekatan ini tampaknya sangat penting: semua keputusan yang kita buat memiliki efek dua kali, dan jika Anda mengubah satu hal, maka di tempat lain Anda pasti juga memiliki perubahan yang perlu dipantau. Pendekatan ganda ini dapat diterapkan pada kode dan pengujian, atau pada kode dan sistem pemantauan, atau pada kode dan dokumentasi.
Banyak sistem yang kami anggap sebagai warisan juga ada dalam dua versi, tetapi ini adalah versi "dalam kode dan di kepala seseorang". Dan di sini, menurut saya, terletak salah satu kesulitan utama kami.
Saya ingat
strip komik satu halaman, "Inilah sebabnya mengapa Anda tidak boleh mengganggu seorang programmer." Pengembang melihat garis kode sederhana, dan langsung mulai berpikir tentang apa yang perlu ditulis ulang di menu navigasi sekarang, bagaimana ini akan mempengaruhi debugger, yang kemudian perlu diubah dalam kode. Seseorang mendatanginya dan bertanya: "Apakah Anda menerima surat saya?", Dan kemudian semua pohon suntingan yang rumit ini terbang keluar dari kepala saya.
Ketika kita bekerja, kita memasuki kondisi kesadaran yang berubah, otak kita membangun model-model rumit yang menjelaskan bagaimana kode itu bekerja. Ketika kode ditulis oleh satu orang (misalnya, dalam startup atau proyek open source), seringkali, selain model di kepala dan model dalam kode, tidak ada apa-apa. Ini memungkinkan Anda untuk bekerja sangat cepat - Anda hanya menerjemahkan apa yang ada di kepala Anda ke dalam kode. Model yang ada di kepala benar, jadi jika ada sesuatu yang salah dalam kode, lihat saja, bandingkan dengan apa yang ada di kepala, dan kesalahan akan segera terlihat. Dan ketika Anda menemukan bug, sering kali ini menunjukkan bahwa Anda belum cukup memikirkan aspek apa pun, dan Anda memperbarui model di kepala terlebih dahulu, lalu kodenya.
Ada
posting indah
oleh Jessica Kerr , di mana dia, di antara hal-hal lain, mengatakan bahwa penemuan adalah bagaimana berlari menuruni gunung, dan analisis adalah bagaimana mendaki gunung. Kami suka menulis kode, itu menarik dan mudah: Anda mulai dari awal dan menemukan sesuatu yang baru, menyelesaikan masalah, menulis algoritma, metode dan kelas. Tetapi membaca kode itu sulit - di depan Anda sejak awal ada banyak sekali kode orang lain, dan ini adalah jenis pekerjaan yang sangat berbeda.
Oleh karena itu, di banyak organisasi Anda dapat mengamati fenomena yang oleh Alberto Brandolini disebut sebagai "dungeon master": ini adalah orang yang menulis versi pertama dari sistem. Saya adalah orang ini di Spotlight - saya menulis bagian penting dari versi pertama saja, dan saya menulisnya di ASP klasik, tanpa dokumentasi dan tanpa unit test. Mereka mulai membuat film dengan alat ini, apakah Star Wars, kami mendapat uang dan semuanya hebat. Tetapi kemudian kami mulai merekrut karyawan baru yang pada awalnya tidak tahu bagaimana semua ini bekerja, dan selama dua hingga tiga bulan mereka harus berkenalan dengan sistem.
Segera, pembicaraan dimulai tentang porting sistem ke .NET, karena ASP klasik tidak cukup andal dan tidak cukup cepat. Percakapan seperti itu akan selalu terjadi - tidak peduli kode apa yang Anda tulis, seseorang akan bersikeras bahwa itu perlu ditulis ulang. Ini terjadi karena orang ini tidak memahami kode Anda, dan menulis kode baru lebih menarik daripada mempelajari yang lama. Pemrograman adalah pekerjaan yang membawa kesenangan, kami sangat menyukainya. Oleh karena itu, sangat wajar bahwa, karena dihadapkan dengan suatu pilihan, kita akan bersandar pada pilihan yang lebih menarik.
Pemilik ruang bawah tanah adalah orang yang tahu semua jebakan dalam kode. Dia tahu tentang tombol yang tidak bisa ditekan, kalau tidak aplikasi akan macet; salah satu yang menjadi gantungan TODO dari tahun 2014, yang belum ada yang mencapai tangan mereka. Kami di industri kami telah belajar untuk tidak lagi membuat sistem seperti itu. Inilah sebabnya saya suka acara seperti DotNext, grup pengguna, komunitas, dan StackOverflow: ketika Anda memulai proyek baru, Anda pasti akan diberitahu bahwa Anda perlu menulis tes, melakukan spesifikasi dengan contoh, integrasi, pemantauan. Jadi masa depan kita adalah layanan microser serverless pada F # dengan cakupan seratus persen dari kode dengan tes.
Tetapi masalahnya bukan pada perangkat lunak yang harus kita tulis: dunia kita sudah penuh dengan perangkat lunak. Dan, jika Anda membayangkan perangkat lunak ini dalam bentuk piramida, maka serverless F # hanya akan menempati posisi paling atas. Sedikit lebih banyak akan menjadi ASP.NET, entah bagaimana tercakup dalam tes. Bahkan lebih - Visual Basic pada Windows XP. Tetapi platform pengembangan produk komersial paling populer dalam sejarah adalah lembar kerja Excel.
Saya siap bertaruh bahwa setiap kali Anda membeli tiket pesawat atau menginap di hotel, entah bagaimana nama Anda muncul di semacam spreadsheet Excel. Pengembangan melalui pengujian tidak memperhitungkan beban besar kode yang sudah tertulis ini.
Tapi mengapa bersikeras menulis ulang kode lama? Pada awalnya, orang tidak suka ASP klasik dan mereka ingin menulis ulang semuanya di .NET. Kemudian ternyata Anda perlu menulis ulang semuanya pada versi 4.5, lalu 4.6, lalu .NET Core. JQuery tidak bagus, jadi Anda harus beralih ke Angular, setelah itu Bereaksi, kemudian Vue, garis akan datang.
Saya menduga bahwa setidaknya salah satu alasan di sini terletak pada pengejaran mode. Kita semua berkomunikasi satu sama lain, dan sebagian besar pekerjaan dengan kualitas terbaik di industri kami dilakukan karena penulis ingin mencapai pengakuan dan rasa hormat kepada orang-orang dari profesi mereka. Sepertinya bagi saya bahwa dalam industri kami ada kecanduan berlebihan pada segala sesuatu yang baru dan mengkilap, dan bahasa pemrograman tunduk pada tren mode. Tapi bagaimanapun, mereka yang lewat mode, dengan sendirinya, tidak berubah dengan cara apa pun, semua keunggulan mereka tetap sama seperti sebelumnya.
Bayangkan ada dua resume di depan Anda:
Tidak ada keraguan bagi saya yang mana dari mereka akan lebih baik bagi saya untuk bekerja pada masalah yang sangat penting. Tetapi jika Anda berbicara dengan orang-orang dari HR, atau dengan mereka yang baru saja menyelesaikan kursus pemrograman, Anda akan melihat bahwa mereka dapat menghasilkan uang dengan baik pada keterampilan programmer pertama, dan mereka menganggap keterampilan yang kedua menjadi usang. Tetapi mereka sama sekali tidak ketinggalan zaman - masih ada banyak masalah yang bisa diselesaikan orang ini.
Saya pikir salah satu alasan untuk sikap ini adalah orang takut. Beberapa rekan saya meninggalkan tim kami karena mereka ingin bekerja di Angular atau NodeJS. Ketika saya bertanya kepada mereka mengapa mereka membutuhkannya, mereka menjawab bahwa jika mereka terus bekerja hanya di .NET, maka setelah dua tahun mereka tidak akan dapat menemukan pekerjaan. Saya menjawab mereka: teman-teman, kami dengan .NET kami baru saja membantu membuat Star Wars! Dan mereka berkata: ya, tapi itu masih bukan Angular.
Jangan salah paham, saya menghargai keputusan mereka. Tidak boleh ada pembicaraan tentang korupsi, hanya orang yang khawatir tentang masa depan mereka dan masa depan keluarga mereka jika mereka harus mencari pekerjaan. Dan dalam industri kami masalah keamanan ini biasanya ditafsirkan dalam arti bahwa Anda perlu mempelajari semuanya dari awal setiap setengah tahun, jika tidak, Anda akan kehilangan daya saing. Sangat sering, kita jauh lebih tertarik pada teknologi itu sendiri daripada kemampuan kita untuk memecahkan masalah.
Selain rasa takut ketinggalan dan menjadi usang di sini, menurut saya, rasa takut memainkan peran penting dalam mengubah sistem yang tidak Anda mengerti. Mereka memberi Anda kode yang tidak Anda ketahui, tetapi jika ada gangguan, itu akan menjadi tanggung jawab Anda, dan jika jatuh di tengah malam, mereka akan membangunkan Anda. Maka timbullah rasa takut.
Seperti yang kita ketahui dari Star Wars yang sama, ketakutan mengarah ke kemarahan, kemarahan mengarah ke kebencian, kebencian mengarah pada penderitaan, penderitaan mengarah ke JavaScript. Bagaimana kita bekerja dengan rasa takut kita dan rasa takut rekan kerja kita? Menurut saya, ada tiga aspek utama:
pemahaman ,
kepercayaan , dan
kontrol .
Kepercayaan adalah yang paling sederhana dan paling sulit dari ketiganya. Saya percaya laptop ini karena tidak pernah crash selama presentasi. Begitu ini terjadi, kepercayaan saya padanya akan hilang. Dalam bahasa Inggris ada pepatah, "kepercayaan dimenangkan setetes demi setetes, tetapi hilang karena ember." Setelah sebulan bekerja dengan seseorang, Anda akan siap untuk mengakui bahwa ia mungkin fasih dalam bisnisnya, dalam dua Anda akan mengatakan bahwa ia fasih, dalam tiga Anda akan setuju bahwa ia tahu bisnisnya dengan sangat baik. Dan setelah tiga bulan dan satu hari, kerentanan terhadap injeksi SQL akan terungkap dalam kodenya, dan Anda akan berkata, "Ah, saya selalu mengatakan bahwa dia tidak ada gunanya".
Memercayai orang lain selalu sulit, karena itu selalu berarti menyerahkan tingkat kontrol tertentu. Keyakinan dalam kode juga merupakan topik penting. Setelah Anda bekerja dengan sistem untuk waktu tertentu, Anda ingin percaya bahwa itu akan bekerja sesuai dengan harapan Anda. Sistem operasi Anda stabil dan andal, dan Anda berharap tidak jatuh. Anda mempercayai basis data dari informasi Anda dan berharap mereka tidak akan kehilangannya. Anda berharap bahwa penyedia cloud akan memastikan operasi situs Anda yang berkelanjutan dan tidak akan menjual informasi pelanggan Anda di pasar gelap.
Tidak ada cara cepat untuk mendapatkan kepercayaan. Benar, kepercayaan itu transitif: jika saya mempercayai Anda, dan Anda memercayai orang lain, kemungkinan besar saya juga bisa mempercayai orang ini. Jika saya mendengarkan pendapat Anda, dan Anda pikir Anda dapat mempercayai Amazon, AWS, Azure atau Google App Engine, maka saya akan siap untuk percaya bahwa ini adalah layanan yang baik. Tetapi tidak ada cara cepat untuk mendapatkan kepercayaan.
Mari kita beralih ke
pemahaman . Di universitas saya belajar ilmu komputer selama tiga tahun. Jika insinyur sipil mengikuti prinsip yang mendasari pendidikan kita, maka pada tahun pertama mereka akan membangun gudang kayu, di logam kedua, dan di kaca ketiga, kaca canggih.
Di tahun pertama kami menulis program kecil di Lisp, di program kedua - kecil di Jawa, di program ketiga - kecil di Skema dan Prolog. Kami tidak menulis program besar, dan, yang lebih penting, tidak mencoba mencari tahu.
Tetapi insinyur sipil tidak diajarkan oleh contoh gudang, mereka dipaksa untuk memahami gedung pencakar langit, jembatan, masyarakat philharmonic dan bangunan seperti yang kita miliki sekarang. Siswa-siswa ini belajar dari proyek-proyek terbesar dan paling mengesankan di industri mereka. Dan jika mereka belajar sesuai dengan prinsip yang sama seperti mereka mengajarkan ilmu komputer, maka siswa, dihadapkan dengan urutan nyata untuk gedung pencakar langit, tidak akan memikirkan apa pun selain meletakkan gudang di atas satu sama lain sampai menara Petronas ternyata.
Dalam situasi ini seorang siswa yang menyelesaikan kursus ilmu komputer menemukan dirinya dan diberi tugas untuk menulis sistem pengadaan komersial terdistribusi. Sebagian besar dari perangkat lunak yang ada ditulis dengan cara yang kira-kira sama. Orang-orang yang menulisnya tidak bertanggung jawab, tetapi hanya tidak berpengalaman. Mereka melakukan dengan sangat baik semua yang mereka lakukan di universitas, dan ini menciptakan kepercayaan diri yang salah. Itulah tepatnya saya pada satu waktu, dan, saya yakin, banyak dari Anda yang sama pada satu waktu. Kami bertindak sebagai berikut: kami menulis halaman web, membuat tautan ke halaman lain, lalu yang lain, menyalin kode dan semua orang akan senang - pelanggan kami memiliki produk, perusahaan kami memiliki uang, kami memiliki bonus. Lima tahun kemudian, Anda melihat mimpi buruk ini dan berpikir: bagaimana ini bisa ditulis?
Bagian dari masalah adalah kemampuan untuk mempelajari perangkat lunak. Insinyur sipil pandai mempelajari bangunan, insinyur pesawat pandai mempelajari pesawat terbang. Ambil bacaan: di War and Peace ada 45 ribu baris (tergantung publikasi). Ini adalah salah satu buku terbesar di dunia, itu membutuhkan studi yang sangat serius oleh orang-orang yang terlibat dalam kritik sastra. Dengan kata lain, mempelajari benda sebesar itu adalah pekerjaan. Ukuran drama terpanjang Shakespeare, Hamlet, adalah 6 ribu baris. Sekarang pikirkan: kernel Linux tiga kali lebih lama dari War and Peace. Dan kita berbicara tentang kode yang sangat kompak, terorganisir dengan baik, dengan dokumentasi yang luas dan komunitas besar. Namun demikian, untuk memahami itu sama dengan harus memahami "Perang dan Damai" tiga kali.
Lihatlah grafik ini, yang menunjukkan jumlah baris dalam buku Hamlet, Moby Dick, The Brothers Karamazov, The Lord of the Rings, Atlas Shrugged, dan War and Peace, serta kernel Linux dan Mono .
Apakah rasio ini tampak realistis bagi Anda? Maafkan saya karena telah menyesatkan Anda. Grafik ini sebenarnya eksponensial.
Grafik garis pada slide berikutnya:
Idenya di sini sangat sederhana: perangkat lunaknya besar, hanya duduk dan membaca itu tidak mungkin. Minta seseorang untuk mengenal kernel Linux dengan cara yang sama seperti meminta seseorang untuk membaca War and Peace, Atlas Shrugged, The Lord of the Rings, dan semua Harry Potters secara berturut-turut. Bayangkan Anda datang ke perusahaan baru, dan mereka memberi tahu Anda dari ambang batas bahwa Anda perlu mempelajari semua buku ini, dan baru setelah itu Anda akan diizinkan untuk kode tersebut. Tentu saja mereka tidak.
Membaca kode bisa sangat berguna - Anda dapat memahami cara beberapa pola bekerja, dan mempelajari beberapa contoh. Tetapi Anda tidak dapat menemukan sistem yang besar jika Anda membacanya seperti Anda membaca buku. Mungkin pendekatan ini memiliki sesuatu yang mulia, tetapi tidak mengarah pada apa pun, seperti yang terlihat oleh saya. Ada terlalu banyak kode, dan itu ditulis lebih buruk daripada buku-buku ini.
Jika hanya membaca kode tidak efisien, lalu bagaimana cara mempelajarinya dengan benar? Ingat Richard Feynman, Peraih Nobel Fisika. Baginya, masalah pengajaran sains sangat penting. Dia percaya bahwa mengajar orang bukan sains, tetapi bagaimana melakukan sains dengan benar. Dia diundang ke Universitas São Paulo di Brasil, karena di Brasil para siswa menerima nilai yang sangat tinggi, tetapi pada saat yang sama tidak mungkin untuk membuat produksi teknologi tinggi. Feynman diminta untuk membantu mencari tahu apa masalahnya.
Selama beberapa tahun, ia datang ke Brasil setiap tahun selama beberapa minggu, dan berbicara dengan siswa. Dia melihat bahwa siswa Brasil sangat tahu, misalnya, nama fenomena yang terjadi ketika tekanan diterapkan pada tubuh kristal - triboluminescence. Tetapi tidak ada dari mereka yang tahu bahwa jika Anda menghancurkan sepotong gula dengan tang di rumah di ruangan gelap, Anda akan melihat percikan api menyelinap - dan ini adalah triboluminescence. Feynman menjelaskan bahwa siswa hanya dilatih dalam buku teks untuk lulus ujian, tetapi mereka tidak membuat percobaan apa pun.
Menurut saya, ini berisi pelajaran penting bagi industri kami. , . , , , . , .
—
. , , , .
—
. , , . , , - .
. ,
.
.
, , .
, — , , . , , - , ? .
- , , - . .
- «I love LAMP», , , . — , , , . : , , , .
, , , . , . , DLL. , , . , — , . , , — .
— ? ? -, « - ». , , . , , . , , Wi-Fi. Wi-Fi , , , . : , , — ? Dan sebagainya.
, , . , , , .
, . , , DLL api.payments.mycompany.com. DLL, , , , , DLL , .
: .
,
: , . . , : , .
. , , . , , . : , , , . , - , . .
Spotlight, ASP Amazon Web Services. , GitHub - « ». , , , , .
- , , . Windows 2016 , ASP, 2003 .
, , , «» , « » Windows 2016 , . ASP.NET MVC 2 , , 3, 4. DLL, , ASP.NET MVC 2, - - microsoft.com, , , Nuget , . Program Files. ASP.NET MVC 2, , .
, . , , - . , : , -?
: , , -?
, , , , . - — -, , . — . , !
, , , - — , .
, . 50 000 , . — 100 000, 200 000… , Int32. , , - id -. , - , , , int, .
, , , . — . , , , .
, , . , , 32 64, . , , . . , , , . , , . , , , .
, 80- 90-, -, , . , . , .
. , — , . , , , , . , .
, . , , . , , . , — « » . , , , . : «, - ?»
, - — , . , , . , ; , — , . . , , . , .
, . , , . , . , . , , , , — , 12 , , , 3 .
, , , . , . , , .
, — ? «definition of done»?
, , GitHub , , , .
, . , . Google Analytics , , . . - , . «», , . — , . , JavaScript, . , .
, , — , . — , 20 . — , .
: , . , . , . GitHub, . - , .
: , .
-. , , , , , , , COBOL. MUMPS? , . , 1960- , 26 . — . , , - .
- , « -» « ». .
:
(control), (alter) (delete) - .
Terima kasih atas perhatian anda
, : DotNext 15-16 . .NET- ( -10 ), — , .NET Foundation. , — .