Bir programcı olarak, geliştirme sürecinin hangi yöntemi kullandığını önemsiyor musunuz?

İş piyasasındayım ve bir sonraki işim için maaş, iş kolu vb. Dahil bir dizi önceliğim var. Ancak, gereksinimler listemde hiçbir yerde olmayan bir şey, geliştirme süreci metodolojisidir. İşimin yazılım yaratmak olduğunu hissediyorum ve süreç yapısını scrum, şelale ya da her neyse uyum sağlayabileceğim bir şey olarak görüyorum.

Geliştirme süreci metodolojisi sizin için bir öncelik midir?

Benim için, çoğu profesyonellerin sahip olacağını umduğumuz sağduyuya girmemek kadar önemlidir.

Sürüm kontrolü hakkında konuştuğumuzda any version control beats not having anything at all, geliştirme yöntemlerinde durum böyle değildir. Yöntemler kurallar anlamına gelir ve kurallar bazen bozulur. Herkes hatırlayabildiği sürece gerçekten aptalca şeyler yapan şirketler için çalıştım, tedavi etmek için akılsız prosedür ne olursa olsun uzun zaman önce gitti.

Bir şirketten aşağıdakileri istiyorum:

• Birkaç sayfaya uyan, açıkça belgelenmiş prosedürler. Hızlanmak için bir tez veya (daha kötüsü) bir roman okumak zorunda kalırsam, uzun süre kaybolacağım.

• Şirketin daha iyi olmak için değişen prosedürlere açık olduğunun kanıtı. Birisine gidip "Neden xyz yaptığınızı anlıyorum, ama şimdi sizin için çoğunu yapan bir araç var. Bunu kullanabilir miyiz?" Diyebilmeliyim.

• Küçük bir rekabet iyi olabilir ve genellikle kaçınılmazdır. Ancak, rekabetin insanları motive etmek için birincil araç olarak kullanıldığı herhangi bir dükkandan kaçınacağım. Geliştirici tarafından günde 17 satır lazer yazıcıya gönderilen # satır gönderen bir şey kodladıysanız, sizin için çalışmak istemiyorum.

• Mübarek depolardaki yapıların söz konusu yapıyı bozan değişiklikleri almasını engellemediyseniz, heck gibi koşarım. 5: 00'da yapmak istediğim son şey, yerel inşaatımı test etmek için usta repodaki değişiklikleri çekmek, sadece kendimi başka birinin noktalı virgülünü tamir etmek için bulmak.

• Çevik ağaçtan düşen yerleşik bir yönteme benzeyen yöntemlere atlamayı tercih ederim. Zorunlu değildir, ancak bir aşinalık duygusu, prosedürel bir hata yapmazken üretken olmaya çalışmanın ilk kamburluğunun üstesinden gelmeye yardımcı olur.

Ben daha fazla zaman harcayacağınız görürseniz resenting onların var olduğunu müteşekkir olmaktan prosedürleri, muhtemelen iş geçmek gerekir.

Diğer yankılanan "oh hayır, bir daha asla!" olan "Biz de bizim için en iyi uygulamaları kurmak gerekir. Biz kod altı milyon hatları ve 21 telecommuter'leri var, biz bir SVN falan kullanıyor olmalıdır umuyoruz?" .

Birisi bunu halletmek için biraz eğlenebilir. Ben o adam değilim :)

Bir geliştirici olarak, geliştirme sürecinin aklı başında olmasını önemsiyorum. Bir dizi farklı geliştirme metodu, aklı başında bir geliştirme süreci sağlayabilir. Tersine, kırık bir şirket, ne derlerse desinler deli bir süreç sağlayabilir.

Bu nedenle özellikle resmi "geliştirme metodolojilerinin" ne olduğu umurumda değil. Yine de bunu soracağım çünkü gerçekten ne yaptıklarını anlamak için takip soruları sormam bir bağlam veriyor .

Evet, tekrarlamak isteyeceğimi düşünmediğim bazı zayıf metodolojiler gördüm. Birkaç örnek olarak şunları göz önünde bulundurun: Herkesin kendi kaynak denetimini, kodlama kurallarını vb. Kullanabileceği bir düzine geliştiriciden oluşan bir ekip için bir kovboy stiliyle iyi olur musunuz? Yapmayacağımı biliyorum. Bir kod satırının nerede değiştirileceği hakkında doldurmak için bir düzine form var ve üst yönetim oturumunun kapatılması biraz zaman alabileceğinden, üretimdeki değişikliğin tamamlanması haftalar alabilecek yaklaşık 20 imza var mı? "Ne olursa olsun" işler aklıma biraz fazla açık kalıyor, ama belki de burada biraz alaycıyım.

Bir geliştirici olarak, uygun metodoloji olduğu sürece, hangi metodolojinin doğru kullanıldığını umursamıyorum.

Örneğin, "kovboy kodlaması" yapan bir şirkette çalışmak istemiyorum , özellikle de gerçekten Agile yaptığını düşünecek kadar cahil oldukları takdirde .

Herkesin takip edebileceği bir geliştirme yöntemi olan yerleri tercih ederim.

Genel olarak kalkınma ve iş için kullanılan süreç seçimleri nedeniyle çok sinir bozucu işlerde çalıştım. Bugünlerde işlem için bazı minimum gereksinimlerim var. Bunlarla meşgul olmayan herhangi bir işin kötü çalıştığını ve işe yaramayacağını düşünüyorum. Eskiden sahip olduğum aptallık için sabrım yok, bu yüzden bu işleri atlayarak kendimi ve onları çok ağırlaştırıyorum.

Mantıklı gereksinimlerle ilgili bir bakış açısına, meşgul ve duyarlı bazı iş temsilcisine ve dev ekibinin zaman çizelgelerinde büyük bir söz sahibi olduğu anlayışına sahip olduğumuz sürece, o zaman mutluyum ve her şeye sığabilirim.