Yönetmeliğin kodun berbat olduğunu söylemenin doğru bir yolu var mı?

Kodumuz kötü. Her zaman kötü olarak kabul edilmemiş olabilir, ama kötüdür ve sadece yokuş aşağı gidiyor. Üniversiteden bir yıldan daha az bir süre önce yeni başladım ve kodumuzdaki birçok şey beni inancın ötesinde tutuyor. İlk başta, yeni adam olarak kod üssümüz hakkında biraz daha fazla şey öğrenene kadar ağzımı kapalı tutmam gerektiğini düşündüm, ancak bunun kötü olduğunu bildiğim için çok şey gördüm.

Önemli noktalardan bazıları:

• Hala çerçeveler kullanıyoruz (querystring'den bir şeyler almaya çalışın, neredeyse imkansız).
• VBScript
• Kaynak Güvenli
• .NET'i kullanıyoruz - demek istediğim, COM DLL'leri çağıran ve kolayca hata ayıklamayı neredeyse imkansız kılan .net sarmalayıcılarımız var.
• Her şey temelde dev bir fonksiyondur
• Kod bakımı yapılamıyor. Her sayfa, her yeni sayfa yapıldığında oluşturulan birden fazla dosyaya sahiptir. Ana sayfa, HTML'yi (runat = "server"? Mümkün değil) oluşturmak için temelde Response.Write () bir kaç kez çalışır. Bundan sonra, müşteri tarafında bir çok mantık olabilir (VBScript), ve nihayet, sayfa kendi kendine gönderir (çoğu zaman gizli alanlara birçok şeyi saklamakta zaman alır); Veritabanına veri.
• Aldığımız özellikler gülünç. Çoğu zaman, Y alanını veya alan Z'yi ne zaman seçeceklerini belirtmeksizin "X alanını Y alanını otomatik olarak doldur veya X alanını otomatik doldur" gibi şeyleri ararlar.

Bunun bir yazılım şirketinde çalışılmamasının bir sonucu olduğuna eminim, ancak yazılım yazan kişilerin en azından kodlarının kalitesini dikkate alması gerektiğini düşünüyorum. Yakında bir şey yapılacağını düşünürsem, yakında büyük bir son teslim tarihi olduğu için yakında bir şeyler yapacağımı hayal edemiyorum, ancak kötü kod yazmaya ve kötü uygulamaları kullanmaya devam ediyoruz.

Ne yapabilirim? Bu sorunları nasıl gündeme getirebilirim? Ekibimin% 75'i benimle aynı fikirde ve geçmişte bu sorunları gündeme getirdi, ancak hiçbir şey değişmedi.

Aşırı tepki vermediğinizden emin olun. Sen yenisin, muhtemelen çok fazla başka yerde çalışmadın, ve "gerçek yaşam kodu" dünyasına hazırlanmadın. Gerçek hayat kodu korkunç bir şey. Güzel okul kodunuz ve saplantılı olarak ayarlanmış kişisel proje kodunuz bir nükleer reaktörün bodrumunda seks yaptı ve bebek bir zehirli atık kanalizasyonunda büyüdü; Bu iğrenç bir mutant.

Ancak haklı olduğunuzu ve kodun söylediğiniz kadar kötü olduğunu varsayarsak (yani yalnızca hatalı koddan daha kötüsü), o zaman endişelenmekte haklısınız. Takımınızla konuşun ve başkalarının yanında olup olmadığını belirleyin. Durumu iyileştirmek için çalışacağız - ekibin geri kalanı sorunu tanırsa ama umursamıyorsanız, zamanınızı boşa harcıyorsunuz.

Küçük olmak, muhtemelen liderlik yapacak durumda değilsindir. Kendinizi yönetmeye giderseniz, aynı zamanda genç olan yeni bir işe alım olarak, fikriniz dikkate alınmayacaktır. Lider geliştiricinizi veya en kıdemli üyelerden birini edinin. Yine, eğer yaşlıların hiçbiri ilgilenmiyorsa, zamanınızı boşa harcıyorsunuz.

Bazı üst düzey teknik kişileri ilgilendirebileceğinizi varsayarsak, sorunlu alanları ve olası çözümleri belirlemeye çalışırım. Örneğin, eğer "her şey temelde bir dev işlevdir" ise, bir dahaki sefere bu “dev işlev” de çalışıyorsanız, belki biraz düzeltici olmalısınız. Yine, herkesi yoluna sokman gerekiyor. Eğer probleminizin küçük parçalarından koparsanız ve parça parça ilerletirseniz, bunlar daha az problem olur. Bir kod parçasına her dokunduğunuzda geliştirilip geliştirilemeyeceğini düşünün.

Yönetimle oturmayacak ve 'her şey kötü ve yeniden yazılmaya ihtiyaç duyacaksınız' demeyeceksiniz. Bu onlar için bir anlam ifade etmiyor - çok pahalı ve potansiyel olarak çok riskli. Bunun yerine, sorunların olduğunun ve değişiklik yapıldıkça yavaşça iyileştirilmesi gereken bir planın olduğunun farkında olmaları gerekir. Korunabilir kodun yararları konusunda eğitilmelidirler. Bu sizden değil, teknik ve profesyonel olarak güvendikleri kıdemli bir kişiden gelmelidir.

Yeniden yazma tamamlandı mı? Neredeyse her zaman kötü bir fikir.

Sonunda yapabileceğin fazla bir şey yok çünkü yenisin. Kimse bir şeyleri geliştirmek istemiyorsa, o zaman deneyiminizi toplar ve bir sonraki yere taşınırsınız.

Oku Joel On Software - yapmanız asla şeyler. Sebepini anlayın, ardından kötü yazılım hakkında ve programcı tarafından değil, yöneticiler tarafından yazılmış nasıl düzeltileceği ile ilgili birkaç makale okuyun. Bu bilgilerle donanmış olarak, yöneticilerin anlayabileceği ve önemseyeceği bir şekilde onu düzeltmek için bir durum sunabileceksiniz. İpucu: İyi yöneticiler, zaman ve parayı yalnızca programcıların yapılması gerekenler hakkındaki görüş ve duygularına dayanarak harcamazlar.

"Bu kod saçma ve yeniden yazma ihtiyacı" teknik olarak doğru olsanız bile kesinlikle size geri atılacak.

"Mevcut proje programından aylarca sürebilir, daha ucuza mal olabilir ve daha güvenilir hale getirebiliriz." onların dikkatini çekecek (bu aşamada bunu yapmak istediğiniz HOW'dan bahsetmediğinize dikkat edin).

Ne dersen söyle, doğru olduğuna emin ol. Kötü olduğunu söylerseniz, yeniden yazma işleminizin kanlı iyi olması gerekir. Bir hafta alacağını söylerseniz, bir hafta olacağından emin olmalısınız ve iyi olmalısınız. Yeniden yapılandıran koddaki herhangi bir kusur size, ne olursa olsun, işi tekrarlamadıysanız, şahsen, çok pahalıya mal olacaktır. Eğer sizden önce biri orada bulunduysa ve mahvoldu ya da bir yeniden yazma sattıysa, pes ederseniz, yöneticiler aptallık yapmaktan hoşlanmazlar ve iki kez olmasına izin vermezler. Bu belirteçle, takip eden adamlar için batırma, sadece bir şansın olacak ...

Maliyeti belirli bir süre boyunca ya da proje sayısı boyunca yaymanın yollarını bulun. Yöneticiler riskten, spekülatif yatırımlardan ve negatif nakit akışından nefret ederler - yöneticileriniz dahilinde bunlara tolerans gösteriniz. Küçük, düşük riskli, düşük maliyetli bir öneri ile başlayın. Doğru olduktan sonra, daha büyük balıklara gidebilirsiniz.

Öncelikle, başlangıçta çalışmadığınız sürece ve programcı olarak çalıştığınız sürece orijinal goofy eski kodunu oluşturan siz olduğun sürece aptalca eski şeyleri bulacaksınız. Programlamada kariyer yapmayı planlıyorsanız, bu yumruklarla yuvarlanmanız gerekir.

İkincisi, eski sistemlerin iyileştirilmesi için genellikle maliyet üzerinde önemli noktalar vardır. Örneğin, 10 yaşında VB6 ve hala çalışan klasik ASP uygulamaları olan birden fazla şirket gördüm. Bazı durumlarda, bunun nedeni .NET'i taşımak için büyük bir projenin kötü bir şekilde başarısız olmasıydı. Diğerlerinde, nedeni "kırılmadıysa, tamir etmeyin" idi. Ancak, diğerlerinde, hareketin maliyeti makul olabilir çünkü eski sistemin neden olduğu sorunlar göz ardı edilebilecek kadar büyüktür.

Geçmişte büyük bir başarısızlığın olduğu durumlarda, bir değişiklik meydana getirmek neredeyse imkansızdır. Bu durumda özgeçmişinizi parlatın ve yeni bir iş aramaya başlayın. Bozulmamışsa, muhtemelen kodun kendisinden şikayet etmek için bir nedeniniz olmayacak ancak tatmin edici ve büyüyen bir kariyer yolunda bulunmadığınızdan emin olabilirsiniz. Kırılırsa ve sanki sizin durumunuzdaki gibi ses çıkarır, o zaman değişim şansınız olur.

Gördüğüm en iyi yaklaşım, çok fazla ısırmak değil, en olumlu etkiye sahip olacak artan değişikliklerle başlamak. Açıklamanıza göre, değişiklik isteklerini daha iyi yönetmek başlamak için bir yer olacaktır. Kontrol altına alındıktan sonra bir servis çerçevesi veya diğer artımlı tasarım / kod iyileştirmeleri oluşturmaya başlayabilirsiniz.

Gördüğüm en kötü yaklaşım, doğrudan eski bir sistemden en son ve en iyiye doğru büyük bir adım atmaya çalışmaktır; örneğin, çalışan ancak tıka basa bir VB6 / Klasik ASP / COM + sisteminden MVC / Entity Framework sistemine atlamak.

"Hey Boss, Büyük Proje'den sonra ben ve takım biraz zaman ister, ideal olarak X ay, kodumuzu düzenlemeyi istiyorlar. Dakikalar içinde yapılması gerekenler saatlerce sürüyor, çünkü hepsi çok dağınık. Büyük Projeden hemen sonra gerçekçi bir program planlamak istiyoruz. ”

(Azkar'ın soru hakkındaki yorumundan kısmen alıntı yapılmıştır)

Joel in Software'i okumaya başla (Joel Spolsky / Stack Exchange Kurucusu) ...

Yapacağım ilk şey bir Joel Testi yapmak .

Bu, “Bir geliştirici olarak geliştirmenin yollarını ararken… Geliştirme ortamları hakkındaki bu 12 soru testine rastladım, eğlenmek için onlara çalıştığım yer hakkında cevap verdim.” Olarak sunmanıza izin verecek. ... Bu da kişisel olarak sizin kodunuzla neyin yanlış olduğunu ana hatlarıyla gösteren bir üçüncü taraf yapar.

Pragmatik Uygulamalar hakkında daha fazlasını okuduğunuzda, kendinizi geliştirecek ve kırmızı / yeşil / refactor gibi şeyleri uygulayacaksınız ve bu da sırayla kod tabanını temizleyebilmenizi sağlayarak bakımını sağlar. (mesai)

Umarım yardımcı olur! Programlamaya hoş geldiniz (yesterdays kodu genellikle berbat) ;-)

Hızlı ipucu: nedenlerinin listesi ile yönetimini teklif yoksa neden daha farklı kod gereken bir argüman "Geliştirilmiş moral / programcılar için çalışma koşulları" olarak sayılabilir.

Teknik ekibin şu anki karmaşadan daha fazla içerik yazıp temiz kod tutacağını açıkça belirtin ve bu kesinlikle işe karşı tutumunuzu artırabilir. Yararlı bir argüman olabilir.

• Yönetim aslında tasarımı dikte ediyor mu? Arkandaki takımın çoğuna sahipseniz, sizi durduran nedir? Proaktif olun ve grup olarak karar verin. Artımlı olarak uygulamak için bir plan ile gel . O zaman yap.
• Yönetim, kullandığınız geliştirme araçlarını belirler mi? Bir takım yönetimini değiştirmek için bir zaman maliyeti olmadığı sürece, genellikle umursamıyor. Proaktif olun ve hangi geliştirme araçlarını kullanmak istediğinizi grup olarak belirleyin. Yönetimden satın almanız gerekiyorsa, onlara bir göç planı ve maliyet avantajı analizi gösterin . O zaman yap.
• Yönetim, kullandığınız dilleri belirler mi? Proaktif olun ve VBScript yerine ne kullanılacağına grup olarak karar verin. Artımlı olarak uygulamak ve yapmak için bir plan yapın. Yönetime ihtiyacınız varsa satın alma planlarını gösterin. O zaman yap.
• Teknik özellikler için hiçbir şeyim yok. Bu genellikle işinizdeki insanlara ve süreçlere bağlıdır. Neyin kırıldığını ve süreci düzeltmek için gereken asgari değişikliklerin belirlenmesi, şu anda işlerin nasıl yürüdüğünü ve nasıl çalışması gerektiğini analiz etmek ve anlamak zaman alır. Biliyorsanız bir plan ile gelip yönetimi ikna etmeye çalışabilirsiniz.

Çok fazla adanmış zaman içermeyen bir değişim yolu önerdiyseniz , bunun için gösterilecek (ya da yumuşak) ticari değeri olmayan daha fazla değişim ve saygı alırsınız .

Tecrübeden konuşma: Kolay değil. Bu neredeyse imkansız. Yönetim, kodun berbat olduğu ve büyük olasılıkla daha fazlasıyla tamamen cahil olduğu ve / veya karşı karşıya kaldığı sorunların ipucu olmadığını umursamıyor ya da uzun zaman önce düzeltmiş olacaklardı ve bugün onunla sıkışıp kalmayacaksınız. Yapabileceğiniz en iyi şey, kodun emdiği nedenlerin bir listesini yapmak ve ardından yeniden düzenleme / yeniden yazma işleminde gerçek işletme değerini göstermek için neden emrettiğinin nedenidir .

Bir örnek "Kod bakımı yapılamaz" olabilir:

Geçerli kod, X , Y ve Z nedeniyle sürdürülemez (neden elde edilemez olduğunu gösteren sebepleri listeler). Bu, değişiklik isteklerini ve yeni özelliklerin yapılmasını çok zorlaştırır, çünkü X , Y , Z (değişiklik yapmanın zor olmasının nedenleri). Değişiklikler zor olduğundan, geliştirme ekibi hata düzeltmelerine ve iyileştirmelere kolayca yanıt veremez.

Tek umudunuz, patronunuzun ve üst düzey yöneticinizin, kod için hangi sonuçları doğuracağını anlamak için çok aptalca olmadığı ve sorunları ele almak için yeni özellik istekleriyle ortaya çıkmayı bırakmaya istekli olduğudur, aksi halde çabalarınız boşuna gidecek. . Geçmiş deneyimlerden bahsetmişken, kodda yanlış bir şey görmeme ihtimalleri çok yüksektir ve / veya iş arkadaşlarınız endişelerini yönetime iletemeyecek kadar çaresizdir.

İyi şanslar. Buna ihtiyacın olacak.

"Üniversiteden yeni çıktım" - sorunuza cevap vermeliyim.

Yönetim muhtemelen orada kod alt optimal olduğunu biliyor. Çoğu kod, Ray Gosling, Guido Van Rossum veya bir başkasının yazması için gerçekten iyi ve pahalı bir işe almadığınız sürece geçerlidir.

Yönetim ayrıca şirketiniz için geçerli olan "işler" tanımını kullanarak çalıştığını da bilir (Kaza yapmaz, satmaz, raporları ya da başka bir şey vermez).

En düşük maliyetle "çalışmakta" kodunu korumanızı istiyorlar. Pahalı bir projenin her şeyi yeniden yazma teklifini istemiyorlar.

İş vakası yapmak neredeyse imkansızdır, çünkü teslim edilebilir durumunuz zarif bir kod değil çalışan bir yazılımdır (zaten sahip oldukları).

Yazılımda, ilk olarak özelliklerle pazara girmenin büyük bir fırsat maliyeti olduğunu da ekleyelim. Bunu gerçekten düşünüyorsanız, yatırımın uzun vadeli geri ödemesi garanti edilmez.

Bununla birlikte, yönetilebilir ısırıklar boyunca küçük şeyleri yeniden düzenlemek ve düzeltmek için hala iyi bir plandır (iyi bir VSS almak gibi). Sonuçta bu bir teknik değil, teknik bir konudur. Sadece verdiğin şeyi yerine getirirken yapman gerekenleri yap, iyi olacaksın. Yönetim, muhtemelen güçlü bir dava açsanız bile kod kalitesinin nitritli kumlu detaylarıyla ilgilenmeyecektir.

Sadece olabildiğince çabuk ayrıl (belki bir iş hunisi gibi görünmek istemediğin zaman çoktan ayrılma). Kodladıkları gerçeği bir karmaşa ve insanların orada kalması, muhtemelen zayıf geliştiricilerle çalışmakta olduğunuz anlamına gelir. İşlerini önemseyen herhangi bir iyi geliştirici, böyle bir saçmalık üzerinde uzun süre çalışmaya devam edemez.

Yeniden yazma şansı, çok net bir şekilde ortaya çıkmadıkça, oldukça düşük bir oranda meydana gelme şansı, yatırımın akıllıca yapılmaya değeceğini gösterir.

Yönetim kodu umursamıyor. Satmak için bir ürüne sahip olmayı önemsiyorlar.

Eski sistem gerçekten, gerçekten kötü ise ve ekibin çoğunluğu için saçma bir miktar ek yük ekliyorsa (çoğunluk diyorum çünkü her zaman büyük parçalara ya da hepsine kodlanmış bir adam var ve bunun arkası gibi biliyor). Elini) sonra onlara yaklaşmak ve geliştirme zamanında iş parasına mal olduğunu ve müşteri memnuniyeti ile etki yaratacağını söylüyor.

Ancak bir kez daha, kodları hala önemsemiyorlar, bir ürünü önemsiyorlar, bu yüzden cevap onları "Evet yapalım" diyebilse de, bir yöneticinin iznini almadan kodu düzeltebilirsiniz. Denize düşmeyin, önce takımla konuştuğunuzdan emin olun, hiç kimse gelmeyi sevmiyor ve 3 ay süren bu işlevi kullanmayı deniyor, şimdi çalışmaz görünüyor çünkü kullanım dışı kaldı.

Yaklaşım yönetimine, kodda büyük değişiklikler yapmanın bütçe etkilerini ve değişiklikleri yapmamanın bütçe etkilerini anladığınızı gösterecek şekilde yaklaşın. Emilio'nun sözlerini sevdim.

"Eski" kodun her zaman korkunç olacağı halde akılda tutulması önemlidir. Bununla, hepimiz sürekli olarak geliştiriciler olarak büyüyoruz. İyi kod yazarız, daha sonra daha iyi kod yazmayı öğreniriz ve önceki "iyi" kod korkunç görünür. Çok sayıda geliştirici sürekli olarak daha iyi hale gelmeye ve uzun vadede daha fazla para harcamayı denemeye yetişmektedir. Bu dengeleyici bir harekettir. Olduğu söyleniyor, gittikçe daha iyi hale gelebilirseniz her zaman harikadır. Bu dev işlevi değiştirmeye gittiğinde, ayır! Sonunda bir yere gideceksin.

Yapma

Büyük bir projeyi sıfırdan yeniden yazmak çoğu zaman yine de büyük bir hatadır.

Yöneticilere özellikle Proje Yöneticilerine kötü kod ve yeniden düzenleme hakkında bilgi vermenin kolay olacağını hiç düşünmedim. Birincisi, size güvenmeleri gerekir, kıdemli bir adam olsanız bile, hala güvenmek için zamana ihtiyacınız vardır. İkincisi, sorunun ne kadar kötü olduğunu anlamıyorlar. Bugün yeni bir sürüm yayınlayacak son günse ve oluşturma başarısız olur. Ne kadar ciddi olduğunu biliyorlar, ancak yapıların başarısız olduğunu asla bilmiyorlar çünkü kötü kod, yetersiz test vb. Gibi birçok sorun var.

Bir web projesinde yapılandırma ve dağıtım görevleri yaptım. Her zaman yeni bir yapı dağıtırken beklenmedik sorunları düzeltmek çok zaman alır. Sorunların çoğu güvenlik ve entegrasyondu (birkaç web / Windows uygulaması arasında). Kodumuz berbat, başkalarının kodu berbat, tamamen spagetti kodu.

Yeni bir sürüm planlıyorduk ve bazı yeniden düzenleme için şiddetle sordum, sadece hataların sıkça gerçekleştiği oturum açma / doğrulama koduna ayrıntı günlüğü ekleyin. Yöneticiler kabul etti, ancak daha sonra sahip olunması gereken bir listeye kondu ve zaten geniş bir özellik listesine ve sıkı bir zaman dilimine sahip olduğumuz için ne yapılacağını bilmiyorum.

İki tür yönetici vardır: Ne yaptığınızı, ne anlamadığını anlıyormuş gibi yapanlar. Yazılımı anlıyor gibi davrananlar size düşman olacaktır. Sadece sizin tarafınızdan rahatsız olmayan olanlar.

Her durumda, yöneticilerin hepsi yalancıdır, bu nedenle başkalarının olduğunu varsaymak için güçlü bir istekleri vardır.

Demek istediğim, yazılımın güncel olmadığını söylerseniz, bunu bir bahane olarak görecekler. Umursamıyorlar.