“En düşük geliştirici” olarak teknik borçla mı mücadele ediyorsunuz?

Diyelim ki bir şirkette çalışıyorsunuz ve yaptığınız şey onlar için yazılım geliştirmek. Büyük resim hakkında hiçbir fikriniz yok ya da hafif. Sahip olduğunuz şey, sorun izleme sistemi aracılığıyla size atanan görevlerdir. Size görevler veriliyor, onları görevin tanımladığı şekilde çalıştırıyorsunuz, geri gönderiyorsunuz 2 tamsayı eklemek gibi:

function add(a,b){return a + b;}

Ancak daha sonra, proje ilerledikçe, adddaha karmaşık hale geldikçe, bunun, parametreler ekleyen ve bir değer döndüren bir işlevden ziyade, bir tür mimariye ihtiyaç duyduğunu fark edersiniz. Ancak, bunu bilmiyordunuz. İlk olarak, tek ihtiyaçları olan bu kadar basitti add. Eklemenin bu kadar karmaşık olmasını beklemiyordunuz.

Proje, ilk başta olmasını beklemediğiniz daha fazla özellik ile ilerliyor. Ve sonunda, mevcut kodu kırmak / yeniden yazmaktan kaçınmak için işlev katmanı üzerine kesmek ve katman biriktirmeye devam edersiniz.

Bu durumlarla nasıl başa çıkıyorsunuz? "En düşük geliştirici" olarak teknik borçla nasıl savaşıyorsunuz?

Açıklama:

• Siz hiyerarşideki en düşük "uygulayıcı "sınız.

• Sorunu görüyorsunuz, ancak bu konuda bir sözünüz yok.

• Teknik borcu ölçmüyorum veya araçlar aramıyorum.

• İlgili üçüncü "yinelenen"

  • Yeniden Düzenleme ve Yeniden Yazma - Görevlerinize kilitlisiniz. Ekstra ücret ödemezsiniz.
  • Mimariye Genel Bakış - Genel sistemi biliyorsunuz, ancak mimari hakkında hiçbir fikriniz yok.
  • Kod Dondurma - Çağrınız değil. Sen yönetim değilsin.
  • Modülerleştirme - Mimari fikri yok. Gereksinimler değiştikçe modüller değişir.
  • Otomatik Testler - Yok.

Böyle bir şey her fark edişinizde, sorun izleme sisteminize yeni bir bilet girin.

Sorun izleyiciyi bu tür şeyleri iletmek için birincil araç olarak kullanmayı alışkanlık haline getirin , çünkü oradan projenizdeki sorunları izlemekle sorumlu kıdemli meslektaşlarınız / lider / müdür / kimseyi seçmek, değerlendirmek ve öncelik vermek kolay olacaktır .

İş için doğru aracı kullanın. Her zaman yaparım ve aynısını yapmanızı şiddetle tavsiye ederim.

Örnek olarak, yaklaşık bir ay önce oluşturduğum bir bilet. Belirli bir özelliğin tamamlanmasının ardından kodun öncekinden çok daha karmaşık hale geldiğini keşfettim, ancak özelliklerin uygulanması için verilen süre içinde bunu düzeltemiyorum.

(Gerçek izleyicide kullanılan özelliklerin, biletlerin ve kodların adları gizlidir, ancak metin olduğu gibi kopyalanır).

Özet: içeren tasarımı basitleştirinParticularPieceOfCode

Açıklama:
TICKET-12345'e göre uygulama sırasında, ParticularPieceOfCodetahakkuk eden birtakım karışıklık içeren kod okumak ve okumak, anlamak ve korumak oldukça zorlaşmıştır (aşağıdaki örnek kod snippet'ine bakın).

Basitleştirmenin bir yolunu bulun.

Yeniden tasarlanması istenen bir kod örneği şurada bulunabilir: ClassName#methodName :

<a piece of code like one behind the right door here:>

