Büro bürokrasisi kod kalitesini nasıl etkiler [kapalı]


22

Büro bürokrasisinin son kod kalitesi sonucunu doğrudan etkilediği hikayelerle ilgileniyorum .

Örneğin, bir arkadaş az önce bana önceki çalışma yerinde sürüm kontrol sisteminin öylesine hantal olduğunu söyledi ki, programcıların VCS tanrılarından izin almadan yeni "modüller" (kaynak ağacındaki kök dizinler) oluşturmalarına izin verilmedi. Sonuç, programcıların bürokratik bir adım atmak istememeleriydi ve hizmetlerini doğru bir şekilde birleştirmek yerine, işlevsellik sadece modülün mevcut tanımına ya da modülün isminin uzaktan tanımlanmasıyla ilgili olsa bile, mevcut modüllerin üstüne ilişkisiz işlevsellik kazıyorlardı. Geçmişte yoluydu. (bir modülü yeniden adlandırmaktan bahsetmiyorum bile ...)

Benzer ofis, operasyonel ya da nihayetinde belki de istemeden yazılım kalitesini etkileyen başka bir bürokrasinin öyküsü ile ilgileniyorum.


Bu çok çok ilginç bir soru ...

1
Onu tehlikeye sok. Bunun için iyi hikayelerim olduğunu biliyorum, ama düşünmemeye çalıştığım bir şey. :)
George Marian,

1
@Bu soru için +1 aldatma noktası elde edersiniz;)
Eran Harel

Bu soru doğal olarak olumsuz ve yıkıcı / eleştirel cevaplar davet ediyor. Teknik çözüm, insani çözüm, yanal düşünme, vb.
JBRWilkinson

1
@JBRWilkinson Acıyı paylaşmanın ve eğlenirken yanlış olan ne? Bu ... diğer insanlar, belki de sıra programcıları yardımcı olacağız olur
Ran

Yanıtlar:


6

Büro bürokrasisinin son kod kalitesi sonucunu doğrudan etkilediği hikayelerle ilgileniyorum.

Bürokrasinin kod kalitesi üzerinde kişisel dinamikleri ve ofis politikaları kadar etkili olduğunu sanmıyorum. Bürokrasinin süreçle ilgisi var. Mevcut bir süreç uygun olmayan bir şekilde yapıldığında (veya olumsuz bir şekilde kullanıldığında ... aşağıya bakınız), teslimat veya ani değişikliklere tepki verme yeteneğini olumsuz yönde etkileme potansiyeli vardır . Bununla birlikte, işlem eksikliğinin kod kalitesi üzerinde kesin ve önemli bir etkisi olacaktır. Ya da daha kesin olmak gerekirse, kod kalitesini yönetmeyen bir işlem (ayrıca kod kalitesi süreci olarak da yorumlanır) kod kalitesini etkiler.

Diğer bir deyişle, bürokrasinin kendisi değil, sömürüldüğünde kod kalitesini etkileyen ya da yanlışlıkla çılgınca bir biçimde, bürokrasideki KG ile ilgili özel delikleridir.

Bununla birlikte, kişisel dinamikler ve ofis politikaları, kötü kodda suçlu olmaktan çok daha fazlasıdır. Kişisel dinamikler, her şeyden önce mesleki etik eksikliğini içerir. İnsanların kötü kod yazdığı argümanını gerçekten almıyorum, çünkü daha iyi bilmedikleri veya iyi eğitilmedikleri için . İnsanları CS ile ilgili derecelerde düzgün kod yazarken gördüm. Bu bir zihinsel durum ve kişisel ve düzenli ve titiz bir meseledir.

Büro politikaları daha da korkunç bir rol oynamaktadır. Düşünme zorlayan patronlar , sadece mantrayı kodlayın (daha sonra sadece kodlamaları, göndermeleri ve sonraları temizlememiz gereken zamanlar olsa da); şu an kapıdan bir şey almakla birlikte mükemmel kod olduğunu düşündüklerini sunmakta ısrar eden geliştiriciler esastır; ** delikleri olan kod gözden geçiricileri; kabin savaşları ve bunun gibi. Bu şeyler sorunlu kişisel dinamikleri şiddetlendirir. Hem sürecin herhangi bir çatlağı (bürokrasi) hem de bunların eksikliğinden kaynaklanan sızıntı kombinasyonu, kod kalite güvencesinde bozulmaya neden oldu.

Bürokrasideki delik, eğer post-morten incelemeleri ve sürekli iyileştirme kültürü varsa çözülebilirdi. Ancak, olumsuz kişisel dinamikler ve yıkıcı ofis politikaları, süreçte bu tür düzeltmeler yapılmasını önler, böylece mevcut sorunları (kod kalitesiyle ilgili olanlar da dahil olmak üzere) sürdürür.

Bürokrasi kendi başına nadiren kötü kod kalitesindeki suçludur. Aslında kod kalitesi ve bürokrasinin olumsuz kişisel dinamiklerden ve ofis politikalarından olumsuz yönde etkilendiğini söyleyebilirim.


hayır tam olarak beklediğim komik cevap türü değildi, ama kesinlikle düşünceli bir cevap verdim, bu yüzden "kabul" olarak işaretleyeceğim, daha fazla hikaye uçarken
görmekle

1

Projedeki bazı modüller üzerinde çalışmayı bıraktım, çünkü kod inceleme uzmanı bir Smart A $$ idi.


1

Yakın tarihli bir projede, kaliteli insanlar resmi ünite testlerine ilişkin birçok zorunluluk vardı (izlenebilirlik, kodlama kuralları, resmi incelemeler, ...). Kodlayıcılar artık birim testleri yazmazlar, yalnızca kodlarında hata ayıklarlar. Bu, sadece yeniden adlandırılan aynı görevdir, aynı teknik sonuçlara yol açar, ancak idari güçlük yoktur.


5
Birim testleri, kodlama hatalarını yakalamak için otomatik olarak çalışan kod parçalarıdır. Koşmak için özgürler. Çok fazla hata ayıklama harcayan insanlar saatte kişi başına $$$ tutar. Yalnızca bir geliştirici ayrılırsa, ekibin hata ayıklama yeteneği azalır, ancak birim testleri yine de iyi olur.
JBRWilkinson
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.