Kovboy kodlama - Cowboy coding

Kovboy kodlama dır-dir yazılım geliştirme programcıların olduğu yer özerklik geliştirme süreci boyunca. Bu, projenin zamanlamasının, dillerinin, algoritmalarının, araçlarının, çerçevelerinin ve kodlama stilinin kontrolünü içerir.

Kovboy kodlayıcı, yalnız bir geliştirici veya minimum süreç veya disiplinle çalışan bir grup geliştiricinin parçası olabilir.[kaynak belirtilmeli ] Genellikle, işletme kullanıcılarının çok az katılımı olduğunda veya geniş hedefler, zaman çizelgeleri, kapsam ve görseller ("nasıl" değil, ancak "nasıl" değil) projenin yalnızca geliştirme dışı yönlerini kontrol eden yönetim tarafından teşvik edildiğinde ortaya çıkar. ").[kaynak belirtilmeli ]

"Kovboy kodlaması" yaygın olarak kullanımı bir aşağılayıcı daha yapılandırılmış ile karşılaştırıldığında terim yazılım geliştirme metodolojileri.

Dezavantajları

Kovboy kodlamasında, biçimsellik eksikliği yazılım proje yönetimi metodolojiler bir projenin küçük boyutunun veya deneysel doğasının göstergesi olabilir (zorunlu olmamakla birlikte).[1] Bu özelliklere sahip yazılım projeleri şunları gösterebilir:

Serbest bırakma yapısının olmaması

Eksiklik tahmin veya uygulama planlaması bir projenin gecikmesine neden olabilir. Ani son tarihler veya yazılımın yayınlanması için yapılan baskılar, daha sonra daha fazla dikkat gerektiren "hızlı ve kirli" tekniklerin kullanılmasını teşvik edebilir.[2]

Deneyimsiz geliştiriciler

Kovboy kodlaması, geliştiricilerin başlangıçta test etme, sürüm kontrolü ve / veya araç oluşturma gibi teknolojilere aşina olmadıkları hobi veya öğrenci düzeyinde yaygın olabilir, genellikle bir yazılım projesinin gerektirdiği temel kodlamadan daha fazlasıdır.

Bu, öğrenme için gereken sürenin hafife alınmasına ve geliştirme sürecinde gecikmelere neden olabilir. Tecrübesizlik, kabul edilenlerin göz ardı edilmesine de yol açabilir standartları, proje kaynağının okunmasını zorlaştırır veya aralarında çatışmalara neden olur. anlambilim dil yapıları ve bunların çıktılarının sonucu.[3]

Belirsiz tasarım gereksinimleri

Özel yazılım uygulamaları, kanıtlanmış bir geliştirme döngüsü kullanırken bile, istemciyle gereksinimlerle ilgili sorunlar yaşayabilir. Kovboy kodlaması, gereksinimleri makul bir zaman çizelgesine ölçeklendirmeyerek bu sorunu vurgulayabilir ve proje tamamlanmadan önce kullanılmayan veya kullanılamaz bileşenlerin oluşturulmasına neden olabilir. Benzer şekilde, daha az somut müşterileri olan projeler (genellikle deneysel projeler, bkz. bağımsız oyun geliştirme ) kodla başlayabilir ve asla tasarım gereksinimlerinin resmi bir analizi olamaz. Tasarım analizi eksikliği, yanlış veya yetersiz teknoloji seçimlerine yol açabilir ve muhtemelen geliştiricinin Liman veya projenin tamamlanabilmesi için yazılımlarını yeniden yazabilirler.

Eksiklik

Gibi birçok yazılım geliştirme modeli Aşırı Programlama, yazılımın her yinelemenin sonunda serbest bırakılabilir olması gerektiğini vurgulayan artımlı bir yaklaşım kullanın. Yönetilmeyen projelerde çok az olabilir birim testleri ya da tamamlanmamış bir projeyi kullanılamaz bırakarak yinelemelerin çalışılması. Bu nedenle, çevik metodolojiler kovboy kodlamayla karşılaştırılmıştır ancak çevik, resmi süreçlere, prosedürlere, ölçümlere, proje yönetimine ve diğer denetimlere sahipken, kovboy kodlamasında bunların hiçbiri yoktur.[4][5]

Avantajları

  • Geliştiriciler, deney yapmayı, öğrenmeyi ve sonuçların serbest dağıtımını teşvik edebilecek serbest biçimli bir çalışma ortamı sağlar.
  • Geliştiricilerin, tasarım sınırlamalarını ve kusurlarını çözmek için mimari ve / veya katmanlı sınırları aşmasına olanak tanır.
  • Mimarileri tartışmak, şartnameleri yazmak ve kodu gözden geçirmek zaman aldığından, tek bir geliştirici (eğer yeterliyse) kovboy kodlamasıyla iyi çalışan bir uygulamayı daha hızlı üretebilir. Araştırma veya prototipleme gibi görevler, daha karmaşık yöntemlerin sağladığı kod kalitesini gerektirmeyebilir.
  • Kodlama, geliştiricinin boş zamanlarında yapılabildiğinden, aksi takdirde olmayacak bir proje meyve verebilir.[6]

Ayrıca bakınız

Referanslar

  1. ^ Hughes, Bob ve Cotterell, Mike (2006). Yazılım Proje Yönetimi, sayfa 283-289. McGraw Hill Education, Berkshire. ISBN  0-07-710989-9
  2. ^ "Şelalenin Savunmasında: Çevik Manifesto'nun Yapısızlaştırılması" (PDF). Alındı 1 Şubat, 2016.
  3. ^ "StickyMinds - STAREAST 2000: Kodlayan Kovboyun (Kurtarıcı) İtirafları". StickyMinds. Alındı 2 Şubat, 2016.
  4. ^ "Çevik Gelişimi Keşfetmek". Pragmatik Yazılım Bülteni.
  5. ^ "StickyMinds - Yalnızca Yazılımı Kırmayın. Yazılım Yapın". StickyMinds. Alındı 2 Şubat, 2016.
  6. ^ K, Alex. "Google'ın" yüzde 20 süresi "iş başında", Resmi Google Blogu, 18 Mayıs 2006

Dış bağlantılar