Kami di Veeam memiliki proyek pendidikan dengan nama singkat Veeam Academy . Ini didedikasikan untuk praktik pengembangan C #. Jika Anda tidak merinci, maka intinya adalah ini: kami mengambil siswa senior dan dalam tiga bulan kami membawa pengetahuan lembaga teoritis murni mereka sesuai dengan kenyataan di sekitarnya. Ini dilakukan baik dengan bantuan ceramah, di mana mereka mengungkapkan makna praktis dari teori membosankan yang mereka berhasil berikan di universitas, dan dengan bantuan proyek bersama, pengembangan yang mereka lakukan selama pelatihan.
Dalam perjalanan ke peluncuran pertama Akademi, kami dihadapkan dengan banyak masalah menarik, baik murni organisasi maupun hukum. (Jika seseorang tidak tahu, pelatihan adalah kegiatan berlisensi, jadi Anda tidak bisa mulai mempelajari sesuatu, bahkan jika Anda benar-benar ingin, agar tidak meningkatkan minat pihak berwenang pada diri Anda sendiri.)
Tetapi dari mana siswa mendapatkan keterampilan praktis yang sama, Anda bertanya? Jawabannya ada pada pengembang kami, yang secara sukarela sepenuhnya bertindak sebagai konsultan, melakukan tinjauan kode untuk anak-anak dan hanya berbagi pengalaman mereka. Selain itu, hanya pengembang senior yang berpartisipasi dalam kegiatan ini. Bersama mereka (setelah 3 lulus dari akademi) kami memutuskan untuk berbicara untuk mencari tahu:
- Mengapa mereka menghabiskan waktu berharga mereka pada siswa?
- Bagaimana rasanya menjadi mentor pemula?
- Bagaimana / mengapa / mengapa hidup dengan kode lama?
- Apa yang kurang dalam pendidikan modern?
- Mengapa orang pergi ke pengembangan produk kotak?
Kami melakukan serangkaian wawancara video kecil dengan gaya Dud, dan akan ada ekstrak teks kecil dari jawaban yang paling menarik. Dua wawancara penuh kini telah dipublikasikan (ada di artikel), tetapi tiga wawancara lagi akan segera diposting.
Aktor:
Alexander Baranov - Manajer Pengembangan, Cadangan & Replikasi Veeam.
Artyom Grigoriev - Pengembang Berpengalaman.
Dmitry Babushkin - Pengembang Senior.
Kirill Lukyanov - Kepala Departemen Pengembangan untuk Hyper-V, pemimpin proyek dengan cara yang sederhana.
Philip Guzeev - Pengembang yang Berpengalaman.
Bagaimana ide lahirnya Veeam Academy?
Alexander - Idenya adalah satu. Dalam berbagai wawancara, muncul pemahaman tentang apa yang tidak ada kandidat. Banyak junior datang kepada kami (pengembang junior). Sebagai aturan, ini adalah orang-orang yang baru saja lulus dari institut, dengan pengalaman kerja sekitar 1 tahun atau tidak sama sekali. Sebagai aturan, mereka kurang latihan. Ini berarti bahwa sesuatu harus dilakukan sehingga jika defisit ini tidak sepenuhnya dihilangkan, maka setidaknya kesenjangan utama akan terisi. Kami mulai berpikir tentang bagaimana menyesuaikan pengalaman kami yang ada dalam kursus singkat dua atau tiga bulan - ini adalah awalnya.
Kursus dalam algoritma dan struktur data yang akan diajarkan di fakultas matematika tidak buruk dalam dirinya sendiri. Masalahnya adalah bahwa mereka sering pergi secara terpisah dari aplikasi praktis dalam pengembangan, sehingga mereka tidak terserap dengan baik. Kami mencoba menyusun pengetahuan ini sedikit dan memberikannya rasa praktis untuk cara kerjanya. Dan bukan hanya "bagaimana teknologi bekerja", tetapi bagaimana proses secara keseluruhan bekerja: bagaimana tim bekerja, bagaimana tugas-tugas didistribusikan, cara menyinkronkan anggota tim, dll.
Bagaimana Anda bisa sampai ke Akademi?
Artyom - Mereka menawarkan untuk berpartisipasi di Akademi sebagai peninjau, saya berpikir: "Mengapa tidak?", Pada saat yang sama saya akan menyegarkan pengetahuan saya dan mendapatkan pengalaman berbicara. Itu adalah pengalaman pertama saya hampir dari universitas, jadi saya sangat khawatir.
Di sisi lain, Akademi adalah kesempatan untuk merekrut lebih banyak karyawan, dan dalam hal apa pun itu adalah pengalaman yang menarik dan kesempatan untuk memahami bagaimana rasanya mentransfer pengetahuan.
Philip - Segera setuju, seperti yang disarankan. Itu selalu menarik untuk melihat apa yang orang pikirkan, untuk memperhatikan sesuatu yang baru untuk diri mereka sendiri. Dan selalu bermanfaat untuk membagikan pengetahuan Anda.
Cyril - Ketika proyek dimulai, itu hanya ide untuk menarik pengembang ke proses. Itu masuk akal karena kami terus-menerus dihadapkan dengan masalah teknis tertentu dalam praktiknya dan kami tahu beberapa aspek yang siap kami bagikan. Sebuah proposal diterima, saya secara spontan setuju, dan ketika saya sudah mulai mendekati ini dengan lebih serius, maka sudah ada tujuan dan keinginan untuk mencapainya.
Apa yang kamu lakukan di Akademi?
Dmitry - Pertanyaan yang disiapkan untuk pengujian online, dilibatkan dalam pemilihan dan wawancara siswa, dan juga bertindak sebagai mentor bagi beberapa siswa.
Alexander - saya melakukan apa yang saya pikirkan dan rencanakan pada awalnya, apa yang harus kita lakukan dan katakan - dan apa yang kita [dalam kandidat] kekurangan, dan itu akan menarik bagi orang-orang yang datang ke Akademi ini.
Philip - Di Akademi, saya dan saya adalah seorang mentor - seseorang yang merevisi kode siswa dan mengarahkan mereka ke jalan yang benar, memberikan segala macam saran.
Jangan menyesali waktu yang dihabiskan?
Dmitry - Tidak, tentu saja. Saya membantu merekrut tiga orang berbakat, bahkan di departemen tetangga, tetapi pada akhirnya kami memiliki satu tim besar, sebuah keluarga, jika Anda mau. Semakin banyak orang di departemen berikutnya, semakin sedikit mereka akan membuang tugas mereka untuk kita =)
Cyril - saya pikir - ini adalah kesempatan yang baik untuk meningkatkan keterampilan saya dengan kemampuan bersosialisasi dan berbicara di depan umum yang sama. Kita semua tahu bahwa topik ini mengerikan bagi banyak pengembang, jadi saya mengatasi ketakutan saya.
Akibatnya, saya merekrut dua siswa, mereka bekerja dengan baik.
Mengapa Anda menjadi seorang mentor?
Dmitry - Saya suka berkembang di berbagai arah, dan itu adalah kesempatan yang bagus untuk membuktikan diri dalam segala hal. Pada masa muda yang penuh kekerasan, pemikiran menyelinap ke pedagogis, tetapi tidak berhasil, meskipun pengalaman tertentu tetap ada.
Philip - Tidak ada yang terjadi tanpa hasil. Misalnya, orang-orang datang ke Akademi bukan hanya seperti itu, tetapi, misalnya, untuk mengambil tempat di tim nanti. Dan peran mentoring, antara lain, adalah memilih orang yang valid dalam tim.
Apa yang kurang pada siswa modern?
Dmitry - Banyak pria berbakat datang yang berpikir dengan baik, tapi, sayangnya, lambat. Mereka belum memiliki pengalaman praktis, otak mereka belum dibangun kembali untuk pemrograman. Mereka tidak dapat dengan cepat menemukan solusi, mereka harus duduk dengan tenang dan berpikir dalam suasana yang nyaman. Ini bukan masalah ketika Anda memecahkan beberapa masalah akademik di rumah, tetapi ketika mereka bergabung ke dalam proses kerja, orang-orang semacam itu mungkin tidak tertarik.
Cyril - Jika Anda menetapkan topik besar, maka kesenjangan utama dalam pengetahuan setelah universitas adalah pemrograman multithreaded. Mungkin area yang paling berbahaya, dilihat dari analisis tugas pengujian kami.
Tapi, saya pikir, ini adalah konsekuensi dari kurangnya latihan. Ada cukup teori di sekitar, tetapi di universitas, sebagai aturan, mereka memberikannya sangat sepihak. Misalnya, dalam C # mereka mengambil tugas, panggilan async, dan menguraikannya. Mekanisme ini nyaman, tetapi tidak memungkinkan Anda untuk melihat di bawah tenda. Murid itu sendiri harus pergi dan mulai mengerti, tetapi hampir tidak ada yang tahu. Keingintahuan adalah hal yang baik, tetapi seringkali tidak cukup waktu untuk itu.
Apa yang menarik dari ulasan kode siswa?
Artyom - Pada prinsipnya, menarik dalam dirinya sendiri untuk melihat kode orang lain. Kami tidak menggunakan banyak inovasi dalam alur kerja, jadi saya bahkan belajar sesuatu yang menarik untuk diri saya sendiri mengenai teknologi yang relatif baru.
Siswa menulis pada ketujuh ketujuh, di studio ketujuh belas, masing-masing, ada beberapa momen yang belum saya temui dalam latihan. Misalnya async / tunggu.
Peninjauan kode, katakanlah, praktik penulisan kode yang baik. Ketika Anda menulisnya sendiri, Anda tanpa sadar berpikir: "Ya, Anda bisa mendapatkannya, ini lebih baik, lebih buruk, maka saya akan mengulanginya, dll." Dan ketika Anda melihat kode orang lain, Anda tidak memiliki batasan bahwa Anda perlu memperbaiki 10 bug sebelum makan siang. Dan Anda dapat dengan tenang menyelidiki di mana itu buruk, di mana Anda dapat melakukan lebih baik, dan ke mana harus benar-benar mengulanginya. Ini membantu untuk melihat proses penulisan kode dari luar, dan di masa depan akan lebih mudah untuk menyelesaikan masalah seperti cara membuat skema panggilan, tanggung jawab kelas, dll.
Apa yang Anda harapkan dari seorang siswa untuk wawancara?
Dmitry - Saya ingin melihat pendekatannya. Orang-orang datang, mereka mengatakan bahwa mereka membaca, misalnya, Richter. Saya tidak membaca Richter, tetapi ketika Anda mulai berbicara dengan mereka, menjadi jelas bahwa mereka menemukan jawaban di sana untuk pertanyaan mereka sendiri dan hanya itu - yaitu: mereka tidak membacanya [dengan serius]. Mereka membuka-buka buku, tetapi mereka tidak tertarik dengan apa yang ditulisnya, tidak tertarik pada bagaimana Net Framework diatur di dalamnya. Ini adalah pendekatan yang valid jika Anda seorang spesialis mapan. Tetapi jika Anda melihat C # di tahun pertama Anda dan mulai menghapus beberapa detail implementasi, bagaimana semuanya diatur di bawah tenda, ini adalah jaminan bahwa Anda akan mulai melangkah menyapu. Dan jika pada saat ini Anda masuk ke proyek tim, itu pasti akan mempengaruhi hasil Anda. Semua orang akan memarahi Anda, motivasi Anda akan turun dan pertanyaan akan muncul tentang pekerjaan lebih lanjut.
Ada aspek lain dari memiliki waktu luang. Sekalipun mata [siswanya] menyala, tetapi dia akan menghabiskan dua jam dalam perjalanan ke Akademi, ditambah pekerjaan paruh waktunya, ditambah masalah kehidupan dan kucing kelaparan di rumah, menjadi jelas bahwa dia tidak punya waktu luang dan dia hanya akan terbakar seperti korek api untuk tiga bulan belajar.
Apakah sulit untuk mengajarkan cara menulis kode "dengan benar dan sesuai kebutuhan"?
Philip - Anda tidak bisa mengatakan "Anda melakukannya dengan benar - atau salah." Tidak ada hal seperti itu. Anda membuat kode yang didukung atau Anda membuat kode yang tidak didukung. Misalkan Anda memiliki tugas untuk menyusun proyek dalam 5 jam pada hackathon. Dan, tentu saja, Anda tidak akan berpikir tentang keindahan arsitektur dan keindahan kode. "Anda mengacaukan" untuk bekerja - dan memang demikian. Di sisi lain, jika Anda bekerja di perusahaan [perusahaan besar - red.], Maka Anda telah memberikan waktu untuk tugas dan persyaratan tertentu untuk kode tersebut, dan inilah yang kami perjuangkan dan apa yang kami cari.
Alexander - Ada dua situasi. Jika seseorang telah melakukan hal serupa di perusahaan makanan lain, maka ia akan menuangkannya dengan relatif mudah. Pasar menstandarkan proses.
Hal lain adalah ketika Anda sudah memiliki pengalaman, tetapi Anda melakukan beberapa hal lainnya. Ini menimbulkan pertanyaan, "Bagaimana Anda ingin berkembang lebih jauh?" Jika tujuan Anda adalah bekerja di perusahaan besar, pindah ke negara lain, maka Anda harus mengalami masa-masa kehancuran. Ini seperti mobil pribadi setelah angkutan umum (atau sebaliknya): pada awalnya terasa menyakitkan dan sedih, tetapi kemudian menjadi sangat nyaman dan nyaman.
Dmitry - Faktanya, jika seseorang memiliki tingkat keterampilan minimum, dia tidak harus “mematahkannya”. Tetapi ketika programmer berpengalaman datang, mereka sudah memiliki set praktik mereka sendiri, gaya kode mereka sendiri, yang dapat menyimpang dari kita - dan percakapan dimulai “Mengapa Anda melarang saya untuk menggunakan vars? Saya memiliki kode yang begitu bagus, tidak ada satu tipe pun yang terlihat, dan semuanya sebagaimana mestinya dalam pemrograman fungsional. ” Tetapi dengan orang-orang seperti itu lebih sulit.
Dan jika ini adalah seorang siswa, bahkan tahun lalu, dengan selusin proyek di github, ia sama sekali tidak punya waktu untuk memperoleh praktik-praktik jahat. Ya, bekerja dengan orang yang benar-benar "murni" adalah suatu kesenangan.
Siswa dapat dengan senang hati terkejut?
Artyom - Katakan saja, kadang-kadang ada situasi yang Anda membuka kode, dan ada konstruksi di mana-mana yang belum pernah Anda lihat sebelumnya. Saya harus duduk bersama mereka, dan mencari tahu cara menggunakannya dengan benar. Kebetulan saya sendiri tidak mengerti dengan benar untuk pertama kalinya.
Apakah Veeam Academy bermanfaat bagi Anda secara pribadi?
Dmitry - Ya, tentu saja. Seperti biasa - ketika Anda memberi tahu seseorang bagaimana melakukannya, pertama-tama, Anda mengerti bagaimana melakukannya. Kedua, Anda mensistematisasikan pengetahuan Anda sendiri dan bahkan dalam proses ceramah Anda menemukan jawaban untuk diri Anda sendiri untuk beberapa pertanyaan yang telah lama menyiksa Anda. Jadi, berbagi pengetahuan Anda dengan orang lain adalah cara yang bagus untuk mengembangkan diri.
Alexander - Pertama-tama, menjadi jelas apa yang diharapkan orang, termasuk dari tempat kerja di masa depan. Ketika Anda, sebagai seorang pemimpin, sedang dalam proses, Anda lebih baik memasak dalam pengembangan bisnis. Dan di mana situasinya lebih informal, seperti di akademi, menjadi jelas apa yang menggerakkan orang, apa yang mereka inginkan dan apa minat mereka.
Anda belajar, termasuk banyak, tentang diri Anda sendiri, dan ini adalah hal yang paling penting.
Misalnya, Anda memahami bahwa banyak hal perlu disederhanakan. Ketika Anda bekerja di satu area untuk waktu yang lama, mata menjadi kabur, dan hal-hal yang jelas bagi Anda menjadi benar-benar tidak dapat dipahami oleh orang lain, terutama pemula.
Philip - Ketika Anda terus-menerus memasak di tengah-tengah pengembang tingkat tertentu, Anda mulai berbicara dalam beberapa jenis bahasa yang hanya dapat dimengerti oleh Anda. Dan ketika seseorang tiba yang baru saja memasuki lingkungan ini, Anda mulai menjelaskan semuanya dengan kata-kata yang lebih sederhana, Anda belajar menyampaikan informasi dengan cara yang lebih terstruktur.
Bekerja dengan siswa, Anda juga belajar kesabaran, semacam kasih sayang dan pengertian =) Tapi kemudian Anda mulai melihat beberapa hal yang dia sendiri tahu, tetapi lupa. Anda harus mempelajari lebih dalam tentang teknologi agar dapat menyampaikan dengan lebih baik makna apa yang sedang terjadi kepada orang tersebut. Alih-alih, makna mengapa lebih baik melakukan seperti ini, tetapi lebih baik tidak melakukan seperti itu.
Pengembangan usaha selalu tentang warisan?
Cyril - Pernyataan yang sepenuhnya benar. Ketika sebuah proyek telah ditulis selama 10 tahun dan terus berkembang, persentase tertentu dari kode warisan akan ada di dalamnya.
Pertanyaan lain adalah bagaimana perusahaan yang berbeda dapat mendekati ini.
Saat modul bekerja, kami mencoba untuk tidak masuk ke dalamnya. Itu debugged 5 tahun yang lalu dan lebih dari satu rilis telah bekerja dengan mantap. Pertanyaan lain adalah ketika Anda mendapatkan kode di mana Anda terus-menerus perlu mengubah sesuatu. Dalam hal ini, tidak dilarang bagi kita untuk memperbaikinya secara bertahap: refactoring, dll. 10 tahun yang lalu ada standar bahasa yang berbeda, konstruksi leksikal lainnya. Tidak ada yang mau mengambil, refactor dan transfer ke desain baru.
Kode secara bertahap meremajakan, tetapi semua ada di tangan pengembang. Anda dapat memalu baut, memecahkan masalah saat ini, dan mungkin ini akan cukup bagi perusahaan, karena tujuan akhir dalam bentuk produk yang bekerja akan tercapai. Nah, apa yang ada di dalamnya ... Ada banyak cerita di Internet, terutama tentang fajar gamedev, ketika hanya kelas yang muncul di C ++ ... Anda membuka kode - ada kelas, ada banyak yang termasuk di dalamnya. Jelas bahwa sekarang mereka akan menyebutnya kata yang sangat spesifik.
Tetapi secara umum, dengan kode lama Anda harus dapat hidup. Tidak perlu takut padanya.
Dmitry - Kode lama, tentu saja, ada dan, tentu saja, Anda harus tetap hidup dengannya. Tetapi Anda tidak hidup dengan dia putus asa, tetapi karena tidak masuk akal untuk menyentuhnya. Paling sering, kode lama adalah beberapa komponen yang sudah didebug, bahkan jika ditulis pada beberapa jenis .Net 2.0. Mereka berfungsi selama bertahun-tahun, tidak ada fungsi baru yang perlu ditambahkan ke dalamnya - dan mengapa menyentuh mereka jika mereka bekerja dan bekerja dengan baik ?
Ada situasi ketika Anda melihat bug di kode lama yang telah melewati beberapa rilis, tetapi tiba-tiba dipecat. Saat itulah Anda mulai menulis ulang kode lama, mungkin tutup dengan unit test agar tidak merusak apa pun. Atau Anda hanya mempercayai penguji tanpa henti. Yaitu Anda hanya mengambil waktu yang baik, tentu saja, bukan untuk rilis - tetapi semua jenis beta hanya untuk ini dan diciptakan.
Sedangkan untuk Akademi, proyek ini juga memungkinkan kita untuk mengikuti perkembangan zaman. Cowok baru datang, mereka aktif mengikuti berita dunia C #, .Net, dll. Mereka menyukai beberapa konstruksi baru, "gula sintaksis" dari versi terbaru. Dan, pada kenyataannya, melalui pemimpin tim mereka, mereka memaksa [mempromosikan] desain ini ke dalam proyek. Ya, itu dapat menyebabkan penolakan, orang mungkin tidak langsung menerimanya, tetapi itu semua bersifat sementara dan jika fitur yang sangat berguna masuk dalam kerangka kerja baru, itu akan masuk ke dalam proses.
Philip - saya harus berurusan dengan apa yang ditulis 10 tahun lalu. Anda tidak akan mendapatkan apa-apa dari ini. Secara alami, kami berupaya memperbarui tumpukan kami, tetapi kami memiliki 180 proyek dalam pengembangan, beberapa juta baris kode telah ditulis selama ini, dan sangat sulit untuk melompati tumpukan itu. Kita harus mengerti dan menerima hal ini.
Alexander - Saya pernah membaca presentasi oleh Mercedes Benz tentang mengapa mereka begitu konservatif dan memperkenalkan teknologi dengan jeda waktu tertentu. Jawabannya sederhana: segala sesuatu yang tidak menguntungkan klien masuk “dalam ember”. Pengembangan usaha mengikuti prinsip yang sama. "Korban" pertama dari teknologi baru harus analis, pengembang, laboratorium pengujian, atau siapa pun, tetapi bukan klien. Teknologi apa pun sebelum muncul di dalam produk harus dijalankan. Dari luar, itu tampak seperti warisan, tetapi dari dalam tidak. Hanya saja semuanya modern yang pertama-tama harus kita uji "pada kucing" dan baru kemudian diterapkan dalam kehidupan.
Artyom - Ya dan tidak. Produk kami berumur 10 tahun, jadi kami memiliki banyak warisan, tetapi ini tidak berarti bahwa kami membabi buta menyeret komponen lama dan tidak melakukan apa pun dengan mereka. Kebetulan kami menulis ulang sepenuhnya.
Lalu bagaimana pengenalan fitur-fitur baru?
Alexander - Pertama-tama, jelaskan masalah apa yang sedang Anda pecahkan. Jika Anda membawa proyek bajak bulan - ini memang bagus, tetapi jelaskan mengapa itu diperlukan. Jika Anda dapat menjelaskan mengapa itu akan bermanfaat bagi kami, maka, tentu saja, kami akan menerapkannya.
Cyril - Pertama, Anda perlu mencari tahu apa itu - karena itu dapat memiliki konsekuensi. Jika kami memperkenalkan beberapa perpustakaan baru, maka tidak hanya pengembang yang terlibat di sini. Departemen pengujian disertakan, yang perlu menguji ulang semua logika yang bergantung pada kode kerja lama, dan sekarang kami telah mengubah segalanya.
Oleh karena itu, pengenalan sesuatu yang baru dalam pengembangan produksi sering dikaitkan dengan biaya overhead yang besar. Dan jika keuntungan dari implementasi melebihi biaya ini, maka, sebagai suatu peraturan, keputusan tentang implementasi dibuat. Dan jika sebaliknya, lalu mengapa? Tidak perlu menembak diri sendiri.
Bagaimana dengan semangat Jones dan keinginan mereka untuk memperbaiki segalanya?
Dmitry - Mereka masih belum menyelesaikan tugas yang serius dan rumit karena kurangnya kompetensi. Usia muda (dalam hal pengembang) adalah peluang besar untuk membuat Anda sendiri terbentur, terutama jika Anda tidak percaya pada kawan yang lebih tua. Jika harga pertanyaannya adalah dua hari, di mana ia akan memahami bahwa idenya yang "cerdik" tidak akan lepas landas, dan ia tidak akan lagi berurusan dengan sampah ini, maka lebih baik memberinya kesempatan untuk menginjak menyapu ini secara pribadi. Jauh lebih buruk untuk melarangnya melakukan ini, dan selama berbulan-bulan dia akan berpikir bahwa "pemimpin tim jahat melarang saya untuk memotong hal yang keren."
Cyril - Segala sesuatu yang diberikan di Akademi memungkinkan siswa, pertama, untuk melihat tumpukan teknologi modern. Kedua, segala yang kami berikan, kami coba gunakan semaksimal mungkin.
Produk kami tidak muda, tetapi ketika fitur baru ditulis, itu dibuat dari awal, dan penggunaan teknologi baru membawa risiko lebih sedikit. Jadi biarkan mereka menggunakannya.
Artyom - Fitur baru bagus untuk diterapkan di area baru. Proyek kami tidak terlalu monolitik sehingga hanya memecahkan satu masalah, dan hanya itu. Ini memiliki banyak fungsi, dan selalu ada tempat untuk menerapkan yang baru.
Ketika orang baru tiba, mereka diberi tugas pendidikan pertama, kemudian yang kecil. Bagaimanapun, pertama-tama ia harus berkenalan dengan proyek, karena itu sangat besar. Sepertinya sudah lebih dari sejuta baris kode, tetapi saya bisa berbohong. Bagaimanapun, untuk melihat dalam seminggu, dan bahkan dalam sebulan dia tidak akan berhasil. Tetapi ketika dia mulai mengerti, kita bisa memberikan eksperimen, mengapa tidak.
Bagaimana menjadi seorang junior dengan warisan?
Philip - Pertama, Anda tidak bisa mengatakan bahwa semua ini sudah ketinggalan zaman. Ada segala macam "know-how" langsung, ok, kami bekerja sebagian besar tanpa mereka. Tetapi bagaimanapun, seseorang akan belajar pendekatan yang tepat untuk organisasi kode dan desain dari kami. Ini tidak ke mana-mana.
Kami juga akan mengajarkan cara bekerja dengan warisan. Ini juga keterampilan yang sangat penting. Anda tidak dapat berpikir bahwa Anda akan datang dan mulai merancang sistem terbaik di dunia. Tidak. Paling sering, datang ke perusahaan, Anda menemukan diri Anda pada produk jadi. [ — .], [ — .].
— . backlog [ , — .], , . , - , , - .
-, . , , , .
, , ?
— Enterprise- , . , , , . , “ ”, “”. , enterprise[-]. , , , , . , Veeam 5 , SMB [small & medium businesses — .] Enterprise. enterprise[-], , , . , , .
. , enterprise. : , enterprise “”, . , , . , enterprise, . : - 5 ( ) , , , . , .
. , . , . , , .
— . , , - , , .
[.. — .] . , .
? , , . , , — . : , . .
, 2-3 . , . , Veeam, , - , - . — .. , , .
— , . , . , enterprise- , .
, , , . , Amazon , Facebook , , .
, enterprise. , .
— “, , ” , . . , . , , - , , , . , .
, , . , , .. , . . , , .
enterprise?
— , . , , , “ ”, .
— . - - . - , “”. . 8 , , . , .
— , enterprise. , , , . , , ..
— , — . , , .
?
— , . , . - , , .
, . — , . , , , . , . -, , , “” [ — .]. , , . .
?
— , . .
— , , .
— . -, . 15 - , , , [Microsoft Visual Studio — .], , - .
— , .
— , , . , , , . , , , .
, , , .