Üniversite öğrencileri ile bir gelişim süreci nasıl uygulanır


9

Bir yazılım geliştiricisi olarak ilk işimde, ekibim proje iş akışımızı yönetmek için çevik / scrum kullandı ve oldukça iyi çalıştı. Beni doğru yola sokan tecrübeli rehberlerim vardı - onlara büyük bir minnet borcum var. Orada birkaç yıl çalıştım, sonra birkaç ay önce yeni bir fırsata geçtim.

Şu anki işime hızlıca sarıl. Bir üniversitede profesör olarak çalışıyorum. Bir üniversitede olduğum için, neredeyse her programcı bir öğrencidir (ucuz ve bol miktarda!) Patronumun yönetim tecrübesi var, ancak yazılım geliştirme ile değil, yazılım ekibi her zaman patronumun zihninde ön planda değil . Bu koşullar, çok düşük kaliteli bir yazılım oluşturmak için mükemmel ortamı yaratmıştır . Yazılım projeleri biraz hileli çalışıyor, tasarlamayı düşünmüyor ve gerçekten korkutucu uygulamalar gerçekleştiriyor. İşlerin daha iyi olabileceğini biliyorum.

Herkesin yoluna girmesine, kod kalitesini artırmasına ve daha kararlı bir yazılım kullanmasına yardımcı olacak bir geliştirme süreci uygulamak istiyorum. Nereden başlayacağımdan emin değilim.

Ben am değil "Çevik bir göz atın!" "Set kanban kurulu yukarı", "Use Scrum" gibi cevaplar için, demek başına, arayan veya (fikirler takdir edilmesine rağmen). Daha spesifik olarak, bu çalışma ortamı için bir geliştirme sürecinin nasıl uygulanacağı konusunda fikir sahibi olmayı umuyorum . Çalışanlar genellikle devam etmeden 1 ila 2 yıl önce çalışır, genellikle deneyimsizdir ve herkesi içeren günlük stand-up toplantıları zamanlamak neredeyse imkansızdır.

Böyle bir işyerinde kalite, verimlilik ve iletişimi nasıl teşvik eder?

Güncelleme: Bazı cevapları ve yorumları okuduktan sonra, ek bir arka plan sağlayacağımı düşündüm.

Kendimi yazılım geliştirme sanatında usta düşünün olmaz, ama ben değilim Görünce kötü programlamayı tanımak için yeterli deneyimli. Bir geliştiricinin onlarla çalıştıktan sadece bir iki dakika geçtikten sonra yetenekli olup olmadığını belirleyebilirim. Bir problemi akıllıca çözmenin bir yolunu bulmak için kendi yeteneklerimden rahatım , ancak gerçekten deneyimden yoksun olduğum alan, diğer geliştiricilerin dahil olduğu proje yönetimi (bu yüzden burada hepinizden harika insanlardan tavsiye).

Bu ofise gelen her öğrencinin tam bir dimwit olduğu gibi ses çıkardım. Burada bazı kötü yumurtalar vardı, ancak tanıştığım öğrencilerin çoğu zeki, öğrenmek istiyor ve çalışma hakkında tutkulu. Bazıları daha yeni başlıyor ve ne bilmediklerini bilmiyorlar. Ve sorun değil. Programlamaya ilk başladığımda daha iyi değildim!


Geliştiriciler kendi KG'lerinden sorumlu mu?
svidgen

Bir proje ortaya çıktığında, geliştiricilere bir dizi gereksinim verilir ve bu noktadan sonra her şey onlara kalmış. Yani, geliştiricilerin kendi Soru-Cevaplarından sorumlu olup olmadıklarını sormak, bir çocuğa silah vermek ve çocuğun silahın güvenli bir şekilde kullanılmasından sorumlu olup olmadığını sormak gibidir.
darksinge

Yarı zamanlı öğrenci geliştiricilerinden oluşan bir ekipten bahsettiğimizi sanıyorum? Ya sen? ... Takımda tam zamanlı veya kıdemli geliştiriciler (> = 10 yıllık deneyim) var mı?
svidgen

Uzaktan çalışan birkaç tam zamanlı geliştirici var, ancak onları çok fazla görmüyoruz (veya hiç). Ofiste, evet, çalışanların hepsi yarı zamanlı öğrencilerdir. Şu anda tam zamanlı çalışıyorum, ancak yakında bir Master programı başlatıyorum, bu değişebilir;) 5 yıllık tecrübem var, çok fazla proje yönetimi deneyimi değil.
darksinge

