Profesyonel yazılım geliştirme ekipleri önemsiz projelerde tasarım karmaşıklığı ile nasıl başa çıkıyor?

İlk olarak, bu sorunun biraz uzun ve belirsiz olabileceğini ve bunun için özür dilerim. Bu muhtemelen "anlayan" herkes için kısa bir adla temel bir sorundur, ancak kendimi bu konuda eksik bulduğumdan, lütfen sorunu açıklarken yanımda olun.

Yaklaşık 11 yaşımdan beri bu şekilde ya da bu şekilde programlama yapıyorum. Bu, çoğunlukla kendime en baştan her şeyi öğrettiğim anlamına geliyor. Teknik bir eğitim aldım, ancak kesinlikle Bilgisayar Bilimi'nde değil (Fotonik Mühendisliği'nden mezun oldum). Tabii ki programlama kurslarımız vardı, ama bu çoğunlukla benim için temel şeylerdi ve çok yeni şeyler öğrenmedim. Sevinç için kendimi eğitmeye devam ettim ve her zaman programlama konusunda kariyer yapacağımı biliyordum, ancak o zaman tüm projelerim oldukça küçüktü. Onları aklımda tutmakta ve korumakta hiç sorun yaşamadım.

Şimdi kendimi bir ekipte lider buluyorum, ancak kurumsal bir ortamda değil - mühendislik uygulamaları için bilimsel yazılım (C ++ 'da) geliştiren üniversitede çalışıyorum. Aniden proje büyüyor (göreceli olarak) ve çoğu zaman zihnimi etrafına sarmakta sorun yaşıyorum. Çoğunlukla iki şey için çok zaman ve çaba harcıyorum:

1. Bir süre üzerinde çalışmadığım bir kod bölümüne geri dönmek zorunda kaldığımda, nasıl çalıştığını hatırlamakta zorluk çekiyorum. İlgili sınıfların başlık dosyalarını incelemek ve kaynak dosyalarda yol boyunca yerleştirdiğim yorumları okumak için çok zaman harcıyorum. Keşke bir tür "şematik" olsaydı resme daha kolay bakabilir ve yeniden kazanabilirim;
2. Değişikliklere girdiğimde, bazen yapmaya çalıştığım şeyin başka bir yerde bir şeyleri kıracağını (ya da daha kötüsü, sadece çalışma zamanında bir sürpriz olarak göründüğünü) yarı yolda fark ediyorum. Geri dönüp farklı bir şekilde yapmaya başladım, sadece başka bir bileşen üzerindeki etkisini ihmal ettiğimi öğrenmek için. Keşke işlerin nasıl yapıldığını, yapmaya çalıştığım şeyin diğer bileşenleri etkileyeceğini ve değişiklikleri uygulamaya başlamadan önce ayrıntılı olarak planlama yapmamın bir yolunu görebileceğim bir "mimari diyagramı" olmasını isterdim.

Birlikte çalıştığım insanların çoğu benimkine benzer hikayelere sahip - güçlü teknik yönelim ve bazen büyük beceriler, ancak işlerini organize etmenin hiçbir yolu yok. Bununla birlikte, projeleri genellikle benimkinden çok daha küçüktür, bu yüzden bir şekilde başa çıkmaktadırlar. Her neyse, bunun benim için anlamı, kendi başıma olduğum ve iyi uygulamaları öğrenecek kimsem olmadığı.

BT yönetiminde bir lisansüstü dersi aldım ve oldukça tatmin edici bulurken, çoğunlukla programcı olmayanları hedefliyor, proje yönetimi metodolojileri, bütçe / program tahminleri, kurumsal mimari vb. Sorun değil, ben de bunları öğrenmeye çalışıyorum. Tabii ki, bazı araçlar (UML gibi) ve yazılım geliştirme süreçlerinin türleri (kademeli, yinelemeli, çevik ...) tanıtıldı, ancak açıkçası çok ayrıntılı değil ve ne seçip kullanmam gerektiğine karar vermekte zorlandım ( ve ne ölçüde).

SO üzerinde yazılım tasarımı hakkında birçok soru ve cevap okuyordum - bunu veya bu aracı veya metodolojiyi kullanarak yapmakla ilgili birçok şey var ve UML belgelerinin sorunlarımı çözeceğine ikna olsaydım - kullanmaya başlayın. Ama bazı insanlar buna yemin ediyor, diğerleri bunun işe yaramaz olduğunu söylüyor. Daha yüksek bir soyutlama seviyesine cevap arıyorum - Yaşadığım iki sorunu çözmenin yolları var mı ve bunu kişisel olarak nasıl yapıyorsunuz? Muhtemelen belirli bir araca bağlı kalmadan bunu yapabilmek için ne öğrenmeliyim? Bunlar zaman zaman modası geçiyor ve projenin türüne bağlı olarak uygulanabilirliklerinin değişeceğini düşünüyorum.

Okuduğunuz için çok teşekkür ederim, daha kısaca ne demek istediğimi söyleyemedim (yazılım tasarım deneyiminden ve kelime bilgisinden yoksun).

Bir süre üzerinde çalışmadığım bir kod bölümüne geri dönmek zorunda kaldığımda, nasıl çalıştığını hatırlamakta zorluk çekiyorum. İlgili sınıfların başlık dosyalarını incelemek ve kaynak dosyalarda yol boyunca yerleştirdiğim yorumları okumak için çok zaman harcıyorum.

Sizden sonra gelen zavallı adamın nasıl hissedeceğini hayal edin - bir zamanlar kodunuzun nasıl çalıştığını bilme avantajına bile sahip değil. Kodunuzu deşifre etmek yerine, söz konusu modül için yazdığınız belgeleri gözden geçiriyor olmalısınız. Bu dokümantasyon, modülün neden herhangi bir neden yaptığını makul bir şekilde doğru bir şekilde sunmalıdır. "Modül üç diziyi döngü için üçlü kullanarak başlatarak başlamaz ..." değil, bunun yerine: "bu modül Fabulotron'un ana sensörü tarafından toplanan verileri alır, standart Neopolitan (çikolata, vanilya, çilek) biçiminde yeniden düzenler, ve Analiz modülüne iletir. "

Mükemmel bir dünyada, sistemdeki çeşitli modülleri belirleyen ve sorumluluklarını açıklayan bir tasarım belgeniz olur ve modüllerinizin her biri, ne yaptıklarını açıklamak için bu belgeye başvurabilir: "Bu modül, Fabulotron veri toplama hizmeti tasarım belgesinin 4.8 bölümünde detaylı olarak açıklanmıştır: http://fabulotron.org/design/section4-8.html . " Böyle bir şeyiniz yoksa üzerinde çalışırken her bir modülün genel bir görünümünü yazmaya başlayın. Bir kitap yazmanıza gerek yoktur - sizi yönlendirmek için genellikle birkaç paragraf yeterlidir.

Değişikliklere girdiğimde, bazen yapmaya çalıştığım şeyin başka bir yerde bir şeyleri kıracağını (ya da daha kötüsü, sadece çalışma zamanında bir sürpriz olarak göründüğünü) yarı yolda fark ediyorum. Geri dönüp farklı bir şekilde yapmaya başladım, sadece başka bir bileşen üzerindeki etkisini ihmal ettiğimi öğrenmek için.

Bu, modüllerinizin birbirine bağlı olduğunun bir göstergesi olabilir. Modüllerinizi / sınıflarınızı / birimlerinizi ne kadar bağımsız hale getirirseniz, bu tür bir sorunla karşılaşma olasılığınız o kadar az olacaktır. Modüller arasındaki arayüzleri olabildiğince açık hale getirmeye çalışın ve onları orada olması gerekenlerle sınırlandırmaya çalışın. Arayüz bir sözleşmedir - bazı modüllerin arayüzde belirtilen yükümlülüklerini yerine getirdiğini biliyorsanız, bu konuda başka bir şey bilmenize gerek yoktur. Bu, üzerinde çalıştığınız modüldeki değişikliklerin diğer modülleri etkilemesini önler.

Keşke işlerin nasıl yapıldığını görebildiğim bir "mimari diyagram" olsaydı

Standart parçaların kullanılması bu konuda yardımcı olabilir. C ++, standart şablonları Standart Şablon Kütüphanesi biçiminde sağlar ve bu parçaları uygun olan yerlerde kullanmak, daha yüksek bir soyutlama düzeyinde çalışmanıza olanak tanır. Listeler gibi veri yapılarını yönetmek için kendi kodunuzu yazdıysanız, siz ve takip edenleri sürekli olarak neler olup bittiğini anlamak için kaynağı okumak zorunda kalacaksınız. Bunun yerine STL tarafından sağlanan standart parçaları kullanırsanız, herhangi bir C ++ programcısı, veri yönetimi rutinlerine girmeden kodunuzun ne yaptığını hızlıca söyleyebilir.

Başka bir standart parça tasarım desenlerinden gelir. Bunlar, iki nesne arasındaki ilişkinin nasıl çalıştığını açıklamak için stenografi olarak kullanılabilecek standart kavramlardır.

Kısa bir süredir profesyonel bir geliştirici oldum ve ilk başladığımda bunu nasıl yapacağım konusunda çok mücadele ettim. Üniversite aracılığıyla bile, öncelikle kendi kendine eğitim aldım. Neyse ki benim için birlikte çalıştığım insanlar çok deneyime sahipler ve beni büyük projeleri yönetme ve üzerinde çalışma yolları konusunda eğitebildiler.

Beni ilk yapan şeylerden biri oturup temiz kodu okumaktı . Bu, ona geri döndüğümde anlayabildiğim veya başka birinin anlayabileceği kodu nasıl yazacağımı anlamama yardımcı olan harika bir kitap.

İkinci şey kaliteli testler yazmaktı: Birim, Entegrasyon, Kabul. Kodunuz iyi test edilmişse, bir şeyi kırdığınızda hızlı bir şekilde bilirsiniz ve sorunu hızlı bir şekilde teşhis edebilirsiniz. İnternette çok sayıda iyi test kaynağı var ve hangisinin size önerileceğinin en iyisi olduğundan emin değilim.

Önemli noktam Test Etme ve Kod Temizleme.

Büyük yazılım sistemlerini organize etmek için bazı üst düzey fikirler. Deneyimlerimin çoğu internet sistemlerinde, ancak bu fikirlerin mühendislik yazılımı için geçerli olduğunu düşünüyorum.

• Fonksiyonelliği nispeten izole edilmiş modüler bloklara ayırın. Örneğin, yazılımınızın sağladığı her bir hesaplama ailesi için bir modülünüz olabilir.
• Varsa, kullanıcı arabirimi için MVC tasarım desenini uygulayın. Arayüzü ve modeli iyi tanımlanmış sınırlarla ayırın.
• Modülleri gruplamak için katmanlar kullanmayı düşünün. Soyutlama katmanları kullanan bir uygulamada, her katman yalnızca altındaki katmana bağlıdır.
• Belgeleri yazarken, tüm uygulama ayrıntılarını unutacağınızı varsayın. Bu varsayım altında çok fazla belge yazacaksınız - belki de kodunuzun yarısı kadarı yorumlar olacaktır, ancak daha sonra daha az kafanız karışacaktır.
• Otomatik ünite, entegrasyon ve kabul testleri bazı alanlarda mükemmeldir, ancak C ++ geliştiricileri bunlarla ilgili karışık hislere sahip gibi görünmektedir.
• Tasarım desenleri üzerinde yoğun bir şekilde çizim yapın . Tasarım kalıpları, genellikle iyi fikirlerin yanı sıra, yazılım mühendisliğinde ortak bir kelime dağarcığı sağlar. Bir sınıfı WidgetFactory olarak adlandırmak, widget yapmak için var olan bir sınıf olduğunu bildirmenin kısa bir yoludur.

Mühendislik yazılımlarıyla çalışmamdan bu yana uzun zaman geçti, bu nedenle kilometreniz bu önerilere göre değişebilir. İyi şanslar!

Cevap yazılım mühendisliğidir.

Büyük projeler için, herhangi bir gerçek kodlama yapılmadan çok önce belirli bir dizi gereksinim toplama, süreç tanımı, belirtim vb.

Çevreye ve kültüre bağlı olarak kullanılan çeşitli yöntemler vardır. İşletme tipi iş " Rasyonel Birleşik Süreç " ya da benzer, teknik start-up genellikle Agile , devlet daireleri bazı aşırı şelale metodoliji bazı varyasyonlar gitmek eğilimindedir .

Her durumda süreç tam olarak ne yaptığınızı tanımlamanıza yardımcı olur ve projenin sonuna doğru yaptığınızı kanıtlamanıza izin verir.

Özgür olmasa da akademik fiyatlandırma sunan Enterprise Architect'e elinizi almanızı şiddetle tavsiye ederim . Projeleri hem makro hem de mikro düzeyde planlamak için mükemmel bir araçtır. Ayrıca kaynak dosyalarınızı sınıf diyagramlarına tersine çevirebilir, bu da uygulamanızın nasıl bir araya geldiğini belgelemek ve yeniden düzenlemek için muhtemelen iyi bir başlangıç ​​olacaktır.

Ayrıca @ Klee'nin önerilerini de ikinci olarak verirdim. Çevik bir süreç izliyorsanız, kullanışlı (zorunlu değilse) en iyi uygulama öğeleri oldukları için sözde "çevik" araçlarla ertelemeyin. Ancak metodolojiniz ne olursa olsun sürekli entegrasyon değerlidir. Ayrıca, birim testleri (cppUnit?) Arkadaşlarınız. Kullanıcı arayüzünü doğrudan denemek yerine, kullanıcı arayüzünüz tarafından çağrılan mantık sınıflarını test ediyorsanız, birim testleri çok yapılabilir olmalıdır. UI testini otomatikleştirmenize yardımcı olabilecek araçlar da var, ancak önce arka uç şeylerini bir araya getirmeye çalışacağım.

İyi şanslar!

Sorununuzun üç boyutu olduğuna inanıyorum

1. Programcı Odaklı
2. Program Odaklı
3. Program Bakımı - Odaklı

İlk sorunla ilgili olarak, programın ne yaptığını anlamayan programcılarınız olabilir (bu genellikle şirket kurulumlarında olur). Ama sorunuza ve bulunduğunuz alana bakarak, siz ve ekibiniz programın ne yaptığını kontrol ediyor gibi görünüyorsunuz, ancak bunu hızlı bir şekilde çalışan bir programa çeviremiyorsunuz (Bir örnek vermek gerekirse, insanları duydum Fizikte doktora derecesine sahip olmak, programlamada işaretçileri anlamakta zorlanıyor ve eminim Fizik C ++ 'dan çok daha zor). Bu durumda, sorununuz çoğunlukla Program merkezli (Etrafınızdaki insanların programınızın ne yaptığını anlayabileceği ve takdir edebileceği kadar şanslı hissetmelisiniz).

Program merkezli problemler durumunda, aşırı önerilerimden biri, Python veya Haskell gibi yeni bir dil öğrenmek gibi C ++ 'dan daha yüksek bir soyutlama düzeyine geçmek olacaktır (Python'un öğrenmesi oldukça kolaydır ve iyi matematikçiler varsa, Haskell sadece harika). Daha yüksek bir soyutlama düzeyine geçmek, kod boyutunuzu düşük tutar, uzun vadede anlaşılması ve bakımı kolay olur ve efekt değişiklikleri hızlı bir şekilde gerçekleşir. Böylece orijinal 50 kod satırının yerine 10 satır kodunuz olabilir. Ayrıca, bilgisayar programlama konusunda uzman birisine sahip olmak kesinlikle yardımcı olacaktır. Bir üniversitede olduğunuzda, GUI ve arayüzlerde birkaç öğrenciyle etkileşime geçebilir, böylece işlevselliğe daha fazla odaklanabilirsiniz. John Lakos'un Büyük Ölçekli C ++ Yazılım Tasarımı kitabını da öneriyorum(Oldukça büyük bir kitap, kitabı okumak için alabileceğiniz sürede yetkin bir Python Programcısı olabilirsiniz)

Sorununuzun ilk 2 boyutundan çıkarırsanız, üçüncü sorun otomatik olarak çözülür. Tek bir büyük proje üzerinde çalıştığınıza inandığımdan, size ulaştığınız iyi proje yönetimi yazılımları. Önceden planlama gereklidir. Kodlamaya hemen başlarsanız, büyük resmi unutamayacağınız programa çok fazla karışabilirsiniz. Bir şeyleri akılda tutmak büyük bir proje için işe yaramaz. Her şeyi kağıda (veya bilgisayara) koyun. Bilgi paylaşmak için wiki kullanın. Metodolojiler konusunda, çevik metodolojiyi tercih ediyorum (Basitçe, çevik artımlı yazılım geliştirme için şık bir isim). Ayrıca, bu alanda uzman birisini işe almanızı ve böylece temel programınıza konsantre olabilmeniz için bunlarla ilgilenmesini öneririm. Buradaki sonuç, tüm proje yönetimi metodolojilerinin programın başarısını sağlamanın bir yolu olduğudur; böylece birisinin en iyisini önerdiği bir şeyi seçmek yerine, size ve ekibinize uyan herkesi seçebilirsiniz. Ayrıca, aşağıdaki yazılımlar size yardımcı olabilir

• Free Mind - Zihin haritalama yazılımı
• Trac - Hızlı ve kolay yazılım hata programı ve wiki
• MoinMoin - Program hakkında bilgi paylaşımını sağlamak için hızlı wiki

Yukarıdaki ipuçları bazı öğrenme eğrisini uzun vadede buna değer olsa da. Ve son olarak, programlama Fotonik Mühendisliğinden daha kolaydır (C ++ Programlama olmasa da)

Sorunuz gibi, sizin için yararlı olan herhangi bir cevap çok uzun ve belirsiz olacaktır - ancak kısa cevap "Yazılım Mühendisliği" dir.

Bir yazılım geliştirme kariyeri konusunda ciddi iseniz, mümkün olduğunca boş bir zaman geçirmenizi ve Steve McConnells sitesini ziyaret ederek başlamanızı öneririm . Programlama kolaydır ve bir dönemde öğretilebilir, Yazılım Mühendisliği daha karmaşık bir büyüklük sırasıdır ve öğrenmesi daha uzun sürer.