Kent Beck - Ekstrem Programlama. Test odaklı geliştirme. Ekstrem Programlama (XP) cesareti zayıf olanlara göre değildir

Ve diğerleri.

Metodolojinin adı, faydalı geleneksel geliştirme yöntem ve uygulamalarının uygulanması fikrinden gelmektedir. yazılım onları yeni bir "aşırı" seviyeye taşıyor. Örneğin, bir programcının başka bir programcı tarafından yazılan kodu kontrol etmesinden oluşan kod revizyonunu "ekstrem" versiyonda gerçekleştirme uygulaması, bir programcı ve ortağının aynı anda kodlama yaptığı "eşli programlama"dır. az önce yazdığı kodu sürekli olarak gözden geçirir.

Ansiklopedik YouTube

1 / 5

Ekstrem Programlama (XP) - Temel Teknikler

Hexlet Web Semineri #6: Ekstrem Programlama

Hayat İpuçları. Neden programlama yarışmalarına katılmalısınız?

032. Çift programlama - Sergey Berezhnoy

Kanal aşırı programlama v. 2.0

Altyazılar

Temel XP Teknikleri

Aşırı programlamanın on iki temel tekniği (kitabın ilk baskısına dayanmaktadır) Ekstrem programlamanın açıklaması) dört gruba birleştirilebilir:

• Kısa geri bildirim döngüsü (İnce ölçekli geri bildirim)
  • Test odaklı geliştirme
  • Planlama oyunu
  • Müşteri her zaman yakındadır (Tüm ekip, Yerinde müşteri)
  • Çiftler programı
• Toplu işlem yerine sürekli
  • Sürekli entegrasyon
  • Yeniden Düzenleme (Tasarım iyileştirme, Yeniden Düzenleme)
  • Sık sık küçük sürümler
• Herkes tarafından paylaşılan anlayış
  • Sadelik (Basit tasarım)
  • Sistem metaforu
  • Toplu kod sahipliği veya seçilen tasarım desenleri (Toplu kalıp sahipliği)
  • Kodlama standardı veya Kodlama kuralları
• Programcı refahı:
  • Haftada 40 saatlik çalışma (Sürdürülebilir tempo, Haftada kırk saat)

Test yapmak

XP, otomatik testler yazmayı içerir (başka bir testin mantığını test etmek için özel olarak yazılan program kodu). program kodu). İki tür teste özellikle dikkat edilir:

• modüllerin birim testi;

Bir geliştirici, geliştirdiği sistemin modüllerinin tüm testleri kesinlikle çalışana kadar yazdığı kodun doğruluğundan emin olamaz. Birim testleri (birim testleri), geliştiricilerin her birinin ayrı ayrı doğru çalıştığını doğrulamasını sağlar. Ayrıca diğer geliştiricilerin belirli bir kod parçasına neden ihtiyaç duyulduğunu ve nasıl çalıştığını anlamalarına da yardımcı olurlar - test kodunu incelerken, test edilen kodun mantığı netleşir, çünkü nasıl kullanılması gerektiği açıktır. Birim testleri ayrıca geliştiricinin endişelenmeden yeniden düzenleme yapmasına olanak tanır.

Fonksiyonel testler, birkaç (çoğunlukla oldukça etkileyici boyutta) parçanın etkileşimi ile oluşan mantığın işleyişini test etmek için tasarlanmıştır. Birim testlerinden daha az ayrıntılıdırlar ancak çok daha fazlasını kapsarlar; yani, daha büyük miktarda kodu kapsayan testlerin yürütüldüğünde herhangi bir yanlış davranışı tespit etme olasılığı açıktır. Bu nedenle içinde endüstriyel programlama Fonksiyonel testlerin yazılması genellikle birim testlerin yazılmasına göre önceliklidir.

XP için, TDD (İngilizce test odaklı geliştirme - test yoluyla geliştirme) adı verilen yaklaşım daha yüksek bir önceliktir. Bu yaklaşımda, önce başlangıçta başarısız olan bir test yazarsınız (çünkü test etmesi gereken mantık henüz mevcut değildir), ardından testi geçmek için gereken mantığı uygularsınız. TDD bir anlamda kullanımı daha uygun kod yazmanıza olanak tanır - çünkü bir test yazarken, henüz bir mantık olmadığında, gelecekteki sistemin rahatlığına dikkat etmek en kolay yoldur.

Planlama oyunu

Planlama oyununun temel amacı hızlı bir şekilde oluşturmaktır. Kaba plançalışın ve görevin koşulları netleştikçe onu sürekli güncelleyin. Planlama oyununun eserleri, üzerine müşteri isteklerinin (müşteri hikayeleri) yazıldığı bir dizi kağıt kart ve ürünün bir sonraki bir veya daha fazla küçük versiyonunun piyasaya sürülmesi için kaba bir çalışma planıdır. Bu planlama tarzını etkili kılan kritik faktör, bu durumda müşteri iş kararlarının alınmasından, geliştirme ekibi ise teknik kararların alınmasından sorumludur. Bu kurala uyulmazsa tüm süreç çöker.

Müşteri her zaman oradadır

XP'deki "müşteri" faturaları ödeyen değil, son kullanıcı yazılım ürünü. XP, müşterinin her zaman iletişim halinde olması ve soruları için hazır olması gerektiğini belirtir.

Çiftler programı

Çiftler programı tüm kodun aynı bilgisayarda çalışan programcı çiftleri tarafından oluşturulduğunu varsayar. Bunlardan biri doğrudan program metniyle çalışır, diğeri ise çalışmasına bakar ve izler. Büyük resim ne oluyor. Gerekirse klavye serbestçe birinden diğerine aktarılabilir. Bir proje üzerinde çalışırken çiftler sabit değildir: takımdaki her programcının tüm sistemi iyi anlayabilmesi için bunların karıştırılması önerilir. Bu şekilde eşli programlama ekip içindeki etkileşimi artırır.

Sürekli Entegrasyon

Yeterince sık geliştirilmekte olan sistemi entegre ederseniz, onunla ilgili sorunların çoğundan kaçınabilirsiniz. Geleneksel yöntemlerde entegrasyon genellikle bir ürün üzerinde çalışmanın en sonunda, geliştirilmekte olan sistemin tüm bileşenlerinin tamamen hazır olduğu düşünüldüğünde gerçekleştirilir. XP'de, geliştiriciler tüm birim testlerinin doğru çalıştığından emin olduktan sonra, tüm sistemin kod entegrasyonu günde birkaç kez gerçekleştirilir.

Yeniden Düzenleme

Yeniden düzenleme, kodun işlevselliğini değiştirmeden iyileştirmeye yönelik bir tekniktir. XP, kod bir kez yazıldığında, proje süresince neredeyse kesinlikle birkaç kez yeniden yazılacağı anlamına gelir. XP geliştiricileri, geliştirmek için önceden yazılmış kodu acımasızca yeniden işler. Bu işleme yeniden düzenleme denir. Test kapsamının olmayışı, sistemi kırma korkusu nedeniyle yeniden düzenlemenin reddedilmesine neden olur ve bu da kodun kademeli olarak bozulmasına yol açar.

Sık sık küçük sürümler