Henüz tam bir cevap için zamanım olmadı. Ancak, göz önünde bulundurulması gereken bir şey var: Yaklaşık 20 yıldır kod yazıyorum. Profesyonel ortamda en az 10 yıl, diğer oldukça üst düzey insanlar arasında. Deneyimli yazılım geliştiricilerin "iyi" ve "kötü" kod dediği çeşitlilik çok büyüktür . İyi bir ilk adım deney teşvik edildiği sınırlarını sağlayacak bir şekilde kod "iyi" ya da "kötü" kılan dile olabilir, yaratıcılık ve yenilik ödüllendirilir ve sizin deneyim ve görüşler değerli olarak kabul etmekle birlikte, sonuçta edilir sınırlı .
svidgen

Yanıtlar:


4

Bir hatayı temizlemek, ön kontrolü yapmaktan daha uzun sürer. (Muhtemelen) vasıfsız veya iyi uygulamadan habersiz olan geliştiricilerle uğraşıyorsanız, kodları deneyimli biri tarafından incelenene kadar (ana) kod tabanını değiştirememeleri gerektiği anlamına gelir.

Metodolojilerin bir açıklamasını istemedin, bu yüzden bu kısmı gözden geçirmeme izin ver: bağımsız olarak geliştirilebilecek farklı özellikler oluşturmak için çevik görevleri kullan.

Özellik dallarını kullanmaya başlayın, böylece herkes ayrı bir dalda çalışır. Bir görev tamamlandığında, geliştirici kodlarını ana dalla birleştiremez. Git kullanıyorsanız, yine de bir çekme isteği başlatabilirler. Aksi takdirde, süslemenizi alan bitmiş görevleri (/ dalları) izlemek için herhangi bir yöntemi kullanın.

Sonra inceleme sürecine geçiyoruz . Sorunuz biraz belirsiz, yargısının öğrencilerinkinden daha fazla güvenilebilecek deneyimli geliştiriciler olup olmadığıdır. Öyleyse her iki şekilde de açıklayayım:

Deneyimli geliştiriciler varsa, bitmiş görevlerin kodunu gözden geçirerek onlara görev verin. İyiyse, ana dalda birleştirebilirler. Değilse, kendileri yeniden düzenleyebilir veya geliştiriciye neyin iyileştirilmesi gerektiği konusunda geri bildirimde bulunabilirler.

Deneyimli geliştirici yoksa, her zaman sorunlarla karşılaşacaksınız. Kötü koddan iyi kodu tespit edecek kimse yoksa, kod kalitesini korumak mümkün değildir.
Yapabileceğiniz en iyi şey, geliştiricilerin diğer geliştiricilerin önünde uygulamalarını sundukları ve açıkladıkları inceleme toplantıları yapmaktır . Bu, her sorunun önlenmesini garanti edemese de (örneğin, tüm geliştiriciler iyi uygulama hakkında aynı yanlış anlama sahip olsalar da, sorunların çoğunu yine de önleyecektir (örneğin, en az bir geliştiricinin doğru fikri varsa ve bunu dile getirebileceği durumlarda; veya sorun kaynaklanıyorsa) sorunu birbirinden farklı olarak anlayan geliştiricilerden)

Böyle bir işyerinde kalite, verimlilik ve iletişimi nasıl teşvik eder?

  • Kalite - Kodu deneyimli geliştiriciler tarafından gözden geçirin. Deneyimli geliştiricilerin yokluğunda, en azından üslerinizi olabildiğince iyi kapsayacak şekilde grup incelemesi yapın.
  • Verimlilik - Bağımsız görevleri doğru ayarlarsanız, birbirlerini beklemek zorunda olan kişileri en aza indirirsiniz. Herkesin aynı anda bulunmadığı bir ortamda, birçok "A kişisini beklemek" gecikmeleriyle uğraştığınızı varsayıyorum. İlerleme yapmayan geliştiricileri takip edin, sadece yardıma ihtiyaç duyup duymadıklarını kontrol etmek ve hatta sadece hayal kırıklıklarını gidermelerine izin vermek (bu hayal kırıklıkları önlenebilir sorunlar hakkında yanlış anlamaları ortaya çıkarabilir).
  • İletişim - Geliştiricilerin birinden yardım, geri bildirim veya ilham isteyebilmesi için açık bir kapı politikası belirleyin. Nitelikli bir akıl hocası olmadığında, takım etkileşimini kolaylaştırmaya çalışın (elbette bunu akıl hocanız olsa bile yapabilirsiniz, ancak akıl hocası olmadığında bunu yapmanın önemi artar). Özellikle insanların uzaktan ve farklı programlarda çalıştığı bir durumda, geliştiriciler genellikle iş arkadaşlarına yakın değildir ve kendi aralarında iletişim kurma eğilimindedir. Bir avuç sosyal toplantı bile, diğer zamanlarda işle ilgili iletişimi geliştirmek için harikalar yaratabilir.

