Bir pozisyon almadan önce potansiyel bir işveren kodunun kalitesini nasıl tespit edersiniz? [kapalı]

Bir şirket için çalışmaya başlamadan önce deneyimlerime göre, kod tabanına bakma fırsatınız yok (sordum ve gizlilik nedenleriyle herkesin her zaman hayır dediğini, bunun adil olduğunu düşünüyorum), görüşme sürecinde Kodun ne tür bir durumda olduğunu bulmak için sorulması gereken en önemli sorular sizce (sonuçta, eğer bir köpekse, o zaman her gün yürümesi gereken zavallı talihsizlerin üzerinde olacaksınız)?

GÜNCELLEŞTİRME:

Bir kontrol listesi: Ask;

• Kod temeli hakkında ne düşündüklerini . Ve yaptığınız zaman yüz ifadelerine ve yanıt vermeleri için geçen süreye özellikle dikkat edin. [Anon]
• Şirketin CMM seviyesi nedir [DPD] (ve eğer Seviye 5'in diğer tarafa doğru koştuğunu duyarsanız [Doug T])
• Hangi yaşam döngüsünü kullanıyorlar [DPD] (Ve "Çevik" duyarsanız, "Çevik" ile "Çevik" veya "kovboy kodlaması" anlamına mı geliyorlardı?]
• Kod kalitesini değerlendirmek için hangi araçları kullanıyorlar? [DPD]
• Gelişim için hangi araçları kullanıyorlar? [DPD] (Yeniden düzenleme araçlarını ve sürekli kurulum sunucularını arayın)
• Kullandıkları kaynak kod (sürüm kontrolü) sistemi ve iyi bir takip neden kullandıklarını sormaktır. [Zachary K].
• Test prosedürleri nasıl? [Karl Bielefeldt] (Özellikle alaycı çerçeveler kullanan ve NUnit / JUnit gibi belirlenmiş çerçeveler aracılığıyla tam bir otomatik birim testine önem veren ekipleri araştırın; test odaklı geliştirme TDD'si kullanmayan ekipler tarafından ertelenmeyin; Testin ayrılmaz ve sağlam bir yazılım geliştirmenin temel taşı olduğunu düşünmüyorlarsa dikkatli olun. Özel test uzmanlarına sahip ekipleri arayın.)
• Yeni geliştiricilere ne tür ödevler verilir? Tecrübeli geliştiricilere mi? [Karl Bielefeldt]
• Bir projede kaç kişi çalışıyor? [Karl Bielefeldt]
• Yeniden yapılanmaya izin verilir mi? Cesaret? [Karl Bielefeldt]
• Hangi kalite ile ilgili süreç veya mimarlık değişiklikleri dikkate alınmakta ya da yakın zamanda yapılmıştır? [Karl Bielefeldt]
• Bireylerin modülleri üzerinde ne kadar özerkliği var? [Karl Bielefeldt]
• Daha yeni projeler (yeşil alan gelişimi) mi yoksa eski projeler (kahverengi alan gelişimi) mi geliştireceksiniz? (Yeşil alan gelişimi genellikle daha eğlenceli ve başkasının hatalarıyla temizlik yapmadığınız için daha az sorun yaşıyor).
• Çalışan devir hızı kuruluş veya ekipte yüksek mi? (Bu genellikle düşük kod kalitesini gösterir) [M.Sameer]
• Kendinize ait bazı programlama problemleri; ama bir pislik gibi görünmekten kaçının. [Kıvılcım]
• Geliştiriciler nasıl işbirliği yapar ve bilgi ekip arasında nasıl paylaşılır? (Bu kişiliğinize uymalıdır; sosyal ihtiyaçlarınızla orantılı olarak solo ve çift çalışmanın bir karışımının muhtemelen en iyisi olduğunu söyleyebilirim)
• Veritabanları, 3. Normal Form'a (3NF) ne kadar yakındır ve eğer nerede ve neden sapma gösteriyorsa? ("3NF ???" derlerse, bırakın. Olmazsa ve bunun için iyi nedenler olabilirse, o zaman ne olduklarını bulun).

NOT: Anon'un cevabını kabul ettim çünkü yaklaşık bir hafta sonra topluluk bunun en iyisi olduğunu düşünüyor - bunun bir şekilde altıncı hissi geliştirmek için ihtiyaç duyduğunuz bir şey olduğunu ileri sürdüğünü düşünüyorum. Ancak, herkesin söyleyecek değerli bir şeyi olduğunu düşünüyorum.

Kodlarını görmek istemek yerine, kod temeli hakkında ne düşündüklerini sorun. Ve yaptığınız zaman yüz ifadelerine ve yanıt vermeleri için geçen süreye özellikle dikkat edin.

Öyleyse kültürünüzün sözsüz jestleri hakkındaki bilginizi gerçekte ne dediklerini yorumlamak için uygulayın. Bir Kuzey Amerika şirketi için aşağıdakiler doğru olmalıdır:

• Küçük bir omuz silkme ve "daha iyi olabilir" çabuk yanıt: muhtemelen oldukça iyi.
• Uzun bir duraklama, nefes alımı, belki küçük bir gülüş: hoş değil ve görüşme yaptığınız kişiler size bunu söylemekten rahat hissetmezler.
• Kıvrılmış gözler, "berbat" çabuk tepki: iyi olabilir, kötü olabilir, ancak siyasi oyunlar da oluyor. Bu oyunu oynamaya ya da hiç kimsenin sessiz kalmasına hazır değilseniz, uzak durun.
• Yükseltilmiş veya daraltılmış kaşlar: soruyu anlamıyorlar ve kod temeli neredeyse kesin olarak yanılıyor.

Tabii ki, kişiler arası iletişimde sorun yaşıyorsanız, bu sizin için işe yaramayabilir.

İstediğine bile şaşırdım. Katılmadan önce hiçbir şirket size kodu göstermez. Bir gizlilik anlaşması imzalamadıkça, sürece çağrılan danışmanlara bile.

İşte öğrenmek için ne isteyebilirsiniz.

• Şirketin CMM seviyesi nedir (ideal olarak 5)
• Prospektif projenizde izlenen süreç nedir (BTW, bunu sormak iyidir, çünkü bu sadece “herhangi bir iş değil,“ bu ”işle ilgilendiğinizi gösterir)
• Hangi yaşam döngüsünü kullanıyorlar ("Çevik" demiyorsanız yargılayıcı olmayın. Eski okul modellerini kullanmak için geçerli bir nedenleri olabilir)
• Kod kalitesini kontrol etmek için herhangi bir araç ve ölçüm kullanıp kullanmadıklarını sorun. Ve eğer evet (hangisi) (metrikler için en az bir araç, kalite için başka bir araç kullanıyorlarsa iyi bir işarettir.)
• Ayrıca hangi araçları kullandıklarına dikkat edin. Bazı ücretsiz araçlar yerine Resharper gibi pahalı bir araç ise o zaman kalite konusunda ciddiler.

1. Kaynak kontrolü kullanıp kullanmadıklarını sorun.
   • Kaynak kontrolü yok mu? -> kod büyük olasılıkla boktan
2. Onlara kod incelemelerinin ne sıklıkla yapıldığını sorun.
   • Kod incelemesi yok mu? -> kod şüpheli olabilir (ancak, kesinlikle, özellikle de geliştiricilerin oluşturduğu küçük bir ekipse).
3. Üretime girmeden önce nasıl test edip uyguladıklarını sorun mu?
   • Test ortamı yok mu? Üretime doğrudan dağıtım? -> kod büyük olasılıkla boktan.
4. Onlara sürekli entegrasyon yapıp yapmadıklarını sorun (.ie. Hudson ile birlikte çalışır)
   • Sürekli entegrasyon yok mu? -> kod şüpheli olabilir, ancak mutlaka olması gerekmez.
5. (# 3 ile ilgili olarak), onlara test ortamlarının geliştirme ortamınızdan ayrı olup olmadığını sorun.
   • Test dev mi? -> İyi bir işaret değil, gerçekten nakit sıkışık olmadıkça değil, ne kadar pahalı olabilir?
6. Üretime başlamadan önce bir eylem listesini gözden geçirip gözden geçirmediklerini sorun.
   • Üretim dağıtımından önceki eylemlerin incelemesi yok mu? -> Kötü juju.
7. Onlara bir yapı oluşturmalarını kaç adım atmaları gerektiğini sorun.
   • 3'ten fazla mı? -> genellikle kötü juju.
8. Siklomatik karmaşıklık veya LCOM (sınıf uyumu ölçüsü) gibi kod ölçümlerini alıyorlar mı?
   • Evet? -> muhtemelen (ancak kesinlikle değil) kodlarının kalitesiyle ilgili iyi bir işaret.
   • Hayır, ama kavramları anlıyorlar (en azından çevrimsel karmaşıklık)? -> söylemesi zor
   • Siklomatik karmaşıklığın Timbuktu'dan egzotik bir tabak veya afrodizyak olduğunu düşünüyorlar (başka bir deyişle, bunun ne olduğunu bilmiyorlar)? -> olası kötü juju.
   • Bunun alakasız bir şey olduğunu mu düşünüyorlar (veya başka türlü tavırlar)? -> kaç.
9. Onlara böcekleri nasıl takip ettiklerini sorun.
   • Bazı metriklere karşı böcek sayısını takip ediyorlar (.ie. Proje başına, değiştirilen modül sayısı veya gereksinim / değişiklik talebi sayısı, bir şey!)? -> kodları hakkında iyi bir işaret (ve onların yazılım süreci).
   • Yukarıdakileri yaptılar ve beklenen bir metriğe (bir dizi değişiklik talebi, proje büyüklüğü, vb.) Dayanarak gelecekteki (ya da devam eden) bir projede karşılaşabilecekleri olası hataların sayısını tahmin etmeye mi çalışıyorlar? -> çok iyi işaret.
   • Sadece böcek çözümlemesi için böcekleri mi takip ediyorlar? -> anlatması zor
   • Tutarlı takip yok mu? -> kaç.

Bu kafamın üstünden olurdu. Sorularımdan bazılarının yalnızca kodlama konusunda değil, yazılım geliştirme süreciyle ilgili olduğunu fark edeceksiniz. Daha sonrakilerin kalitesi, öncekilerin kalitesinin doğrudan bir işlevidir.

Bununla birlikte, bu soruları sorduğunuzda dikkatli olun. Onları inceleyin ve görüşme sırasında birkaç kişiyi seçin.

Aklında tutman gereken birkaç şey var. İyi bir geliştirme ekibi, görüşülen bir kişinin dokunuşla sorulması şartıyla bu soruları sorduğunu duymaktan mutluluk duyacaktır. Yanlış yaparsanız, görüşmeciye kibir ve mükemmeliyetçilik izlenimi verir. Bir takım ne kadar iyi olursa olsun, hiçbir grup mükemmel değildir ve hepsinin çözmesi gereken problemleri vardır, kaliteden ödün vermezler. Yıkıcı bir mükemmeliyetçiyi değil, kaliteyi seven bir takım oyuncusu istiyorlar. Yani dikkatli ol.

Ayrıca, dış koşullar gereği düşük kalitedeki kodda çalışması gereken iyi insanlar ekibine sahip olduğunuz durumlar olabilir (küçük geliştiriciler olabilirler veya basitçe şu an üzerinde çalışacakları bir bok yığınını miras aldılar). Kaliteyi arttırmaya adanmış kaynaklar.) Çevrenizdeki insanlar da (hem şahsen hem de profesyonel olarak) iyi insanlarsa, boktan kodlarla çalışabilir ve yine de iyi bir çalışma deneyimine sahip olabilirsiniz. Soruları sorduğunuzda onlara yanlış izlenim verin ve onlar sizi tamamen işe almaktan kaçınabilirler (sizi iyi insanlarla çok zor ve zorlu bir durumda çalışma fırsatını soyarak).

• btw, bir yazılım geliştiricisinin bir tür umutsuz (veya umudun ötesinde) koduyla en az bir kez çalışmasının bir zorunluluk olduğuna inanıyorum. Bundan kurtulur ve iyi bir iş çıkarırsınız, bu değerli bir derstir.

Ayrıca boktan insanlarla birlikte boktan bir gelişme grubuyla da karşılaşabilirsiniz. Açıkçası, o zaman, kodları boktan olacak ve bu sorulardan herhangi birine dalacaklar. Onlara sert sorular sormak için sizi küçümseyebilirler (ve bu nedenle size bir iyilik yapıyor olabilirler) veya sizi işe alacaklar çünkü size ihtiyaçları var (sizinle birlikte çalışamayacakları olsa bile).

Bu olduğunda, o zaman bu işe bu kadar kötü ihtiyacınız olup olmadığını kendinize sormalısınız . Bazen yaparsın ve spagetti bokuna dalmak zorunda kalırsın. Bazen yapmazsın (anlamsız, göze alamazsın.)

Bunlar, görüşmeci tarafından kodlarının ve yazılım işlemlerinin kalitesi hakkında soru sormayı seçtiyseniz / seçtiyseniz göz önünde bulundurmanız gereken şeylerdir.

Gerçek kod kalitesi yerine, kod kalitesinin öneminin iyi anlaşıldığı bir şirket aramayı tercih ederim.

Örneğin, A şirketinin “planlama zamanın boşa harcandığını” ve “tasarım sorunlarını daha sonra çözebileceğimize (örneğin, cehennem düştüğünde. Zamanımız olacak”) inanan yöneticileri olduğunu söyleyin. Bu şirket şimdi iyi bir kod tabanına sahip olsa bile, uzun sürmeyecek. Ve sen onu daha da kötüleştirecek (zorlanacak) biri olacaksın.

Öte yandan, B şirketinin kötü bir kod tabanına sahip olduğunu, ancak yönetimin kod kalitesinin tüm bu hatalara ve gecikmelere neden olduğunu anladığını, değişime ihtiyaç duyulduğunu anladıklarını ve bu konuda bir şeyler yapmaya istekli olduklarını (örneğin, büyük ölçekli) yeniden düzenleme, hatta yeniden yazma Bu şirket kod tabanını geliştirecek ve bunu gerçekleştirmelerine yardımcı olabilirsiniz.

Nerede çalışmak istediğimi biliyorum.

Başlamadan önce kodu görememeniz için% 99,9 şansınız var. (Tabii ki özgür yazılım ürünü çıkarmazlarsa)

Peki ne yapabilirsin, süreç hakkında soracağım, genel olarak iyi süreç iyi kod üretecektir. Joel testiyle başlar ve geliştirme yöntemini sorardım. Ayrıca temellerin ötesine geçin. Örneğin, her zaman hangi kaynak kod sistemini kullandıklarını soruyorum, bu yüzden iyi bir takip neden kullandıklarını sormaktır.

Çok kaliteli kodla çalıştığım yer temel olarak geliştiricilerin üçte ikisinin koda dokunmasına izin vermedi. Diğerleri otomatik kara kutu test komut dosyaları yazdı. Asıl kodu değiştirmeye layık olduğunuzu kanıtladıysanız, gereksinimler o kadar fazlasıyla belirlenirdi ki, temelde kaynak koda dönüştürülmekten başka bir şey değildi. Test komut dosyaları yazmak gerçekten daha eğlenceliydi.

En düşük kalite kodunu gördüğüm yerler tam tersi oldu: yalnızca göreceli olarak eğitimsiz veya denetlenmemiş programcılar koda değdi, çünkü genellikle şirketin ürünüyle doğrudan ilgili olmayan ya da deneysel olarak kabul edilen bir araçtı.

Çalışılacak en keyifli yerler dengelidir. Yeni geliştiricilere gerçek ödevler verilir, ancak danışmanlar. Hatalarınızı yakalamak için iyi bir QA departmanı ve meslektaş inceleme süreci var. Hata yaptığınız için ceza almazsınız, ancak düzeltmeniz ve onlardan öğrenmeniz beklenir. Bazen, kötü yazılmış bir modül çatlaklardan düşer, ancak bunlarla karşılaştığınızda kod kalitesini iyileştirmek için zaman harcamaktan eleştirilmezsiniz. Bir bütün olarak şirket, kodu daha iyi hale getirmenin yeni yollarını bulmak için sürekli çaba göstermektedir.

Bu nedenle, kod kalitesini değerlendirmek isteyeceğim sorular şunlardır:

• Test prosedürleriniz nasıl?
• Yeni geliştiricilere ne tür ödevler verilir? Tecrübeli geliştiricilere mi?
• Bir projede kaç kişi çalışıyor?
• Yeniden yapılanmaya izin verilir mi? Cesaret?
• Hangi kalite ile ilgili süreç veya mimarlık değişiklikleri dikkate alınmakta ya da yakın zamanda yapılmıştır?
• Bireylerin modülleri üzerinde ne kadar özerkliği var?

@DPD ve @ Zachary'in dediği gibi, süreç ve SDLC çok önemli faktörlerdir ancak deneyimlerime göre kod kalitesi üzerinde önemli etkiye sahip olan bazı diğer faktörler eklemek istiyorum:

• Geliştirme aşamasında nispeten daha yeni bir projede mi yoksa eski uygulamayı sürdürmekte mi çalışacağınızı sorun. Eski uygulamalar, yeni projelere göre daha az temiz olma eğilimindedir.
• Çalışanların ciro oranının organizasyonda veya takımda yüksek olup olmadığını öğrenmeye çalışın. Bu, muhtemelen kodun kalitesini de düşürecektir.

Bir sürecin çok faydası olduğunu ancak yukarıdaki faktörlere karşı tam bir bağışıklık kazanmayacağını unutmayın. Bir çok geliştirici bir projeye geçtiğinde, her biri farklı bir zihniyetle gelir. Mimar ve geliştirici, seleflerinin bazı tutarsızlıklara yol açacağı şekliyle tam olarak uymayacak.

Benim tavrım bu, kod, eğer kötüyse, daha iyi hale getirmek için bir meydan okumadır. Eğer iyiyse, daha iyi hale getirmek için daha da zor bir mücadele!

Benim için en önemlisi, şirket için çalışıp çalışamayacağım ve etkileşimde bulunma olanağım olan insanlar. Kod değiştirilebilir, insanlar ...

Biraz şaka yapıyorum, benimle röportaj .

Normalde kod tabanımızda gerçek bir hata (önceden düzeltilmiş) görüşme testi olarak kullanıyorum, bu yüzden bazı gerçek kodlar görüyorsunuz. Genellikle biraz karmaşık kod ve içinde bir hata var.

Herkesi bu tekniği kullanmaya teşvik ediyorum, zaten hatanın gerçek olduğunu, sorunun gerçek olduğunu ve ne kadar zaman bulup düzeltildiğini biliyorsunuz.

Harika olan şey, ölçülebilir derecede zor bir probleminiz olabilir.

Uzmanları oldukça iyiden ayırmak için son görüşme sorusu olarak çok zor bir problem kullandım.

OP'nin sorusuyla alakası, fiziksel bir röportajı yapan herkesin bazı kodları görmesidir. (Şirketin gizli içeriğine sahip hiçbir şey yok)

Bu tekniği kullanamayacak olursanız, söyleyeceğiniz gibi, kod tabanındaki küfürler, o zaman test çalışır, aday çalışanlar "kodu görebilir miyim" diye sorarlar ve cevap "olur" küfür dolu ".

Tabii ki, standart "hepsi bir şirket sırrı" cevabı toplam at-puckey.
Kanıtım: önceki işverenimde, bir ordunun gizli olmayan bir parçası ürünün , görüşme sorusunun kod örneğiydi. [Neyse ki sınıflandırılmamış]

Orada benden daha zeki birine çalışmadan önce sınıflandırılmış tasarımların kalitesini belirleme sorununu bırakıyorum. Sınıflandırmanın gözetimsiz ile eşanlamlı olması yaygın olabilir.

Kodlarını görmenize izin vermeleri şüphelidir, ancak bir programlama ödevi ödevi verirseniz nasıl bir fikir edinebileceğinizi öğrenebilirsiniz. Pek çok yer, görüşmecilere sizi ölçmek için kullanabilecekleri bir eve dönüş programlama ödevi verir. İyiliğin karşılığını ver - onlardan birini bekle, böylece içine girebileceğini daha iyi ölçebilirsin.

Üretimin içine koyabilmesi için neyin gerekli olduğunu sorun. Eğer 'ah ... dev bunu taahhüt ederse ...' alırsanız, o zaman neredeyse kesinlikle çöp.

Kodun kalitesini artırma eğiliminde olan çok sayıda şey vardır (açıkçası, hiçbir garantisi yoktur).

• Statik analiz (.NET'te bu fxcop / stylecop gibi şeylerdir)
• Test setinin bir alt kümesi (veya tam seti) - birim / entegrasyon / regresyon / manuel vb.
• Buddy build (ekipteki başka bir geliştirici, makineye / kullanıcıya bağlı herhangi bir sorun olup olmadığını görmek için değişiklikler yapar - bazen de aynı zamanda hızlı bir akıl sağlığı koşar)
• Kod incelemesi

Bunlar, yalnızca kodun gücünü değil, kodun kalitesini de artırmaya yardımcı olabilir.

Onlara birim testi hakkında danışın. Eğer ciddiye alırlarsa, görüşmeci muhtemelen konuyla ilgili kesin fikirlere sahip olacak ve bunları paylaşmaktan memnuniyet duyacaktır. Cevaplar belirsizse, bu büyük bir uyarı işaretidir.

Eğer bir Java mağazasıysa, hangi ORM kütüphanesini kullandıklarını sorun. Kendilerini yuvarladılarsa, her iki şekilde de gidebilirdi - ya emebilir ya da iyi olabilirdi. Kullanmıyorlarsa, hemen kapıya doğru koşun.

Bu zor bir iştir, çünkü o kadar çok farklı kötü kodlama uygulaması vardır ki, hepsini asla tahmin edemezsiniz.

Yapamazsın maalesef. Hiçbir şirket kodlarını görmenize izin vermez (ancak SİZİN kodunu görmek isteyeceklerdir ...) ve olasılıkla, onlara doğrudan yalan söyleyeceğiniz çevre hakkında sorular sorarsanız ("Sürüm kontrolü? Elbette .. kullandığımız .. ahh .. düşünme Alt .. Alt şey ") veya (kalitesi hakkında yanıltılmış" Biz kullandığınız son ve en büyük .NET 4" sadece öğrenmek için onlar .NET 4 kullanarak yaparken onlar' .NET 1.1 gibi yeniden yazıyorum).

Geçmişte birçok kez yanmışım ve kaliteyi ölçmek için henüz iyi bir yol bulamadım. Genellikle en iyi yol kendi kararınızı kullanmaktır ve eğer kaynarsa, düşündüğünüzden daha kötüsü varsa hemen bırakın; bir iş hunisini bitirebilirsin ama akıl sağlığını koruyacaksın.