Ürünün sürümleri (sürümleri) mümkün olduğunca sık hizmete sunulmalıdır. Her sürümün tamamlanması mümkün olduğunca az zaman almalıdır. Ayrıca her versiyonun işe yararlılık açısından yeterince anlamlı olması gerekir.

Ürünün ilk çalışan versiyonu ne kadar erken piyasaya sürülürse, müşteri o kadar çabuk ek kar elde etmeye başlar. Bugün kazanılan paranın yarın kazanılan paradan daha değerli olduğunu unutmayın. Müşteri ürünü ne kadar erken kullanmaya başlarsa, geliştiriciler müşterinin gereksinimlerini neyin karşıladığı konusunda ondan o kadar çabuk bilgi alacaktır. Bu bilgiler bir sonraki sürümünüzü planlarken son derece yararlı olabilir.

Tasarım kolaylığı

XP, çalışma süreci boyunca problemin koşullarının tekrar tekrar değişebileceği gerçeğinden yola çıkıyor, bu da geliştirilmekte olan ürünün bütünüyle önceden tasarlanmaması gerektiği anlamına geliyor. Bir sistemi en baştan detaylı bir şekilde tasarlamaya çalışmak zaman kaybıdır. XP, tasarımın proje boyunca sürekli yapılması gereken önemli bir süreç olduğunu varsayar. Tasarım, sürekli değişen gereksinimler dikkate alınarak küçük adımlarla gerçekleştirilmelidir. Herhangi bir zamanda mevcut problemin çözümüne uygun en basit tasarımı kullanmaya çalışmalı ve problemin koşulları değiştikçe onu değiştirmelisiniz.

Sistem metaforu

Mimarlık, bir sistemin bileşenleri ve bunların birbirleriyle ilişkileri hakkında bir fikirdir. Geliştiricilerin, sistemin neresine yeni işlevsellik eklenmesi gerektiğini ve yeni bileşenin neyle etkileşime gireceğini anlamak için yazılım mimarisini analiz etmeleri gerekir.

Sistem metaforu çoğu teknikte mimari olarak adlandırılan şeyin bir benzeridir. Sistem metaforu, ekibe sistemin şu anda nasıl çalıştığı, yeni bileşenlerin nereye eklendiği ve bunların hangi formu alması gerektiği konusunda fikir verir.

İyi bir metafor seçmek, geliştirme ekibinin sistemin nasıl çalıştığını anlamasını kolaylaştırır. Bazen bunu yapmak kolay değildir.

Kodlama Standartları

Tüm ekip üyelerinin çalışırken ortak kodlama standartlarına uyması gerekir. Böylece:

• ekip üyeleri projedeki çalışma hızını aslında etkilemeyen şeyler hakkında tartışarak zaman kaybetmezler;
• diğer uygulamaların etkin bir şekilde uygulanması sağlanır.

Bir ekip tutarlı kodlama standartları kullanmazsa geliştiricilerin yeniden düzenleme yapması daha zor hale gelir; çiftlerde partner değiştirirken daha fazla zorluk ortaya çıkar; genel olarak projenin ilerlemesi zorlaşıyor. XP'de, şu veya bu kod parçasının yazarının kim olduğunu anlamanın zor olmasını sağlamak gerekir - tüm ekip tek bir kişi gibi birlikte çalışır. Ekip bir dizi kural oluşturmalı ve ardından her ekip üyesi kodlama sürecinde bu kurallara uymalıdır. Kural listesi kapsamlı veya çok hacimli olmamalıdır. Amaç, kodu ekipteki herkes için anlaşılır kılan genel yönergeler sağlamaktır. Kodlama standardı basit bir şekilde başlamalı ve geliştirme ekibi deneyim kazandıkça giderek daha karmaşık hale gelmelidir. Standardın ön geliştirmesi için çok fazla zaman harcamanıza gerek yoktur.

Kolektif mülkiyet

Kolektif mülkiyet her ekip üyesinin tüm kaynak kodundan sorumlu olduğu anlamına gelir. Böylece herkes programın herhangi bir bölümünde değişiklik yapma hakkına sahiptir. Eşli programlama bu uygulamayı destekler: farklı çiftler halinde çalışarak tüm programcılar sistem kodunun tüm bölümlerine aşina olur. Paylaşılan kod sahipliğinin önemli bir avantajı, geliştirme sürecini hızlandırmasıdır; çünkü bir hata oluşursa herhangi bir programcı bunu düzeltebilir.

Ekleyen: Çarş, 01/25/2012 - 02:28

7. Uyarlanabilir geliştirme süreci modelleri: Scrum

Şu anda daha yaygın hale geliyorlar uyarlanabilir veya hafif e, “canlı” (çevik) geliştirme süreçleri
Onlar bu kadar katı bir düzenlemeye gerek yok, itiraf etmek Müşteri gereksinimlerinde sık ve önemli değişiklik olasılığı

Uyarlanabilir Süreçler odaklan kullanmak iyi geliştiriciler yerleşik geliştirme süreçlerinden ziyade
Onlar Net eylem kalıplarını sabitlemekten kaçının Her özel projede daha fazla esneklik sağlamak ve ek ara belgelerin geliştirilmesini gerektirmemek

Canlı gelişimin ilkeleri

Canlı yazılım geliştirmenin temel ilkeleri 2000 yılında ortaya çıkan manifestoda kaydedilenler: =

1. Bir projede yer alan kişiler ve onların iletişimi, süreç ve araçlardan daha önemlidir
2. Çalışan bir program kapsamlı dokümantasyondan daha önemlidir
3. Müşteriyle işbirliği, sözleşme ayrıntılarını tartışmaktan daha önemlidir
4. Değişiklikler üzerinde çalışmak planlara bağlı kalmaktan daha önemlidir

Ekstrem Programlama

En çok kullanılan uyarlanabilir model dır-dir aşırı programlama modeli(eXtreme Programlama, XP süreci)
XP süreç odaklı belirsiz veya hızla değişen gereksinimler altında yazılım geliştiren küçük ve orta ölçekli ekiplere bölünebilir

XP Süreci (Ekstrem Programlama)

XP sürecinin temel fikri – Değişiklik yapmanın yüksek maliyetini ortadan kaldırın. Bu başarıldı bireysel yinelemelerin süresini keskin bir şekilde (iki haftaya kadar) azaltarak.
XP'nin temel eylemleri şunlardır:=

1. kodlama,
2. test yapmak,
3. müşteriyi dinlemek,
4. tasarım

XP İlkeleri

Yüksek dinamizm gelişme aşağıdaki ilkelerle sağlanır:=

1. Müşteri ile sürekli iletişim halinde olan,
2. Seçilen çözümlerin basitliği,
3. Operasyonel testlere dayalı hızlı geri bildirim,
4. risk önleme

XP geliştirme uygulamaları

Bu ilkelerin uygulanması sağlanır aşağıdaki yöntemleri kullanarak:=