Bazı iyi cevaplar vardı, ama bu en kapsamlı ve doğrudan oldu, teşekkürler!
darksinge

1
Bu yakın ama tam olarak orada değil. Ben kod değerlendirmeleri ile katılıyorum ama deneyimli geliştirici ile tutkuyla katılmıyorum düzeltmeleri yapıyor bu özensiz kodlayıcılar temiz olabilir daha hızlı çalışma ile deneyimli kodlayıcı bataklık son derece kötü bir geribildirim döngü kurar. İncelemeleri orijinal kodlayıcıya geri göndermek ve işi yapmalarını sağlamak çok daha iyi. Bu, onlara nasıl daha iyi kodlanacağını öğretme amacına ulaşır, ancak aynı zamanda özensiz kodlayıcıları, kabul edilebilir bir standarda yazılım üretene kadar yeniden işleme sokarak yavaşlatma avantajına sahiptir.
mcottle

@mcottle Hiç yapmadığım bir noktaya karşı koyuyorsun. Yeniden düzenleme sabitleme ile aynı şey değildir. Kod çalışmazsa, dediğin gibi geri gönderilmesi gerekir. Sorun küçük bir stilistik argümansa, geliştiriciye geri dönmek hala önemlidir, ancak bazen ayrıntılı olarak açıklamak yerine sorunu düzeltmek daha kolaydır. Ne demek istediğini görmek böylece aldatıcı gelişmiş kod gösterebilirsiniz yararına sahiptir.
flater

8

İnsanların yeni ve ayrılma ihtimali olan ortamlar için en büyük şey zorunlu kod incelemeleridir.

Ne yapılması gerektiği konusunda bilginin yayılmasına yardımcı olurlar. En kötü kodun kod tabanına girmesini önlemeye yardımcı olurlar. Uygulamada tutarlılığı teşvik ederler.

Çünkü bu kadar ciro ve deneyimsizlikle iletişim , genellikle olduğundan daha önemlidir.


2
Aslında bu konuda biraz şüpheliyim. Kod incelemelerinin gerekli olması gerektiği konusunda aynı fikirde değilim ... Ancak, OP'nin diğer clueless geliştiricilerden geri bildirim isteyen bir grup clueless geliştiriciden bahsediyorsunuz - OP'nin her şeyi gözden geçirmek ve yorum yapmak için zamana sahip olmadığını düşünmüyorsanız . .. Demek istediğim. Belki de o kadar zorlanmış değil. Giriş akışına bağlıdır. Ancak, "kod incelemeleri" çözümün dörtte birinden fazlası gibi görünmüyor. Yani en iyi.
svidgen

@svidgen: Diğer clueless geliştiriciler tarafından yapılan yorumları savunduğunu sanmıyorum. Hiçbir zaman açıkça belirtmedi (bu yüzden her iki şekilde de gidebilir), ancak tecrübelerime göre, incelemeler deneyimli meslektaşları veya zincirdeki insanlar (kurşun geliştirici) tarafından, özellikle bazı geliştiricilerin yeteneklerinin sivilceli veya kanıtlanmamış.
flater

1
@svidgen - başlangıçta lider tarafından yapılması gerekebilir, ancak bir tekne yükü veya clueless geliştiricilere sahip olmak sorun. Bunu, cahil olmayan bir şey yapmadan çözemezsiniz. İdeal olarak, onu alan ve daha az kritik olan şeyler üzerinde kod incelemeleri gerçekleştirmeye yardımcı olabilecek birkaç geliştirici olacaktır.
Telastyn

2

Bir çözümden daha çok bir fikir, ancak kod tabanının öğrenci geliştiricilerinizin yapabileceği projelere benzer özellikler ve öğeler içeren kritik bir bölümünü bulun ve ÇOK iyi temizleyin. Yeni geliştiricilerle ilgili büyük bir sorun, kod tabanının normlarını ve kurallarını bilmemeleri ve kendi kodlarını nasıl kuracakları hakkında bir fikir edinmek için diğer koda bakacaklarıdır. Dağınık bir kod tabanında çalışan birçok yeni geliştiriciye sahip olmak, karışıklığı görecekleri ve bunun kabul edilebilir veya bir şeyler yapmanın en iyi yolu olduğunu düşünecekleri anlamına gelir. Kötü uygulamalar daha sonra çevrimi yüksek bir çevrede bile devam eder.