FWIW tavsiyem, sizin "seviye" olduğunuzdan bağımsız olarak geçerlidir.

Şu anki ("en düşük") seviyenizde kullanıyorum ve şu an seviyem "en düşük" den oldukça uzak ve ben onu çağırırken tatmin edici "demek" var ve ben kullanacağım ne olursa olsun hep.

Sadece düşünün, seviye yok, ne kadar yetkiye sahip olursanız olun, daha iyi bir yol olamaz.

"Eğer" dersen hey bir sorunumuz var , sadece hava tıkırtı. Patronunuz / lideriniz kabul edip haklı olduğunuzu söylese bile , bir sorunumuz var , bu hiçbir şeyi değiştirmiyor - yine hava tıkırtıyor ve başka bir şey olamaz.

• ^{Sözünüzü yazmanın (örneğin e-postada) daha iyi olacağını düşünebilirsiniz, ancak bunu düşünüyorsanız, gerçekten değil. Projenizde önemli posta etkinliği varsa, yazılanlar bir ay sonra kaybolacak ve uzun süre unutulacaktır.}

İş için doğru aracı kullanın. Açıkladığınız iş için, sorun izleyici tam olarak doğru araçtır.

Sorunu fark edersiniz, bunları izlemek için tasarlanmış bir sisteme girersiniz ve geri kalanıyla mümkün olan en iyi şekilde ilgilenir - çünkü bunun için tasarlandı :

bir kuruluşun ihtiyaç duyduğu sorun listelerini yöneten ve koruyan bilgisayar yazılım paketi ... yaygın olarak kullanılan ... bildirilen müşteri sorunlarını, hatta o kuruluşun diğer çalışanları tarafından bildirilen sorunları oluşturmak, güncellemek ve çözmek için ... Sorun izleme sistem bir " bugtracker " ile benzerdir ve genellikle bir yazılım şirketi her ikisini de satar ve bazı bugtrackers bir sorun izleme sistemi olarak kullanılabilir ve bunun tersi de geçerlidir. Bir sorunun veya hata izleme sisteminin tutarlı kullanımı "iyi bir yazılım ekibinin ayırt edici özelliklerinden" ^{1 olarak kabul edilir} ...

İletişim kurmayı seçmek istediğiniz başka ne olursa olsun, izleyicide bir bilete sahip olmak sadece sizin için daha kolay olacaktır.

"TICKET-54321 ... 'i tartışmak isterim" diyerek havayı sarsmayı tercih etseniz bile , "Dinleyin Bir süre önce ele aldığım bir kod parçası hakkında konuşmak istiyorum. ... "Ve bilete referansları güvenli bir şekilde posta ile iletebilirsiniz: posta kaybolsa bile, sorun hala anlatmak istediğiniz tüm ayrıntılarla izleyicide olacaktır.

Senaryo hakkında beni kötü hissettiren şey, tam olarak başlıkta ve soru metninde birkaç kez yazdığınız şeydir:

Zincirdeki en düşük geliştiricisin

Bu nokta neden bu kadar önemli? Her şeyden önce ve tamamen teknik açıdan, kesinlikle haklısınız. Bir şeylerin "uygulayıcısı" olarak adlandırdığınız şey, verilen komutlar üzerinde hareket eden bir işçi arı olarak işe alınırsınız.

Ancak sıralama konusunda en düşük geliştirici olsanız bile, bu hala doğru değil. Buradaki anahtar, kendinizi yalnızca en düşük geliştirici olarak algıladığınızı fark etmektir. Hiç bu kişisel algının üstesinden gelmeye çalıştınız ve aslında bir şey için sorumluluğu üstlendiniz mi?

Al! Birisi sizi sorumlu kılana kadar beklemeyin.