1. Metafor– tüm geliştirmeler sistemin nasıl çalıştığına dair basit, kamuya açık bir hikayeye dayanmaktadır
2. Basit tasarım– mümkün olan en basit tasarım çözümleri benimsenmiştir
3. Sürekli test hem bireysel modüller hem de bir bütün olarak sistem; kod yazmak için giriş kriteri başarısız bir test senaryosudur
4. Tanzimat(Yeniden Düzenleme) - davranışını korurken sistemin yapısını iyileştirmek
5. Çiftler programı e – kod iki programcı tarafından bir bilgisayarda yazılır
6. Toplu kod sahipliği– herhangi bir geliştirici herhangi bir sistem modülünün kodunu iyileştirebilir
7. Sürekli Entegrasyon – sistem mümkün olduğunca sık entegre edilir; Sürekli regresyon testi, gereksinimler değiştikçe işlevselliğin aynı kalmasını sağlar
8. Yerel müşteri– Müşterinin yetkili bir temsilcisi her zaman grupta bulunmalıdır
9. Kodlama Standartları– Sistemin her yerinde aynı kod sunumunu sağlamak için kurallara uyulmalıdır

XP geliştirme şeması

XP görüntüsü (XP geliştirme şeması):

Scrum modeli

Uyarlanabilir geliştirme sürecinin başka bir örneğidir (daha önce bakmıştık)
Modelin ana fikirleri 1986 yılında Hirotaka Takeuchi ve Ikujiro Nonaka tarafından formüle edildi.

Scrum modelinin ana fikri

Deneysel gerçek: Küçük, çapraz fonksiyonlu ekipler tarafından üzerinde çalışılan projeler sistematik olarak daha iyi sonuçlar üretme eğilimindedir

Takeuki ve Nonata bunu şu şekilde açıkladılar: "ragbi yaklaşımı" ve terimin kendisini tanıttı

"hücum"- "ezmek; topun etrafında hücum etmek (rugby'de)"

Scrum yöntemi ilk kez 1996 yılında Sutherland ve Schwaber tarafından ortaklaşa belgelenmiş biçimde sunuldu.

Roller

1. Saldırı ustası Süreçlerle ilgilenen ve proje yöneticisi olarak çalışan,
2. Ürün sahibi, son kullanıcıların ve ürünle ilgilenen diğer tarafların çıkarlarını temsil eden kişi,
3. Takım geliştiricileri içeren

Geliştirme aşamaları

Geliştirme süreci aşağıdakilere ayrılmıştır: belirli bir sürenin ayrı aşamaları - sprintler(genellikle 15-30 gün)
Her sprint öncesinde ürün biriktirme listesi adı verilen bir aşama gelir– iş taleplerinin belgelenmesi

Sprint planlama

İş talepleri Sprint Planlama Kurulu aşamasında belirlenir – sprint planlama toplantısı

Sprint planlama
Bu toplantı sırasında Ürün Sahibi tamamlanması gereken görevler hakkında bilgi verir.
Takım bir sonraki sprintte gerekli parçaları tamamlamak için ne kadarını başarmak istediklerini belirler.

Bir sprint yürütmek

Bir sprint sırasında takım tamamlar belirli bir sabit görev listesi - biriktirme listesi öğeleri yazılım ürününün işlevselliğini arttırmak

Bu süreçte hiç kimsenin iş gereksinimleri listesini değiştirme hakkı yoktur bir sprint sırasında donma gereksinimleri olarak anlaşılmalıdır

Scrum diyagramı =

Referans cevabının metni (zorunlu olarak konumlandırmıyorum)

Ekstrem Programlama

Temel XP Teknikleri

· Kısa geri bildirim döngüsü (İnce ölçekli geri bildirim)

o Test odaklı geliştirme

o Planlama oyunu

o Müşteri her zaman yakındadır (Tüm ekip, Yerinde müşteri)

o Eşli programlama

Toplu işlem yerine sürekli

o Sürekli Entegrasyon

o Yeniden Düzenleme (Tasarım İyileştirme, Yeniden Düzenleme)

o Sık Küçük Sürümler

· Herkes tarafından paylaşılan anlayış

o Sadelik (Basit tasarım)

o Sistem metaforu

o Kolektif kod sahipliği veya seçilmiş tasarım modelleri (Kolektif kalıp sahipliği)

o Kodlama standardı veya Kodlama kuralları

· Programcı refahı:

o Haftada 40 saatlik çalışma (Sürdürülebilir tempo, Haftada kırk saat)

Test yapmak

XP iki tür teste özellikle önem vermektedir:

· birim testi;

· Kabul testleri.

Bir geliştirici, geliştirdiği sistemin modüllerinin tüm testleri kesinlikle çalışana kadar yazdığı kodun doğruluğundan emin olamaz. Birim testleri, geliştiricilerin kodlarının düzgün çalıştığını doğrulamasını sağlar. Ayrıca diğer geliştiricilerin belirli bir kod parçasına neden ihtiyaç duyulduğunu ve nasıl çalıştığını anlamalarına da yardımcı olurlar. Birim testleri ayrıca geliştiricinin endişelenmeden yeniden düzenleme yapmasına olanak tanır.

Kabul testleri, sistemin gerçekten belirtilen yeteneklere sahip olmasını sağlar. Ayrıca kabul testleri, geliştirilmekte olan ürünün doğru çalıştığını doğrulamanıza olanak tanır.

XP için, TDD (Test Odaklı Geliştirme) adı verilen bir yaklaşım daha yüksek önceliğe sahiptir - önce geçemeyen bir test yazılır, ardından kod, testin geçmesi için yazılır ve ancak bundan sonra kod yeniden düzenlenir.

Planlama oyunu

Planlama oyununun temel amacı hızlı bir şekilde kaba bir çalışma planı oluşturmak ve sorun koşulları netleştikçe bu planı sürekli güncellemektir. Planlama oyununun eserleri, üzerine müşteri isteklerinin (müşteri hikayeleri) yazıldığı bir dizi kağıt kart ve ürünün bir sonraki bir veya daha fazla küçük versiyonunun piyasaya sürülmesi için kaba bir çalışma planıdır. Bu planlama tarzını etkili kılan kritik faktör, bu durumda iş kararlarının alınmasından müşterinin, teknik kararların alınmasından ise geliştirme ekibinin sorumlu olmasıdır. Bu kurala uyulmazsa tüm süreç çöker.

Müşteri her zaman oradadır

XP'de "müşteri" faturaları ödeyen değil, sistemi gerçekten kullanan kişidir. XP, müşterinin her zaman iletişim halinde olması ve soruları için hazır olması gerektiğini belirtir.

Çiftler programı

Eşli programlama, aynı bilgisayarda çalışan programcı çiftleri tarafından oluşturulan tüm kodları içerir. Bunlardan biri doğrudan program metniyle çalışır, diğeri ise çalışmasına bakar ve olup bitenlerin genel resmini izler. Gerekirse klavye serbestçe birinden diğerine aktarılır. Bir proje üzerinde çalışırken çiftler sabit değildir: takımdaki her programcının tüm sistemi iyi anlayabilmesi için bunların karıştırılması önerilir. Bu şekilde eşli programlama ekip içindeki işbirliğini geliştirir.

Sürekli Entegrasyon

Geliştirdiğiniz sistemi yeterince sık entegre ederseniz, onunla ilgili sorunların çoğundan kaçınabilirsiniz. Geleneksel yöntemlerde entegrasyon genellikle bir ürün üzerinde çalışmanın en sonunda, geliştirilmekte olan sistemin tüm bileşenlerinin tamamen hazır olduğu düşünüldüğünde gerçekleştirilir. XP'de, geliştiriciler tüm birim testlerinin doğru çalıştığından emin olduktan sonra, tüm sistemin kod entegrasyonu günde birkaç kez gerçekleştirilir.