En az bir bozulmamış, iyi yazılmış bir kod bölümüne (veya sadece bir dosyaya) sahip olarak, öğrenci geliştiricilerinize bunu en iyi uygulamaların bir örneği olarak kullanmasını söyleyebilirsiniz. Onlara benzer bir kod yazabilirlerse heyecanlanacağınızı ve diğer kodun çoğunun doğru şeyler yapmanın iyi bir örneği olmayabileceğini söyleyin.

İşlerin neden belirli bir şekilde yapıldığına dair bir açıklama ile yorum veya başka belgeler eklemek, yeni geliştiricilerin daha iyi kod uygulamalarıyla daha hızlı hızlanmasına yardımcı olacaktır.


2

Sürekli Entegrasyon -

Bu, takım araçlarının, becerilerinin ve süreçlerinin artımlı ve esnek bir şekilde uygulanması için pratik ve kavramsal bir çerçevedir.

CI, kod yazmadan konuşlandırmaya kadar bir iş akışı fikridir. Bu görevler kavramsal ve aslında bağımsızdır.

CI özellikle otomasyondur. Bunun, kodun ekranda yazıldığı noktadan başlayarak kalite ve üretkenlik üzerinde derin etkileri vardır.

  • CI görev uygulaması bağımsız, ayrıntılı ve eşzamanlı olarak ele alınabilir. Odak gerektiğinde kayabilir.
  • Çorbadan fındık CI aracını tanıtmayın
    • Hepiniz süreç dikkatinizi dağıtacak ve kapsüllenmiş görev becerilerini beyazlatır.
  • Kova esasına göre bir şeyleri tanıtın
  • Tam zamanlı değişim aracısı olmasını bekleyin. Lider olun; sadece bir yönetici değil, sadece kıdemli kodlayıcı değil.

  • Stratejik olun

    • CI'nın Kutsal Kâsesi, dağıtım otomasyonu için bir derleme, derleme. Dokunamazlarsa FUBAR yapamazlar.
    • Eğitim ve öğretim materyalleri.
      • Belge işlemleri.
      • Bir Programcı Kılavuzu oluşturun , organik olarak gelişmesine izin verin.
      • Zorunlu.
      • Keşif, belirli becerileri ve kod tabanının kendisini hedefliyor.
    • Aşağıdaki gibi profesyonel programcı değerleri girin:
      • TDD kesinlikle kalite yaratır
      • Kod incelemeleri tüm eserleri içerir: yorumlar, yorum yapılan kod, birim testleri vb.
      • "Kaç tane hata bulunduğuna utandım"
      • Nesnellik, kişisel kod sahibi olma duygusu ve sahibini "rahatsız etme" korkusuyla boğulmaz.
  • Taktik olun

    • Ayrık CI görevleri otomatikleştirilebilir, örneğin derleme ve birim testlerini tetikleyen bir sürüm kontrol taahhüdü.
    • Kod biçimlendirme gibi otomasyon tarafından zorlanan kurallar.
      • Çok fazla bilgiç minutiye dikkat edin. Araç göz ardı edilmeye başlanacaktır. Kural zorlamayı ezici olmayacak şekilde değiştirin.
    • Test Odaklı Geliştirme'yi hemen uygulayın
    • Her değişikliğe öncelik verin ve vurgulayın
      • Temel bilgi ve beceri sıçramalarının gerçekleştiğini varsaymayın.
    • Uygun uygulamayı bozma aciliyetine izin verme
    • Değişime öncülük et ve takip et
      • Yeni adam oryantasyonu ve biraz asgari eğitim gereklidir.
      • Yeni şeyler için açık eğitim ve açık rehberlik
      • En azından minimum, standart standartlara göre eğitim alın. Gerçek bir resmi olmak zorunda değildir, ancak YouTube'da rastgele bir yürüyüş yapmak eğitim değildir. Şahsen doğrulayın - tekrar formaliteden kaçının.
    • Kod denetleyici olun, tüm kodu inceleyin.
      • Zorlu hata düzeltmelerini açıkça yönlendirin ve dikkate değer öğrenme deneyimlerini paylaşın.
    • Sert esneklik. Üzgünüm, söylemek zorundaydım. Ama gerçek bu.
  • Kültür yaratın
    • Profesyonel beklentileriniz var
    • Araçları standartlaştırma
    • Üretim metrikleri üzerinden öğrenmeyi vurgulayın
    • Mentor olun
    • Değişim getirilirken, sadece bireylerin “bunu yapmak için” inisiyatifine bağlı olarak takım gelişimini incelikli bir şekilde yıkar. Uyumlu bir ekibin kimliği ortak olanı içerir: araçlar, bilgi ve beceri seviyesi. Karşılıklı saygı, her üyenin tezleri değerli değerler olarak kabul ettiği ölçüde büyür. Takım lideri modeldir, kaçınılmazdır; "ne olursa olsun" bir tutum ve beklenti modellemeyin.

