Umarım bu bir soru için çok genel değildir; Tecrübeli tavsiye alabilirim.

Son 10-20 yılını geniş bir kod üssünde bir araya gelerek geçiren oldukça küçük bir bilim insanı dükkanında tek "SW Mühendisi" olarak çalışmaktayım. (Gerçekten eski bir dilde yazılmış: G2 - Pascal'ı grafikli düşünün). Programın kendisi, karmaşık bir kimyasal işleme tesisinin fiziksel bir modelidir; Bunu yazan takım inanılmaz derecede derin alan bilgisine sahip ancak programlama temelleri konusunda resmi bir eğitim yok veya hiç yok. Kısa süre önce var olmayan konfigürasyon yönetiminin sonuçları hakkında bazı zor dersler öğrendiler. Bakım çabaları, kodun kendisinde belgelenmemiş "çamur" muazzam birikimiyle de büyük ölçüde engellenmektedir. Size durumun "politikasını" koruyacağım ( her zaman var siyaset!), ancak söylemeye yetecek kadar, ilerideki yol için neyin gerekli olduğu konusunda bir fikir birliği yoktur.

Benden takıma modern yazılım geliştirme ilkelerinin bazılarını sunmaya başlamamı istediler. Kodlama kuralları, yaşam döngüsü yönetimi, üst düzey tasarım kalıpları ve kaynak kontrolü ile ilgili endüstri standardı uygulamalardan ve stratejilerden bazılarını tanıtmamı istiyorlar. Açıkçası, bu oldukça göz korkutucu bir görev ve nereden başlayacağımdan emin değilim.

Başlangıçta, onları Pragmatik Programcı ya da Fowler's Refactoring'in ("Kod Kokuları", vb.) Temel kavramlarında öğretmeye meyilliyim . Ayrıca bir dizi Çevik metodoloji getirmeyi umuyorum. Fakat nihayetinde, etkili olmak için 5-7 çekirdek temelde bilemek zorunda kalacağımı düşünüyorum; Başka bir deyişle, gerçekçi olarak uygulamaya başlayabilecekleri en önemli prensipler veya uygulamalar nelerdir?

Yani bu benim sorum: Ne olur sen en etkili stratejiler listenizde spagetti düzeltmek yardımcı (ve ileride bunu önlemek) için dahil?

Önsöz

Bu gerçekten göz korkutucu bir iş ve ele alınması gereken çok şey var. Bu yüzden alçakgönüllülükle uygun takımlar ve eğitim materyali için işaretçilerle, ekibiniz için biraz kapsamlı bir rehber olarak öneriyorum.

Unutmayın: Bunlar kurallardır ve koşullara göre benimsenmesi, uyarlanması veya bırakılması anlamına gelir.

Dikkat: Bütün bunları bir takıma bir kerede bırakmak büyük olasılıkla başarısız olacaktır. Size en iyi ter için uygun olanı verecek elemanları seçmeye çalışmalı ve bunları birer birer yavaşça tanıtmalısınız.

Not: Tüm bunlar doğrudan G2 gibi Görsel Programlama Sistemleri için geçerli değildir. Bunlarla nasıl başa çıkılacağına dair daha ayrıntılı bilgi için , sondaki Ek bölümüne bakınız .

Sabırsızlar İçin Yönetici Özeti

• Bir katı proje yapısını tanımlayın :
  • Proje şablonları ,
  • kodlama kuralları ,
  • Bilinen yapı sistemleri ,
  • ve altyapınız ve araçlarınız için kullanım kılavuzu setleri .
• İyi bir SCM takın ve nasıl kullanacaklarını bildiklerinden emin olun.
• Onları teknolojileri için iyi IDE'lere yönlendirin ve nasıl kullanacaklarını bildiklerinden emin olun.
• Uygulamak kod kalite dama ve otomatik raporlama inşa sisteminde.
• Yapı sistemini sürekli entegrasyon ve sürekli denetim sistemleri ile birleştirin.
• Yukarıdakilerin yardımıyla, kod kalitesi "sıcak noktalar" ve refactor tanımlayın .

Şimdi uzun versiyon için ... Dikkat, kendinizi hazırlayın!

Sertlik (Genellikle) İyi

Sertlik genellikle size karşı çalışan bir güç olarak görüldüğü için bu tartışmalı bir görüşdür. Bazı projelerin bazı aşamaları için geçerlidir. Ancak bir kez yapısal bir destek, tahminde bulunmayan bir çerçeve olarak gördüğünüzde, boşa harcanan zaman ve emeğin miktarını büyük ölçüde azaltır. Senin için çalışsın, sana karşı değil.

Sertlik = Proses / Prosedür .

Yazılım geliştirme, kimyasal tesislerin veya fabrikaların el kitaplarına, prosedürlere, tatbikatlara ve acil durum kılavuzlarına sahip olma nedenleriyle aynı şekilde iyi işlem ve prosedürlere ihtiyaç duyar: kötü sonuçları önlemek, öngörülebilirliği artırmak, verimliliği en üst düzeye çıkarmak ...

Sertlik ölçülü geliyor!

Proje Yapısının Sertliği

Her proje kendi yapısına sahipse, siz (ve yeni gelenler) kaybedilirsiniz ve her açışınızda sıfırdan toplanmaları gerekir. Bunu profesyonel bir yazılım mağazasında istemiyorsunuz ve bunu laboratuarda da istemiyorsunuz.

Yapı Sistemlerinin Sertliği

Her proje farklı görünüyorsa, farklı inşa etme şansları da var . Bir yapı, çok fazla araştırma veya fazla tahminde bulunulmamalıdır. Sen kanonik şeyi yapmak ve özellikleriyle ilgili endişelenmenize gerek yoktur edebilmek istiyorum: configure; make install, ant, mvn install, vb ...

Aynı yapı sistemini yeniden kullanmak ve zaman içinde gelişmesini sağlamak aynı zamanda tutarlı bir kalite seviyesi sağlar.

READMEProjenin özelliklerini belirtmek için hızlı bir şekilde ihtiyacınız var ve varsa kullanıcı / geliştirici / araştırmacıyı incelikle yönlendirin.

Bu, yapı altyapınızın diğer bölümlerini de büyük ölçüde kolaylaştırır, yani:

• sürekli entegrasyon ,
• sürekli denetim .

Bu nedenle yapınızı (projeleriniz gibi) güncel tutun, ancak zamanla daha katı ve ihlalleri ve kötü uygulamaları bildirmede daha verimli olmasını sağlayın.

Tekerleği yeniden icat etmeyin ve daha önce yaptıklarınızı tekrar kullanın.

Önerilen Kaynaklar:

• Sürekli Entegrasyon: Yazılım Kalitesini Artırma ve Riski Azaltma (Duval, Matyas, Glover, 2007)
• Sürekli Teslimat: Yapma, Test Etme ve Dağıtma Otomasyonu ile Sotware Sürümlerini Yayınlayın (Humble, Farley, 2010)

Programlama Dillerinin Seçiminde Sertlik

Özellikle araştırma ortamında, tüm ekiplerin (ve hatta tüm geliştiricilerin) aynı dili ve teknoloji yığınını kullanmalarını bekleyemezsiniz. Bununla birlikte, bir dizi “resmi olarak desteklenen” araç tanımlayabilir ve bunların kullanımını teşvik edebilirsiniz. Gerisi, iyi bir gerekçe olmadan, izin verilmemelidir (prototiplemenin ötesinde).

Teknoloji yığınınızı basit tutun ve gerekli becerilerin korunmasını ve genişliğini minimum düzeyde tutun: güçlü bir çekirdek.

Kodlama Sözleşmelerinin ve Kılavuzlarının Sertliği

Kodlama kuralları ve yönergeler, hem ekip olarak bir kimlik hem de ortak bir dil geliştirmenize olanak sağlayan şeydir . Kaynak dosyayı her açtığınızda , terra gizli durumuna geçmek istemezsiniz .

Hayatı zorlaştıran ya da yasaklayan eylemleri, basit tek ihlallere dayanarak taahhütlerin reddedilme derecesine kadar açık yapan saçma kurallar bir yüktür. Ancak:

• iyi düşünülmüş bir temel kural, sızlanan ve düşünenlerin çoğunu elinden alır: hiç kimse hiçbir koşulda kırılmamalıdır;

• ve bir dizi önerilen kural ek rehberlik sağlar.

Kişisel Yaklaşım: Kodlama sözleşmeleri söz konusu olduğunda saldırganım, bazıları nazi bile diyor , çünkü ekibim için tanınabilir bir stil olan lingua franca'ya inanıyoruz . Bok kodu kontrol edildiğinde, bir Hollywood yıldızının yüzündeki soğuk bir yara gibi göze çarpıyor: bir incelemeyi ve bir işlemi otomatik olarak tetikliyor. Aslında, bazen uygun olmayan taahhütleri reddetmek için ön-işlemeli kancaların kullanımını savunmak kadar ileri gittim. Daha önce de belirtildiği gibi, aşırı çılgınca olmamalı ve üretkenlik yoluna gitmeli: onu sürmeli. Bunları yavaşça, özellikle başlangıçta tanıtın. Ancak, gerçek sorunlar üzerinde çalışamayacağınız hatalı kodu düzeltmek için çok fazla zaman harcamaktan daha çok tercih edilir.

Bazı diller bile tasarım gereği bunu zorlar:

• Java, onunla yazabileceğiniz donuk bok miktarını azaltmayı amaçlıyordu (şüphesiz birçokları bunu başarabiliyordu).

• Python'un girintili blok yapısı bu anlamda başka bir fikirdir.

• Tarzın doğasında var olan gofmther türlü tartışmayı ve çabayı ( ve ego !! ) tamamen ortadan kaldıran aracıyla git : gofmttaahhüt etmeden önce koş .

Kod çürümesinin kaymayacağından emin olun . Kod kuralları , sürekli entegrasyon ve sürekli denetim , çift ​​programlama ve kod incelemeleri bu şeytana karşı cephaneliğinizdir.

Ayrıca, aşağıda göreceğiniz gibi, kod dokümantasyondur ve bu, sözleşmelerin okunabilirliği ve açıklığı teşvik ettiği başka bir alandır.

Dokümantasyonun Sertliği

Belgeler kodla el ele gider. Kodun kendisi dokümantasyondur. Ancak bir şeylerin nasıl inşa edileceğine, kullanılacağına ve korunacağına dair kesin talimatlar olmalıdır.

Dokümantasyon için tek bir kontrol noktası kullanmak (bir WikiWiki veya DMS gibi) iyi bir şeydir. Projeler için boşluklar yaratın, daha rastgele şakalar ve deneyler için boşluklar yaratın. Tüm alanların ortak kuralları ve kuralları yeniden kullanmasını sağlayın. Bunu takım ruhunun bir parçası yapmaya çalış.

Kodlama ve takımlama için geçerli tavsiyelerin çoğu belgeler için de geçerlidir.

Kod Açıklamalarında Sertlik

Yukarıda da belirtildiği gibi kod yorumları da belgelerdir. Geliştiriciler kodlarıyla ilgili duygularını ifade etmeyi sever (bana sorarsanız, çoğunlukla gurur ve hayal kırıklığı). Bu nedenle, daha resmi bir metin parçası daha az patlayıcı ya da drama ile aynı anlamı taşıdığı zaman, yorumlarda (ya da hatta kodlarda) belirsiz terimlerle bunları ifade etmeleri alışılmadık bir durum değildir. Eğlenceli ve tarihi nedenlerden dolayı birkaç kişinin kaymasına izin vermek sorun değil: bu aynı zamanda bir ekip kültürü geliştirmenin bir parçası . Ancak, herkesin neyin kabul edilebilir ve neyin kabul edilmediğini bilmesi ve bu yorum gürültüsünün tam da şu olması önemlidir: gürültü .

Taahhüt Kayıtlarında Sertlik

Taahhüt kütükleri, SCM'nizin yaşam döngüsünün can sıkıcı ve işe yaramaz bir "adımı" değildir: zamanında eve gitmek veya bir sonraki göreve devam etmek ya da öğle yemeği için ayrılan arkadaşlarla yetinmek için atlamazsınız. Önemlidir ve (çoğu) iyi şarap gibi, zaman geçtikçe daha değerli hale gelirler. Yani onları doğru yapın. İş arkadaşlarının devasa işler veya açık olmayan saldırılar için tek gömlek yazdığını görünce şaşırdım.

Taahhütler bir nedenden dolayı yapılır ve bu nedenle ISN'T her zaman kodunuz ve girdiğiniz bir satırlık işlem kaydıyla açıkça ifade edilir. Bundan daha fazlası var.

Her kod satırının bir hikayesi ve bir geçmişi vardır . Farklılıklar onun tarihini anlatabilir, ama onun hikayesini yazmalısın.

Bu satırı neden güncelledim? -> Arayüz değiştiği için.

Arayüz neden değişti? -> Çünkü L1 tanımlayan kütüphanesi güncellendi.

Kütüphane neden güncellendi? -> Çünkü F özelliği için gerekli olan L2 kütüphanesi, L1 kütüphanesine bağlıydı.

Ve X özelliği nedir? -> Sorun izleyicideki görev 3456'ye bakın.

Bu benim SCM seçeneğim değil ve laboratuarınız için de en iyisi olmayabilir; ancak Gitbu hakkı alır ve kullanarak, daha çoğu diğer SCMS sistemlere göre iyi günlükleri yazmak için zorlar çalışır short logsve long logs. Görev kimliğini bağlayın (evet, birine ihtiyacınız var) ve izin için genel bir özet bırakın shortlogve uzun günlüğünde genişletin: Değişikliğin hikayesini yazın .

Bu bir günlük: Güncellemeleri takip etmek ve kaydetmek için burada.

Küçük Kural: Daha sonra bu değişiklik hakkında bir şey arıyorsanız, günlüğünüzün sorunuzu yanıtlaması olası mı?

Projeler, Dökümanlar ve Kodlar ALIVE

Onları senkronize tut, aksi halde artık bu simbiyotik varlığı oluşturmazlar. Sahip olduğunuzda harikalar yaratıyor:

• SCM'nizdeki günlükleri temizleyin, sorun izleyicinizdeki görev kimlikleriyle bağlantı kurun
• bu izleyicinin biletlerinin kendilerinin SCM'nizdeki değişikliklere (ve muhtemelen CI sisteminizdeki yapılara) bağlandığı,
• ve bunlara bağlanan bir dokümantasyon sistemi.

Kod ve dokümantasyon uyumlu olmalıdır .

Testte Sertlik

Başparmak Kuralları:

• Herhangi bir yeni kod (en azından) birim testleri ile gelmelidir.
• Herhangi bir yeniden düzenlenmiş miras kodu birim testleriyle birlikte gelir.

Tabii ki, bu ihtiyaç:

• aslında değerli bir şeyi test etmek (ya da zaman ve enerji kaybıdır),
• iyi yazılmış ve yorumlanmış olması (giriş yaptığınız diğer kodlar gibi).

Ayrıca belgeler ve kodunuzun sözleşmesinin ana hatlarını çizmeye yardımcı olurlar. Özellikle TDD kullanıyorsanız . Yapmasanız bile, iç huzurunuz için onlara ihtiyacınız var. Bunlar, yeni kod (bakım veya özellik) eklediğinizde ve kod çürümesi ve çevresel arızalara karşı korunmak için gözetleme kuleniz olduğunda emniyet ağınızdır.

Elbette, daha ileri gitmeli ve entegrasyon testlerini ve düzelteceğiniz her tekrarlanabilir hata için regresyon testlerini yaptırmalısınız .

Araç Kullanımında Sertlik

Ara sıra geliştirici / bilim adamının kaynakta yeni bir statik denetleyici denemek, bir başkasını kullanarak bir grafik veya model oluşturmak veya bir DSL kullanarak yeni bir modül uygulamak istemesi sorun değil. Ancak, tüm ekip üyelerinin bilmesi ve kullanması beklenen kanonik bir araç seti varsa en iyisidir .

Bunun ötesinde, üyelerin istediklerini TÜM oldukları sürece kullanmalarına izin verin:

• üretken ,
• Düzenli olarak yardım gerektiren DEĞİL
• Genel altyapınıza düzenli olarak ayar yapmamak ,
• Altyapınızı bozmamak (kod, yapı sistemi, dokümantasyon gibi ortak alanları değiştirerek…),
• Başkalarının çalışmalarını etkilememek ,
• İstenen herhangi bir görevi zamanında yapmak için ABLE .

Bu durumda değilse, varsayılanlara geri dönmelerini sağlayın.

Sertlik - Çok Yönlülük, Uyarlanabilirlik, Prototiplendirme ve Acil Durumlar

Esneklik iyi olabilir. Birinin ara sıra kesmek, çabuk kirletmek için bir yaklaşım veya işi yapmak için favori bir evcil hayvan aracı kullanmasına izin vermek iyidir. ASLA bir alışkanlık haline gelmesine izin vermeyin ve ASLA bu kodun desteklenecek gerçek kod temeli olmasına izin vermeyin.

Takım Ruhu Önemlidir

Codebase'inizde Gurur Duygusu Geliştirin

• Kodda bir Gurur duygusu geliştirin
  • Duvar panolarını kullan
    • Sürekli bir entegrasyon oyunu için lider kurulu
    • sorun yönetimi ve hata sayımı için duvar panoları
  • Bir sorun izci / hata izci kullanın

Suçlama Oyunları önlemek

• Sürekli Entegrasyon / Sürekli Muayene oyunlarını kullanın: iyi huylu ve üretken rekabeti teşvik eder .
• Kusurları takip edin: bu sadece ev temizliğidir.
• DO temel nedenlerinin belirlenmesi : bu sadece gelecek geçirmezlik işlemleri var.
• AMA suçu atamayın : bu karşı verimli.

Bu Kod Hakkında, Geliştiriciler Hakkında Değil

Geliştiricilere kodlarının kalitesinin bilincinde olun, ancak onları eleştirilemeyen, kendilerinin bir uzantısı olarak değil, kodu bağımsız bir varlık olarak görmelerini sağlayın.

Bu bir paradoks: Sağlıklı bir iş yeri için ego'suz programlamayı teşvik etmeniz, ancak motivasyon amaçlı egoya güvenmeniz gerekiyor.

Bilim Adamı'ndan Programcıya

Değer vermeyen ve kodla gurur duyan insanlar iyi kod üretmezler. Bu özelliğin ortaya çıkması için ne kadar değerli ve eğlenceli olabileceğini keşfetmeleri gerekiyor. Saf profesyonellik ve iyi şeyler yapma arzusu yeterli değil: tutku gerektiriyor. Bu yüzden bilim adamlarınızı programcılara dönüştürmeniz gerekiyor (büyük anlamda).

Birisi, bir projede ve kodunda 10 ila 20 yıl sonra herhangi birinin bağlılık hissedeceği yorumunda bulundu. Belki yanılıyorum ama kodun kendisiyle ya da yazma eylemiyle değil, kodun sonuçlarından, işinden ve mirasından gurur duyduğunu varsayıyorum.

Deneyimden, çoğu araştırmacı kodlamayı bir gereklilik olarak ya da en iyi ihtimalle eğlenceli bir dikkat dağıtımı olarak görüyor. Sadece çalışmasını istiyorlar. Zaten oldukça ustalaşmış ve programlamaya ilgi duyanlar, en iyi uygulamaları benimsemeye ve teknolojileri değiştirmeye ikna etmek için çok daha kolaydır. Onları yarıya kadar götürmelisin.

Kod Bakım, Araştırma Çalışmalarının Bir Parçasıdır

Kimse boktan araştırma makaleleri okumuyor. Bu nedenle, hakem tarafından gözden geçirilir, prova okur, inceltilir, yeniden yazılır ve tekrar yayınlanmaya hazır olana kadar tekrar tekrar onaylanır. Aynı tez ve kod temeli için de geçerlidir !

Bir kod tabanının sürekli yeniden yapılandırılması ve yenilenmesinin kod çürümesini önlediğini ve teknik borçları azalttığını ve işin diğer projeler için yeniden kullanılmasını ve uyarlanmasını kolaylaştırdığını açıkça belirtin.

Neden Bütün Bu ??!

Neden yukarıdakilerin hepsiyle uğraşıyoruz? İçin kod kalitesi . Yoksa kalite kodu mu?

Bu kurallar, ekibinizi bu amaca doğru yönlendirmeyi amaçlar. Bazı yönler, basitçe onlara yolu göstererek ve yapmalarına izin vererek (ki bu çok daha iyi) ve diğerleri onları ele geçirir (ancak insanları bu şekilde eğitir ve alışkanlıklar geliştirirsiniz).

Amacın ne zaman erişilebilir olduğunu nereden biliyorsun?

Kalite Ölçülebilir

Her zaman kantitatif değil, ancak ölçülebilir . Bahsedildiği gibi, ekibinizde bir gurur duygusu geliştirmelisiniz ve ilerlemeyi ve iyi sonuçları göstermek kilit önemdedir. Kod kalitesini düzenli olarak ölçün ve aralıklar arasındaki ilerlemeyi ve bunun nasıl önemli olduğunu gösterin. Ne yapıldığını ve işlerin nasıl daha iyi veya daha kötü hale getirildiğini yansıtmak için retrospektifler uygulayın.

Sürekli inceleme için harika araçlar var . Sonar , Java dünyasında popüler bir markadır , ancak herhangi bir teknolojiye adapte olabilir; ve diğerleri var. Kodunuzu mikroskop altında tutun ve sinir bozucu sinir bozucu böcek ve mikropları arayın.

Peki ya Kodum Zaten Berbatsa?

Yukarıdakilerin tümü Never Land'e yapılan bir gezi gibi eğlenceli ve sevimlidir, ancak zaten (buharlı ve kokulu bir yığın) şifre koduna ve değiştirmek konusunda isteksiz bir ekibiniz olduğunda yapmak o kadar kolay değildir.

İşte sır: İşte bir yerden başlaman gerek .

Kişisel fıkra: Bir projede, başlangıçta 650.000+ Java LOC, 200.000+ JSP, 40.000+ JavaScript LOC ve 400+ MB ikili bağımlılıktan oluşan bir kod temeli ile çalıştık.

Yaklaşık 18 ay sonra, 100 MB'ye kadar bağımlılıklarla 500.000 Java LOC (EN TEMİZ TEMİZ) , 150.000 satır JSP ve 38.000 JavaScript LOC (ve bunlar artık SCM'mizde değil!).