Yeniden Düzenleme

Bu, işlevselliğini değiştirmeden kodu geliştirmeye yönelik bir tekniktir. XP, kod bir kez yazıldığında, proje süresince neredeyse kesinlikle birkaç kez yeniden yazılacağı anlamına gelir. XP geliştiricileri, geliştirmek için önceden yazılmış kodu acımasızca yeniden işler. Bu işleme yeniden düzenleme denir. Test kapsamının olmayışı, sistemi kırma korkusu nedeniyle yeniden düzenlemenin reddedilmesine neden olur ve bu da kodun kademeli olarak bozulmasına yol açar.

Sık sık küçük sürümler

Ürünün sürümleri (sürümleri) mümkün olduğunca sık hizmete sunulmalıdır. Her sürümün tamamlanması mümkün olduğunca az zaman almalıdır. Ayrıca her versiyonun işe yararlılık açısından yeterince anlamlı olması gerekir.

Ürünün ilk çalışan versiyonunu ne kadar erken yayınlarsak, müşteri o kadar erken üründen ek kar elde etmeye başlayacaktır. Bugün kazanılan paranın yarın kazanılan paradan daha değerli olduğunu unutmayın. Müşteri ürünü ne kadar erken kullanmaya başlarsa, geliştiriciler müşterinin gereksinimlerini neyin karşıladığı konusunda ondan o kadar çabuk bilgi alacaktır. Bu bilgiler bir sonraki sürümünüzü planlarken son derece yararlı olabilir.

Tasarımın basitliği

XP, çalışma süreci boyunca problemin koşullarının tekrar tekrar değişebileceği gerçeğinden yola çıkıyor, bu da geliştirilmekte olan ürünün bütünüyle önceden tasarlanmaması gerektiği anlamına geliyor. İlk başladığınızda bir sistemi baştan sona detaylı bir şekilde tasarlamaya çalışırsanız zamanınızı boşa harcıyorsunuz demektir. XP, tasarımın proje boyunca sürekli yapılması gereken önemli bir süreç olduğunu varsayar. Tasarım, sürekli değişen gereksinimler dikkate alınarak küçük adımlarla gerçekleştirilmelidir. Her an mevcut problemin çözümüne uygun, en basit tasarımı kullanmaya çalışıyoruz. Aynı zamanda sorunun koşulları değiştikçe biz de onu değiştiriyoruz.

Sistem metaforu

Mimarlık, bir sistemin bileşenleri ve bunların birbirine nasıl bağlı olduğu hakkında bir fikirdir. Geliştiriciler, bazı yeni işlevlerin sistemin neresine ekleneceğini ve bazı yeni bileşenlerin neyle etkileşime gireceğini anlamak için mimariyi kullanır.

Sistem metaforu çoğu teknikte mimari olarak adlandırılan şeyin bir benzeridir. Sistem metaforu ekibe sistemin şu anda nasıl çalıştığı, yeni bileşenlerin nereye eklendiği ve bunların hangi formu alması gerektiği konusunda fikir verir.

İyi bir metafor seçerek ekibinizin sisteminizin nasıl çalıştığını anlamasını kolaylaştırırsınız. Bazen bunu yapmak kolay değildir.

Kodlama Standartları

Tüm ekip üyelerinin çalışırken ortak kodlama standartlarına uyması gerekir. Böylece:

· ekip üyeleri, projedeki çalışma hızını aslında etkilemeyen şeyler hakkında aptalca tartışmalarla zaman kaybetmezler;

· Diğer uygulamaların etkin bir şekilde uygulanmasını sağlar.

Bir ekip tutarlı kodlama standartları kullanmazsa geliştiricilerin yeniden düzenleme yapması daha zor hale gelir; çiftlerde partner değiştirirken daha fazla zorluk ortaya çıkar; genel olarak projenin ilerlemesi zorlaşıyor. XP'de, şu veya bu kod parçasının yazarının kim olduğunu anlamanın zor olmasını sağlamak gerekir - tüm ekip tek bir kişi gibi birlikte çalışır. Ekip bir dizi kural oluşturmalı ve ardından her ekip üyesi kodlama sürecinde bu kurallara uymalıdır. Kural listesi kapsamlı veya çok uzun olmamalıdır. Amaç, kodu ekipteki herkes için anlaşılır kılan genel yönergeler sağlamaktır. Kodlama standardı basit bir şekilde başlamalı ve ekip deneyim kazandıkça gelişmelidir. Standardın ön geliştirilmesine çok fazla zaman harcamamalısınız.

Kolektif mülkiyet

Ekip sahipliği, her ekip üyesinin işin tamamından sorumlu olduğu anlamına gelir. kaynak. Böylece herkes programın herhangi bir bölümünde değişiklik yapma hakkına sahiptir. Eşli programlama bu uygulamayı destekler: farklı çiftler halinde çalışarak tüm programcılar sistem kodunun tüm bölümlerine aşina olur. Paylaşılan kod sahipliğinin önemli bir avantajı, geliştirme sürecini hızlandırmasıdır; çünkü bir hata oluşursa herhangi bir programcı bunu düzeltebilir.

Her programcıya kodu değiştirme hakkı vererek, ne yaptıklarını bildiklerini düşünen ancak belirli bağımlılıkları dikkate almayan programcıların neden olduğu hatalar riskini üstleniyoruz. İyi tanımlanmış UNIT testleri bu sorunu çözer: incelenmemiş bağımlılıklar hatalara neden olursa, UNIT testlerinin bir sonraki çalıştırması başarısız olur

Scrum, geliştirme sürecinin üzerine inşa edildiği, kesin olarak sabit kısa sürelerde (2 ila 4 hafta arası sprintler) son kullanıcıya en yüksek önceliğin verildiği yeni özelliklere sahip çalışan bir yazılım sağlanmasına olanak tanıyan bir dizi prensiptir. azimli. Bir sonraki sprintte uygulamaya yönelik yazılım yetenekleri, sprintin başında planlama aşamasında belirlenir ve tüm süre boyunca değiştirilemez. Aynı zamanda, sprintin kesin olarak sabit kısa süresi, geliştirme sürecine öngörülebilirlik ve esneklik kazandırır.

Scrum'daki ana oyunculuk rolleri: ScrumMaster, Scrum toplantılarına liderlik eden ve tüm Scrum ilkelerinin takip edilmesini sağlayan kişidir (rol, Scrum'ın doğru yürütülmesinden başka bir şeyi ifade etmez, proje yöneticisinin Ürün Sahibi olma olasılığı daha yüksektir) ve ScrumMaster olmamalıdır); Ürün Sahibi - son kullanıcıların ve ürünle ilgilenen diğer tarafların çıkarlarını temsil eden kişi; ve hem geliştiriciler hem de test uzmanları, mimarlar, analistler vb.'den oluşan işlevler arası bir Ekip (Scrum Takımı) (ideal takım büyüklüğü 7±2 kişidir). Ekip, geliştirme sürecine tamamen dahil olan tek katılımcıdır ve sonuçtan tek bir bütün olarak sorumludur. Sprint sırasında takım dışında hiç kimse geliştirme sürecine müdahale edemez.

