Aldırmadan nasıl kod yazarsın?

Bununla demek istediğim, yıllardır üzerinde çalışmakta olan ve çok aşina olan geliştiricilerle paylaştığınız bir kod temelini geliştirmeye nasıl gidiyorsunuz?

Kimsenin ayak parmaklarına basmak istemiyorum, ancak işlerimi yapma biçimim, kodumun ne kadar boşluk bıraktığım veya SVN'ye ne sıklıkta kontrol ettiğimden (o kadar sık) ne sıkıntı duyduğum hakkında çok fazla şikayet edemiyorum. Bu yüzden bunları kolayca değiştirebildiğim halde, genel olarak daha iyi bir takım geliştiricisi olmak istiyorum.

Sormaktan başka ne yapacağımdan emin değilim, ama belki siz pratik yapabileceğim bazı düşünceleriniz var.

GÜNCELLEŞTİRME

Konuşacak herhangi bir stil rehberi yok - yalnızca kod tabanını paylaşmaya alışkın olmayan insanlar var. Herkesin kendi küçük sessiz dünyası vardır.

Burası bir perl dükkanı, ama bunların herhangi bir dil için geçerli olduğundan eminim.

GÜNCELLEME 2

Daha sonra CEO olan CTO tam bir megalomandı ve bu şikayetlerin ana kaynağıydı. Tam olarak sevdiği şeyleri yapmadıysanız, bir Mac veya Emacs veya 2 yerine 4 sekme alanı kullanıyorsa veya belirli bir şekilde giyiniyorsanız, yetersiz kaldınız. Düzeltmeye çalıştığım korkunç bir durumdu ama benim için tek doğru cevap ayrılmaktı.

Bunun bir işyerinde zorbalığın bir örneği olduğuna ikna oldum ve daha sonra bir iş ortamında neyin zorbalık olabileceği ve uygunsuz davranışların olabileceğinin daha fazla farkındayım.

Böyle bir duruma cevap arayan geliştiricilere hemen bırakın. Kötü bir takım durumundan kurtulmak için takım çalışamazsın

Sor. Bu, birlikte çalıştığınız insanlara sorun. Mevcut kodun oluşturulmuş stiline uymak için elinizden geleni yapın. Özellikle kodlama standartlarının bir belge listesi olup olmadığını sorun ve uygulayın. Eğer bir tane yoksa, kodda ne gözettiğinize dayalı bir ilk taslak hazırlayın ve ardından diğer ekip üyelerinden onu eleştirmelerini isteyin. Kabul edilen kodlama uygulamalarını belgelemeye başlayarak, şirketi (ve ardından gelen yeni geliştiricileri) bir servis yapacaksınız. Eski zamanlayıcıların neyin kabul edilebilir veya neyin kabul edilemez olduğu konusunda birbirleriyle aynı fikirde olmadıkları ortaya çıkarsa, tek risk muhtemelen ortada yakalanmaktır.

Ayrıca, kendin olmaktan korkma . Siz yeni adam olabilirsiniz, ancak ekibin bir üyesisiniz ve görüşleriniz geçerli. Bir şeyi yapmanın daha iyi yollarını düşünebiliyorsanız, önerin. Diğer ekip üyelerine ve bir şeyler yapmanın yerleşik yoluna saygı gösterin, ancak sizi yönlendirmelerine izin vermeyin. Girdiinize değer vermemiş olsaydı, şirket sizi işe almazdı.

Takımda arkadaşça görünen ve özellikle soruları cevaplamak isteyen birilerini bulabilirseniz çok yardımcı olacaktır . (Eğer iyi bir takımsa, herkes olmalı, ama takımlar her zaman böyle değil.) Patronun, başlamana yardım etmesi için birisini görevlendirmiş olabilir. Bu kişiyi kaynak olarak kullanın. Size gelen soruları yazın ve bu yardımcı kişiden zaman zaman cevaplamasını isteyin.

"Çok sık" kodunu kontrol etmek için, neden periyodik taahhütleriniz için kendi şubenizi yaratmıyorsunuz ve daha sonra kodunuz hazır olduğunda bagaja geri dönüyorsunuz? Bunu yaparken kimsenin zararı yoktur ve iş arkadaşlarınız SVN'den istediklerini aldıklarını gördüklerinde liderinizi takip edebilirler.

Boşluk alanı ile ilgili: Sadece bunu yapın, ancak kod zaten yapar. Akışına bırak.

