Pengaturcaraan Extreme - atau, ringkasnya, XP (Pengaturcaraan eXtreme) - ialah tindak balas komuniti pengaturcaraan terhadap serangan pendekatan formal untuk mencipta produk perisian dan direka untuk mengembalikan semangat kreativiti kepada persekitaran pembangun.

Mana-mana idea yang dibawa ke tahap yang tidak masuk akal akan merosot menjadi sebaliknya. Ini betul-betul keadaan dalam industri perisian Amerika Utara dengan alat pembangunan RAD. Pada satu ketika, alatan yang direka untuk pembangunan aplikasi pantas mula menyesakkan segala-galanya dalam fikiran pengurus, termasuk pembangun, pelanggan dan projek itu sendiri. Perhatian yang tidak wajar dan hipertropi kepada Proses sehingga menjejaskan faktor pembangunan lain menimbulkan banyak prosedur formal - tetapi kualiti produk yang dihasilkan dan bilangan projek yang berjaya ternyata mengecewakan.

Inisiatif sekumpulan pembangun yang bersatu di bawah slogan Extreme Programming, atau XP, direka untuk menentang tekanan formalisme dalam kerja pengaturcara.

Pengaturcaraan Extreme adalah berdasarkan beberapa prinsip yang sangat khusus, sering dinyatakan secara berangka yang mentakrifkan perkara yang perlu dilakukan, bila dan bagaimana ia harus dilakukan. Tanpa mengambil nombor ini sebagai dogma, seseorang mesti, walau bagaimanapun, ingat bahawa ia muncul sebagai hasil daripada analisis banyak projek yang berjaya dan tidak berjaya, jadi sekurang-kurangnya, mesti ada sebab yang kukuh untuk membuat pindaan.

Pengaturcaraan Extreme tidak berdasarkan teknik khusus, seperti yang lazimnya dipercayai, tetapi hanya pada empat prinsip asas: komunikasi, kesederhanaan, maklum balas dan keberanian. Di sinilah anda perlu bermula.

Pengaturcaraan Extreme menawarkan penyelesaian sedia: pastikan segala-galanya semudah mungkin, simpan pelanggan untuk diri sendiri atau tinggal bersama pelanggan, biarkan dia memantau secara aktif proses pembangunan, mengalu-alukan perubahan - dan kejayaan hampir terjamin.

Dalam pasukan XP, komunikasi sentiasa digalakkan - cara terpantas untuk berkongsi maklumat dan pengalaman. Ini sangat penting apabila kelajuan pembangunan maksimum diperlukan. Tetapi komunikasi, seperti mana-mana usaha berguna lain, memerlukan sokongan berterusan. Itulah sebabnya seseorang dari pasukan mesti bertanggungjawab untuk memantau komunikasi, menjadi diplomat yang dipanggil. Komunikasi dan keperluan untuk menerangkan tindakan anda kepada ahli pasukan lain memaksa anda melakukan segala-galanya semudah mungkin. Jika ia tidak berjaya pada kali pertama, mereka akan berusaha untuk memudahkan lagi dan lagi sehingga matlamat utama dicapai - kefahaman maksimum kod untuk pembangun lain.

Kitaran Melampau

Pengaturcaraan Extreme adalah berdasarkan kitaran pembangunan berulang yang sangat singkat selama satu hingga tiga minggu. Menjelang akhir setiap kitaran, perlu ada keluaran aplikasi yang berfungsi, berfungsi dan diuji sepenuhnya. Kitaran ini mesti berulang dan tidak terganggu sepanjang projek.

Prasyarat untuk mod operasi ini adalah fakta yang berulang kali terbukti bahawa keperluan jarang lengkap, tepat pada masanya dan betul. Dalam erti kata lain, tidak kira seberapa baik sesuatu aplikasi dirancang, ia 100% perlu direka bentuk semula. Lebih-lebih lagi, ia mungkin perlu dibuat semula walaupun pada peringkat akhir. Pengubahsuaian tidak boleh ditunda sehingga akhir kerja; ia mesti dilakukan secara berkala.

Akibat keperluan yang sentiasa berubah-ubah, prinsip lain mengikuti - membuat keputusan lewat.

Ini mungkin kedengaran pelik, tetapi kira-kira 75% perisian tidak menjangkau orang ramai sama sekali. Sebaliknya, terdapat banyak syarikat yang menghasilkan perisian dalam kuantiti yang banyak. Semua ini dan banyak lagi mewajibkan pengaturcara mengurangkan kos pembangunan. Dan untuk melakukan ini, anda perlu memahami kepentingan pelanggan, sentiasa bekerjasama dengannya, untuk akhirnya mencipta apa yang dia perlukan.

Metodologi Pembangunan Perisian Pengaturcaraan eXtreme(pencipta - Kent Beck) semakin diiktiraf kerana memaksimumkan penyederhanaan reka bentuk dan pembangunan sebenar produk perisian dalam persekitaran dengan keperluan yang berubah dengan pantas.

Terdapat hanya 5 nilai Pengaturcaraan Extreme: kesederhanaan, komunikasi, maklum balas, keberanian dan rasa hormat ("hormat" telah ditambah dalam edisi terbaru XP). Amalan 12 XP bertujuan untuk merealisasikan nilai teras ini. Mari lihat mereka dengan lebih dekat. Sebagai tambahan kepada kebenaran yang diketahui ramai, saya akan menambah ulasan saya tentang amalan, berdasarkan pengalaman praktikal saya.

Proses perancangan (permainan perancangan). Dalam XP, perancangan adalah bahagian teras pembangunan. Hakikat bahawa rancangan boleh berubah secara tiba-tiba diambil kira pada awalnya. Selera makan pelanggan datang semasa makan dan keadaan mesti sentiasa dikawal. Komunikasi dengan pelanggan harus dilakukan sekerap mungkin. Ini akan membolehkan anda menganggarkan tarikh akhir untuk menyelesaikan tugasan dengan lebih tepat dan membuat pelarasan yang diperlukan jika perlu.

Keluaran versi cepat (keluaran kecil). Tidak kira betapa indahnya produk itu diterangkan, semua keseronokan penggunaannya hanya dapat difahami dengan bekerja dengannya. Metodologi keluaran pantas membolehkan anda memahami perkara yang pelanggan inginkan, memastikan keluaran awal versi produk yang berfungsi.

Ulasan: Seperti yang ditunjukkan oleh amalan, versi awal pertama boleh disiapkan dalam 2-8 minggu, tanpa mengira kerumitan produk yang dijangkakan. Adalah dinasihatkan bahawa versi pertama produk (sekurang-kurangnya beberapa lelaran pertama) dibuat oleh 2 orang pada satu komputer. Dalam kes ini, reka bentuk sistem muncul dengan cepat. Kemudian anda boleh menarik lebih ramai orang dengan mengagihkan semula pasangan.