Bunu nasıl yaptık? Yukarıdakilerin hepsini biz yaptık. Veya çok denedim.

Bu bir ekip işidir, ama biz yavaş yavaş enjekte aceleyle ederken, Ürünümüzün kalp atışlarını takip etmek bizim süreç yönetmelik ve araçları acımasız "yağ" Uzak: Biz tüm gelişimini durmadı ... bok kodu, yararsız bağımlılıkları bunu yapın: Kod temeli üzerinde çıldırmakta özgür olduğumuz ve parçalara ayırdığımız zamanlar göreceli barış ve sessizlik dönemleri var, ancak çoğu zaman aldığımız her fırsatta bir "gözden geçirme ve refaktör" moduna geçerek : inşaatlar sırasında, öğle yemeği sırasında, hata onarım çalışmaları sırasında, cuma öğleden sonraları ...

Bazı büyük "işler" vardı ... Yapı sistemimizi devasa bir 8500+ XML LOC kurulumundan çok modüllü bir modüle geçirmek Maven yapı onlardan biriydi. Sonra biz vardı:

• kesin modüller (veya en azından zaten çok daha iyiydi ve hala gelecek için büyük planlarımız var),
• otomatik bağımlılık yönetimi (kolay bakım ve güncellemeler için ve gereksiz depremleri kaldırmak için),
• daha hızlı, daha kolay ve tekrar üretilebilir yapılar,
• kalite ile ilgili günlük raporlar.