• Sorunu görüyorsunuz, ancak bu konuda bir sözünüz yok.
• Teknik borcu ölçmüyorum veya araçlar aramıyorum.
• Görevlerinize kilitlisiniz. Ekstra ücret ödemezsiniz.
• Aramanız değil. Sen yönetim değilsin.

Tipik olarak tam tersi: Paraya değdiğinizi gösterdiğinizde, size daha fazla ödeme yapılır ve fikrinize daha fazla saygı gösterilir . "Daha önce yap", tersi değil.

Ekibimdeki insanlardan beklediğim tam olarak şudur: Oluşturmaya çalıştığımız proje veya ürün ve bu çaba ile ilgili tüm süreçler için sorumluluk duygusu. Ekibimdeki bir kişi sorumluluk üstlenerek beni etkilediğinde, örneğin iyileştirme önermek, hatta kendi başlarına iyileştirmeye başlamak daha iyi olduğunda, bunlar terfi edecek insanlardır.

Başka bir deyişle: Hiç kimse işçi arıları teşvik etmiyor, insanlar pasif olarak kendilerine atanan görevleri bekliyorlar, inisiyatifin en ufak bir göz kırpmasından bile yoksunlar, çünkü bunun için ödeme yapılmıyor , nihayet hiç şansları olmadığı için sızlanan .

Tabii ki, tüm bunlar yine şirketinizin kültürüne, Joel'in Arthur tarafından bağlanan "İki Hikayede" ne ilişkin olduğuna bağlıdır. Eğer şirket yöneticileri, kendi halkının ilerleme kaydetmesini gerçekten aptallarsa, dalgalanma oranı muhtemelen çok yüksektir ve bundan sonuç çıkarmanın zamanı gelmiş olabilir. Ancak durum böyle değilse, asıl sorun kendi içinizde olabilir.

Sen bir profesyonelsin. İşvereniniz sizi profesyonel olmanız için işe aldı. Yani, kaygıları sen uzmanları istediğimiz aynı şekilde muamele Eğer tedavi etmek işe kendi mesleki görüşler . Özellikle, diğer optimizasyonların maliyeti beklenmedik şekilde artırmaması koşuluyla, yol boyunca gerekli optimizasyonları ve düzeltmeleri yapmasını beklersiniz.

Örneğin, lambanın değiştirilmesi için arabanızı bir tamirciye götürdüğünüzü varsayalım. Tamirci dört şeyi fark eder:

1. Lambaya giden tel yıpranmış ve tehlikelidir. Ancak, maliyeti önemli ölçüde artırmadan kesilebilir. Ondan kabloyu düzeltmesi için birkaç dakika geçmesini beklersiniz, muhtemelen fark etmeden.
2. Bir cıvata gevşek. Tamamen ilgisiz, sadece gördü. Gerekli sürücüyü alıp sıkmak için 20 saniyelik zamanı var; yani, onu yapmasını beklersiniz.
3. Lambanın şasisi çatlar, bu da lambanın çınlamasına neden olur. Değiştirilmesi pahalı. Ve bu gerekli değil. Bu yüzden sizi bu konuda soru sormaya çağırıyor - "hayır" derseniz , ziyaret özetinize yazılı bir öneri ekler .
4. Aracın altında oldukça fazla fren hidroliği var. Birinin sızıntıyı düzeltmesine izin verene kadar arabayı kullanmanızı önlemek için profesyonel olarak bile gerekli ve hatta gerekli olabilir .

Bu senaryoların her birinin ve eminim başkalarının yazılım geliştirmede paralellikleri vardır - özellikle de kendinizi herhangi bir seviyede profesyonel olarak kabul ediyorsanız . Bir profesyonel olarak, çok az istisna dışında, işiniz, profesyonel anlayışınıza göre ürünü belirli bir şekilde geliştirmenin nihai hedefine ulaşmaktır .