Metafora. Adalah lebih mudah bagi seseorang untuk mengingati perbezaan antara dua objek yang serupa daripada mengetahui keseluruhan struktur objek tersebut. Teknik metafora mencadangkan membandingkan sistem (atau salah satu modulnya) dengan analognya untuk memudahkan komunikasi dalam pasukan dan pemahaman yang lebih mendalam tentang sistem secara keseluruhan.

Komen: Amalan yang agak rumit, walaupun pada pandangan pertama nampak mudah. Menghasilkan metafora untuk modul utama sistem bukanlah mudah, tetapi ia sangat berguna. Ramai pengaturcara mengaitkan "metafora sistem" kepada amalan pengurusan, tetapi saya nampaknya pembangun lebih memerlukannya. Pilihan metafora yang tepat akhirnya akan membantu pengaturcara menghasilkan nama yang baik untuk kelas dan kaedah, yang sentiasa memberi kesan positif pada reka bentuk sistem secara keseluruhan.

Kemudahan pelaksanaan (reka bentuk ringkas). XP menggalakkan memastikan kod program mudah. Mengapa merumitkan hidup anda apabila program ringkas lebih mudah difahami, diselenggara dan kurang terdedah kepada ralat.

Pembangunan berasaskan ujian. Pengaturcaraan Extreme mengesyorkan menguji kod sedia ada sekerap mungkin. Sebab itulah teknik ini diamalkan. Ujian ditulis sebelum sekeping kod ditulis. Ini membolehkan anda memahami dengan lebih baik tugasan yang ada dan memberi peluang untuk menyemak kod sebaik sahaja ia ditulis.

Ulasan: Pendekatan ini mempunyai banyak kelebihan.

Pertama, menulis ujian sebelum menulis kod ialah salah satu cara terbaik untuk memastikan bahawa ujian tersebut disediakan.

Kedua, ia menghapuskan keengganan untuk menguji beberapa cabang "jelas" pelaksanaan program, jika hanya kerana tiada kod lagi :). Oleh itu, dengan pengaturcaraan pasangan, ujian sememangnya akan ringkas dan berkualiti tinggi.

Ketiga, ujian meningkatkan keyakinan diri pengaturcara apabila mereka ingin memfaktorkan semula.

Pemfaktoran semula (penambahbaikan reka bentuk). Menambah fungsi baharu dan meningkatkan jumlah kod merumitkan pembangunan dan penyelesaian masalah. Penyelesaian kepada masalah ini ialah pemfaktoran semula kod yang berterusan. Pemfaktoran semula adalah perkara yang sangat berkuasa dan berguna dan bukan sahaja layak untuk artikel berasingan, tetapi keseluruhan buku.

Ulasan: Jangan lupa nilai "keberanian" dan jangan takut untuk memecahkan sistem semasa pemfaktoran semula. Ujian akan menunjukkan apa yang rosak dan anda akan membetulkan ralat dengan cepat. Walaupun ujian tidak merangkumi beberapa aspek, dan anda tidak melihat sebarang masalah yang berpotensi, tidak mengapa, semuanya sentiasa boleh diperbaiki. Perkara utama ialah reka bentuk sistem telah menjadi lebih mudah dan jelas, dan sistem yang kompleks adalah sumber ralat yang lebih dahsyat daripada ralat yang terhasil daripada pemfaktoran semula.

Pengaturcaraan pasangan. Menyemak kod orang lain secara berkala mempunyai kesan positif pada kualitinya. Prinsip ini mendasari pengaturcaraan pasangan. Ia terdiri daripada fakta bahawa dua pengaturcara serentak bekerja pada satu komputer. Anehnya, kos pembangunan tidak meningkat dua kali ganda, tetapi kekal pada tahap yang sama. Sebaliknya, dengan pengaturcaraan pasangan, kualiti kod meningkat, pemindahan pengetahuan tersirat dan eksplisit berlaku, dan komunikasi berterusan antara pembangun berlaku.

Pemilikan kod kolektif. Selalunya, apabila membangunkan produk perisian, seseorang bertanggungjawab untuk bahagian tertentu kod. Percutian, pemecatan, atau sakit (maafkan saya, Tuhan) salah seorang pengaturcara boleh sangat melambatkan pembangunan produk. Itulah sebabnya dalam XP sekurang-kurangnya dua orang bertanggungjawab untuk satu keping kod dan mana-mana pengaturcara boleh membuat perubahan pada mana-mana sebahagian daripada kod program.

Integrasi berterusan. Pasukan pengaturcaraan XP mencipta binaan produk baharu beberapa kali sehari. Ini membolehkan semua pengaturcara menyedari perkara yang berlaku dan menghalang masalah penyepaduan dengan produk dan bahagian kod lain.

Komen: Pada masa kini, amalan ini menyebabkan senyuman atau salah faham di kalangan profesional muda, kerana terdapat svn, perforce, cvs dan banyak lagi. Sebelum ini, dua lelaki duduk berhampiran komputer utama dan secara manual bergabung dengan cawangan utama projek itu.

Namun begitu, amalan ini masih relevan. Tiada siapa yang telah membatalkan pemilikan bersama kod: jika anda tidak mahu membuang masa pada gabungan yang besar dan kompleks, luangkan masa untuk beberapa kod kecil :).

40 jam seminggu (empat puluh jam seminggu). Orang ramai mampu melakukan banyak perkara untuk tujuan tertentu, tetapi pengaturcaraan yang melampau secara mutlak bertentangan dengan pengorbanan diri pembangun. Seseorang mesti berehat, iaitu apabila dia akan mencapai produktiviti maksimum pada waktu bekerja.

Teknik Asas XP

Dua belas teknik asas pengaturcaraan melampau (berdasarkan edisi pertama buku Pengaturcaraan melampau dijelaskan) boleh digabungkan menjadi empat kumpulan:

• Maklum balas skala halus
  • Pembangunan berasaskan ujian
  • Permainan perancangan
  • Pelanggan sentiasa berdekatan (Seluruh pasukan, pelanggan Di Tapak)
  • Pengaturcaraan pasangan
• Berterusan daripada proses batch
  • Integrasi berterusan
  • Pemfaktoran Semula (Penambahbaikan Reka Bentuk, Pemfaktoran Semula)
  • Keluaran Kecil yang kerap
• Kefahaman dikongsi oleh semua
  • Kesederhanaan (Reka bentuk ringkas)
  • Metafora sistem
  • Pemilikan kod kolektif atau corak reka bentuk terpilih (Pemilikan corak kolektif)
  • Standard pengekodan atau Konvensyen Pengekodan
• Kebajikan pengaturcara:
  • 40 jam seminggu bekerja (Kelajuan yang mampan, Empat puluh jam seminggu)

Menguji