Her sprint sırasında yazılımın işlevsel büyümesi yaratılır. Her sprintte teslim edilen özellikler kümesi, ürün biriktirme listesi adı verilen ve tamamlanması gereken iş gereksinimleri düzeyi bakımından en yüksek önceliğe sahip olan bir aşamadan gelir. Sprint planlama toplantısı sırasında belirlenen biriktirme listesi öğeleri sprint aşamasına taşınır. Bu toplantı sırasında Ürün Sahibi tamamlanması gereken görevleri bildirir. Takım daha sonra bir sonraki sprintte gerekli parçaları tamamlamak için ne kadarını başarmak istediklerini belirler. Bir sprint sırasında takım belirli bir sabit görev listesini (sprint biriktirme listesi olarak adlandırılır) tamamlar. Bu süre zarfında hiç kimsenin sprint sırasında donma gereksinimleri olarak anlaşılması gereken iş gereksinimleri listesini değiştirme hakkı yoktur.

_____________
VSU Matematik Fakültesi ve diğer klasikler =)

• Yorum yazmak için giriş yapın

Extreme Programming (XP), esnek yazılım geliştirme metodolojilerinden biridir. Metodolojinin yazarları Kent Beck, Ward Cunningham, Martin Fowler ve diğerleridir.

Planlama oyunu

Yayın planı

Yineleme planlaması

Toplantı ayakta

Basitlik

Metafor sistemi

Müşteri iş yerinde

Geliştirme başlamadan önce test etme

Çiftler programı

Pozisyonları değiştirme

Toplu kod sahipliği

Kodlama kuralı

Sık entegrasyon

Kırk saatlik çalışma haftası

Çözüm

Kaynakça:

Ekstrem Programlama: Test Odaklı Geliştirme

Cindy'ye ithaf edilmiştir: ruhumun kanatları

Yayın hakları Addison-Wesley Longman ile yapılan anlaşma kapsamında elde edildi. Her hakkı saklıdır. Bu kitabın hiçbir bölümü, telif hakkı sahiplerinin yazılı izni olmadan hiçbir şekilde çoğaltılamaz.

Bu kitapta yer alan bilgiler yayıncının güvenilir kabul ettiği kaynaklardan elde edilmiştir. Ancak olası insan veya teknik hatalar yayıncı, sağlanan bilgilerin mutlak doğruluğunu ve eksiksizliğini garanti edemez ve kitabın kullanımıyla ilgili olası hatalardan sorumlu değildir.

ISBN 978-0321146533 İngilizce

ISBN 978-5-496-02570-6

© 2003 Pearson Education, Inc.'e aittir.

© Russian LLC Yayınevi "Piter"'a Çeviri, 2017

© Rusça Baskı, Peter Publishing House LLC tarafından tasarlanmıştır, 2017

© Seri “Programcının Kütüphanesi”, 2017

Önsöz

Çalışan temiz kod Ron Jeffries tarafından türetilen bu kısa ama anlamlı ifade, "çalışan temiz kod", Test Odaklı Geliştirmenin (TDD) tüm anlamını özetlemektedir. Çalışan temiz kod, uğruna çabalamaya değer bir hedeftir çünkü

Bu, program geliştirmenin öngörülebilir bir yoludur. Uzun bir dizi hata konusunda endişelenmeden bir işin ne zaman tamamlanmış sayılabileceğini bilirsiniz;

Kodun öğrettiği dersleri öğrenme şansı verir. Aklınıza gelen ilk fikri kullanırsanız daha iyi olan ikinci fikri hayata geçirme şansınız olmaz;

Programlarınızın kullanıcılarının yaşamlarını iyileştirir;

Meslektaşlarınızın size, sizin de onlara güvenmenizi sağlar;

Bu şekilde kod yazmak daha keyifli.

Peki işe yarayan temiz kodu nasıl elde edersiniz? Pek çok etken temiz kod almamızı engelliyor ve bazen işe yarayan kodu bile alamıyoruz. Birçok sorundan kurtulmak için kodu otomatik teste dayalı olarak geliştireceğiz. Bu programlama tarzına test odaklı geliştirme denir. Bu tekniğe göre

Yeni kod ancak yazıldıktan sonra yazılır otomatik test başarısızlıkla sonuçlanan;

Her türlü çoğaltma ortadan kaldırılır.

İki Basit kurallar, değil mi? Ancak birçok teknik sonucu olan karmaşık bireysel ve grup davranışlarına neden olurlar:

Tasarım sürecinde kodu sürekli çalıştırıp nasıl çalıştığına dair fikir ediniriz, bu da doğru kararları vermemize yardımcı olur;

Kendi testlerimizi yazarız çünkü başka birinin bizim için testler yazmasını bekleyemeyiz;

Geliştirme ortamımızın küçük kod değişikliklerine hızla yanıt vermesi gerekir;

Program tasarımı, kodun test edilmesini kolaylaştırmak için birçok bağımsız, gevşek bağlı bileşenin kullanımına dayanmalıdır.

Bahsedilen iki TDD kuralı programlama adımlarının sırasını belirler.

1. Kırmızı - Çalışmayan ve belki de derlenmeyen küçük bir test yazın.

2. Yeşil - tasarımın doğruluğu ve kodun temizliği konusunda endişelenmeden test çalıştırmasını mümkün olduğunca hızlı yapın. Testin çalışmasını sağlayacak kadar kod yazın.

3. Yeniden Düzenleme – yazılı koddaki her türlü tekrarı ortadan kaldırın.

Kırmızı – yeşil – yeniden düzenleme TDD'nin mantrasıdır.

Bu tarz programlamanın mümkün olduğunu varsayarsak, kullanımı sayesinde kodun önemli ölçüde daha az kusur içereceğini, ayrıca işin amacının, katılan herkes için net olacağını varsayabiliriz. Eğer öyleyse, yalnızca testleri geçmek için gereken kodu geliştirmenin sosyal sonuçları da vardır:

Kusur yoğunluğu yeterince düşükse, Kalite Güvence (QA) ekibi hatalara tepki vermekten onları önlemeye geçebilecektir;

Azalan miktarla hoş olmayan sürprizler proje yöneticileri işçilik maliyetlerini daha doğru tahmin edebilecek ve müşterileri geliştirme sürecine dahil edebilecek;

Teknik tartışmaların konuları açıkça tanımlanırsa programcılar günde bir veya haftada bir yerine sürekli olarak birbirleriyle etkileşime girebilecek;

Bir kez daha, yeterince düşük kusur yoğunluğuyla, her gün üzerine yeni işlevler eklenen entegre bir iş ürünü üretebileceğiz ve bu da müşterilerimizle tamamen yeni türde bir iş ilişkisine girmemize olanak tanıyacak.

Yani fikir basit ama ilgimiz ne? Bir programcı neden otomatik testler yazmanın ek sorumluluğunu üstlenmelidir? Beyni çok daha karmaşık bir tasarım yapısını düşünebilme yeteneğine sahipken, bir programcı neden küçük adımlarla ilerlesin ki? Cesaret.

TDD, programlama sürecinde korkuyu yönetmenin bir yoludur. Sandalyeden düşme korkusunu ya da patronunun karşısına çıkma korkusunu kastetmiyorum. Yani “o kadar zor ki, henüz nasıl çözeceğimi bilmiyorum” bir sorunla yüzleşme korkusunu kastediyorum. Acı, doğanın bize "Dur!" demesidir ve korku, doğanın bize "Dikkatli ol!" demesidir. Tedbir hiç de kötü bir şey değil ama korkunun yararlarının yanı sıra üzerimizde bazı olumsuz etkileri de var:

Korku bizi şu veya bu eylemin neye yol açabileceği konusunda önceden ve dikkatli düşünmeye zorlar;

Korku daha az iletişim kurmamızı sağlar;

Korku, çalışmalarımıza ilişkin değerlendirmelerden korkmamıza neden olur;

Korku bizi sinirlendirir.

Bunların hiçbiri programlama sürecine yardımcı olmaz, özellikle de karmaşık bir sorun üzerinde çalışıyorsanız. Yani zor bir durumdan nasıl çıkılacağı sorusuyla karşı karşıyayız ve

Geleceği tahmin etmeye çalışmayın, hemen sorunla ilgili pratik bir çalışmaya başlayın;

Kendinizi dünyanın geri kalanından soyutlamayın, iletişim düzeyini artırın;

Yanıtlardan kaçmayın, tam tersine güvenilir bir yanıt oluşturun. geri bildirim ve onun yardımıyla eylemlerinizin sonuçlarını dikkatle izleyin;

(tahrişle kendiniz başa çıkmalısınız).

Programlamayı kuyudan kova çıkarmaya benzetelim. Kova suyla doldurulur, kolu çevirirsiniz, zinciri yakanın etrafına sararsınız ve kovayı yukarı kaldırırsınız. Kova küçükse, düzenli, serbest dönen bir kapak yeterli olacaktır. Ancak kova büyük ve ağırsa kaldırmadan yorulursunuz. Kolun dönüşleri arasında dinlenebilmek için kolun kilitlenmesini sağlayacak bir mandal mekanizmasına ihtiyaç vardır. Kova ne kadar ağırsa, cırcır dişlisinin dişleri de o kadar hızlı takip etmelidir.

TDD'deki testler bir cırcır dişlisinin dişleri gibidir. Testin işe yaramasını sağladıktan sonra, testin artık, şimdi ve sonsuza kadar işe yaradığını biliyoruz. Testi tamamlamaya testin yayına girmesinden öncesine göre bir adım daha yaklaştık. Bundan sonra ikinci testi çalıştırırız, ardından üçüncü, dördüncü vb. daha zor problem programcının önünde dururken, daha az işlevsellik her testi kapsamalıdır.

Kitap okuyucuları Ekstrem Programlama Açıklaması Ekstrem Programlama (XP) ile Test Odaklı Geliştirme (TDD) arasındaki ton farkını fark etmiş olabilirsiniz. XP'den farklı olarak TDD metodolojisi mutlak değildir. XP diyor ki, "ileri gitmek için şunda ve bunda ustalaşmalısınız." TDD daha az spesifik bir tekniktir. TDD, karar verme ile sonuçlar arasında bir aralık olduğunu varsayar ve bu aralığın uzunluğunu yönetmek için araçlar sağlar. “Bir haftayı kağıt üzerinde bir algoritma tasarlamaya ve ardından önce test yaklaşımını kullanarak kod yazmaya harcasam ne olur? Bu TDD uyumlu olacak mı?” Elbette olacak. Karar vermeniz ile sonuçları değerlendirmeniz arasındaki sürenin büyüklüğünü biliyorsunuz ve bu aralığı bilinçli olarak kontrol ediyorsunuz.

TDD konusunda uzmanlaşan çoğu kişi, programlama uygulamalarının daha iyiye doğru değiştiğini söylüyor. Testlerle enfekte(test enfekte) - bu, bu değişikliği tanımlamak için Erich Gamma tarafından türetilen tanımdır. TDD'de ustalaştıktan sonra, kendinizi eskisinden çok daha fazla test yazarken ve daha önce size anlamsız görünen küçük adımlarla ilerlerken bulursunuz. Öte yandan, TDD'ye aşina olan bazı programcılar, TDD'yi geleneksel programlamanın istenen ilerlemeyi sağlamadığı özel durumlar için saklayarak eski uygulamalara dönmeye karar verirler.

Yalnızca testler kullanılarak (en azından şu anda) çözülemeyen sorunlar kesinlikle vardır. Özellikle TDD, geliştirilen kodun veri güvenliği ve paralel operasyonların güvenilirliği açısından yeterliliğinin mekanik olarak gösterilmesine izin vermez. Elbette güvenlik, hatasız olması gereken koda dayanmaktadır, ancak aynı zamanda veri koruma prosedürlerine insanın katılımına da dayanmaktadır. Hafif eşzamanlılık sorunları, yalnızca bazı kodların çalıştırılmasıyla kesin olarak yeniden oluşturulamaz.

Son zamanlarda yazılım geliştiriciler
"ekstrem programlama" veya XP olarak adlandırılan popüler teknoloji. Hakkında
teorik temeller hakkında fikir veren birçok makale ve kitap yazılıyor
bu metodoloji. Bunun pratikte neye benzediğini size anlatmak isterim ve
avantajları ve dezavantajları nelerdir

Öncelikle XP nedir? İnternette birçok tanım ve açıklama bulabilirsiniz.
bu dönem. Prensip olarak, her biri az çok özü yeterince yansıtıyor
ancak tanımların çeşitliliği geliştiricinin kafasını karıştırabilir. Bu nedenle gerekli
XP'nin, ikinci plana atmak için geliştirilmiş bir dizi teknik olduğunu anlayın.
yazılım geliştirme süreci dört temel prensipler. Yani:

• iletişim;
• basitlik;
• Geri bildirim;
• cesaret.

Tipik olarak bu teknikler XP materyallerinde belirtilmiştir. İşte en çok
bunların tipik bir listesi:

• Planlama oyunu;
• Geliştirme başlamadan önce test etme;
• Çiftler programı;
• Sürekli geri dönüşüm;
• Geliştirme kolaylığı;
• Toplu kod sahipliği;
• Devam eden entegrasyon;
• Müşteri şantiyede;
• Sürümlerin hızlı yayınlanması;
• Kırk saatlik çalışma haftası;
• Kodlama Standartları;
• Sistem metaforu.

Çoğunun anlamı aynı olduğundan sadece bazı teknikler hakkında yorum yapacağım.
adından da oldukça açıktır ve literatürde ayrıntılı olarak anlatılmıştır. Bazıları
yöntemler oldukça mantıklı görünüyor, bazıları ise tam tersine şaşkınlığa neden oluyor.

