Hızlı prototip oluşturma ve yeniden düzenleme


9

Bazen küçük bir projeye başladığımda (bir android uygulaması gibi), sonunda hangi yaklaşımın işe yarayacağını bilmiyorum ve sadece bir yaklaşım için gidip deniyorum. Ancak bu yaklaşımı daha önce hiç kullanmamışsam (daha önce hiç programlamamış olduğum bir tür uygulama için), bilinmeyen araziye adım atmak gibidir. Hangi kütüphaneleri kullanacağımı bilmiyorum (belki birkaç kütüphaneyi denemek zorundayım) ve çok sayıda unkonwns var (örneğin: android'de ham ses verisi nasıl alınır)

O zaman geliştirme sürecim şöyle gider:

  • Yaklaşımın bir şansı olup olmadığını görmek için bir parça kod yazın. (Yaklaşım ne kadar belirsiz olursa, kod çirkinleşir)
  • Çalışırsa, güzel olana kadar çok refactor

Bu noktada yazılım tasarımımı ayrıntılı olarak planlamam zaman kaybı olabilir, harita olmadan bir seyahat planlamak gibi olurdu.

Bu aglie gelişiminin bir parçası mı? Yazılım geliştirmede bilinmeyen arazi ile nasıl başa çıkıyorsunuz?


Temiz Kod 2'de bu kitaba inanıp inanmamanıza bağlı olarak yinelemeli gelişim aracı olarak bahsedilmektedir.
Rig

Yanıtlar:


11

Bunun çeviklikle bir ilgisi yok, ama insanlar bunun bir tür varsayıyor çünkü Agile'ın böyle olduğunu düşünüyorlar; hippi komününde başsız tavuk gelişimi.

Yaptığınız şey teknolojiyi değerlendirmektir çünkü şu anda bir karar araması yapmak için yeterli deneyime sahip değilsiniz. Bu iyi ve asla bitmiyor çünkü yeni kütüphaneler, çerçeveler, diller ve platformlar neredeyse her gün görünüyor.

Bilinmeyenle nasıl başa çıkacağınız gerçekten iyi bir soru ve alternatifleri araştırmak, değerlendirmek ve sonra birini seçmek.

Burada yardımcı olan Agile ile ilişkilendirilme eğilimi, refactor için kolay ve güvenli kod oluşturmayı içerir. TDD iyi bir örnektir. Gelişiminizi sonuçlar açısından düşünmeye teşvik eder. Zihni odaklayan ve hedefin çözülmesine katkıda bulunmayan kod miktarını azaltan "Bu kod bu sonucu üretmelidir".

SOLID (Kısaltma) ilkelerine göre kod yazarsanız, daha sonra yanlış seçim yaptıysanız veya sık sık olduğu gibi seçiminizi büyüttüğünüzde kitaplığı değiştirmek için iyi bir konumda olacaksınız.

Bu tür bir soru sormanız iyi olur. Çeşitli nedenlerle doğru teknolojiyi seçmek için zaman ayırarak "cahil" görünme riskini göze alamayacak çok fazla geliştirici var. Projede erkenden geç kalmayın. Deneme bir israf değil, bu yüzden bence doğru şekilde gidiyorsunuz.


2

Bu aglie gelişiminin bir parçası mı? Yazılım geliştirmede bilinmeyen arazi ile nasıl başa çıkıyorsunuz?

Ne nitelendirdiler Çevik değil. Çevik gelişmedir zaman kutulu iteratif yaklaşımla adaptif planlama, evrimsel gelişim ve teslimat tanıtma hakkında daha fazla. Agile, değişime hızlı ve esnek bir tepki vermeyi teşvik eder. Bu nedenle, geliştirme ilerledikçe kodunuzu yeniden çarpanlara ayırmanın içinde Agile metodolojisi vardır.

Projenin bilinmeyen bir parçasıyla başa çıkmak , bilinen gereksinimleri, üst düzey tasarımla toplamakla başlar. Çoğu bileşeni elinize aldığınızda, doğru çözümü arayabilirsiniz. Bununla birlikte, tam gelişmiş gelişimden önce küçük bir kavram kanıtı oluşturmak, ekibimizin izlediği yaklaşımdır.

SOLID adı verilen bir yazılım geliştirme ilkeleri vardır . Deneyimlerime göre, bunları sorunlara / sorunlara uygulamak, projenizin kod tabanını geliştirmede her zaman bir adımdır.


2

Projeye bağlı olarak, küçük bir proje üzerinde tek başına çalışıyorsanız, geliştirmenin bir parçası olarak teknoloji araştırmanızı ve araştırmanızı gerçekleştirmek mükemmel bir mantıklı olabilir. Ve Agile'ın bir parçası olmasa da, elbette buna biraz kontrol eklemek için Agile metodolojisi kullanılabilir. Ancak bu, süreci tahmin etmeyi / veya zaman kutusunu zorlaştırır. Tamamen sizin olan küçük bir projede tek başına çalışıyorsanız, iyi, hatta daha hızlı olabilir, gereksinimlerinizi öğrenirken ortaya çıkmasına izin verin. Yol boyunca iyi prensipler kullanın ve tutarlı olun; bu kadar çok faktoring yapmanız gerekmez.

İş yerinde Kanban, Scrum ve daha geleneksel şelale yaklaşımlarını kullanıyoruz. Projeye bağlı olarak, iyi tanımlanmış ön gereksinimleri olan karmaşık gelişmelerin çeviklik için en uygun olmadığını, birçoğunun buna katılmayacağını düşünüyorum.

Çevik bir projede bile çalışmaya başlamadan önce (en basit olanlar hariç), bazı belgeler oluşturuyoruz. Bir modelimiz var (ui odaklıysa), bir dizi gereksinimimiz ve işlevsel bir spesifikasyonumuz var.

Geliştirmeden işlevsel spesifikasyondan teknik spesifikasyon yaratması istenecek ve bu süreçte teknolojiyi belirleyecek ve ihtiyacımız olan her türlü ön araştırmayı yapacağız. Bu süreç benim için çok önemli görünüyor, çünkü gereksinimler / fonksiyonel özelliklerdeki boşlukları görme fırsatı veriyor - ve bu tür kararları almak için deneyim ve sistem bilgisi olan insanlara büyük teknoloji kararları veriyor.

Bununla birlikte, önemli olan, fonksiyonel spesifikasyonun mermi noktalarının bir listesi olabileceği ve teknoloji spesifikasyonunun genellikle bazı mermi noktaları ve teknoloji yönlendirmeleri olan bir model olacağı, belki bazı durumlarda sadece 3 veya 4 sayfa olacağıdır.

Çevik bir proje yürütürken bile belgeler oluşturuyoruz:

  • Tüm belgelerin bir maliyeti vardır.
  • Taşınmaya ve kötü tanımlanmış yüksek seviye gereksinimlere karşı geliştirmenin bir maliyeti vardır.
  • Yukarıdakilere doğru denge, projenize, kültüre ve insanlara bağlıdır.
  • Belgeleme Tam zamanında, belgeler eski.
  • Yeterince / yeterince belgelemiyoruz.
  • Bu belgeleri korumuyor veya güncellemiyoruz, bunlara fazla çaba sarf etmiyoruz. Küçükler. Onları atmayı umuyoruz.
  • Teknoloji kararları, puslu gereksinimler ve mimari gibi büyük bilinmeyenleri ön plana çıkarıyoruz.
  • Başlamadan önce ne geliştirdiğimizi biliyoruz.
  • Geliştiricilere dokümantasyon hakkında bilinçli kararlar vermeleri ve sorunları tartışmaları konusunda güveniyoruz.
  • İletişimin dokümantasyona değer veriyoruz, çünkü ilgili herkesin sık iletişim kurmasını bekliyoruz.
  • Sistemleri (genel bakış) geliştirmeden sonra, daha önce değil, sırasında belgeliyoruz.

Çevik sürecimizde küçük bir şelale olduğunu görüyorsunuz.

Yalnız çalışıyorsanız, açık bir model (şema!) Oluşturun ve teknolojiyle oynayın ve seçin ve daha sonra bu üst düzey gereksinimler konseptine sahip olduğunuzda, ilerleyin ve çevik bir yinelemeli şekilde geliştirin, ancak iyi ilkeleri ve tutarlılık ve gittikçe daha az, daha fazla yeniden faktör gerekir.

Ancak genel olarak, gerçek bir maliyet varsa (bir hobi değil) kod yazmadan önce ne geliştirdiğinizi bilin, ancak fikrinizi değiştireceğiniz için gereksiz hale gelecek olan belgeleri yazmak için çok fazla zaman harcamayın ve daha iyi bilgilendirildikçe gelişim sırasında fikrinizi değiştirin. Ve projeniz rotayı büyük ölçüde değiştirebilir, ancak iyi, iyi tanımlanmış bir temelden başlayabilir.


1

Kabaca yeni projelere böyle başladım ve ufacık projelerden bahsettiğimizi varsayarak oldukça iyi çalıştı. Örneğin, bir ORM veya o büyüklükte bir şey yazsaydım, bu rotaya gitmezdim. Bazen kafamın üzerinde olduğumda daha resmi bir araştırmaya başvuracağım. Ama çoğunlukla kod yazmaya başlıyorum ve ne olduğunu görüyorum. Ancak bunu yaparken çok fazla kod atmaya hazır olmalısınız.

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.