Kaliteye Giden Yol

  • Birim testi

    • Geliştirilmiş Testi Test Etmenin Anahtarı
      • Bununla ilgili bütün kitapları okumak gerekli değildir
      • Bu haline gelmelidir kodlama paradigma
      • Lider olarak herkes "birim iman sıçramasını" yapana kadar ona devam etmelisin. Bu paradigma değişimi, "Kodun iki katı yazıyorum!" harika üretkenliğini benimsemeye
    • Mağazamızda birim testi zorunluydu. Ama birçoğu bunu yapmadı çünkü istemiyorlardı. Yönetimin mahkumiyet eksikliği, birim testlerinin gerçekten işe yaramadığı mesajını gönderdi.
  • Sürüm kontrolü

    • İlk önce bunu yapardım ama birim teste başlamak daha kolay
    • sürüm kontrolü çok kolay olmadığı için diğer girişimleri geciktirmeyin
    • Bir sürüm kontrol planı yapın.
      • Yazmalısın.
      • "Her şeyi gövdeye at ve dallanma yok" kadar basit olsa bile bunu yap.
  • Kod İncelemeleri

    • Bu, kod kalitesini ayrıntılı olarak geliştirme potansiyeli en yüksek olanıdır.
    • 2 inceleme işlemi kullanın.
      • 2 Bir daha gözden geçirme kaç hata yakaladı çok şaşırdım.
      • Güven ama doğrula. Kodu çalıştırın. Bunu neden söylemek zorundasın ki? Hemen yukarıya bakınız.
      • Başlangıçta tek gözden geçiren siz olacaksınız. Ekibin "canlı" olarak izlemesini sağlayın. Başka türlü düşünmeyi asla öğrenemezler.
      • Yakında sadece ikinci gözden geçiren olacaksınız. Bireysel beceriler gerektiğinde bunları gözden geçirin; sonunda her iki gözden geçiren. Elbette istisnasız olarak koda her zaman bakacaksınız.
  • üstlenmeden

    • Bu belirgin, resmi bir disiplindir.
    • Yeniden düzenleme: Martin Fowler tarafından mevcut kod tasarımının iyileştirilmesi
      • Uyarılmış hatasız kod değişikliği sağlayan kodlanmış yeniden düzenleme tarifleri.
      • Bu kitapla profesyonel bir kütüphane başlatın.
    • Formalite bir yana, kod incelemeleriyle ad hoc'u tanıtın
  • Ortamınızı yakalayın

    • Temel araç yapılandırmaları: sürüm kontrolü, IDE, CI aracı, OS vb.
    • Kaynak kodu, dokümantasyon, konfigürasyonlar sürüm kontrolünde senkronize edilmelidir.

Süreç Hakkında Bir Söz

Çevik (ve Scrum gibi alt türleri): Unut. "Sen çeviksin, çevik değilsin." Bunları Agile Manifestosunun orijinal imzalayıcılarından Dave Thomas tarafından görün .

Küçük, deneyimsiz takımlar göz önüne alındığında, Visual Studio Team Services gibi takım entegrasyon araçlarını gördüğümde spidey duygum söner. Deneyimlerim burada sınırlı, ancak güçlü, gereksiz, katı süreç dayatması hissediyorum. Birçoğunun bu şeyleri büyük bir etki için kullandığını biliyorum, ancak potansiyel olarak bir sorun arayan bir çözüm satın almaya dikkat edin.


Araçlar Hakkında Bir Söz

Benim. O "Şimdi en iyi yazılım araçları ..." değil tıklayın yem bal kapları.

Jenkins