Hatalar için yüzeyini azaltmak Kodunuzdaki aşağı Google Guava ve Apache Commons ince ve ve: Başka biz bağımlılıkları azaltmak için çalışıyor olsa bile, "yarar alet kemerleri" nin enjeksiyondu sizin kod çok.

Ayrıca BT departmanımızı yeni araçlarımızı (JIRA, Fisheye, Crucible, Confluence, Jenkins) kullanmanın yerindekilerden daha iyi olduğuna ikna ettik. Hala küçümsemiş olduğumuz bazılarıyla (QC, Sharepoint ve SupportWorks ...) başa çıkmamız gerekiyordu, ancak biraz daha fazla alan kalmasıyla genel olarak geliştirilmiş bir deneyimdi.

Ve her gün, artık sadece tamir ve yenilemekle ilgilenen bir ila onlarca taahhüt arasında bir kandırmaca var. Bazen bir şeyler kırarız (birim testlerine ihtiyaç duyarsınız ve bunları yeniden ateşlemeden önce onları daha iyi yazarsınız ), ancak genel olarak moralimiz için VE ürünün ürün için yararı çok büyük olmuştur. Her seferinde bir kod kalitesi yüzdesinin bir kısmını elde ediyoruz. Ve arttığını görmek eğlenceli !!!

Not: Yine, yeni ve daha iyi şeylere yer açmak için rijitliğin sallanması gerekir. Hedefimde, BT departmanımız kısmen bize bazı şeyleri empoze etme konusunda haklıdır ve diğerleri için yanlıştır. Ya da belki haklılardı . Her şey değişir. Verimliliğinizi artırmanın daha iyi bir yolu olduğunu kanıtlayın. Deneme çalışmaları ve prototipler bunun için burada.

Süper Gizli Artımlı Spagetti Kodu Mükemmel Kalite için Refactoring Döngüsü

       +-----------------+      +-----------------+
       |  A N A L Y Z E  +----->| I D E N T I F Y |
       +-----------------+      +---------+-------+
                ^                           |
                |                           v
       +--------+--------+      +-----------------+
       |    C L E A N    +<-----|      F I X      |
       +-----------------+      +-----------------+

Alet kemerinizde bazı kaliteli aletlere sahip olduğunuzda:

1. Kodunuzu kalite kontrolleri ile analiz edin.

   Linerler, statik analizörler veya neyin var.

2. Belirleyin senin kritik noktaları VE düşük asılı meyve .

   İhlallerin ciddiyet düzeyleri vardır ve çok sayıda yüksek ciddiyeti olan büyük sınıflar büyük bir kırmızı bayraktır: radyatör / ısı haritası türlerinde "sıcak noktalar" olarak görünürler.

3. Önce sıcak noktaları düzeltin .

   En yüksek işletme değerine sahip olduklarından kısa bir sürede etkilerinizi en üst düzeye çıkarır. İdeal olarak, kritik ihlaller, ortaya çıktıkları anda, olası güvenlik açıkları veya çarpma nedenleri olduğu ve bunlara neden olma riski taşıdığı (ve sizin durumunuzda laboratuar için kötü performans) riski yüksek olduğu için, ele alınmalıdır.

4. Temizleyin ile düşük seviye ihlallerini otomatik kod temeli süpürür .

   Sinyal-gürültü oranını iyileştirir, böylece göründüğü gibi radarda önemli ihlaller görebilirsiniz. İlk başta, eğer başlarına hiç bakılmadıysa ve kod tabanınız vahşi doğada serbest bırakıldıysa, genellikle ilk başta küçük ihlaller ordusu olur. Gerçek bir “risk” sunmazlar ancak kodun okunabilirliğini ve bakımını bozarlar. Bir görev üzerinde çalışırken tanıştığınız gibi düzeltin ya da mümkünse otomatik kod tarama ile büyük temizlik görevlerinde bulunun. İyi bir test takımınız ve entegrasyon sisteminiz yoksa, büyük otomatik tarama işlemlerine dikkat edin. İş arkadaşlarınızla, sıkıntıyı en aza indirmek için onları çalıştırmak için doğru zaman konusunda anlaştıklarından emin olun.

5. Memnun kalana kadar tekrarlayın .

   Hangi, ideal olarak, eğer hala aktif bir ürün ise, asla olmamalısınız: gelişmeye devam edecek.

İyi Ev Tutma için Hızlı İpuçları

• Düzeltme modundayken , müşteri destek isteğine göre:

  • İsteyerek yenilerini tanıtabileceğiniz için, genellikle diğer sorunları çözme konusunda ÇALIŞMAMAK en iyi yöntemdir .
  • Git SEAL tarzı: içeri gir, böceği öldür, dışarı çık ve yamanı gönder. Bu cerrahi ve taktik bir grev.

• Ancak diğer tüm durumlarda , bir dosya açarsanız, aşağıdakileri yapmak sizin görevinizdir:

  • Kesinlikle: gözden (notlar, dosya sorunu raporlarını almak) bunu,
  • belki: temizle (stil temizleme ve küçük ihlaller),
  • İdeal: refactor onu (büyük bölümleri ve onların komşularını yeniden düzenlemek).

Sadece bir hafta boyunca dosyadan dosyaya harcamaktan kaçınmayın ve birden fazla özellik ve modüle yayılan binlerce düzeltmeden oluşan büyük bir değişiklik kümesi ile bitirin - bu gelecekteki takibi zorlaştırır. Koddaki bir sorun = izleyicinizde bir bilet. Bazen, bir değişiklik birden fazla bileti etkileyebilir; ama eğer çok sık olursa, muhtemelen yanlış bir şeyler yapıyorsunuz demektir.

Ek: Görsel Programlama Ortamlarını Yönetme

Ismarlama Programlama Sistemlerinin Duvarlı Bahçeleri