1. Düzeltme ilgisiz olsun ya da olmasın önemsizse, düzeltmeyi yapın.
2. Düzeltme önemsiz ve gereksizse, üzerinde anlaştığınız resmi iletişim / sorun izleme mekanizmasını kullanarak resmi bir öneri yapın.
3. Birincil görevi gerçekleştirmek için düzeltmenin gerekli olduğu ancak beklenmedik bir şekilde maliyeti artıracak bir durum ortaya çıkarsa, kapsam değişikliğini bildirin.
4. Tespit edilen sorun projenin başarısı için ciddi bir tehdit oluşturuyorsa, bunu netleştirin. Resmen. Sorunun giderilmemesine (sağlık, acil durum veya nakliye sistemlerinde olduğu gibi) ilişkin etik kaygılar varsa, ürünün gönderilmesinden önce sorunun ele alınması konusunda ısrar edin (etik olarak gerekliyse medyaya veya yetkililere bildirin).

Bunu bir hukuk bürosundaki bir katipin etik dışı davranışlarla, bir fast food çalışanının sağlıksız davranışlarla veya bir park icra memurunun polisin yolsuzlukla savaştığı şekilde yapmasını sağlarsınız.

1. İyi bir örnek olun. Mümkün olduğunca temiz ve mantıklı kodlar üretin. Bir seçenek verildiğinde, ihtiyaçlarınızı karşılayanı daha az olumsuz olanı seçin. (Teknik borcun ipotek borcundan farklı olmadığını unutmayın - sadece sahip olmak mutlaka kötü bir şey değildir.)
2. Endişelerinizi iletin . Teknik bir borcu yönetmek ve şirketinizin kaynaklarını tahsis etmekle ilgili gerçek sorumluluğa sahip bir ekip lideri veya müşteri veya mimar olan birisine sahip olmalısınız. Kötü olduğuna inandığınız bir şey gördüğünüzde endişenizi onlara iletin. Girdilerinizi anlayacaklarından, yanıtlayacağından ve kredi vereceğinden emin değilseniz, bunu yazılı olarak (örneğin, bir e-posta) yazın.
3. Stres yapma. Teknik borç nadiren bir işletmenin istihdamın sona ermesine neden olur. Endişelerinizi ilettiğiniz ve işinizi yaptığınız sürece, teknik borç gibi mimarlık sorunları sizin probleminiz değildir. Evet, sizi etkileyebilirler, ancak şerifin yeniden seçilmesinden genç bir polis memurunun endişesi olmaktan daha fazla endişe etmiyorlar.

Sağladığınız örnekte, addtam özellik kayması olan bir işlevle, birkaç dakika ayırın ve neyin geliştirilebileceğinin ana hatlarını çizin. Uygulamak için onaya ihtiyaç duyacağınız kişiye gönderin ve devam edin.

İşletmenizin son derece yetkin kişiler tarafından yönetildiği ve doğru bir şekilde yapılandırıldığı varsayıldığında, endişeniz bir karar için doğru sistem tasarımcısına yönlendirilecek veya önerinizi uygulamanız için size yol verilecektir. Küçük bir geliştirici olarak, işletmenizin teknik borçtan ziyade nasıl çalıştığını öğrenmek hakkında daha fazla endişe duyarım - ve ilkini biliyorsanız, ikincisini nasıl ele alacağınız açık olmalıdır.

Çalışanlarının katılmasını istemeyen bir organizasyonu hiç duymadım. Siz sadece görevleri yerine getirmeniz için para ödendiğini söylüyorsunuz. Aklınızda doğru görevlerin bulunduğundan şüphe duyuyorum. Çünkü size iyi bir yazılım yazmanız için para ödeniyor.

Bu sorumluluğu üstlenin. Tabanı destekleyemiyorsanız özellikler eklemeye hayır deyin. Uzmanlığınızla müşteriye tavsiyelerde bulunun. Artık çok geç olmadan ve tüm projeyi atmak zorunda kalmadan önce frenlere basın, çünkü artık bakım yapılmayacak.