Planlama oyunu Bu tekniğin fikri oldukça basittir. Geliştiriciler birlikte
müşteriler bir araya gelir ve bazı olası durumları oynarlar (
ideal olarak hayattaki bir sorunu çözerken ortaya çıkabilecek her şey. Bu tür toplantılar
her alt sistemin geliştirilmesine başlamadan önce düzenleme yapılması tavsiye edilir.
bu, geliştirme süreci boyunca düzenli olarak yapılır. Bu yapmamanıza izin verir
Sıkı bir plana göre gelişime katılın ve zamanında uyum sağlayın
Konu alanında değişiklikler.

Geliştirme başlamadan önce test etme. Gelişimin başlamasından önce olduğu varsayılmaktadır.
programın herhangi bir parçası için bir test yazılır. Bu bir takım avantajlar sağlar.
İlk olarak, bir kod parçasındaki bir değişiklik aşağıdakileri gerektirir:
başkalarındaki hatalar. Teste yönelik bu yaklaşım anında tanımlamanıza olanak tanır
bu tür durumlar. İkincisi, müşterinin testin işe yaradığını açıkça görmesi daha uygundur,
büyük hacimli belgeleri okumaktan daha iyidir. Bu yüzden test sonucu
görselleştirilmesi gerekmektedir.

Sistem metaforu. Geliştirilmekte olan ürünler veya kod parçaları aşağıdakilerle karşılaştırılır:
benzer ürünler veya olaylar. Metaforlar inşa ediliyor. Bu
Sorunun anlaşılmasını kolaylaştırır ve buna bağlı olarak gelişimi hızlandırır.

Ancak şunu da anlamalısınız ki, herhangi bir nedenle,
bu tekniklerin herhangi biri XP'nin temel ilkelerine aykırı olmaya başlar ve
Bu tür durumlar oldukça mümkündür, o zaman terk edilmelidir.

Açıkça söylemek gerekirse, anlatılan olaylar başlamadan önce ben
Ekstrem programlama konusunda genel bir anlayışa sahipti, ancak bu süreçte
Size anlatmak istediğim uygulamanın geliştirilmesine bilinçli olarak bağlı kalın
XP yöntemlerini denemedim. Ancak bana göre bu tipik bir durum
örnek XP. Her durumda olumlu bir sonuç elde edildi.

Şimdi XP yaklaşımlarının pratikte nasıl kullanılabileceğini görelim.
koşullarımız. İşyerindeki görevlerimden biri eğitimin otomasyonudur.
işlem. Aslına bakılırsa, uzun bir süre boyunca
Uygulayan bir uygulama yazıyorum (en azından tasarım gereği)
yazar :)) bu soruna kapsamlı bir çözüm. Projenin bütçesi yetersiz ve hacmi
çalışıyor - iyi. Neredeyse belirleyici olan bir diğer faktör ise sürekli
konu alanının değiştirilmesi. Raporlama formları düzenli olarak değişir
belgeler ve bunları elde etme yöntemleri. Proje durdurulduğunda bir durum ortaya çıktı
Kullanıcı gereksinimlerine ayak uydurun. Ve bir gün öyle bir an geldi ki
Objektif ve sübjektif sebeplerle, gelişme güvenli bir şekilde gömülebilir. Fakat
beklenmedik bir şekilde bana belirli bir görev verildi.
dönem için sınıf fonunun iş yükü. Bu noktada üç katılımcıdan
Projeden geriye bir tek ben kaldım ama bu alt sistem hayata geçirilmedi ve hayata geçirilmesi
projenin acil kalkınma planlarında bile yoktu. Gibi küçük şeyler hakkında
Sorunun yetkin formülasyonu, işin emek yoğunluğunun hesaplanması, tahsisi
Kimse ek kaynakları düşünmedi bile. Görevi tamamlamak için oradaydı
iki hafta süre tanınır. Aynı zamanda yerine getirilmesinin imkansızlığına ilişkin argümanlarım
bu sorun prensipte dikkate alınmadı. İlk kararım bulmaktı
kendim başka bir işverenim, çünkü iki hafta içinde sadece yazmak zorunda kalmadım
sınıf fonunun iş yükünü analiz etmek için bir modül ve aynı zamanda bir program giriş sistemi
sınıflar, kontrol katmanları ve çok daha fazlası. Bu sorun tek başına çözülemez
Prensip olarak başlangıç ​​verilerine ihtiyacımız var. Ve yalnızca orijinal veriler değil, doğru veriler de
Yukarıdaki görevlerin tamamının takip edildiği ilk veriler. Yine de,
Nedenini bilmiyorum ama bu sorunun çözümünü üstlendim.

Bu durumda klasik yöntemlerle kalkınmadan bahsetmek doğaldır.
uygunsuz. XP yaklaşımlarının işe yaradığı yer burasıdır. Görevin genel fikri
zaten vardı, ancak potansiyel olarak olabilecek birçok nüans vardı.
iş hacmini önemli ölçüde artırır. Numarayı çevirerek işe başladım
eğitim departmanı telefona cevap veren kişiyi birçok soru, cevap bombardımanına tutmaya başladı
kendi başıma bulamadığım veya emin olamadığım.
.
Rational Rose'u başlattım ve bir model oluşturmaya başladım. Çalışma gününün sonunda
Bana aşağı yukarı yeterli görünen bir model çizdim. İşten sonra ben
XP ideolojisi doğrultusunda bir adım daha attı. arkadaşımı dışarı çıkardım
bira içmek için eğitim bölümünde çalışıyorum. Bu süreçte her bakımdan önemli
Etkinliğin ilişkilerini ona anlattım, program hakkındaki vizyonumu, arayüzü ve
işin mantığı. O da ihtiyaçtan bahsetmeye başladı
Bazı yerel alt problemleri çözmek. Akşama doğru ne olduğunu daha net anladım.
hala bu proje çerçevesinde yapılması gerekiyor (artık görevin olduğundan şüphem yoktu)
ayrı bir proje olarak değerlendirilmelidir). Ancak bir tanesi daha çözülmedi
Önemli bir konu geliştirme araçlarının seçimidir. Anlatılan olaylar ne zaman gerçekleşti?
olaylar, MDA teknolojisini aktif olarak incelemeye başladım. Kısaca işin özü şudur:
uygulama kodu parçaları ve veri yapıları, aşağıdakilere dayalı olarak otomatik olarak oluşturulur:
UML modelinden geliştirme süresini önemli ölçüde azaltabilir. İçinde
Bu yazıda MDA'nın çalışma prensiplerini detaylı olarak anlatmayacağım ama istiyorum
Bu teknolojinin kullanımının tamamen
"XP'nin ruhuna" karşılık gelir. Bunun nedeni, aşağıdaki koşullardan birinin olmasıdır.
XP teknikleri başarıyla çalışacak, bu da yapılan değişikliklerin maliyetini azaltacaktır.
Uygulama geliştirmenin son aşamalarındadır. Katkıda bulunan faktörler arasında
Bunu başarmak için çeşitli yeni yöntemler kullanmak önemsiz değildir.
programlama teknolojileri. MDA'yı yeniden düzenlemenin tam olarak basitliği olduğunu not ediyorum
uygulamalar bu teknolojinin temel avantajlarından biridir. Genel olarak
Bugün oldukça fazla MDA uygulaması var, ben seçtim
Delphi için cesur.

Ancak benim durumumda birkaç "kaygan an" vardı. Öncelikle şunu fark etmek
MDA belirli faydalar sağlıyor, hâlâ yeterince emin değilim
bu teknolojiye sahipti ve MDA uygulamaları yazma konusunda neredeyse hiç deneyimi yoktu.
İkinci olarak bazı kod parçalarının sorunlu olabileceğini anladım
standart MDA araçları kullanılarak uygulanır ve yapılması gereken çok sayıda "manuel" iş vardır
Bu durumda belirli özelliklere sahip olacak kodlama”.

