Bir fenomeni bildiğinizi varsayıyorum: bir yazılım projesi üzerinde çalışın ve bir hata keşfedin. Aslında hemen çözmelisiniz, ancak şu anda zaten geç bir işlevle meşgulsünüz. Hatayı düzeltmek için, bir bağımlılığı da güncellemelisiniz, bu kolayca mümkün değildir, bu nedenle kodun bazı alanlarında değişiklik yapmalısınız.
Duyuru
Zaten geç kaldığımdan beri, akla gelebilecek tek kararı veriyorlar: Bugfix'i “daha sonra” olarak taşıyorlar. Ancak, atlama noktası: bu “daha sonra” asla gerçekleşmez. Bu, bir süre sonra büyük bir teknik borç dağıyla karşı karşıya kaldığınız ve kendinize sorduğunuz anlamına gelir: Şimdiye kadar nasıl gelebilir?
Kırık pencereler teorisi
Bu durum hiç yeni değil. Ayrıca bir isim taşır: “Kırık Pencere Teorisi”. Bu, Windows işletim sisteminin tekrar kusurlu olduğu anlamına gelmez, ancak terim kentsel planlamadan kaynaklanır. İlişkili fikir basit ve aynı zamanda etkilidir: Suçun görünüşe göre şehrin bazı bölgelerinde kavrayabilmesinin nedeni budur. Kırık pencereler teorisinin tezi, bunun bölgeler ihmal edildiğinde gerçekleştiğini belirtir. Örneğin, binalar kalıcı olarak boş ve boş değilse – muhtemelen uzun süre beklendiği gibi – yıkılmamışlardır.
Önerilen editoryal içerik
Rızanızla, burada harici bir YouTube videosu (Google Ireland Limited) burada davet edilir.
YouTube videosu her zaman yüklenir
YouTube videosu artık yüklüyor
Alman yazılımının kalitesi için sıfır tolerans //
Bunun bir sembolü olarak, Amerikalı sosyal araştırmacılar James Wilson ve George Kelling, 80'lerin başında kırık pencereyi seçtiler: bir pencere durduğunda ve hiç kimse yerini almadığında, kimsenin umursamadığını gösteriyor. Ancak, kimse kalıcı olarak kırık bir pencereye sahip boş bir evin yanında yaşamak istemediğinden, ilk komşular yakında devam edecek.
Bunu diğer boş evler izler ve birisi muhtemelen er ya da geç bir pencere başlatır. Bu, çeyreğin azalmaya devam ettiği, sosyal uyum kendini zayıflattığı bir zincir reaksiyonu yaratır ve bir noktada birisi istese bile bir şeyi değiştirmek çok zor olabilir. Bu, sonunda tüm süreci hızlandıran suçla ilgili inhibisyon eşiğini azaltır.
90'larda New York
Önemli soru şimdi böyle bir gelişmenin kontrol altında nasıl rapor edilebileceğidir. Aslında, geçmişte zaten işe yaramış bir cevap var, örneğin 90'larda New York'ta. Başlangıçta tarif edilen durum statükoyu tanımladı ve o zaman belediye başkanı (1994'ten 2001'e kadar Donald Trump'ın eski bir hukuk danışmanı olarak bilebileceğiniz Rudolph Giuliani idi), “sıfır sıfır toleransını izledi. Suç “Stratejisi.
Adından da anlaşılacağı gibi, sahte otopark gibi daha küçük suçlarla bile ihlallere hoşgörü olmamakla ilgilidir. Bu bağlamda, sonraki yıllarda suç oranı aniden düştüğünde başarılı oldu. Ancak, polisin bu sürekli varlığının çok ileri gittiği için eleştirildiği uygulanmamalıdır. Özellikle Amerika Birleşik Devletleri'nden, elbette açıkça isteyen polis şiddetini ve ırkçı yaklaşımı duyabilirsiniz. Özetle, doğru dengeyi bulmak zordur, ancak açıkçası sıfır tolerans stratejisi suça önemli ölçüde katkıda bulunur.
Yazılımın geliştirilmesine referans
Bunun yazılımın geliştirilmesi ile ne ilgisi var? Kırık Windows teorisi mükemmel bir şekilde aktarılabilir. Özetle: Çözülmemiş her hata kırık bir penceredir. Bakımı yapılması, ancak olmaması gereken her kod satırı kırık bir penceredir. Güncellenmeyen herhangi bir eski bağımlılık kırık bir penceredir. Ve benzeri. Başka bir deyişle, sıfır tolerans stratejisi ile kod tabanınızı sürekli olarak ele almazsanız, bu kaçınılmaz olarak projenizde azalan bir spirale yol açar.
Neden? Çünkü hatalar ve teknik borçlar toplanır. Bu, bir noktada çözme çabasının sürekli büyüyeceği anlamına gelir. Aynı zamanda bir şeyler yapma riski de vardır. Her ikisi de kimsenin koda girmemesini sağlar, bu da sadece daha fazla hataya ve hatta daha fazla teknik borca yol açar. Kararsız bir taban başlangıçtan itibaren kurulur ve dayanmaya devam eder ve kaçınılmaz olarak çöken bir kart evine ayrılıncaya kadar bu yapıyı hala kırılgan hale getirir.
Buna ek olarak, mevcut modülleri uyarlama veya genişletme korkusu vardır, çünkü bir işlevin bu kırılgan yapının yükleme haritası olup olmadığını bilmiyorsunuz. Sonuç olarak, gelişimi karmaşık, yavaş ve pahalı hale getiren mevcut kodun her yerinde. Ve bu istikrarsızlık nedeniyle, kimse dış bağımlılıklardan kurtulmaya cesaret etmek istemiyor çünkü bu çaba anlamına geliyor. Bu nedenle, görünüşe göre işe yarayan sürümlerle birlikte olmayı tercih edersiniz, ancak bu uzun vadede güncelleme seçeneklerini yükler ve hızla güvenlik boşluklarına veya çözülmemiş sorunlara yol açar.
Açıkçası, bir projenin kodunun kalitesi konusunda endişelenmemek risklidir. Ama başka bir faktör daha var: Pencereleri kırık olan bir alandan ayrılan ilk komşular kimler? Bunlar her zaman sorunsuz bir şekilde karşılayabilenlerdir. Yazılım projelerinde, genellikle ilk gidecek olan özellikle yetenekli geliştiricilerdir – ve maalesef bunlar tam olarak durumu kurtarmak için ihtiyaç duydukları insanlardır, çünkü hala geniş bir deneyim ve deneyime sahiptirler.
Gözlerini kapatın mı?
Son derece dramatik görünüyor. Ama bu böyle gerçek. Muhtemelen sayısız konu bulacaksınız, bu yüzden sizinle geliştirme başka bir şekilde performans gösteremez. Ama tam olarak bunun hakkında konuştukları şey bu. Gözlerinize kapatmak ve inanmak için, diğerleri artık göremiyor, bu anaokulunda mantıklı olabilecek bir davranıştır, ancak yazılımın gelişiminde işe yaramaz. Kaç şirketin bu yaklaşımı tekrar tekrar seçmesini korkutucu buluyorum.
Şimdi yazılım projenizde zaten kırılmış bazı dilimleri nasıl tanıdıklarını merak edeceksiniz. Bu yüzden size bazı tipik işaretler vermek istiyorum. Bu listenin belirli bir siparişi yoktur, akla gelince listeliyorum.
Örneğin kırık pencerelerin göstergeleri şaşırtıcı derecede uzundur ve muhtemelen inşaat ve dağıtım sürelerini daha da arttırır. “Todo” veya “FixMe” gibi yorumlar içeren kod bile ağırlıklandırılmalıdır. Sorunları tamamen ortadan kaldırmak yerine alternatif çözümler ve geçici çözümler düzenli olarak uygulanıyorsa, bu bir uyarı sinyalidir. Test kapsamı zaman içinde azalırsa, zaten çözülmüş hatalar tekrar gerçekleşirse, belgeler yoktur veya yanlış veya eski ise, bunların hepsi kırık pencerelerin belirtileridir.
Teknik etkinlikler için daha fazla bilet geldiğinde bağımlılıkları güncellenmezse kimsenin dokunmak istemediği kod alanları varsa – bunlar bir şeylerin yanlış olduğuna dair göstergelerdir. Ve tüm bu olaylar buzdağı gibidir: ilk gördüğünüz sadece üst ve gerçek uzatma gizli kalır. Bu yüzden durumu önemsiz şeyler olarak reddederek hafife almayın. Asıl sorun genellikle başlangıçta göründüğünden çok daha büyük.
Duyuru
Zaten geç kaldığımdan beri, akla gelebilecek tek kararı veriyorlar: Bugfix'i “daha sonra” olarak taşıyorlar. Ancak, atlama noktası: bu “daha sonra” asla gerçekleşmez. Bu, bir süre sonra büyük bir teknik borç dağıyla karşı karşıya kaldığınız ve kendinize sorduğunuz anlamına gelir: Şimdiye kadar nasıl gelebilir?
Kırık pencereler teorisi
Bu durum hiç yeni değil. Ayrıca bir isim taşır: “Kırık Pencere Teorisi”. Bu, Windows işletim sisteminin tekrar kusurlu olduğu anlamına gelmez, ancak terim kentsel planlamadan kaynaklanır. İlişkili fikir basit ve aynı zamanda etkilidir: Suçun görünüşe göre şehrin bazı bölgelerinde kavrayabilmesinin nedeni budur. Kırık pencereler teorisinin tezi, bunun bölgeler ihmal edildiğinde gerçekleştiğini belirtir. Örneğin, binalar kalıcı olarak boş ve boş değilse – muhtemelen uzun süre beklendiği gibi – yıkılmamışlardır.
Önerilen editoryal içerik
Rızanızla, burada harici bir YouTube videosu (Google Ireland Limited) burada davet edilir.
YouTube videosu her zaman yüklenir
YouTube videosu artık yüklüyor
Alman yazılımının kalitesi için sıfır tolerans //
Bunun bir sembolü olarak, Amerikalı sosyal araştırmacılar James Wilson ve George Kelling, 80'lerin başında kırık pencereyi seçtiler: bir pencere durduğunda ve hiç kimse yerini almadığında, kimsenin umursamadığını gösteriyor. Ancak, kimse kalıcı olarak kırık bir pencereye sahip boş bir evin yanında yaşamak istemediğinden, ilk komşular yakında devam edecek.
Bunu diğer boş evler izler ve birisi muhtemelen er ya da geç bir pencere başlatır. Bu, çeyreğin azalmaya devam ettiği, sosyal uyum kendini zayıflattığı bir zincir reaksiyonu yaratır ve bir noktada birisi istese bile bir şeyi değiştirmek çok zor olabilir. Bu, sonunda tüm süreci hızlandıran suçla ilgili inhibisyon eşiğini azaltır.
90'larda New York
Önemli soru şimdi böyle bir gelişmenin kontrol altında nasıl rapor edilebileceğidir. Aslında, geçmişte zaten işe yaramış bir cevap var, örneğin 90'larda New York'ta. Başlangıçta tarif edilen durum statükoyu tanımladı ve o zaman belediye başkanı (1994'ten 2001'e kadar Donald Trump'ın eski bir hukuk danışmanı olarak bilebileceğiniz Rudolph Giuliani idi), “sıfır sıfır toleransını izledi. Suç “Stratejisi.
Adından da anlaşılacağı gibi, sahte otopark gibi daha küçük suçlarla bile ihlallere hoşgörü olmamakla ilgilidir. Bu bağlamda, sonraki yıllarda suç oranı aniden düştüğünde başarılı oldu. Ancak, polisin bu sürekli varlığının çok ileri gittiği için eleştirildiği uygulanmamalıdır. Özellikle Amerika Birleşik Devletleri'nden, elbette açıkça isteyen polis şiddetini ve ırkçı yaklaşımı duyabilirsiniz. Özetle, doğru dengeyi bulmak zordur, ancak açıkçası sıfır tolerans stratejisi suça önemli ölçüde katkıda bulunur.
Yazılımın geliştirilmesine referans
Bunun yazılımın geliştirilmesi ile ne ilgisi var? Kırık Windows teorisi mükemmel bir şekilde aktarılabilir. Özetle: Çözülmemiş her hata kırık bir penceredir. Bakımı yapılması, ancak olmaması gereken her kod satırı kırık bir penceredir. Güncellenmeyen herhangi bir eski bağımlılık kırık bir penceredir. Ve benzeri. Başka bir deyişle, sıfır tolerans stratejisi ile kod tabanınızı sürekli olarak ele almazsanız, bu kaçınılmaz olarak projenizde azalan bir spirale yol açar.
Neden? Çünkü hatalar ve teknik borçlar toplanır. Bu, bir noktada çözme çabasının sürekli büyüyeceği anlamına gelir. Aynı zamanda bir şeyler yapma riski de vardır. Her ikisi de kimsenin koda girmemesini sağlar, bu da sadece daha fazla hataya ve hatta daha fazla teknik borca yol açar. Kararsız bir taban başlangıçtan itibaren kurulur ve dayanmaya devam eder ve kaçınılmaz olarak çöken bir kart evine ayrılıncaya kadar bu yapıyı hala kırılgan hale getirir.
Buna ek olarak, mevcut modülleri uyarlama veya genişletme korkusu vardır, çünkü bir işlevin bu kırılgan yapının yükleme haritası olup olmadığını bilmiyorsunuz. Sonuç olarak, gelişimi karmaşık, yavaş ve pahalı hale getiren mevcut kodun her yerinde. Ve bu istikrarsızlık nedeniyle, kimse dış bağımlılıklardan kurtulmaya cesaret etmek istemiyor çünkü bu çaba anlamına geliyor. Bu nedenle, görünüşe göre işe yarayan sürümlerle birlikte olmayı tercih edersiniz, ancak bu uzun vadede güncelleme seçeneklerini yükler ve hızla güvenlik boşluklarına veya çözülmemiş sorunlara yol açar.
Açıkçası, bir projenin kodunun kalitesi konusunda endişelenmemek risklidir. Ama başka bir faktör daha var: Pencereleri kırık olan bir alandan ayrılan ilk komşular kimler? Bunlar her zaman sorunsuz bir şekilde karşılayabilenlerdir. Yazılım projelerinde, genellikle ilk gidecek olan özellikle yetenekli geliştiricilerdir – ve maalesef bunlar tam olarak durumu kurtarmak için ihtiyaç duydukları insanlardır, çünkü hala geniş bir deneyim ve deneyime sahiptirler.
Gözlerini kapatın mı?
Son derece dramatik görünüyor. Ama bu böyle gerçek. Muhtemelen sayısız konu bulacaksınız, bu yüzden sizinle geliştirme başka bir şekilde performans gösteremez. Ama tam olarak bunun hakkında konuştukları şey bu. Gözlerinize kapatmak ve inanmak için, diğerleri artık göremiyor, bu anaokulunda mantıklı olabilecek bir davranıştır, ancak yazılımın gelişiminde işe yaramaz. Kaç şirketin bu yaklaşımı tekrar tekrar seçmesini korkutucu buluyorum.
Şimdi yazılım projenizde zaten kırılmış bazı dilimleri nasıl tanıdıklarını merak edeceksiniz. Bu yüzden size bazı tipik işaretler vermek istiyorum. Bu listenin belirli bir siparişi yoktur, akla gelince listeliyorum.
Örneğin kırık pencerelerin göstergeleri şaşırtıcı derecede uzundur ve muhtemelen inşaat ve dağıtım sürelerini daha da arttırır. “Todo” veya “FixMe” gibi yorumlar içeren kod bile ağırlıklandırılmalıdır. Sorunları tamamen ortadan kaldırmak yerine alternatif çözümler ve geçici çözümler düzenli olarak uygulanıyorsa, bu bir uyarı sinyalidir. Test kapsamı zaman içinde azalırsa, zaten çözülmüş hatalar tekrar gerçekleşirse, belgeler yoktur veya yanlış veya eski ise, bunların hepsi kırık pencerelerin belirtileridir.
Teknik etkinlikler için daha fazla bilet geldiğinde bağımlılıkları güncellenmezse kimsenin dokunmak istemediği kod alanları varsa – bunlar bir şeylerin yanlış olduğuna dair göstergelerdir. Ve tüm bu olaylar buzdağı gibidir: ilk gördüğünüz sadece üst ve gerçek uzatma gizli kalır. Bu yüzden durumu önemsiz şeyler olarak reddederek hafife almayın. Asıl sorun genellikle başlangıçta göründüğünden çok daha büyük.