XP memberi penekanan khusus pada dua jenis ujian:

• ujian unit;
• ujian penerimaan.

Seorang pembangun tidak dapat memastikan ketepatan kod yang ditulisnya sehingga semua ujian modul sistem yang sedang dibangunkannya berjaya. Ujian unit membolehkan pembangun mengesahkan bahawa kod mereka berfungsi dengan betul. Mereka juga membantu pembangun lain memahami mengapa sekeping kod tertentu diperlukan dan cara ia berfungsi. Ujian unit juga membolehkan pembangun membuat pemfaktoran semula tanpa sebarang kebimbangan.

Ujian penerimaan memastikan bahawa sistem sebenarnya mempunyai keupayaan yang dinyatakan. Selain itu, ujian penerimaan membolehkan anda mengesahkan fungsi produk yang sedang dibangunkan dengan betul.

Untuk XP, keutamaan yang lebih tinggi ialah pendekatan yang dipanggil TDD (Test Driven Development) - pertama ujian ditulis yang tidak lulus, kemudian kod ditulis supaya ujian itu lulus, dan hanya kemudian kod itu difaktorkan semula.

Permainan perancangan

Matlamat utama permainan perancangan adalah untuk merumuskan pelan kerja kasar dengan cepat dan sentiasa mengemas kininya apabila keadaan tugas menjadi lebih jelas. Artifak permainan perancangan ialah satu set kad kertas di mana keinginan pelanggan ditulis (cerita pelanggan), dan rancangan kerja kasar untuk mengeluarkan satu atau lebih versi kecil produk yang seterusnya. Faktor kritikal yang menjadikan gaya perancangan ini berkesan ialah dalam kes ini, pelanggan bertanggungjawab untuk membuat keputusan perniagaan, dan pasukan pembangunan bertanggungjawab untuk membuat keputusan teknikal. Jika peraturan ini tidak dipatuhi, keseluruhan proses akan rosak.

Pelanggan sentiasa ada

"Pelanggan" dalam XP bukanlah orang yang membayar bil, tetapi pengguna akhir produk perisian. XP menyatakan bahawa pelanggan mesti berhubung pada setiap masa dan tersedia untuk pertanyaan.

Pengaturcaraan pasangan

Pengaturcaraan pasangan menganggap bahawa semua kod dicipta oleh pasangan pengaturcara yang bekerja pada komputer yang sama. Salah seorang daripada mereka berfungsi secara langsung dengan teks program, yang lain melihat kerjanya dan memantau gambaran keseluruhan tentang apa yang berlaku. Jika perlu, papan kekunci dipindahkan secara bebas dari satu ke yang lain. Semasa menjalankan projek, pasangan tidak tetap: adalah disyorkan untuk mencampurkannya supaya setiap pengaturcara dalam pasukan mempunyai pemahaman yang baik tentang keseluruhan sistem. Dengan cara ini, pengaturcaraan pasangan meningkatkan kerjasama dalam pasukan.

Integrasi berterusan

Jika anda mengintegrasikan sistem yang anda sedang bangunkan dengan cukup kerap, anda boleh mengelakkan kebanyakan masalah yang berkaitan dengannya. Dalam kaedah tradisional, penyepaduan biasanya dilakukan pada penghujung kerja pada produk, apabila dianggap bahawa semua komponen sistem yang dibangunkan telah siap sepenuhnya. Dalam XP, penyepaduan kod keseluruhan sistem dilakukan beberapa kali sehari, selepas pembangun yakin bahawa semua ujian unit berfungsi dengan betul.

Pemfaktoran semula

Pemfaktoran semula ialah teknik untuk menambah baik kod tanpa mengubah fungsinya. XP bermaksud bahawa sebaik sahaja kod ditulis, ia hampir pasti akan ditulis semula beberapa kali semasa projek dijalankan. Pembangun XP dengan kejam mengolah semula kod yang ditulis sebelum ini untuk memperbaikinya. Proses ini dipanggil pemfaktoran semula. Kekurangan liputan ujian mencetuskan keengganan untuk memfaktorkan semula kerana ketakutan untuk memecahkan sistem, yang membawa kepada kemerosotan kod secara beransur-ansur.

Keluaran kecil yang kerap

Versi (keluaran) produk harus dikeluarkan ke dalam perkhidmatan sekerap mungkin. Setiap versi perlu mengambil masa sesingkat mungkin untuk disiapkan. Selain itu, setiap versi mestilah cukup bermakna dari segi kegunaan untuk perniagaan.

Lebih cepat kami mengeluarkan versi pertama produk yang berfungsi, lebih cepat pelanggan akan mula menerima keuntungan tambahan daripadanya. Ingatlah bahawa wang yang diperoleh hari ini lebih bernilai daripada wang yang diperoleh esok. Lebih cepat pelanggan mula menggunakan produk, lebih cepat pembangun akan menerima maklumat daripadanya tentang perkara yang memenuhi keperluan pelanggan. Maklumat ini boleh sangat membantu semasa merancang keluaran anda yang seterusnya.

Kesederhanaan reka bentuk

XP berpunca daripada fakta bahawa semasa proses kerja, keadaan masalah boleh berubah berulang kali, yang bermaksud bahawa produk yang dibangunkan tidak seharusnya direka bentuk terlebih dahulu secara keseluruhannya. Jika anda cuba mereka bentuk sistem secara terperinci dari mula hingga akhir apabila anda mula-mula mula, anda membuang masa anda. XP menganggap bahawa reka bentuk adalah satu proses yang penting yang mesti dilakukan secara berterusan sepanjang keseluruhan projek. Reka bentuk mesti dijalankan dalam langkah-langkah kecil, dengan mengambil kira keperluan yang sentiasa berubah. Pada setiap saat kami cuba menggunakan reka bentuk paling ringkas yang sesuai untuk menyelesaikan masalah semasa. Pada masa yang sama, kami mengubahnya apabila keadaan masalah berubah.

Metafora sistem

Seni bina adalah idea tentang komponen sistem dan hubungannya antara satu sama lain. Pembangun perlu menganalisis seni bina perisian untuk memahami di mana dalam sistem fungsi baharu perlu ditambah dan komponen baharu itu akan berinteraksi.

Metafora sistem adalah analog daripada apa yang dipanggil seni bina dalam kebanyakan teknik. Metafora sistem memberi gambaran kepada pasukan tentang cara sistem itu beroperasi pada masa ini, tempat komponen baharu ditambah, dan bentuk yang sepatutnya diambil.

Memilih metafora yang baik memudahkan pasukan pembangunan memahami cara sistem berfungsi. Kadang-kadang ini tidak mudah untuk dilakukan.

Piawaian Pengekodan

Semua ahli pasukan mesti mematuhi piawaian pengekodan biasa semasa bekerja. Oleh itu:

• ahli pasukan tidak membuang masa dengan hujah bodoh tentang perkara yang sebenarnya tidak menjejaskan kelajuan kerja projek;
• pelaksanaan amalan lain yang berkesan dipastikan.

Jika pasukan tidak menggunakan piawaian pengekodan yang konsisten, ia menjadi lebih sukar bagi pembangun untuk memfaktorkan semula; apabila menukar pasangan dalam pasangan, lebih banyak kesukaran timbul; secara amnya, kemajuan projek menjadi sukar. Dalam XP, adalah perlu untuk memastikan bahawa sukar untuk memahami siapa pengarang kod ini atau itu - seluruh pasukan bekerja secara bersatu, seperti satu orang. Pasukan mesti membentuk satu set peraturan, dan kemudian setiap ahli pasukan mesti mematuhi peraturan tersebut semasa proses pengekodan. Senarai peraturan tidak boleh lengkap atau terlalu panjang. Matlamatnya adalah untuk menyediakan garis panduan umum yang menjadikan kod itu boleh difahami oleh semua orang dalam pasukan. Standard pengekodan harus bermula dengan mudah dan kemudian beransur-ansur menjadi lebih kompleks apabila pasukan pembangunan memperoleh pengalaman. Tidak perlu menghabiskan terlalu banyak masa untuk pembangunan awal standard.

Pemilikan kolektif

Pemilikan kolektif bermakna setiap ahli pasukan bertanggungjawab untuk semua kod sumber. Oleh itu, setiap orang mempunyai hak untuk membuat perubahan pada mana-mana bahagian program. Pengaturcaraan pasangan menyokong amalan ini: bekerja dalam pasangan yang berbeza, semua pengaturcara menjadi biasa dengan semua bahagian kod sistem. Kelebihan penting pemilikan kod kongsi ialah ia mempercepatkan proses pembangunan, kerana jika ralat berlaku, mana-mana pengaturcara boleh membetulkannya.

Dengan memberi setiap pengaturcara hak untuk menukar kod, kami menghadapi risiko pepijat yang diperkenalkan oleh pengaturcara yang berpendapat mereka tahu apa yang mereka lakukan tetapi tidak menganggap kebergantungan tertentu. Ujian UNIT yang ditakrifkan dengan baik menyelesaikan masalah ini: jika kebergantungan yang tidak diperiksa menghasilkan ralat, maka ujian UNIT yang seterusnya akan gagal.

kesusasteraan

• Kent Beck: Pengaturcaraan Melampau- Peter, 2002, ISBN 5-94723-032-1.
• Kent Beck, Martin Fowler: Pengaturcaraan Ekstrem: Perancangan- Peter, 2003, ISBN 5-318-00111-4.
• Kent Beck: Pengaturcaraan Ekstrem: Pembangunan Dipacu Ujian- Peter, 2003, ISBN 5-8046-0051-6.
• Ken Auer, Roy Miller: "Pengaturcaraan Melampau: Menetapkan proses dari langkah pertama hingga akhir yang pahit" - Peter, 2003, ISBN 5-318-00132-7.

lihat juga

Pautan

• Ward Cunningham Wiki - "termaju" XP.
• XProgramming.com (Bahasa Inggeris) - Tapak Ron Jeffries: artikel dan sumber tentang XP dan topik berkaitan, ulasan buku.
• Pengaturcaraan Ekstrem: Pengenalan yang lembut (Bahasa Inggeris) - "Pengenalan yang lembut kepada XP" oleh Don Wells.
• MAXKIR.COM (Rusia) - terjemahan artikel oleh bapa pengasas dan ahli ideologi XP
• www.agiledev.ru (Rusia) - Laman web untuk kaedah pembangunan yang fleksibel
• TopCoder (Bahasa Inggeris) - pertandingan pengaturcaraan sukan
• Perpustakaan elektronik buku mengenai pengaturcaraan melampau (Rusia)
• Pengaturcaraan melampau - realiti dan mitos (Rusia)
• Menguji berdasarkan Pengaturcaraan Extreme. Bahagian 1 (Bahasa Rusia)
• IT dan psikologi. Faktor manusia dalam pengaturcaraan berpasangan: mengapa ramai orang tidak mendapat apa yang mereka mahu daripada pelaksanaannya? (Bahasa Rusia)

Pembangunan perisian
Terkenal angka
Proses
Konsep
Arah
model pembangunan
Model lain
Lain-lain

Yayasan Wikimedia. 2010.

Lihat apa "Pengaturcaraan Melampau" dalam kamus lain:

pengaturcaraan yang melampau- Salah satu metodologi pembangunan perisian. Topik: teknologi maklumat secara umum EN pengaturcaraan ekstremXP ... Panduan Penterjemah Teknikal

Artikel ini perlu ditulis semula sepenuhnya. Mungkin terdapat penjelasan pada halaman perbincangan. Istilah ini mempunyai makna lain, lihat Program ... Wikipedia

Pengurusan projek melampau (XPM) ialah kaedah mengurus projek yang sangat kompleks atau tidak pasti. XPM berbeza daripada kaedah pengurusan projek tradisional dalam sifat terbuka, fleksibel dan... ... Wikipedia

Pengaturcaraan Ekstrem: Pembangunan Dipacu Ujian

Didedikasikan untuk Cindy: sayap jiwa saya

Hak penerbitan diperoleh di bawah perjanjian dengan Addison-Wesley Longman. Hak cipta terpelihara. Tiada bahagian buku ini boleh diterbitkan semula dalam apa jua bentuk tanpa kebenaran bertulis daripada pemegang hak cipta.

Maklumat yang terkandung dalam buku ini telah diperolehi daripada sumber yang dianggap boleh dipercayai oleh penerbit. Walau bagaimanapun, dengan mengambil kira kemungkinan kesilapan manusia atau teknikal, penerbit tidak dapat menjamin ketepatan dan kesempurnaan mutlak maklumat yang diberikan dan tidak bertanggungjawab terhadap kemungkinan ralat yang berkaitan dengan penggunaan buku.

ISBN 978-0321146533 Bahasa Inggeris

ISBN 978-5-496-02570-6

© 2003 oleh Pearson Education, Inc.

© Terjemahan ke dalam Russian LLC Publishing House "Piter", 2017

© Edisi dalam bahasa Rusia, direka oleh Peter Publishing House LLC, 2017

© Siri "Perpustakaan Pengaturcara", 2017

Mukadimah

Kod bersih yang berfungsi"kod bersih yang berfungsi," frasa pendek tetapi bermakna ini, dicipta oleh Ron Jeffries, merangkum keseluruhan makna Pembangunan Dipacu Ujian (TDD). Kod bersih yang berfungsi ialah matlamat yang patut diperjuangkan kerana

Ini adalah cara yang boleh diramal untuk membangunkan program. Anda tahu bila kerja boleh dianggap lengkap tanpa perlu risau tentang siri kesilapan yang panjang;