OP G2 gibi çoklu programlama sistemleri farklı canavarlardır ...

• Kaynak yok "Kod"

  Genellikle, kaynak "kod" unuzun metinsel temsiline erişiminizi sağlamazlar: özel bir ikili biçimde saklanabilirler veya belki de metin biçiminde saklarlar, ancak bunları sizden saklarlar. Ismarlama grafiksel programlama sistemleri, araştırma laboratuvarlarında, tekrarlayan veri işleme iş akışlarının otomasyonunu basitleştirdiğinden nadir değildir.

• Takım yok

  Onların dışında, bu. Genellikle programlama ortamları, kendi hata ayıklayıcıları, kendi tercümanları, kendi dokümantasyon araçları ve formatları tarafından kısıtlanırsınız. En sonunda, biçimlerini değiştirebilecek kadar motive olmuş birinin çıkarlarını yakalayıp, dış araçları geliştirmeleri dışında - duvarlar bahçelidir .

• Belge Eksikliği

  Oldukça sık, bunlar oldukça kapalı ortamlarda kullanılan niş programlama sistemleridir. Bunları kullanan insanlar sık ​​sık NDA'ları imzalar ve asla yaptıkları hakkında konuşmazlar. Onlar için programlama toplulukları nadirdir. Yani kaynaklar azdır. Resmi referansınla sıkışıp kaldın ve o kadar.

İronik (ve genellikle sinir bozucu) bit, bu sistemlerin yaptığı her şeye açıkça ana ve genel amaçlı programlama dilleri kullanarak ve muhtemelen daha verimli bir şekilde ulaşılabiliyordu. Fakat daha derin bir programlama bilgisi gerektirir, oysa biyologunuzdan, kimyagerinizden veya fizikçinizden (birkaç kişiyi) programlama hakkında yeterince şey bilmesini bekleyemezsiniz ve hatta uygulamak (ve sürdürmek) için zamana (ve arzuya) sahip olmak için daha azını beklersiniz. karmaşık sistemler, uzun ömürlü olabilir veya olmayabilir. Aynı sebepten dolayı DSL kullanıyoruz, bu özel programlama sistemlerimiz var.

Kişisel Anekdot 2:Aslında bunlardan biri üzerinde çalıştım. OP'nin isteği ile bağlantı kurmadım, ancak projem birbirine bağlı büyük veri işleme ve veri depolama yazılımı grubuydu (öncelikle biyo-bilişim araştırması, sağlık ve kozmetik için, aynı zamanda iş dünyası için). istihbarat veya herhangi bir türde büyük miktarda araştırma verisinin izlenmesini ve veri işleme iş akışlarının ve ETL'lerin hazırlanmasını gerektiren herhangi bir alan). Bu uygulamalardan biri oldukça basit bir şekilde olağan çan ve ıslık kullanan bir görsel IDE idi: sürükle ve bırak arayüzleri, sürümlendirilmiş proje çalışma alanları (meta veri depolaması için metin ve XML dosyalarını kullanarak), heterojen veri kaynaklarına çok sayıda takılabilir sürücü ve görsel N veri kaynağından ve sonunda M'den dönüştürülmüş çıktılar üretmek için boru hatları tasarlamak üzere tuval tasarlamak, ve olası parlak görselleştirmeler ve karmaşık (ve etkileşimli) çevrimiçi raporlar. Kullanıcıların ihtiyaçlarına göre uyarlanmış bir sistem tasarlama bahanesi altında bir miktar NIH sendromundan muzdarip olan tipik ısmarlama görsel programlama sisteminiz.

Ve beklediğiniz gibi, güzel bir sistem, ihtiyaçları için oldukça esnek olmasına rağmen bazen biraz üstünden geçiyor, böylece "neden komut satırı araçlarını kullanmıyorsunuz?" Diye merak ediyorsunuz ve ne yazık ki her zaman orta ölçekli Büyük projeler üzerinde çalışan ekipler, onu farklı "en iyi" uygulamalarla kullanan pek çok farklı kişiye.

Harika, biz mahvolduk! - Biz bu konuda ne yapacağız?

Sonunda, yukarıdakilerin hepsi hala geçerli. Programlamanın çoğunu daha yaygın araç ve dilleri kullanmak için bu sistemden çıkaramazsanız, “sadece” sisteminizin kısıtlarına uyarlamanız gerekir.

Sürüm Oluşturma ve Depolama Hakkında

Sonunda, olabildiğince hemen her zaman versiyon şeyler, hatta en kısıtlı ve duvarlı çevre ile. Çoğu zaman değil, bu sistemler hala kendi sürümleri ile birlikte gelir (ne yazık ki genellikle oldukça basittir ve sadece önceki fotoğrafları saklamak için çok fazla görünürlük olmadan önceki sürümlere dönmeyi teklif eder). Seçtiğiniz SCM'niz gibi diferansiyel değişiklikler kullanmıyor ve aynı anda değişiklik yapan birden fazla kullanıcı için uygun değil.

Fakat yine de, eğer böyle bir işlevsellik sağlıyorlarsa, belki de sizin çözümünüz yukarıdaki sevgili endüstri standardı yönergelerimizi takip etmek ve onları bu programlama sistemine aktarmaktır !!

Depolama sistemi bir veritabanıysa, büyük olasılıkla dışa aktarma işlevlerini gösterir veya dosya sistemi düzeyinde yedeklenebilir. Özel bir ikili format kullanıyorsa, belki de sadece ikili veri desteği olan bir VCS ile versiyonlamayı deneyebilirsiniz. İnce ayarlı bir kontrole sahip olmayacaksınız, ama en azından felaketlere karşı sırtınızı örttünüz ve bir dereceye kadar felaket kurtarma uyumluluğuna sahip olacaksınız.

Test hakkında

Testlerinizi platformun içinde uygulayın ve düzenli yedekleme yapmak için harici araçları ve arka plan işlerini kullanın. Büyük olasılıkla, bu testleri, bu programlama sistemi ile geliştirilen programları ateşleyeceğiniz şekilde başlatırsınız.

Elbette, bu bir hack işidir ve kesinlikle "normal" programlama için ortak olanın standardına kadar değildir, ancak fikir profesyonel yazılım geliştirme sürecinin bir kesimini sürdürmeye çalışırken sisteme uyum sağlamaktır.

Yol Uzun ve Dik ...

Her zaman olduğu gibi niş ortamlarda ve ısmarlama programlama sistemlerinde olduğu gibi ve yukarıda ortaya koyduğumuz gibi, garip biçimlerle, yalnızca sınırlı (veya tamamen yetersiz) bir olasılıkla beceriksiz araç kümesiyle ve bir topluluğun yerine bir boşlukla başa çıkacaksınız.

Tavsiye: Yukarıdaki yönergeleri ısmarlama programlama sisteminizin dışında mümkün olduğunca uygulamaya çalışın. Bu, uygun destek ve topluluk sürüşüne sahip "ortak" araçlara güvenebilmenizi sağlar.

Geçici Çözüm: Bu bir seçenek olmadığında, bu genel çerçeveyi "kutunuza" uyarlamaya çalışın. Buradaki amaç, programlama sisteminizin üzerine endüstri standardı en iyi uygulamaların bu planını kaplamak ve en iyisini yapmaktır. Tavsiye hala geçerlidir: yapıyı ve en iyi uygulamaları tanımlayın, uygunluğu teşvik edin.

Ne yazık ki, bu, dalmanıza ve muazzam miktarda bacak işi yapmanız gerekebileceği anlamına gelir. Yani...

Ünlü Son Sözler ve Alçakgönüllü İstekler:

• Yaptığınız her şeyi belgeleyin .
• Deneyiminizi paylaşın .
• Kaynak yazın herhangi bir aracı açın.

Bunların hepsini yaparak, yapacaksınız:

• sadece benzer durumlarda insanlardan destek alma şansınızı arttırmakla kalmaz,
• aynı zamanda diğer insanlara yardım sağlar ve teknoloji yığıtınızın etrafındaki tartışmaları teşvik eder.

Kim bilir, yeni, canlı bir Obscure Language X topluluğunun başında olabilirsiniz . Hiçbiri yoksa, başla!

• Yığın Taşması ile ilgili sorular sorun ,
• Belki Alan 51'deki yeni bir StackExchange Sitesi için bir teklif bile yazabilirsiniz .

Belki içerde güzeldir , fakat şu ana kadar kimsenin ipucu yok, bu çirkin duvarı yıkmaya yardım et ve başkalarının gözetlemesine izin ver!

Çok ilk adım olacağını bir Sürüm Kontrol Sisteminin tanıtımı (SVN, Git, Mercurial, TFS, vs.). Bunun, yeniden faktoring yapacak bir projeye sahip olması gerekir.

Düzenleme: VSC ile ilgili - Her kaynak kontrol paketi, bazı sınırlamalar olsa da, ikili dosyaları yönetebilir. Piyasadaki araçların çoğu, özel bir fark görüntüleyici ve düzenleyici kullanma yeteneğine sahiptir, bu özelliği kullanın. İkili kaynak dosyaları sürüm denetimini kullanmamak için bir bahane değildir.

Eski kodla nasıl başa çıkılacağı konusunda benzer bir yazı var , bunu takip etmek iyi bir referans olabilir - Eski kodla çalışma konusunda tavsiyeler

Spagetti koduyla çalışmak zorunda kaldığımda, üzerinde çalıştığım ilk şey modülerleştirme . Çizgi çizebileceğiniz ve kod tabanının bağımsız parçalarını (az ya da çok) çıkarabileceğiniz yerleri bulun. Muhtemelen çok fazla bağlantı yapmayacak ve yüksek bağlantı dereceleri nedeniyle çok küçük olmayacaklar, ancak eğer onları ararsanız bazı modül hatları ortaya çıkacak.