Alternatif "normal" bir Delphi uygulaması yazmaktı. başlattım
ICQ ve Bold taraftarı arkadaşıma bir mesaj yazdım. Benden sonra
Ona sorunun özünü kısaca özetledim, benim yerime ne yapacağını sordum.
Şöyle bir cevap verdi: “Ya doğrudan Bold'a dalın, ya da
asla ustalaşamayacaksın. Ciddi bir proje yapın - En iyi yolçalışmak
teknoloji." Aslında başka bir cevap beklemiyordum.

Sabah aldım mevcut model ve uygulamayı oluşturmaya başladık. Aynen, inşa et. İLE
Kodlamaya başlamadım, sadece taslak çizdim Kullanıcı arayüzü, birçok
unsurları neredeyse anında çalışmaya başladı. Sigara molası için dışarı çıkmaya çalıştım
eğitim departmanı çalışanlarından oluşan bir şirket, bu bana başka bir şeyi sürüklememi sağladı
Monitörünün ekranına "kurban" oldu ve (belirli bir gurur duymadan) gösterdi
ara sonuçlar. Böylece geri bildirim ilkesi hayata geçirildi.
Haklı olarak şunu söyleyebilirsiniz: "Peki ya eşli programlama?" Evet,
Aslında projede programcı olarak yer alan tek kişi bendim. Ama işte buradayım
Bir mutlu tesadüften daha bahsedeyim. Bu süre zarfında
anlatılan olaylar meydana geldiğinde, bir grup geliştiriciyle birlikte ben -
meraklıları özellikle MDA'ya adanmış bir İnternet projesi geliştirdiler. Ve işte o zaman
Gelişiminin en zor noktasına gelen bu proje,
tamamen beklenmedik sonuçlar.

Birkaç gün boyunca etkinliklerin görüntülenmesini uygulayan bir prosedür için kod yazdım
ekranda. Standart kontroller her şeyin ekranda görüntülenmesine izin vermiyordu
veriler genellikle sunuldukları biçimdedir. bunu istedim
son kullanıcı programın ne yaptığını en azından yaklaşık olarak anlıyorsa
ve onunla nasıl çalışılacağı. Kendi bileşenimi normal bir TStringGrid'e dayanarak yazdım.
Ne olduğundan emin değildim iyi karar, ancak kod işe yaradı. Forumda
Projemiz hakkında, bir tür değerlendirme almayı umarak çözümümü özetledim.
oldukça uzun bir süre boyunca. Ancak tam anlamıyla 15-20 dakika sonra geldi
ilk cevap. Önerildi Alternatif seçenekçözümler ve 10 dakika daha sonra
iki yazardan yalnızca bir değil aynı anda iki test örneği geldi. Eğer
geliştiricilerin neden bu kadar coşkuyla çözmeye başladıklarını düşünün
başkasının sorunuysa, o zaman basit bir sonuca varabilirsin. İlk olarak, onlar sadece
bazılarını bulmak ilginç evrensel çözüm, bu daha sonra olabilir
projelerinizde kullanın. İkincisi, sürecin kendisi ile ilgilendiler
iletişim. Diğer sorunların da aynı şevkle çözüldüğünü belirtmek gerekir.
çeşitli zorluk seviyeleri. Tabii ki, bu çift programlama değil
olağan anlayış. Daha ziyade bir tür vekildir, ancak yine de
avantajları. Diyelim ki ifade edilen tüm düşünce ve fikirler otomatik olarak
belgelendi ve istenildiği zaman erişilebildi.

Testler üzerinde ayrı ayrı durmak istiyorum. Kitabında tavsiye ettiği gibi
"Ekstrem Programlama" Kent Beck, testler önceden yazılmalıdır. Daha
Üstelik yazar için şöyle bir şeye benziyor. Özel bir program var
düğmelerden birine tıkladığınızda geliştiricinin kendisi tarafından yazılmıştır
tüm testler başlatılır ve sonuç olarak ekranda yeşil bir "ışık" belirir
Olumlu sonuç olması durumunda kırmızı, aksi halde kırmızı. Bu benim tarifim
biraz cesaret kırıcı. Katılıyorum, nasıl olduğunu hayal etmek zor
kesinlikle her durumda kullanıcı eylemlerini simüle eden bir program yazabilirsiniz.
durumlar.

Daha önce de söylediğim gibi, aşırı yöntemlere sıkı sıkıya bağlı kalmaya çalışmadım.
programlama. Ve okuduğum kitaplarda açıkça belirtiliyordu ki
Test yazmak XP'deki en önemli noktalardan biridir ve o olmadan geri kalanı
teknikler işe yaramamalı. Sonunda neden olumlu bir şey başardım?
sonuç? Her şeyin oldukça basit olduğu ortaya çıktı. Bu soruyu cevaplamama yardımcı oldu
yeşil ve kırmızı ampullerle tam olarak bu örnek. Mesele şu ki Kalın harflerle
uyup uymadığını göstermek mümkündür bu nesne modeller. VE
Bu tam olarak bu tür "ampullerin" yardımıyla yapılır. Kelimenin tam anlamıyla iki satır
neredeyse anında uygulama koduna eklediğim, hangisinde olduğunu görmemi sağladı
tutarsızlığın ortaya çıktığı yer (varsa). Değiştirilen şey bu
test ediyorum. Bu yaklaşımın tamamen tutarlı olmaması mümkündür.
Orijinal "geliştirmeden önce test etme" fikri ama işe yaradı.

Bir hafta içinde neredeyse tamamlanmış bir başvurum vardı. İkinci sırada
Haftalar sonra, işlevselliği ciddi şekilde genişlettiğim iki versiyon daha yaptım ve
ayrıca iş için gerekli verilerin çoğunu başka ülkelerden içe aktardı
çalışma sistemleri. Sorun çözüldü ve büyük ölçüde kullanım nedeniyle
XP teknikleri. Yukarıdakilerin hepsinin anlamını sadece bu örneğin şu gerçeğinde görüyorum:
Uygulamada aşırı programlamanın verimliliğini kanıtladı.

Sonuç olarak bir noktaya daha değinmek istiyorum. Aşırı Programlama,
bence her derde deva değil. Ve onun yöntemleri çok uzaklara uygulanabilir.
herhangi bir proje için. Prensip olarak, bazı işaretlere göre değerlendirilen proje
tam olarak XP kullanımının tavsiye edilmediği projeler kategorisine girdi.
Ancak daha esnek bir yaklaşımla ekstrem tekniklerin kullanılması
programlama oldukça şaşırtıcı sonuçlar getirebilir. Okurken
yerli okuyucular için bu konuya ayrılmış yabancı yazarların kitapları
XP tekniklerinin prensipte kullanılamayacağı düşünülebilir.
koşullarımız. Ve bu sadece geliştiriciler ve
Müşterilerin yanı sıra kitaplarda açıklanan geliştirme ekibindeki ilişkiler
örnekler biraz farklı ilkelere dayanmaktadır. Bu daha çok farklılık meselesi
zihniyet. Ancak XP'yi koşullarımıza uyarlamak oldukça mümkün ve bu
çok etkileyici sonuçlar veriyor.

http://xprogramming.com.ua/ - dünya
aşırı programlama

http://www.xprogramming.ru/ —
Rusça aşırı programlama

http://www.maxkir.com/ - geliştirme hakkında
yazılım

http://xprogramming.com/ - web sitesi
XP ideologu Ron Jeffries