Memberi anda peluang untuk mempelajari pelajaran yang diajar oleh kod tersebut. Jika anda menggunakan idea pertama yang terlintas di fikiran, anda tidak akan mempunyai peluang untuk melaksanakan idea kedua yang lebih baik;

Meningkatkan kehidupan pengguna program anda;

Membenarkan rakan sekerja anda bergantung kepada anda, dan anda bergantung kepada mereka;

Lebih seronok menulis kod seperti ini.

Tetapi bagaimana anda mendapatkan kod bersih yang berfungsi? Banyak kuasa menghalang kami daripada mendapatkan kod bersih, dan kadangkala kami tidak boleh mendapatkan kod yang hanya berfungsi. Untuk menyingkirkan banyak masalah, kami akan membangunkan kod berdasarkan ujian automatik. Gaya pengaturcaraan ini dipanggil pembangunan dipacu ujian. Mengikut teknik ini

Kod baharu ditulis hanya selepas ujian automatik telah ditulis yang gagal;

Sebarang pertindihan dihapuskan.

Dua peraturan mudah, bukan? Walau bagaimanapun, mereka menjana tingkah laku individu dan kumpulan yang kompleks dengan banyak akibat teknikal:

Semasa proses reka bentuk, kami sentiasa menjalankan kod dan mendapat idea tentang cara ia berfungsi, ini membantu kami membuat keputusan yang betul;

Kami menulis ujian kami sendiri kerana kami tidak sabar menunggu orang lain menulis ujian untuk kami;

Persekitaran pembangunan kami perlu bertindak balas dengan cepat kepada pengubahsuaian kod kecil;

Reka bentuk program hendaklah berdasarkan penggunaan banyak komponen serba lengkap dan longgar untuk menjadikan kod lebih mudah untuk diuji.

Dua peraturan TDD yang disebutkan menentukan susunan langkah pengaturcaraan.

1. Merah - Tulis ujian kecil yang tidak berfungsi dan mungkin tidak disusun.

2. Hijau - buat ujian dijalankan secepat mungkin, tanpa perlu risau tentang ketepatan reka bentuk dan kebersihan kod. Tulis kod yang cukup untuk membuat ujian berfungsi.

3. Pemfaktoran semula – hapuskan sebarang pertindihan daripada kod bertulis.

Merah – hijau – pemfaktoran semula adalah mantra TDD.

Jika kita menganggap bahawa gaya pengaturcaraan ini mungkin, kita boleh mengandaikan bahawa terima kasih kepada penggunaannya, kod itu akan mengandungi lebih sedikit kecacatan, di samping itu, tujuan kerja akan jelas kepada semua orang yang mengambil bahagian di dalamnya. Jika ya, maka hanya membangunkan kod yang diperlukan untuk lulus ujian juga mempunyai akibat sosial:

Jika ketumpatan kecacatan cukup rendah, pasukan Jaminan Kualiti (QA) akan dapat beralih daripada bertindak balas terhadap kesilapan kepada menghalangnya;

Dengan lebih sedikit kejutan yang tidak menyenangkan, pengurus projek akan dapat menganggarkan kos buruh dengan lebih tepat dan melibatkan pelanggan dalam proses pembangunan;

Jika topik perbincangan teknikal ditakrifkan dengan jelas, pengaturcara akan dapat berinteraksi antara satu sama lain secara berterusan, bukannya sekali sehari atau seminggu sekali;

Sekali lagi, dengan ketumpatan kecacatan yang cukup rendah, kami akan dapat menghasilkan produk kerja bersepadu setiap hari dengan fungsi baharu ditambah padanya, membolehkan kami memasuki jenis hubungan perniagaan yang baharu sepenuhnya dengan pelanggan kami.

Jadi ideanya mudah, tetapi apakah minat kita? Mengapakah seorang pengaturcara perlu mengambil tanggungjawab tambahan untuk menulis ujian automatik? Mengapakah seorang pengaturcara bergerak ke hadapan dalam langkah kecil apabila otaknya mampu berfikir melalui struktur reka bentuk yang lebih kompleks? Keberanian.

Keberanian

TDD ialah cara menguruskan ketakutan dalam proses pengaturcaraan. Saya tidak bermaksud takut jatuh dari kerusi atau takut berada di hadapan bos anda. Maksud saya ketakutan untuk menghadapi masalah "sangat sukar sehingga saya tidak tahu bagaimana untuk menyelesaikannya." Kesakitan adalah apabila alam memberitahu kita: "Berhenti!", dan ketakutan adalah apabila alam memberitahu kita: "Berhati-hati!" Berhati-hati bukanlah perkara yang buruk sama sekali, tetapi sebagai tambahan kepada faedahnya, ketakutan mempunyai beberapa kesan negatif kepada kita:

Ketakutan memaksa kita untuk berfikir ke hadapan dan berhati-hati tentang apa yang mungkin membawa kepada tindakan ini atau itu;

Ketakutan membuatkan kita kurang berkomunikasi;

Ketakutan membuatkan kita takut dengan ulasan kerja kita;

Ketakutan membuatkan kita mudah marah.

Tiada satu pun daripada ini membantu proses pengaturcaraan, terutamanya jika anda sedang menyelesaikan masalah yang rumit. Jadi, kita berhadapan dengan persoalan bagaimana untuk keluar dari situasi yang sukar dan

Jangan cuba meramalkan masa depan, tetapi segera mulakan kajian praktikal tentang masalah itu;

Jangan mengasingkan diri anda dari seluruh dunia, tetapi tingkatkan tahap komunikasi;

Jangan elakkan respons, tetapi, sebaliknya, wujudkan maklum balas yang boleh dipercayai dan, dengan bantuannya, pantau dengan teliti hasil tindakan anda;

(anda mesti menangani kerengsaan sendiri).

Mari kita bandingkan pengaturcaraan dengan mengangkat baldi dari perigi. Baldi diisi dengan air, anda memutarkan tuil, menggulung rantai di sekeliling kolar dan mengangkat baldi ke atas. Jika baldinya kecil, pagar biasa yang berputar bebas akan berfungsi dengan baik. Tetapi jika baldi itu besar dan berat, anda akan letih sebelum anda mengangkatnya. Untuk dapat berehat di antara pusingan tuil, mekanisme ratcheting diperlukan untuk membolehkan tuil dikunci. Semakin berat baldi, semakin laju gigi pada gear ratchet harus mengikuti.

Ujian dalam TDD adalah seperti gigi pada gear ratchet. Setelah membuat ujian berfungsi, kami tahu bahawa ujian itu kini berfungsi, kini dan selama-lamanya. Kami selangkah lebih hampir untuk selesai berbanding sebelum ujian disiarkan secara langsung. Selepas itu, kami membuat ujian kedua dijalankan, kemudian yang ketiga, keempat, dan lain-lain. Semakin kompleks masalah yang dihadapi oleh pengaturcara, semakin kurang fungsi setiap ujian mesti meliputi.