Modüllere sahip olduğunuzda, artık dağınık bir programı temizleme işinin korkutucu görevi ile karşı karşıya kalmazsınız. Şimdi, bunun yerine, temizlemek için birkaç küçük bağımsız dağınık modülünüz var. Şimdi bir modül seçin ve daha küçük bir ölçekte tekrarlayın. Büyük fonksiyonları daha küçük fonksiyonlara veya hatta sınıflara ayırabileceğiniz yerleri bulun (G2 destekliyorsa).

Eğer diliniz yeterince güçlü bir yazı sistemine sahipse, bu çok daha kolaydır, çünkü derleyiciyi sizin için ağır kaldırma işleminin çoğunu gerçekleştirebilirsiniz. Uyumluluğu bozacak bir yerde (bilerek) bir değişiklik yaparsınız, sonra derlemeye çalışırsınız. Derleme hataları sizi doğrudan değiştirilmesi gereken yerlere götürecektir ve onları almayı bıraktığınızda her şeyi bulmuş olursunuz. Ardından programı çalıştırın ve her şeyi test edin! Yeniden test yapılırken sürekli testler çok önemlidir.

Bunun sizin için bir seçenek olup olmadığını bilmiyorum, ama onları daha fazla profesyonel geliştirici işe almaya ikna etmeye çalışacağım . Bu şekilde etki alanı sorunlarına yoğunlaşabilirler (eminim orada yeterince var).

Çok akıllı insanlar olduklarına inanıyorum, ancak iyi bir geliştirici olmak çok zaman alıyor. Asıl işi olmayan bir aktivitede bu kadar zaman geçirmeye hazırlar mı? IMHO, bu en iyi sonucu elde etmenin yolu değil.

Vay. Önünde gerçekten büyük bir zorluk var gibi geliyor! Aşağıdaki satırlar boyunca bir şeyler yapardım:

• Her şeyden önce: Önceliklendirin . İlk olarak ne elde etmek istersiniz? Projenin mevcut durumu için en önemli olan nedir? Oradan ne kadar zaman alacağına karşı en çok neyi alacaksın.
• Bir sürüm kontrol sisteminizin olduğundan emin olun . Örneğin Git veya Mercurial .
• Bir çeşit sürekli entegrasyon sistemi (örn. Jenkins ) hazır hale getirin.
• Bir Get hata takip sistemi kurma ve çalışıyor. Mantis bence oldukça güzel.
• İçine bak statik kod analizi (bir şey şu anda çalışmakta olduğunuz dil için kullanılabilir durumdaysa).
• Değişkenlerin adlandırılmasından genel kod sözleşmelerine ve kod tabanındaki kurallara kadar her şeyde tutarlılık sağlamaya çalışın .
• Sistemi test et . Bu bence böyle büyük bir eski sistem için son derece önemlidir. Davranış garip gelse de olmasa da, mevcut davranışı belgelemek için test senaryoları kullanın (genellikle, kodun neden belirli, neden iyi veya kötü veya her ikisi de olabileceğinin bir nedeni vardır; P). Eski Tüylerle Etkili Çalışma Michael Tüyleri bunun için mükemmel bir kaynaktır.

Bir problemi çözmedeki ilk adımın sizin bir probleminiz olduğunu kabul etmek olduğunu söylüyorlar. Bunu akılda tutarak, geçerli kod tabanınız olan engin arapsaçıyı gösteren bir bağımlılık grafiği oluşturarak başlayabilirsiniz. Bağımlılık diyagramı oluşturmak için iyi bir araç? birkaç yaşında ancak bu tür grafiklerin oluşturulmasına yardımcı olabilecek araçlara yönelik bazı işaretçiler içeriyor. Ben eve götürmeyi mümkün olduğunca gösteren büyük, çirkin bir grafikle giderdim. Çok fazla karşılıklı bağımlılıktan kaynaklanan ve belki de Buckaroo Banzai'nin çizgisine atılan sorunlardan bahsedin :

Anatomisini istediğin kadar kontrol edebilirsin ve normal bir çeşitlilik olsa bile, başından aşağıya geldiğinde, bu kafanın içinde, hepsi aynı görünüyor. Hayır, hayır, hayır, bunu çözme. Neye bağlı olabileceğini asla bilemezsin.

Oradan, karışıklığı düzeltmeye başlamak için bir plan tanıtın. Kodu, mümkün olduğunca kendi kendine yeten modüllere bölün. Bunun nasıl yapılacağına dair önerilere açık olun - konuştuğunuz kişiler kodun geçmişini ve işlevselliğini sizden daha iyi biliyor. Ancak amaç, büyük bir problemi ele almak ve daha sonra öncelik sırasına koymayı ve temizlemeye başlayabileceğiniz bazı küçük problemlere dönüştürmektir.

Odaklanılacak bazı şeyler:

• Modüller arasında temiz arayüzler oluşturun ve kullanmaya başlayın. Eski kod, zorunlu olarak, bu hoş yeni arayüzleri bir süre kullanmaya devam edebilir - çözmeye başladığınız sorun budur. Ancak herkesin ileriye dönük sadece yeni arayüzleri kullanmayı kabul etmesini sağlayın. Arayüzlerde olmayan bir şey varsa, ara yüzleri düzeltin, etraflarında dolaşmayın.

• Aynı işlevselliğin tekrarlandığı durumlara bakın. Birleşmeye doğru çalışın.

• Zaman zaman herkese, bu değişikliklerin hayatı zorlaştırmak için zorlaştırmayacağını hatırlatın. Geçiş yapmak acı verici olabilir, ancak bu iyi bir amaç için ve ne kadar fazla sayıda insan o kadar hızlı olursa, faydalar o kadar hızlı gelecektir.

Bir süre Gensym G2'ye baktıktan sonra , bu soruna yaklaşmanın yolu, kod tabanının ne kadarının bu gibi göründüğüne çok bağlı olacaktır:

veya bu:

Buna karşı, 99 Şişe Bira'nın izniyle :

beer-bottles()

i:integer =99;
j:integer;
constant:integer =-1;

begin
for i=99 down to 1
    do
    j = (i+constant);
        if (i=1) then begin
            post"[i] bottle of beer on the wall";
            post" [i] bottle of beer";
            post" Take one down and pass it around ";
            post" No bottle of beer on the wall"; 
        end 
        else begin
            post"[i] bottles of beer on the wall";
            post" [i] bottles of beer";
            post" Take one down and pass it around ";
            if (i=2) then 
                post" [j] bottle of beer on the wall"
           else
                post" [j] bottles of beer on the wall"; 
           end
    end
end

İkincisi durumunda, etkili bir şekilde bilinen bir miktar olan kaynak kodu ile çalışıyorsunuz ve diğer cevapların bazıları , onunla başa çıkabilmek için çok önemli bir tavsiye sunuyor.

Kod tabanının çoğu ikincisiyse veya oldukça büyük bir yığın olsa bile, çok özelleşmiş veya daha da kötüsü gibi görünen bir şeyden dolayı muhtemelen yeniden kodlanamayan bir kodun olması sorunu ile karşılaşacaksınız. çıkarılabilir olabilir, ancak doğru bir şekilde belgelenmemişse, ilk bakışta görünmeyen kritik kodu kaldırdığınızı (bir scram işlemi sırasında bir şey düşünün ) bilmiyorsunuz.

Her ne kadar açıkça, ilk önceliğiniz ElYusubov'un belirttiği gibi çevrimiçi olarak bir çeşit versiyon kontrolü elde etmek olacak ve versiyon kontrolünün 8.3 sürümünden bu yana desteklendiği görülüyor . G2, birkaç farklı dil metodolojisinin bir birleşimi olduğu için, başka bir şey bulmaya çalışmak ve onu işe almak yerine, sağlanan sürüm kontrolünü kullanmanın en etkili olduğunu düşünebilirsiniz.

Daha sonra, bazılarının refactor'a başlaması için muhtemelen savunuculuğu yapsa da, kodlardan herhangi birine dokunmadan önce, özellikle de tarafından geliştirilen kod ve görsel şemalarla uğraşırken, birlikte çalıştığınız sistemi tam olarak anladığınızdan emin olmanızın güçlü bir savunucusuyum. yazılım mühendisliği metodolojileri konusunda resmi eğitim almamış geliştiriciler (veya arka planı). Bunun nedeni birkaç katlıdır, ancak en açık neden, potansiyel olarak 100'den fazla kişi-yıl çalışmasına değecek bir uygulama ile çalışıyor olmanız ve ne yaptığını ve ne kadarını bildiğinizden emin olmanız gerektiğidir. İçinde belgeler var. Sistemin hangi sektöre dağıtıldığını söylemediğiniz gibi G2 hakkında okuduklarımdan yola çıkarak, can güvenliği açısından da potansiyel olarak önemli bir potansiyele sahip olabilecek bir görev kritik uygulamasının olduğunu varsaymak güvenli görünüyor. Bu yüzden, tam olarak ne yaptığını anlamak çok önemli olacak. İnsanların kodun ne yaptığını belirleyebilmelerini sağlamak için dokümantasyonun yapıldığından emin olmak için takımdaki diğer kişilerle birlikte çalışma belgelenmemiş bir kod vardır.

Bir sonraki paketleme birimi, kod tabanının ve yapabileceğiniz görsel şemaların etrafında test eder. Bunun G2 ile nasıl yapılacağına ilişkin bazı cehaletleri kabul etmeliyim, ancak bunu gerçekleştirmek için kendi test çerçevenizi oluşturmaya neredeyse değer. Bu aynı zamanda, ekibin diğer üyelerine kod kalitesiyle ilgili daha titiz mühendislik uygulamalarını kullanmalarını sağlamak için ideal bir zamandır (yani tüm kodların birim testleri ve dokümantasyonu olması gerekir).

Uygun miktarda kod üzerinde birim testler yaptıktan sonra, yeniden deneme uygulamasına haylem tarafından önerilen şekilde yaklaşmaya başlayabilirsiniz ; Bununla birlikte, uzman sistemler geliştirmek ve yenilemek için tasarlanmış bir şeyle uğraştığınızı, bir yokuş yukarı savaş olabileceğini unutmayın. Bu aslında bir şey için söylenecek orada bir ortamdır değil zamanlarda son derece jenerik kod yazmadan.