Bir CI entegrasyon aracı. Web tabanlı, yaygın olarak kullanılır. Temel olarak, bir web GUI aracılığıyla derleme, birim testleri çalıştırma, sürüm kontrolünü güncelleme gibi çeşitli görevleri ve yürütme sırasını özel olarak yapılandırır ve otomatikleştirirsiniz. Çok A-La Carte olduğundan, yeni başlayan CI ortamınıza uygundur.

Sürüm Kontrolü

Git yerine Mercurial'ı tercih ederim. Bu blog yazısı neden Mercurial'ı seçtim: Git MacGyver, Mercurial James Bond

İntikam iyidir. Mercurial & Git Subversion'dan daha farklı bir mimariye sahiptir.

Entegre geliştirme ortamı

Herkes farklı kodlama araçları kullanıyorsa, büyük bir yağ düşüncesi: Düz Metin Olarak Böyle Bir Şey Yok


Profesyonel Kütüphane Hakkında Bir Söz

İnternet geniş, sığ ve düzensiz.

  • Kod Tamamlandı Steve McConnell
    • Herkesi ortadaki üçüncü okumayı yap.
    • Önerilen profesyonel kitapların bir ekine sahiptir.
  • Yeniden düzenleme: Mevcut kod tasarımının iyileştirilmesi
    • Uyarılmış hatasız kod değişikliği sağlayan kodlanmış yeniden düzenleme tarifleri.
  • Yazılım Hataları. Özel bir öneri yok ama bir inceleme karşısında hikayeler olmalıdır.

0

süreçlerinizi yönetmek için başka bir metodoloji kullanmayı öneriyorum çünkü söylediğiniz gibi toplantıları planlamak imkansız (scrum için kesinlikle önemlidir!). İyi bir konsept yapmak için hala kötü bir şey yok, bu yüzden herkes neler olduğunu biliyor (muhtemelen dikey bir prototip de kullanıyor) ve şelale modeli kullanıyor. Her iki durumda da iletişim işin en büyük parçasıdır.


1
dikey prototip nedir; cevabınızı genişletmeyi düşünebilirsiniz.
esoterik

Üzgünüm, bu sabah çok az zamanım vardı. İlk olarak, bir [dikey prototip] (tutorialspoint.com/sdlc/sdlc_software_prototyping.htm), herhangi bir işlevsellik uygulamadan yazılımınızı tamamen oluşturduğunuz anlamına gelen bir prototip türüdür. Avantajları, öncelikle söz konusu müşterinin ürünün neye benzeyebileceğini görebilmesidir, ikincisi, geliştiriciye "olması gereken" işlevsellik / sağlaması gereken veriler hakkında iyi bir fikir vermesidir.
gkhaos

"oldukça kısa" ile ne demek istiyorsun? Proje yönetimi türünü belirlemek oldukça zordur, çünkü projeniz ne hakkında gibi çeşitli şeylere bağlıdır? Ekibiniz ne kadar büyük? Ayrıca scrum'da scrum hakkında derin bilgiye sahip olması gereken scrum-master'a ihtiyacınız vardır. Scrum'ın proje yönetimine tek cevap olmadığını düşünmeye çalıştım.
gkhaos

0

Henüz yapmadıysanız kaynak kontrolünü kullanmanızı öneririm. Bu, her geliştirici tarafından nelerin kontrol edildiğini görmenize ve bir hatanın nereye sokulduğuna gerilemeye izin verir.

Bir çeşit test paketi kurarım. Bu, yürüttüğünüz her işlev için testler yazdığınız test odaklı geliştirme olabilir veya uygulamalarınızı çalıştırmak ve sonuçları istenen ile karşılaştırılabilecek bir dosyaya göndermelerini sağlamak için otomatik bir yol olabilir. çıktı. Bu, her taahhütten sonra yapılırsa veya her gece en az bir kez yapılırsa, regresyonları hızlı bir şekilde bulacaksınız.

Yapacağım son şey 2 politika uygulamaktır: 1) tüm yapıların hatalara ayarlanmış uyarılara sahip olması ve tüm hataların açık olması gerekir 2) Tüm kodlar, herhangi bir hata veya uyarı üretmeden önce statik analizörden geçmelidir. Bunu bir ön taahhüt eylemi bile yapardım. Bu 2 şey, kodun birkaç yaygın yolla hızla korkunç olmasını önleyecektir. (Her şeyi yakalamazlar, ama çok yakalarlar.)

Bu aynı zamanda öğrencilerinizi "gerçek dünyada" nasıl olacaklarına hazırlayacak ve bunlara makul derecede iyi alışkanlıklar kazandıracaktır.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.