SVN kontrolleri ile ilgili olarak: Onları çok net bir şekilde belgeleyin. Bu, insanların kodda neler olduğunu anlamalarına yardımcı olur. (Takip: Sık sık checkin'e itirazları nelerdir?)

Genel olarak: Bir standart kodlama belgesi oluşturmaya başlayın. 100 kuralla doldurmaya çalışmayın. Sadece onlar geldikçe kuralları ekleyin.

Ayrıca: Geliştiricilerinize sorular sorun. Bu, hoşlanmayacakları bir şey yapmadan önce tartılmalarına fırsat verir. Ayrıca, ilişkiler kurar. Ayrıca, dükkanın nasıl çalıştığı hakkında daha fazla şey öğrenirsiniz.

Kod biçimlendirme stiline (boşluk, sekmeler, parantezlerin gittiği yerler vb.) Gelince, koddaki geçerli standarda uymalısınız. Eğer bir tane yoksa, şikayet edecek çok şeyleri olduğunu sanmıyorum. Konuya gelince, kendi satırına parantez koyup koymadığınız, yöntem parametre listelerinin etrafına boşluk koyup koymadığınız, kişisel tercihinizdir ve geçerli stile vermelisiniz, çünkü uzun vadede, gerçekten değil önemli . Önemli olan tutarlı olmak.

SVN kodunu kontrol etmeye gelince, kendimi buharda bırakmaya izin vermektense, bir şeyler yapmanın doğru yolunun ne olduğunu düşündüğümü hatırlatmaya çalışırdım. Testler inşa edip geçmedikçe kodumu kontrol etmiyorum ve ilgisiz birkaç değişiklik yapıyorum, çalışmamı birkaç işe ayırıyorum. Bir süre bir şey bozulursa, bir şube açıp işimi orada yapıyorum. Komisyon açıklayıcı yorumlar alır. Bu benim deneyimimde "Cuma günü saat 5: 00’de yapılan bir değişiklik yığınını kontrol etme" yönteminden daha iyi çalışıyor ve burada ve başka yerlerde okuduğumun çoğuna göre geçerli "en iyi uygulama" gibi görünüyor.

İlk önce kodlama kuralları belgesini okuyun (eğer onlardan bir tane yoksa, onlardan bir tane yazmalarını isteyin, böylece onu takip edin)

Öyleyse dikkat edin ve bunu ve söylediklerini takip etmek için bilinçli bir çaba gösterin. Onlar size sert davranıyor gibi görünebilir ancak kodlama standartları önemlidir, daha sonra daha büyük değişiklikler yaparken daha sonra bir soruna dönüşmesine izin vermek yerine, neyin yanlış olduğunu belirtmek daha iyidir.

Bazı acemiler parmaklarınıza basarken bir veya iki yıl içinde aynı şeyi yapacağınıza eminim :)

Şirket kod standartlarını isteyin. Ayrıntılara daha fazla dikkat edin. Başkalarının çok özel bir beyaz boşluk ve destek desenleri izlediğini görürseniz, onları izleyin. Bir Sr. olarak bunun çok seçici olduğunu iddia edebilirsiniz, ancak bir projedeki bir Jr. ya da yeni bir erkek olarak liderlik yapmadan önce takip edebileceğinizi göstermeniz gerekir.

Ayrıca, bir projedeki yeni geliştiricilerin gerçekten de gerekli bir "hızlanma" süresi olacağını anlayın . Bu yüzden kendin için endişelenme.

Yapabileceğiniz en iyi şey, size verdikleri tavsiyelere uymaktır. Ne istediklerini vaktinden önce söylemenin yolu yok. Psişik olmadıkça.

Bununla birlikte, insanlar size tavsiyelerde bulunurken bunu belgelemenizi öneririm. Bir viki var mı? Eğer öyleyse, onu kullan. Değilse, kaynak koduyla kontrol edilen bir metin dosyası iyi bir fikir olabilir. İyi organize edilmiş bir programlama rehberi oluşturun. Bir şeyi nasıl yapacağınızı hatırlamanıza yardımcı olacak ve eğer birileri size verilen daha önceki tavsiyeyle çelişirse, tutarsızlığı tartışmanız için size bir referans noktası sunar. Artı, bir sonraki kişi takıma katıldığında, yaşadıklarından geçmek zorunda kalmayacaklar.

Belgedeki önerileri kişilere atfetmemenizi öneririm ("kod bloklarının üç boşlukla girilmesi gerekir", "Bill bana kod bloklarının üç boşlukla girilmesi gerektiğini söyledi"). Ancak, bu bilgileri göze çarpmayan bir şekilde kaydedebilirsiniz (örneğin, yorumda, "Bill'in tavsiyesine dayanarak girintiyle ilgili ek kurallar yazınız"), o zaman hemen iki bakış açısına sahip olabileceğiniz için çelişkileri çözmede yardımcı olabilir. Bir şey üzerinde. Burada düşündüğüm şey, gerçekten, eğer çelişkili tavsiyeler verilirse, bir şeye katılmıyor iki meslektaşım tarafından atılan bir futbol olmaktan kaçınmanız gerekir. Biraz kıçını örtecek bir yaklaşım, ama ihtiyatlı olabilir.

Stil rehberini bulmak ve onu takip etmek kolay bir yöntemdir. Birçoğunun içinde çok rahatsız edici bir şey yoktur ve sizi başkalarına kızdırmanızı önler.