Son olarak, diğer takım üyelerinin söylediklerine çok dikkat ettiğinizden emin olun, çünkü sadece kod ve şema kalitesinin en iyisi olmaması, mutlaka kendilerine kötü bir şekilde yansıması gerekmez. Sonuçta, şu an için uygulamanın sizden daha fazla ne yaptığını daha iyi bilmeleri muhtemeldir; bu nedenle, oturup değişiklik yapmadan önce ne yaptığınızı anlamanızdan daha önemli olmanızın nedeni budur.

Genellikle önceden duyacağınız şikayetlerin önemli sorunlarla hiçbir ilgisi yoktur. Sonuçta, bu şikayetleri herhangi bir yazılım projesinde duymak tamamen normaldir.

Kodu anlamak zor mu? Kontrol. Büyük kod tabanı? Kontrol.

Asıl sorun insanların ayrılması ve yeni kişi kuruma katıldığında tipik bir oryantasyon bozukluğu yaşanması. Ayrıca, gerçekçi olmayan beklentiler ve kod kalitesi ile ilgili bir sorun var.

İşte, sırayla mücadele edeceğim şey:

1. Hem sunucu hem de yerel sürüm olan yedeklemeler
2. Hata izleyiciyi ayarla
3. Versiyon sistemini kur
4. SSS / Wiki'yi ayarla
5. Tüm bilim adamlarının / programcıların ilk bilgi alma
   • Onlara 80/20 kuralını hatırlat. Hataların% 20'si sorunların% 80'inden sorumludur.
   • En büyük konulara odaklanın ve geliştirme isteklerini uzak tutun.
   • Buradaki amaç, insanları büyük bir listeyle korkutmak değil, elde edilebilecek küçük kazançların bir listesidir. Ne de olsa, değerini de kanıtlamalısın.
6. Derleme sistemini kur
   • Güvenilir yapılar elde etmek için çalışmaya başlayın (bu biraz zaman alabilir)
   • her projeyi tanımlayın ve adlandırın
   • döngüsel bağımlılıkları tanımlamak
   • Bazı açık kaynaklı projelerden ikili dosyalar varsa, kaynak bulmaya çalışın.
7. G2 kodunun nasıl modülerleştirilebileceğini belirleyin, örneğin API'ler, servisler
8. G2 kodunun nasıl test edilebileceğini, belgelendiğini tanımlayın.
9. Kod inceleme sistemini kurun
10. İkinci bilgi
    • İdeal bir modül neye benziyor?
    • Eski kod kapalı kordon nasıl
    • Yeni modül eski kodun etrafına nasıl sarılır (Strangler Pattern'e bakınız http://agilefromthegroundup.blogspot.com.au/2011/03/strangulation-pattern-of-choice-for.html )
11. Daha iyi programcılardan oluşan bir çatlak ekip belirleyin ve modüllerini sarmak için onlarla birlikte çalışın.
12. İletişimin ve dokümantasyonun iyileştirilmesi için kod incelemeleri bu aşamada bulunmaktadır. Bu aşamada kolay olsun. Herhangi bir işlem sorunlarını sıralayın.
13. Sistemi diğer programcılara dağıtın. Çatlak ekibi üyelerinin diğerlerine akıl hocaları olsun. Ölçeklendirmenin burada sorun olduğunu unutmayın. Etkili bir yönetim roldesiniz.

Bunun gibi sorular Yazılım Marangozluğu projesinin varlığının sebebidir .

Son 14 yıldır, bilim insanlarına ve mühendislere temel yazılım geliştirme becerilerini öğretiyoruz: sürüm kontrolü, test etme, kod modülerliği vb. Tüm materyallerimiz Creative Commons lisansı altında ücretsiz olarak mevcuttur ve insanların başlamasına yardımcı olmak için her yıl birkaç düzine ücretsiz iki günlük atölye çalışmaktadır.

Buna dayanarak, bence en iyi başlangıç ​​noktası muhtemelen Robert Glass'ın Yazılım Mühendisliğinin Gerçekler ve Yanılgıları adlı mükemmel kitabıdır : kanıta dayalı yaklaşımı, bilim insanlarını iyi programlama uygulamaları hakkında söylediklerimize ikna etmenin iyi bir yoludur. sadece fikirden daha fazlası.
Özel uygulamalara gelince, insanların benimsemeye en çok istekli oldukları versiyon kontrolü ve birim testi; bunlar yerleştirildikten sonra, Michael Feathers'ın Eski Kodla Etkili Çalışma'da tarif ettiği sistematik yeniden yapılandırma türüyle başa çıkabilir . Pragmatic Programmer'ı (acemiler için pratik yapmak zor, çok büyük bir keşif)
artık tavsiye etmiyorum ve McConnell's Code Complete'i düşünüyorum. başlamak için çok fazla (temel konulara hakim olduktan sonra, onlara altı ay veya bir yıl vermeleri harika bir şey olsa da).

Ayrıca yüksek Paul Dubois' mükemmel kağıt öneriyoruz 'Bilimsel Programları Correctness bakımı' ( Bilimi ve Mühendisliği Bilgisayar mantıklı, tutarlı bir düzine farklı uygulamalar birleştiren 'derinlemesine savunma' yaklaşımını tarif etmektedir, Mayıs-Haziran 2005), yol.

Her şeyden önce durumunuzu düzeltmeniz gerektiğini düşünüyorum. Sizden ne istiyorlar?

• Eski bir dil öğrenmenizi istemeleri çok olası değildir, çünkü bu artık çıkmaz bir durum gibi görünüyor: G2'yi tanımak veya öğrenmek isteyen birini bulmak için azalan bir şans var. Mevcut bilim adamları ayrılıyor ya da tüm kodlar gittikçe daha sık başarısız oluyor.
• Bilim adamları (veya bir kısmı) yeni bir dil ve çok sayıda programlama paradigması öğrenmeye hazır mı? Yoksa programlama ve bilimsel aktiviteyi uzun vadede ayırmak istiyorlar ve gerekirse daha fazla programcı da var mı? Bu, uzmanlığın rasyonel ve daha verimli bir ayrımı gibi görünüyor.

Bence buradaki temel gereksinim, "sistemdeki bilgiyi kurtarmak" demek, bu yüzden gidip kazmanız gerekiyor!

İlk görev bir belge yazmaktır.

Yapıyı ve gereklilikleri sanki yeni bir görevmiş gibi analiz edin, ancak mevcut bir sistemin yardımıyla. Memnun kalacaklar, çünkü önce ÖĞRETMEN yerine SORUNUZ - ve bir programcının bakış açısından yeterince hızlı, ancak daha organize bir arka plan bilgisine sahip olacaksınız: "burada neler oluyor?" Dokümanlar (sistem statik yapısı, iş akışı, bileşenler, problemler) onlar için hemen değerli olacak ve belki onlar için sizden daha alakalı bilgiler gösterecek (bazı erkekler "AHA!" Alabilir ve bazı kodları derhal düzeltmeye başlayabilirler. ) ...

O zaman nereye gitmek istediklerini sormaya başlamalısın?

G2'den uzaklaşmaya hazırlarsahangi sistemi görmek istiyorlar (platform, dil, arayüz, genel yapı)? Mümkünse, hedef yapıya sahip, ancak orijinal bileşenleri koruyarak, mümkünse, sistemin çevresine harici bir sarmalayıcı yazmaya başlayabilir, böylece yavaş yavaş yeni bileşenlerin bu hedef ortamda uygulanmasına izin veren bir tür çerçeve başlatabilirsiniz. Çekirdek hizmetleri (kalıcı veri bağlantıları ve "araç kitleri": çekirdek hesaplama, çizim, ... kitaplıklar) bulmanız gerekir; böylece onlara ya da sizin tarafınızdan geçiş yapmanıza izin veren yeni bir platform ve dilde tanıdık bir ortam sağlarsınız. onlar: eski kodları birer birer alın, onları yeni ortama tekrar yerleştirin (ve TEMİZ!). Bu hazır olduğunda, yeni dili biliyorlar; ve servis katmanı (çoğunlukla sizin için üzgünüm) yeni bileşenleri barındırmaya hazır.

Hareket etmiyorlarsa , G2'yi öğrenmeli ve orada (sizin temizlikle) bileşenlerini taşımanız gereken modüler çerçeveyi oluşturmalısınız. Her neyse, dil sadece veri ve algoritma ağacının serileştirilmesi ...

Dokümanları analiz ederken ve yazarken, GoF Tasarım modellerini okuyun, kullanın ve tanıtın! :-)

... benim 2 kuruş

İş arkadaşlarım için Robert Martin'in SOLID ilkeleri üzerine bir dizi sunum yaptım. Bu ilkelerin G2'ye ne kadar iyi dönüştüğünü bilmiyorum, ancak 5-7 temel temeli aradığınız için, bunlar başlangıç ​​için iyi kurulmuş bir set gibi görünüyor. 7'ye yuvarlamak istiyorsanız, DRY ile başlayıp Fail-Fast'e atabilirsiniz.

Tek üretim sorunu bir değişim yönetimi sorunu gibi görünüyor. Eğer durum buysa ve yazılım aksi takdirde bunu yerine getirirse, vereceğim ilk tavsiye çok hızlı bir şekilde yapma dürtüsüne karşı koymaktır.

Kaynak kontrolü, yeniden düzenleme, daha eğitimli geliştiriciler tüm iyi önerilerdir, ancak bu ilk kez yavaşça hareket eden ve kontrol edilen değişikliklerle uğraşmak zorunda kaldıysanız yeterince vurgulanamaz.

Dağınıklığı parçalama dürtüsü zaman zaman harika olacak, ancak tersine mühendislik yapana kadar değiştireceğinize kadar, değiştirme versiyonunuzu yeterince dikkatli bir şekilde test etmeniz gerektiğini biliyorsunuz.