Pembaca buku Extreme Programming Terangkan Anda mungkin perasan perbezaan nada antara Pengaturcaraan Ekstrem (XP) dan Pembangunan Dipacu Ujian (TDD). Tidak seperti XP, metodologi TDD tidak mutlak. XP berkata, "untuk bergerak ke hadapan, anda mesti menguasai ini dan itu." TDD ialah teknik yang kurang spesifik. TDD menganggap bahawa terdapat selang antara membuat keputusan dan keputusan, dan menyediakan alat untuk menguruskan panjang selang ini. "Bagaimana jika saya menghabiskan seminggu mereka bentuk algoritma di atas kertas dan kemudian menulis kod menggunakan pendekatan ujian pertama? Adakah ini akan mematuhi TDD?” Sudah tentu ia akan menjadi. Anda tahu saiz selang antara membuat keputusan dan menilai keputusan dan mengawal selang ini secara sedar.

Kebanyakan orang yang telah menguasai TDD mengatakan bahawa amalan pengaturcaraan mereka telah berubah menjadi lebih baik. Dijangkiti oleh ujian(ujian dijangkiti) ialah definisi yang dicipta oleh Erich Gamma untuk menggambarkan perubahan ini. Sebaik sahaja anda menguasai TDD, anda mendapati diri anda menulis lebih banyak ujian daripada sebelumnya, dan bergerak ke hadapan dalam langkah-langkah kecil yang sebelum ini nampaknya tidak berguna kepada anda. Sebaliknya, sesetengah pengaturcara, setelah membiasakan diri dengan TDD, memutuskan untuk kembali kepada amalan lama, menempah TDD untuk kes khas apabila pengaturcaraan konvensional tidak membawa kepada kemajuan yang diingini.

Pasti ada masalah yang tidak dapat (sekurang-kurangnya pada masa ini) diselesaikan menggunakan ujian sahaja. Khususnya, TDD tidak membenarkan seseorang untuk menunjukkan secara mekanikal kecukupan kod yang dibangunkan dari segi keselamatan data dan kebolehpercayaan operasi selari. Sudah tentu, keselamatan adalah berdasarkan kod yang mesti bebas daripada kecacatan, tetapi ia juga berdasarkan penyertaan manusia dalam prosedur perlindungan data. Isu konkurensi yang halus tidak boleh dihasilkan semula dengan pasti dengan hanya menjalankan beberapa kod.

Baru-baru ini, pembangun perisian telah menjadi
teknologi popular yang dipanggil "pengaturcaraan melampau" atau XP. Tentang
banyak artikel dan buku sedang ditulis yang memberi gambaran tentang asas teori
metodologi ini. Saya ingin memberitahu anda bagaimana keadaan ini dalam amalan, dan
apakah kelebihan dan kekurangannya

Pertama sekali, apakah itu XP? Anda boleh menemui banyak definisi dan penerangan di Internet.
istilah ini. Pada dasarnya, setiap daripada mereka lebih kurang cukup mencerminkan intipati
fenomena, tetapi kepelbagaian definisi boleh mengelirukan pembangun. Oleh itu adalah perlu
memahami bahawa XP adalah satu set teknik yang dibangunkan untuk subordinat
proses pembangunan perisian empat prinsip asas. Iaitu:

• komunikasi;
• kesederhanaan;
• Maklum balas;
• keberanian.

Biasanya, teknik ini dinyatakan dalam bahan XP. Berikut adalah yang paling banyak
senarai biasa mereka:

• Permainan perancangan;
• Ujian sebelum pembangunan bermula;
• Pengaturcaraan pasangan;
• Kitar semula berterusan;
• Kemudahan pembangunan;
• Pemilikan kod kolektif;
• Penyepaduan berterusan;
• Pelanggan di tapak kerja;
• Keluaran pantas versi;
• Empat puluh jam seminggu bekerja;
• Piawaian Pengekodan;
• Metafora sistem.

Saya akan mengulas hanya pada beberapa teknik, kerana maksud kebanyakannya adalah
agak jelas dari namanya dan diterangkan secara terperinci dalam kesusasteraan. Sebahagian daripada mereka
kaedah kelihatan agak logik, sesetengahnya, sebaliknya, menyebabkan kebingungan.

Permainan perancangan Idea teknik ini agak mudah. Pemaju bersama-sama dengan
pelanggan berkumpul dan bermain beberapa situasi yang mungkin (dalam
idealnya segala-galanya) yang mungkin timbul apabila menyelesaikan masalah dalam kehidupan. Mesyuarat sedemikian
adalah dinasihatkan untuk mengatur sebelum memulakan pembangunan setiap subsistem, iaitu, untuk dilakukan
ini dilakukan secara berkala sepanjang proses pembangunan. Ini membolehkan anda tidak
melibatkan diri dalam pembangunan mengikut rancangan yang ketat, dan menyesuaikan diri tepat pada masanya untuk
perubahan dalam bidang subjek.

Ujian sebelum pembangunan bermula. Diandaikan bahawa sebelum pembangunan bermula
mana-mana serpihan program, ujian ditulis untuknya. Ini memberikan beberapa kelebihan.
Pertama, ia berlaku bahawa satu perubahan dalam satu bahagian kod memerlukan
kesilapan orang lain. Pendekatan untuk ujian ini membolehkan anda mengenal pasti serta-merta
situasi sedemikian. Kedua, lebih mudah bagi pelanggan untuk melihat dengan jelas bahawa ujian itu berfungsi,
daripada membaca sejumlah besar dokumentasi. Itulah sebabnya keputusan ujian
perlu divisualisasikan.

Metafora sistem. Produk atau serpihan kod yang sedang dibangunkan dibandingkan dengan
sebarang produk atau fenomena yang serupa. Metafora dibina. ini
memudahkan pemahaman masalah, dan, dengan itu, mempercepatkan pembangunan.

Tetapi anda juga perlu memahami bahawa jika, atas sebab tertentu,
mana-mana teknik ini mula bertentangan dengan prinsip teras XP, dan
Situasi sedemikian agak mungkin, maka ia harus ditinggalkan.

Terus terang, walaupun fakta bahawa sebelum peristiwa yang diterangkan bermula, saya
mempunyai pemahaman umum tentang pengaturcaraan yang melampau, tetapi dalam proses
pembangunan aplikasi yang saya ingin memberitahu anda tentang, secara sedar mematuhi
Saya belum mencuba kaedah XP. Walau bagaimanapun, pada pendapat saya ini adalah tipikal
contoh XP. Walau apa pun, keputusan positif telah dicapai.