Böyle bir durumda çalışmak için en önemli ilkeler şunlardır:

1. Sabırlı ol. Kazması 20 yıl süren bir delik birkaç hafta içinde doldurulmayacak.

2. Olumlu ol. Şikayet etme ve huysuz olma ayartmasına karşı koy.

3. Pragmatik olun. Bir günde başarabileceğiniz olumlu değişime bakın ve bugün bunu yapın. Henüz bir sürüm kontrol sisteminiz var mı? Uygula ve insanları eğit. Daha sonra test edip otomatikleştirip kontrol edemeyeceğinize bakın (Birim testi veya benzeri bir şey). Durulama. Tekrar et.

4. Manken ol. Çevik davranarak insanlara çevikliğin nasıl çalıştığını gösterin (yalnızca söyleme). Yukarıdaki ilk üç puan, etkili bir Çevik adam olmanın öncülü olan İyi Adam olmanın anahtarıdır. Bence, hayranlık uyandıran geliştiriciler insanlar akıllı değil, aynı zamanda iyi, model çalışanlar ve meslektaşlar.

5. Bölgenizi haritalayın. Dev eski kod tabanlarını haritalamak için bir tekniğim var. Depoyu klonluyorum, çalışan bir kopya oluşturdum ve sonra bir şeyi değiştirmeye çalışıyorum ve başka nelerin kırıldığını görüyorum. Birleşmeyi araştırarak (global devlet veya hatalı API'ler veya tutarlı bir API veya programa yönelik herhangi bir soyutlama veya arabirim eksikliği) ve bir şeyleri değiştirdiğimde kırılan kodu okuyarak, hamuru keşfederek, sorulan soruları soruyorum takımın geri kalanından gelen içgörüler (Ah, ekledik çünkü Boss X 5 yıl önce bunu istedi, hiç işe yaramadı!). Zamanla, bölgenin zihinsel bir haritasını elde edersiniz. Ne kadar büyük olduğunu öğrendikten sonra haritanızı oluşturacak ve eve dönecek kadar bilginiz olacak. Başkalarını devasa kod tabanınızın bölgesini haritalandırmaya ve ekibin teknik bilgisini oluşturmaya teşvik edin. Bazı insanlar "dokümantasyonda" balkırıyor çünkü çevik değil. Her neyse. Ben de bilimsel ortamlarda çalışıyorum ve belgeler benim için kral, çevik manifestolar lanet olası.

6. Küçük uygulamalar oluşturun. Eski bir kod temeli ile çalışırken, bir kağıt hamurundan toplandığımı anlıyorum. Küçük yardımcı uygulamalar oluşturarak ruhumu geri alıyorum. Belki bu uygulamalar, bu dev G2 kod tabanını okumanıza, anlamanıza ve değiştirmenize yardımcı olacaktır. Belki ortamınızda çalışmanıza yardımcı olacak bir mini IDE veya ayrıştırıcı araç yapabilirsiniz. Meta-programlama ve Alet oluşturma işleminin yalnızca size eski kod tabanlarının size uyguladığı dev kilitlenmelerden kurtulmanıza yardımcı olmakla kalmayacak, aynı zamanda beyninize G2 dilinizle sınırsız olarak uçma kabiliyeti kazandıracak birçok durum vardır. Araçlarınızı ve yardımcılarınızı en hızlı ve en iyi şekilde yapabilecekleri dile yazın. Bana göre, bu diller Python ve Delphi'dir. Perl denen bir adamsanız veya aslında C ++ veya C # ile programlıyorsanız, yardımcı araçlarınızı o dilde yazın.

1. Revizyon kontrolü : etki alanı uzmanlarına geri dönme, kimin neyi değiştirdiğine bakma vb. Yararlarını gösterin (Bu, tüm ikili dosyalarda daha zordur, ancak içerik gerçekten de kod ise, kesinlikle bir çeşit G2'den ... farkları etkinleştirebilen metin dönüştürücü.)

2. Sürekli entegrasyon ve test : Alan uzmanlarının uçtan uca testler (daha kolay, çünkü zaten bir yerde girdiler ve beklenen çıktılar olması gerekir) ve küçük birim testleri (daha zor çünkü spagetti kodu çok fazla küresel değişken içerdiğinden) oluşturulmasına dahil olurlar. hemen hemen tüm işlevselliği kapsar ve vakaları kullanır.

3. Refactor ortak kodunu tekrar kullanılabilir rutinlere ve bileşenlere dönüştürün. Revizyon kontrolü olmayan yazılım dışı insanlar muhtemelen bir seferde 100s satır kopyalayıp yapıştırın. Onları bulun ve yeniden inceleyin, tüm testlerin geçtiğini ve kodun kısaldığını gösterin. Bu aynı zamanda mimarisini öğrenmenize yardımcı olacaktır. Zorlu mimari kararlar almaya başlamanız gerektiğinde şanslıysanız, 100KLOC'ye düşmüş olabilirsiniz.

Siyasi olarak , bu süreçte eski zamanlayıcılardan direnç bulursanız, içeri girmek için bir danışman alın ve iyi yazılım metodolojisi hakkında bir konuşma yapın. Görüşlerini kabul ettiğiniz iyi bir görüş bulduğunuzdan emin olun ve alan uzmanları olmasa bile danışmanın gerekliliği üzerine satın alma yönetimi alın. (Kabul etmeliler - sonuçta, sizi işe aldılar, bu yüzden açıkça belli ki yazılım mühendisliği uzmanlığına ihtiyaç duyduklarının farkına vardılar.) Tabii ki, para harcayan bir hile, elbette, ama sebebi şudur ki - eğer yeni sıcak genç programcısı - Onlara bir şeyler yapmaları gerekiyor, bunu görmezden gelebilirler. Fakat eğer yönetim içeri girip onlara ne yapmaları gerektiğini söylemeleri için 5000 dolar ödüyorsa, buna daha fazla güvenir. Bonus puanlar: danışmana gerçekte istediğinizden iki kat daha fazla değişiklik bildirmesini isteyin, o zaman "iyi adam" olabilirsiniz ve etki alanı uzmanlarının yanında olabilirsiniz;

"Programın kendisi karmaşık bir kimyasal işleme tesisinin fiziksel bir modelidir ..."

"G2 kod değil gibi, fakat oldukça korkak bir GUI tarafından yazılmış otomatik kod gibi ..." - Erik Reppen

Yazılımınızın asıl amacının, karmaşık bir kimyasal tesis veya bir bölümünün parçalarını benzetmek (belki de optimize etmek, parametre tahminlerini çalıştırmak) olduğunu varsayarsak, daha sonra oldukça farklı bir öneride bulunmak istiyorum:

Sen, özünü, çekirdek matematiksel modeller ayıklamak için yüksek seviyeli matematiksel modelleme dili kullanmayı düşünün iyi yapabilir dışına elle kodlanmış yazılımlar.

Bir modelleme dili, problemin tanımını problemi çözmek için kullanılan algoritmalardan ayırmaktır. Bu algoritmalar genellikle belirli bir sınıfın (örn. Kimyasal prosesler) simülasyonlarının / optimizasyonlarının çoğunda uygulanabilir. Bu durumda, gerçekten icat edilmemeleri ve kurum içinde muhafaza edilmemeleri gerekir.

Endüstrinizde yaygın olarak kullanılan üç ticari paket şunlardır: gPROMS, Aspen Custom Modeller ve (modelleriniz uzaysal alanlara dağılmış olayları içermiyorsa) Dymola gibi Modelica tabanlı yazılım paketleri vardır.

Bu paketlerin tümü "uzantıları" bir şekilde veya başka bir şekilde destekler, böylece özel programlama gerektiren modelleriniz varsa, bunlar denklemlerde denklemlerle referans alınabilen bir nesneye (örneğin bir .DLL) yerleştirilebilir. modeli. Bu arada, modelinizin büyük kısmı, bilim adamları tarafından doğrudan kolayca okunabilen bir formda açıklanan özlü kalır. Bu, şirketinizin bilgi ve IP'sini yakalamanın çok daha iyi bir yoludur.

Bu programların çoğu, harici olarak çağrılarak, monolitik kodunuzun 'küçük' başlamasına ve küçük parçalarını (alt modellerini) formatlarına koymanıza izin vermelidir. Bu, çalışan bir sistemi sürdürmek ve bir defada bir parça doğrulamak için iyi bir yol olabilir.

Tam sorumluluk reddi: 8 yıl boyunca gPROMS'un arkasındaki şirkette yazılım mühendisi olarak çalıştım. O zamanlar küçük ve düzenli başlayan, bazı akıllı çözümler ya da algoritmalar uygulayan, ancak sonradan, uzatma ve değişikliklerle yıllar içinde patlayan özel yazılım örneklerini (örneğin akademi'den geliyor) gördüm (ve yararlı bir rehber olmadan). temiz tutmak için bir yazılım mühendisi. (Ben çok disiplinli takımların büyük bir hayranıyım.)

Bu nedenle, bazı deneyimlerle, bir yazılımın geliştirilmesinde (dil ya da anahtar kütüphanesi gibi) erken başlarda zayıf bir şekilde yapılan bazı önemli seçimlerin uzun süredir yapışmaya ve acıya neden olma eğiliminde olduğunu söyleyebilirim. çevrelerindeki yazılımı. Bana sanki burada yıllarca süren saf kod temizliği ile karşı karşıya kalmış gibi görünüyorsunuz. (Numaraları kullanmakta tereddüt ediyorum ama 10+ kişi yılını düşünüyorum, belki de G2'den Eclipse / Java hızlı akıllı gibi iyi otomatik yeniden yapılandırma araçlarını destekleyen bir şeye aktarılan kodu bulamıyorsanız, çok daha fazlasını düşünüyorum.)

Varsayılan durumum "yeniden çalışan ve çalışan bir sisteme sahip olmak" olmakla birlikte, bir sorunun bir kez "çok büyük" olduğunu düşünüyorum, sonra daha radikal bir değişiklik / yeniden yazma daha hızlı hale geliyor. (Ve belki de daha modern bir teknolojiye atlamak gibi ek faydalar sağlar.) Diyorum ki, bazı deneyimlerle yeni bir yazılım platformuna taşınıyorum, ama topladığımdan bir matematiksel modelleme paketine bağlantı noktasıyla daha da çarpıcı.

Bir bakış açısı vermek için, boyut küçültme konusunda hayrete düşmüş olabilirsiniz. Örneğin, 200.000 LoC, aslında 5.000 denklik gibi bir şeyle temsil edilebilir (Tamam, burada tahmin ediyorum, ama size iş arkadaşlarından gerçek bir referans alacağım); artı C gibi bir şeyle yazılmış birkaç göreceli olarak küçük işlev modülü (örneğin, fiziksel özellik hesaplamaları - yine de raf işlemlerinde kimyasal işleminize bağlı olarak var olabilir). Bunun nedeni kelimenin tam anlamıyla algoritmik çözüm kodunu atmanız ve genel bir matematiksel çözücüler yığınının zor işi yapmasına izin vermenizdir. Simülasyonları çalıştırdıktan sonra, bir kod satırı değiştirmeden işlemi optimize etmek gibi onlarla daha fazlasını yapabilirsiniz.

Sonunda şunu söyleyebilirim: eğer çeşitli matematiksel modellerin (ve algoritmaların) güvenilir bir şekilde belgelenmesi kodun kendisi ise, bilim adamları ve orijinal yazarların yardımlarını isteyip istemediklerinde, ASAP'ın bu modelleri çıkarmasına yardım etmek isteyeceksiniz. bazıları devam etmiş olabilir. Matematiksel bir modelleme dilinin bu modelleri yakalamanın çok doğal bir yolu olduğunu bulmalılar - hatta (şok korkuları) onu yazmaktan (yeniden) zevk alabilirler.

Sonunda, cevabım işaretin dışına çıkabileceği için, burada referans olarak verilen iyi kitaplar listesine bir kitap daha eklemek isterim: Robert Martin tarafından Temiz Kod. Öğrenmesi ve uygulaması kolay, ancak şirketinizde yeni kod geliştiren insanlar için fark yaratan bir dünya yaratabilecek basit (ve haklı) ipuçlarıyla doludur.

Aşağıdakileri atacağım:

1. Burada bir programcı var. Politikayı boşver. Ticaretini biliyorlar. Sen seninkini biliyorsun. İşemek zorunda olsan bile o bölgeyi işaretle. Onlar bilim adamları. Bu tür bir şeye saygı duyabilirler veya hemen hemen aynı şeyi yaptıkları için gereği gibi. Yapabilecekleriniz ne olursa olsun, sınırları şimdi işaretleyin. Düzelteceğim şey bu. Bunun için sorumlu olamam.

2. Bilim adamları algoritmaları yazar / test eder. Kendi algoritmalarını 1-3 dilde yazmak isteyen bilim adamları, sizin temel koda dönüştürmeniz için herkes üzerinde anlaşabilir. Bu onların üzerinde eşyalarını test ediyor. Bunun ötesinde, mimarlık için yaptıklarını, iyi bildiklerinize karşı önemli bilim şeylerini izole etmenize yardımcı olacaklar. Kod temeli hortumludur. Yapılması gereken çok fazla eğik çizgi ve yanık var. Onlara, size en iyi bildiklerini kullanan ve çalışanların en iyi yaptıklarını yapabilmeleri için çalışma sürümlerini sağlama seçenekleri verin. Bilgilerini sorumlu oldukları ama üzerinde çalışabileceğin bir kutuya sok.

3. Yapabiliyorsanız, birinci sınıf işlevlerle etkinliğe dayalı bir dil kullanın. Diğerleri başarısız olduğunda, bir olayı tetiklemek veya gerçekte mantıklı olan bir arayüz ve durum mekanizmasına sahip bazı nesnelere geri arama yapmak kanlı bir anlam ifade etmeyen ve muhtemelen hiç bir zaman asla zor olmadı niyet. Bilim adamları Python'u severler. Düşük seviyeli matematik yoğun C malzemelerini bununla yapıştırmak zor değil. Sadece söylüyorum'

4. Bunu ya da benzer bir sorunu çözen birini arayın. Araştırmaya ciddi zaman ayırın. Bu adamlar G2'yi birinden duymuş.

5. Tasarım desenleri. Adaptörleri. Onları kullan. Bu gibi durumlarda onları çok kullanın.

6. Bilimin ne yapabileceğini öğren. Ne kadar çok bilirseniz, koddaki amacı o kadar iyi belirleyebilirsiniz.

İlk önce analizi yap.

Ne öğreteceğime karar vermeden önce biraz analiz yapardım. En büyük ağrı noktalarının nerede olduğunu bulun. Hangi uygulamaların üzerinden geçileceğini önceliklendirmek için bunları kullanın.

Bir seferde sadece birkaç değişiklik yapın (benzer bir durumda her 2 haftada 2-3 uygulama yaptım) .

Uygulamaları SDLC programlama tarzındaki değişim seviyesine bağlı olarak ~ 3 olarak sınırlardım; Onlarla rahat olmaya başlayana kadar (yeni yaklaşımlar öğrenme fikri ile daha rahat olduklarında her ~ 1-2 haftada 1 yeni değişiklik getirmeye zorlardım). Başarı ölçütlerinin ne olduğunu belirlemek de iyi bir fikirdir. Uygulamanın başarması gerekenler (takım morali gibi yumuşak bir hedef olsa bile). Bu şekilde etkili olup olmadığını gösterebilirsiniz.

• Neden değişiklik sayısını sınırla?

Bu insanların daha iyi programcılar olmak istediklerini ve öğrenmeye açık olduklarını varsaysanız bile, insanların yeni kavramları ne kadar hızlı ve ne kadar hızlı öğrenebileceği ve uygulayabileceği konusunda sınırlamalar vardır; özellikle CS vakfına sahip değilse veya daha önce bir Yazılım Geliştirme Yaşam Döngüsüne katıldıysanız.

Uygulamaların kendilerini nasıl etkilediğini tartışmak için haftalık bir toplanma toplantısı ekleyin.

Toplantı neyin iyi gittiğini ve neye ihtiyaç duyulduğunu tartışmak için kullanılmalıdır. Onların bir sesi olmalarına ve işbirlikçi olmalarına izin verin. Tartışmakta oldukları sorunları ele almak ve gelecek değişikliklerin önizlemesini tartışmak ve plan yapmak. Toplantının uygulamalara ve uygulamalarına odaklanmasını sağlayın. Uygulamaları uygulamaktan görmeye başlamaları gereken faydaları biraz gözden geçirin.

Bazı uygulamalar önceliklidir.

Bir sürüm kontrol sisteminin (IMO) doğru kullanımı, diğer her şeyi koyar. Yakında modülerleştirme, kuplaj / uyum ve özellik / hata bileti takibi dersleri var.

Çalışmayan uygulamaları kaldırın.

Çalışmayan uygulamalardan kurtulmaktan korkmayın. Yüksek maliyet varsa ve faydası yoktur veya çok az olması durumunda, uygulamayı kaldırın.

İyileştirme bir süreçtir.

Sürdürülen, tutarlı iyileştirme sağlayan bir süreçtir. En büyük ağrı noktalarını belirleyin, bir çözüm uygulayın, bekleyin / antrenör olun ve tekrarlayın. Biraz ivme kazanana kadar başlangıçta acı verici derecede yavaş hissedeceksiniz. Herkesi gelişmekte olan gelişmelere ve başarılı olan gelişmelere odaklanın.

Gördüğünüz ilk adım, yeni yazılım metodolojisine yatırım yapmanız gereken takıma satış yapmak gibi görünüyor. İfadenize göre, ekipte bir fikir birliği yoktur ve kodun yavaş bir şekilde "yükseltilmesi" ile devam edebilmeniz için ihtiyacınız olacak.

(Yapabilirsem) şahsen öğrendiğim zor dersleri alır ve yazılım endüstrisinde soruna çözüm olarak istediğiniz anahtar kavramları tanıtırdım.

Örneğin, iki geliştiricinin farklı kopyaları vardı ve melez test edilmemiş bir sürümü kullanarak sona erdi -> Sürüm kontrolü, dallanma ve test uygulamalarına giriş.

Birileri anlamadıkları ve kesintiye neden olduğu birkaç satır kod çıkardı -> DDD'yi tanıttı.

Zor dersler sizinle yeterince ayrıntılı bir şekilde paylaşılmıyorsa, o zaman bu disipline uyulmadığında işlerinizin nasıl ters gittiğine dair kendi örneklerinizi gösterin.

Kaynak kodu kontrolü, daha önce birçok kez belirtildiği gibi 1. adımdır. Birlikte çalıştığınız insanlar profesyonel geliştiriciler olmayabilir ve birçok girişime veya çevik mumbo jumbo'ya cevap vermeyeceklerdir. Onlar düşük seviyeli kod maymunları da değiller ve onlara “böyle bir şey” yapmaya zorlayarak onlara böyle davranmaya çalışıyorlar.

Orada ne olduğunu araştırmalısın. Eğer kaynak kod kontrolü kullanmamışlarsa, sadece kodun doğru versiyonlarını tanımlamak (eğer mümkünse) ve mümkün olan tüm teslimatların ne kadar uzun süreceğini belirtmek. Öyleyse, meslektaşlarınıza kaynak kodu kontrolünü nasıl kullanacaklarını öğretme görevine sahip olacaksınız ve onları zamanlarının değerli olduğuna ikna edeceksiniz. Avantajlarla başla!

Bunu yaparken, diğer düşük asılı meyveler bulmak ve bu sorunları gidermek.

Her şeyden önce, söyleyeceklerini dinle ve durumlarını iyileştirmeye çalış. Pullarını ne yaptıklarına takmaya çalışmaktan endişe etme.

İyi şanslar!