Sekarang mari kita lihat bagaimana pendekatan XP boleh digunakan dalam amalan dalam
syarat kami. Salah satu tugas saya di tempat kerja ialah automasi pendidikan
proses. Sebenarnya, untuk jangka masa yang agak lama saya
Saya sedang menulis aplikasi yang melaksanakan (sekurang-kurangnya mengikut reka bentuk
penulis:)) penyelesaian yang komprehensif untuk masalah ini. Bajet projek adalah sedikit, dan jumlahnya
berfungsi - baik. Satu lagi faktor yang hampir menentukan ialah pemalar
pengubahsuaian bidang subjek. Borang pelaporan sentiasa berubah
dokumentasi dan kaedah untuk mendapatkannya. Satu situasi timbul apabila projek itu dihentikan
mengikuti kehendak pengguna. Dan suatu hari tibalah saatnya
sebab objektif dan subjektif, pembangunan itu dapat dikebumikan dengan selamat. Namun begitu
tanpa disangka saya diberi tugas khusus untuk menentukan
beban kerja dana bilik darjah untuk semester tersebut. Pada ketika ini, daripada tiga peserta
Saya seorang sahaja yang tinggal dalam projek itu, tetapi subsistem ini tidak dilaksanakan dan pelaksanaannya
tidak ada dalam rancangan pembangunan segera projek itu. Mengenai perkara kecil seperti
perumusan masalah yang kompeten, pengiraan intensiti buruh kerja, peruntukan
Tiada siapa pun memikirkan tentang sumber tambahan. Untuk menyelesaikan tugasan yang ada
dua minggu diperuntukkan. Pada masa yang sama, hujah saya mengenai kemustahilan untuk dipenuhi
masalah ini tidak diambil kira secara prinsip. Keputusan pertama saya ialah mencari
diri saya seorang lagi majikan, memandangkan dalam dua minggu saya terpaksa menulis bukan sahaja
modul untuk menganalisis beban kerja dana bilik darjah, tetapi juga sistem kemasukan jadual
kelas, tindanan kawalan dan banyak lagi. Masalah ini tidak boleh diselesaikan secara autonomi
Pada dasarnya, kita memerlukan data awal. Dan bukan hanya data asal, tetapi yang betul
data awal, dari mana semua tugas di atas mengikuti. Namun begitu,
Saya tidak tahu mengapa, tetapi saya mengambil penyelesaian untuk masalah ini.

Adalah wajar untuk bercakap tentang pembangunan menggunakan kaedah klasik dalam kes ini
tidak sesuai. Di sinilah pendekatan XP berguna. Idea umum tugas
sudah ada, tetapi terdapat banyak nuansa yang berpotensi
meningkatkan jumlah kerja dengan ketara. Saya mula bekerja dengan mendail nombor
jabatan pendidikan dan mula membedil orang yang menjawab telefon dengan banyak soalan, jawapan kepada
yang saya tidak dapat mencari sendiri atau yang saya tidak pasti.
.
Saya melancarkan Rational Rose dan mula membina model. Menjelang akhir hari bekerja
Saya melakar model yang kelihatan lebih kurang memadai untuk saya. Selepas kerja I
mengambil setapak lagi sejajar dengan ideologi XP. Saya menarik kawan saya keluar
bekerja di jabatan pendidikan untuk minum bir. Dalam proses ini, penting dalam semua
hubungan acara itu, saya menggariskan kepadanya visi saya tentang program, antara muka dan
logik kerja. Dia pula mula bercakap tentang keperluan
menyelesaikan beberapa submasalah tempatan. Menjelang petang saya faham dengan lebih jelas apa
masih perlu dilakukan dalam rangka projek ini (saya tidak lagi meragui bahawa tugas
harus dianggap sebagai projek yang berasingan). Bagaimanapun, satu lagi tidak dapat diselesaikan
Isu penting ialah pilihan alat pembangunan. Bilakah peristiwa yang diterangkan itu berlaku?
peristiwa, saya mula aktif mengkaji teknologi MDA. Secara ringkasnya, intipatinya adalah ini:
serpihan kod aplikasi dan struktur data dijana secara automatik berdasarkan
daripada model UML, yang boleh mengurangkan masa pembangunan dengan ketara. dalam
Dalam artikel ini saya tidak akan menerangkan secara terperinci prinsip operasi MDA, tetapi saya mahu
menarik perhatian anda kepada fakta bahawa penggunaan teknologi ini sepenuhnya
sepadan dengan "semangat XP". Ini disebabkan oleh fakta bahawa salah satu syarat di bawahnya
Teknik XP akan berfungsi dengan jayanya, ini akan mengurangkan kos perubahan yang dibuat kepada
Aplikasi ini dalam peringkat akhir pembangunan. Antara faktor yang menyumbang
Untuk mencapai matlamat ini, tidak penting untuk menggunakan pelbagai yang baru
teknologi pengaturcaraan. Saya perhatikan bahawa ia adalah tepat kesederhanaan pemfaktoran semula MDA
aplikasi adalah salah satu kelebihan utama teknologi ini. Secara umum, pada
Hari ini terdapat banyak pelaksanaan MDA, saya pilih
Tebal untuk Delphi.

Tetapi dalam keadaan saya terdapat beberapa "saat-saat licin". Pertama, mengiktiraf itu
MDA memberikan faedah tertentu, saya masih belum cukup yakin
memiliki teknologi ini dan hampir tidak mempunyai pengalaman dalam menulis aplikasi MDA.
Kedua, saya faham bahawa beberapa serpihan kod akan menjadi masalah
dilaksanakan menggunakan alat MDA standard, dan terdapat banyak kerja "manual" yang perlu dilakukan
pengekodan", yang dalam kes ini akan mempunyai spesifik tertentu.

Alternatifnya ialah menulis aplikasi Delphi "biasa". saya melancarkan
ICQ dan menulis mesej kepada rakan saya, seorang penganut Bold. Selepas saya
Saya secara ringkas menggariskan intipati masalah kepadanya, saya bertanya apa yang akan dia lakukan di tempat saya.
Dia menjawab seperti ini: “Sama ada terjun dahulu ke Bold, atau
anda tidak akan pernah menguasainya. Melakukan projek yang serius adalah cara terbaik untuk belajar
teknologi." Sebenarnya, saya tidak mengharapkan jawapan lain.

Pada waktu pagi saya mengambil model sedia ada dan mula membina aplikasi. Betul, bina. KEPADA
Saya tidak memulakan pengekodan, saya hanya melakar antara muka pengguna, banyak
elemen yang mula berfungsi hampir serta-merta. Untuk rehat asap saya cuba keluar masuk
syarikat pekerja jabatan pendidikan, ini membolehkan saya mengheret yang lain
"mangsa" skrin monitornya dan (bukan tanpa kebanggaan tertentu) ditunjukkan
keputusan pertengahan. Oleh itu, prinsip maklum balas telah dilaksanakan.
Anda mungkin betul berkata: "Bagaimana dengan pengaturcaraan pasangan?" ya,
Memang saya seorang sahaja yang terlibat dalam projek itu sebagai pengaturcara. Tetapi di sini saya
Biar saya sebutkan satu lagi kebetulan yang menggembirakan. Dalam tempoh masa tersebut
apabila peristiwa yang diterangkan berlaku, saya, bersama sekumpulan pembangun -
peminat membangunkan projek Internet yang didedikasikan khusus untuk MDA. Dan ketika itulah saya
datang ke tempat yang paling sukar dalam pembangunannya, projek ini membawa
keputusan yang sama sekali tidak dijangka.

Sepanjang beberapa hari, saya menulis kod untuk prosedur yang melaksanakan paparan aktiviti
pada skrin. Kawalan standard tidak membenarkan semuanya dipaparkan pada skrin
data dalam bentuk yang biasanya dipersembahkan. Saya mahu itu
jika pengguna akhir sekurang-kurangnya lebih kurang memahami apa yang program itu lakukan
dan bagaimana untuk bekerja dengannya. Saya menulis komponen saya sendiri berdasarkan TStringGrid biasa.
Saya tidak pasti sama ada ini penyelesaian yang baik, tetapi kod itu berfungsi. Dalam forum
projek kami, saya menggariskan penyelesaian saya, mengharapkan untuk menerima beberapa jenis penilaian dalam
untuk jangka masa yang agak lama. Bagaimanapun, 15-20 minit kemudian dia tiba
jawapan pertama. Penyelesaian alternatif telah dicadangkan, dan selepas 10 minit lagi
contoh ujian tiba, bukan hanya seorang, tetapi dua sekaligus, daripada dua pengarang. Jika
fikirkan mengapa pembangun mula menyelesaikan dengan penuh semangat
masalah orang lain, maka anda boleh membuat kesimpulan yang mudah. Pertama, mereka hanya mempunyai
adalah menarik untuk mencari beberapa penyelesaian universal, yang kemudiannya boleh
gunakan dalam projek anda. Dan kedua, mereka berminat dengan proses itu sendiri
komunikasi. Perlu diingatkan bahawa masalah lain diselesaikan dengan semangat yang sama.
pelbagai aras kesukaran. Sudah tentu, ini bukan pengaturcaraan berpasangan
pemahaman biasa. Sebaliknya, ia adalah sejenis pengganti, tetapi, bagaimanapun, ada juga
kelebihannya. Katakan semua fikiran dan idea yang dinyatakan adalah secara automatik
telah didokumenkan dan boleh diakses pada bila-bila masa.

Saya ingin membincangkan ujian secara berasingan. Seperti yang dia cadangkan dalam bukunya
"Pengaturcaraan Extreme" Kent Beck, ujian harus ditulis lebih awal. Lagi
Lebih-lebih lagi, bagi penulis ia kelihatan seperti ini. Ada program khas
ditulis oleh pembangun sendiri, apabila anda mengklik pada salah satu butang
semua ujian dilancarkan, dan akibatnya "lampu" hijau muncul pada skrin masuk
dalam kes keputusan positif dan merah sebaliknya. Ini penerangan saya
agak mengecewakan. Setuju, sukar untuk membayangkan bagaimana
anda boleh menulis program yang mensimulasikan tindakan pengguna dalam semua
situasi.

Seperti yang telah saya katakan, saya tidak cuba untuk mematuhi kaedah yang melampau
pengaturcaraan. Dan dalam buku-buku yang saya baca, dinyatakan dengan jelas
menulis ujian adalah salah satu mata yang paling penting dalam XP, dan tanpa ujian yang lain
teknik tidak sepatutnya berfungsi. Mengapa saya mencapai sesuatu yang positif pada akhirnya?
keputusan? Semuanya ternyata agak mudah. Membantu saya menjawab soalan ini
betul-betul contoh ini dengan mentol lampu hijau dan merah. Perkara itu ialah dalam Bold
Adalah mungkin untuk menunjukkan sama ada objek yang diberikan sepadan dengan model. DAN
Ini dilakukan dengan tepat dengan bantuan "mentol lampu" sedemikian. Secara harfiah dua baris
yang saya hampir serta-merta dimasukkan ke dalam kod aplikasi, membolehkan saya melihat di mana
di mana percanggahan berlaku (jika ada). Ini yang digantikan
saya menguji. Ada kemungkinan bahawa pendekatan ini tidak sepenuhnya konsisten
idea asal "ujian sebelum pembangunan", tetapi ia berjaya.

Dalam masa seminggu saya mempunyai permohonan yang hampir selesai. Semasa kedua
minggu, saya membuat dua lagi versi, di mana saya serius mengembangkan fungsi, dan
juga mengimport kebanyakan data yang diperlukan untuk kerja daripada yang lain
sistem kerja. Masalahnya telah diselesaikan, dan sebahagian besarnya disebabkan oleh penggunaan
teknik XP. Maksud semua perkara di atas, saya lihat hanya dalam fakta bahawa contoh ini adalah
Dalam amalan, dia membuktikan keberkesanan pengaturcaraan yang melampau.

Kesimpulannya, saya ingin membuat satu perkara lagi. Pengaturcaraan Ekstrem,
pada pendapat saya, bukanlah ubat penawar. Dan kaedahnya boleh digunakan jauh dari
untuk sebarang projek. Pada dasarnya, projek yang dipertimbangkan, mengikut beberapa tanda
jatuh ke dalam kategori projek yang menggunakan XP tidak disyorkan.
Namun, dengan pendekatan yang lebih fleksibel, penggunaan teknik ekstrem
pengaturcaraan boleh membawa hasil yang agak menakjubkan. Apabila membaca
buku oleh pengarang asing yang dikhaskan untuk topik ini untuk pembaca domestik
Seseorang mungkin berfikir bahawa teknik XP tidak boleh, pada dasarnya, digunakan dalam
syarat kami. Dan bukan sahaja hubungan antara pembangun dan
pelanggan, serta perhubungan dalam pasukan pembangunan yang diterangkan dalam buku
contoh adalah berdasarkan prinsip yang sedikit berbeza. Ia lebih kepada perbezaan
mentaliti. Walau bagaimanapun, menyesuaikan XP dengan keadaan kami agak mungkin, dan ini mungkin
memberikan hasil yang sangat mengagumkan.

http://xprogramming.com.ua/ - dunia
pengaturcaraan yang melampau

http://www.xprogramming.ru/ —
pengaturcaraan melampau dalam bahasa Rusia

http://www.maxkir.com/ - tentang pembangunan
perisian

http://xprogramming.com/ - laman web
Ahli ideologi XP Ron Jeffries