Liderim tarafından önerilen şekilde bu projeyi tasarlamayı ve mimariyi başlatmayı nasıl bırakabilirim? [kapalı]

Ben küçük bir geliştiriciyim (yaklaşık 3 yıl) ve iş yerimde yeni bir sistem inşa etme sürecindeyiz. Lider geliştiricim asıl mimar olacak, ancak sistemi kendim (paralel olarak) yapmayı denemem için bana meydan okudu.

Birkaç beyin fırtınası fikri yinelemesi ve mimarlık önerileri olarak gördüklerimi önerme sürecinde, benim önerim bana yaptığım işlerin çoğunun "tasarlama" olduğu ve "mimarlık" olmadığı yönünde bir geribildirim verdi.

Farklılığı mimarlığın uygulama-agnostik olarak tanımlarken, bir tasarım bir uygulamanın açıklamasıdır. Tasarımcı şapkamı çıkarmam ve mimar şapkamı giymem gerektiğini söyledi. Bana bunun nasıl yapılacağı konusunda bir tavsiyede bulundu, ama ben de size sormak isterim:

Yazılım tasarımcısı modundan nasıl çıkıp mimar gibi düşünmeye nasıl başlayabilirim?

İşte benim öncülüğümde mimarlıkla alakalı olarak görülmeyen bazı "tasarım" örnekleri :

1. Sistemimizden kaynakları yüklemek ve boşaltmak için bir algoritma buldum ve liderim algoritmaların kategorik olarak mimarlık olmadığını söyledi.
2. Sistemin yükselmesi gereken ve onları hangi sırayla yükseltmesi gerektiği konusunda bir takım olaylar buldum, ama bu da onu mimarlık olarak kesti.

Ayrıntılara kapılıyor gibi görünüyorum ve yeterince geri adım atmıyorum. Bir mimari seviyede olan bir şey bulsam bile, sık sık çeşitli uygulamalar deneyerek ve detaylarda dolaşıp daha sonra genelleme ve soyutlama yaparak vardım. Bunu liderime anlattığımda yanlış bir yaklaşım benim dediğimi söyledi: "aşağıdan yukarıya" değil, "aşağıdan yukarıya" düşünmem gerekiyordu.

İşte proje hakkında daha detaylı bilgi :

• Mimarladığımız proje bir web uygulamasıdır.
• 10-100 bin civarında kod satırı tahmin ediyorum.
• Biz bir başlangıçız. Mühendislik ekibimiz yaklaşık 3-5 kişidir.
• Uygulamamızı karşılaştırabileceğim en yakın şey hafif bir CMS. Benzer bir karmaşıklığa sahiptir ve büyük ölçüde bileşen yükleme ve boşaltma, düzen yönetimi ve eklenti stili modülleriyle ilgilenir.
• Uygulama ajax-y. Kullanıcı istemciyi bir kez indirir ve ardından sunucudan ihtiyaç duyduğu gibi veri ister.
• MVC modelini kullanacağız.
• Uygulama kimlik doğrulamasına sahip olacak.
• Eski tarayıcı desteğinden çok fazla endişe duymadık (vay!), Bu yüzden orada olan ve ortaya çıkacak olan en son ve en büyükleri kullanmak istiyoruz. (HTML5, CSS3, WebGL?, Medya Kaynağı Uzantıları ve daha fazlası!)

İşte projenin bazı amaçları :

• Uygulamanın ölçeklendirilmesi gerekiyor. Yakın vadede, kullanıcılarımız yüzlerce ila binlerce arasında olacak, ancak on binlerce ila milyonlarca ve daha ötesini planlıyoruz.
• Uygulamanın sonsuza kadar süreceğini umuyoruz. Bu geçici bir çözüm değil. (Aslında zaten geçici bir çözümümüz var ve mimarlık yaptığımız şey, sahip olduğumuz şeyin uzun vadeli yerine geçmesidir).
• Hassas kişisel bilgilerle temas halinde olabileceğinden, başvuru güvenli olmalıdır.
• Uygulamanın kararlı olması gerekiyor. (İdeal olarak, gmail düzeyinde istikrarlı olur, ancak Mars rover'ın aşağısında olması gerekmez.)

Her şeyden önce mimari ve tasarım arasındaki farkın temel olarak anlamsal olduğunu söyleyebilirim. Bazı takımların ikisi arasında kontrol noktaları vardır. Teknik lideriniz, mimarlığı tasarımdan önce olduğu gibi mimariyi de uygulama özeti olarak tanımlar. Bundan yola çıkarak, yazılım mimarisine girmeden önce ürünü kullanıcılara göre tasarlamanıza yardımcı olacak Endüstriyel Tasarım'dan değil, şelale modelinde olduğu gibi tasarımdan bahsettiğimizi varsayıyorum. Ben mimarlığın sık sık tasarıma girdiğini ve bunun mutlaka kötü bir şey olmadığını düşünüyorum, mimarın eldeki sistemde neyin mümkün olduğuna dair derin bir bilgiye sahip olması genellikle çok yararlı olur.

Bunları söyledikten sonra içinde bulunduğunuz durum için bir tavsiyeye ihtiyacınız var. Orada bir yazılım mimarisi dünyası var, kağıtlar, kitaplar, konferanslar ama genel olarak desen ve soyutlamalar arıyorsunuz. Proje hakkında daha fazla ayrıntı olmadan sadece geniş bir örnek verebilirim. Örneğin, entegrasyonda çalışıyorsanız, Servis Odaklı Mimari ( SOA) var.) sistemin parçalarını 'hizmetlere' ayırdığınız desen, böylece her bir parça ile tanımlanmış şekilde çalışabilirsiniz, web programında bu genellikle Web Hizmetleri olarak uygulanır (bununla sınırlı olmamakla birlikte) ve daha yakın zamanda JSON ile RESTful API'lerin yükselişi, yine de bunun SOA mimarisinden gelen bir tasarım olduğunu söyleyebilirim. Model, View, Controller (MVC) ortak kullanımdaki bir mimarlık modelinin başka bir örneği olduğunu, parçaların sökülmesine, hata içermesine ve test edilmesine izin vermek için bir sistemin bileşenlerinin sorumluluğunu ayrıştırdığını söyleyebilirim.

10.000ft seviyesinden, onu bir beyaz tahtaya çizip alanınızda çalışmayan ve programlama dilinizi ve mevcut uygulama ayrıntılarınızı bilmeyen yetkin bir programcıya açıklayabilirseniz, o zaman muhtemelen mimarlık olur. Şirketinizin dışındaki herkesin umursayacağı bir kitap yazabilirsiniz, o zaman muhtemelen mimarisidir. Kendinizi açıklayan ayrıntı bulursanız ve onu diğer kod tabanlarına / şirketlere / endüstrilere genelleştiremiyorsanız, muhtemelen tasarımdır.

Verdiğiniz iki örneğin kod mimarisi değil, kod tasarımı olduğuna katılıyorum. Birincisi, kaynakları yüklemek için bir 'algoritma' ile geldiğinizi söylerken bence bu görevi gerçekleştirmek için bir talimatlar dizisi oluşturduğunuzu düşünüyorum, ve 1. yılda öğretecekleri yeni bir algoritma tasarladığınız anlamına gelmiyor. COMSC gelecek yıl. İkinci örnekte, yine tasarım olduğunu kabul ediyorum. Bana bu fikirlerden birini gösterdiyseniz, onları rastgele yazılım projemde kullanamazdım. Müşteri Sınıfının bir Kişi Sınıfının alt sınıfı olmasını istediğimden, Java'da 'daha yüksek bir seviyeye', Nesneye Yönelik (OO) seviyesine gitmelisiniz. İstisnalar hakkında genel olarak konuşmak bile çok düşük bir düzeyde görülebilir (uygulamaya çok yakın).

Listede bulunduğunuz özellikleri ele almak için, düşünmeniz gereken şey, web tabanlı bir CMS'yi nasıl tasarlayacağınızdır. Wordpress, tasarım uygulama detayları hakkında çok konuştukları bir site mimarisi kodeksine sahiptir, ancak ana mimarlıklarının Wordpress'i temalarla genişletilebilir kılmaya odaklandığı açıktır. Bir temanın şirket dışından biri tarafından yazılabileceği şekilde net bir arayüz oluşturmak, açıkça aldıkları bir mimari karardı. Bunlar 'uzun vadeli' çözümünüzü tasarlarken kağıda almanın en iyi yolu (geçici değil) çözümdür, böylelikle geliştirme sırasında alınan tüm tasarım ve uygulama kararları (sadece mimar tarafından değil, tüm geliştiriciler tarafından) bu düşünceye uygun.

Durumunuz için diğer mimari örnekler:

1. Her şeyi sanal makinelere yerleştirmek, bir bulut sağlayıcıda veya evde barındırmak ve durumsuz makine örneklerine sahip olmak, böylece herhangi bir hatayı kopyalamak veya herhangi bir bilgiyi kaybetmek zorunda kalmadan yeni bir sanal makine örneği ile değiştirilebilecek şekilde.
2. Canlı üretim hatası testinde baştan beri kaos simyacıları ile yapılan testler yapıldı .

Belki bütün sistemi bir beyaz tahtaya çizmeyi deneyebilirim Farklı düzeylerde deneyin, ilk tahta GUI-> dispatcher-> backend-> DB ya da başka bir şey olabilir ve sonra zamirleri kullanmaya başlayana kadar delinir.

Çalıştığım yerde bu iki fikir arasındaki fark gerçekten önemli.

Ne diyorsun "mimarlık" biz "İngilizce programlama" diyoruz. Bu kısmen önemlidir, çünkü programcı olmayan bir kişiye tanımlayamazsanız, bir şeyler yanlış olur. Sorunu yeterince iyi anlamıyor olabilirsiniz, VEYA "hayalet" bir problemi çözüyor olabilirsiniz (burada tartışılmamaktadır).

Tasarımın bu iki farklı yönü için kullanılan terimler genellikle farklıdır, ancak ilkeler her yerde kolayca tanınır. Bir yönü (sizin durumunuzda mimar, benim durumumda tasarımcı) İngilizce, diğerinde (sizin durumunuzda "tasarımcı" benim durumumda "geliştirici") belli bir dilde programlar. Ayrıca genellikle "tasarım" ve "uygulama" olarak da ayırt edilirler. "Tasarım", başarması gereken şey ve "uygulama", onu gerçekleştiren koddur.

Üzerinde çalıştığım bazı örnekler:

Bir programın mimarisi şudur: Kolayca modüller ekleyebileceğimiz merkezi bir yönetici veya hub'a ihtiyacımız var. Bu Yönetici olayları kayıtlı tüm modüllere dağıtacaktır. Bir modül kendisini Etkinlik Yöneticisine kaydedebilir ve böylece olayları sistemin geri kalanına yayınlayabilir ve umursadığı olayları alabilir. Her modül, istediği gibi kontrol edip boşlayabileceği bir "posta kutusuna" sahiptir. Bu bize henüz ihtiyacımız olmadığını bilmediğimiz yeni modülleri yerleştirmemize izin verir.

Kod yok. Herhangi bir dilde yazılabilir. Uygulama bu açıklama ile belirlenir.

Başka bir projenin mimarisi: Başka programları beklemeden güvenli bir şekilde başlatmak ve durdurmak için bir yola ihtiyacımız var. Belirli bir programdan sorumlu bir yöneticimiz olabilir. Sadece programına başlamasını ya da durdurmasını söyleyebiliriz ve yönetici de ilgilenir. Bu programdan durması istenirse ve belirli bir süre içinde durmazsa, yönetici durması ve karışıklığı temizlemesi için nasıl zorlayacağını bilir. Program başka bir şey tarafından başlatılmaz veya durdurulmaz ve yöneticiye programının çalışıp çalışmadığını, durduğunu veya durmayı bekleyip beklemediği sorulabilir. Bu, yapmamız gereken diğer şeylerle devam etmemize izin verirken, diğer programları düzgün bir şekilde başlatıp durdurmaya devam etmemizi sağlar.

Yine, buradaki hiçbir şey, bazı uygulamalar diğerlerinden açıkça daha faydalı olsa da, uygulamayı belirlemez.

Tasarım (desen veya uygulama dediğimiz) ile mimari (tasarım dediğimiz) arasındaki fark, birinin kodlama / uygulama problemini çözdüğü ve diğeri gerçek dünya problemini çözdüğüdür.

Belki bu yardımcı olur. Her zaman bir mühendisin kıdemliliğini, bir problemi kendi başlarına çözebilecekleri büyüklükte bir soru olarak gördüm.

Kabaca, fikri iletmek için:

• Görevin diğer parçalarla nasıl bütünleştirilmesi gerektiğine dair çok sayıda açık talimat içeren küçük, içerilen görevleri programlamak için yeni birini verebilirsiniz

• Orta seviye bir dev, bir uygulamanın bir kısmının açıklamasını alıp bu uygulama kapsamında çalışmasını sağlayabilen bir kişidir.

• Üst düzey bir geliştirici, bir mağazanın teknik kısıtlamaları dahilinde, sıfırdan orta ölçekli bir uygulama oluşturabilir.

• Daha üst düzey bir geliştirici bunu yapabilir ve hangi teknolojilerin iyi çalışması için kullanılacağı hakkında yol boyunca teknoloji seçimleri yapabilir.

... ama bunlar zor ve hızlı kurallar değil. Ve bazı insanlar farklı bir ünvan ile zaman geçirmek zorunda kalsalar bile, "kıdemli" IMHO olarak kapıdan çıkarlar.

Mimarın istediği, sorunu ondan daha genel olarak görmektir. Sistemin çalışması için birkaç uygulamayı bir araya getirmeniz gerekirse:

• Hangi uygulamalara ve hizmetlere ihtiyacınız olacak?
• Hangi parçalar müşterilerle etkileşime giriyor ve hangileri birbiriyle etkileşime giriyor?
• Nasıl iletişim kuracaklar?
• Verileri nerede depolayacaklar?
• Başarısızlık riskleri nerede?
• Güvenilirliği nasıl sağlayacaksınız?
• Güvenliği nasıl sağlayacaksınız?

Yani, bir anlamda teknik mimari bir yapı mimarisi gibidir. Bu, plan veya plan. Çeşitli parçalar için neyin gerekli olduğunu, nasıl bir arada olduklarını ve en önemlisi nedenini gösterir .

(BTW, mimarlar için bana benzer bir büyüme eğrisi yaşadım, ilgili uygulamalar ailesini ya da çok karmaşık özelliklerin tasarımını yapmaktan, bir grubun teknik yönünü belirlemeye, tüm kuruluş için stratejik teknik kararlar almaya kadar. .)

Bu, her seviyedeki mühendislerin çoğunun "mimarlık" yapmaları gerektiğini de belirtti. Parlak bir çizgi değil. İlk önce Büyük Resme odaklanırsanız ve uygulama ayrıntılarına takılmıyorsanız, aradığı şeyle daha uyumlu olacaksınız gibi geliyor. BTW'nin Küçük Resim'yi olduğu kadar Küçük Resim'yi de görebilme yeteneği bu sektörde büyük bir varlık, bu yüzden bu harika bir fırsat gibi görünüyor.

... İşte bir benzetme. Diyelim ki bir Sihirli Kara Kutu yaratmanız istendi. Bir mühendis olarak, Magic Black Box'ın iç işleyişini saptamanız beklenir. Ancak bir mimar olarak, odak noktanız farklı. Kutuya meraktan bakabilirsin, ama tüm Magic Black Box'ların etrafındaki herşeye takıntılısın .

Bu analojiye benzer şekilde, tüm sistemi sihirli kutu olarak görmek gibi mimarlık rolünü düşünebilirsiniz . Yani eğer bir Gigantic Glass Box alırsanız ve müşterileri, müşteri uygulamalarını, güvenlik duvarını, servis katmanını, veri tabanını ve hatta dümen adamlarını bile koyarsanız, o zaman bu büyük sistem kutusunu nasıl yapacağınıza dair takıntılı olduğunuzu düşünürsünüz. işe iyi .

"Tasarım" ve "mimari" arasındaki kesin fark biraz özneldir ve bir miktar örtüşme vardır. Ancak, anladığım kadarıyla fark bu:

Mimari , üst düzey konseptlere bakar. Sistemdeki aktörler kimlerdir? Başlıca nesneler nelerdir ve hangileri ne için sorumludur? Mimarlığı düşündüğümde, sanırım kod değil Visio.

Örneğin, bir etkinlik sistemi, gelen olayları kabul eden ve olay işleyicilere gönderen bir olay yöneticisine sahip olabilir. Eşzamanlı olmayanlar, eşzamansız v. Eşzamanlı ve diğer alt düzey kavramları fikri burada ortaya çıkmamaktadır. MVC başka bir örnektir: spesifik detaylar, üç parçanın nasıl etkileşimde bulunduğunun yüksek düzeyde belirtilmemiştir, sadece ayrı kod paketleri tarafından ele alınan üç ayrı endişe vardır.

Tasarım prototip üretmeyi, kod arayüzlerini çizmeyi, kod iskeletlerini vb. İçerir. Soyut mimari ile düşük seviyeli "kod maymunu" işi arasında oturur.

Bir etkinlik çerçevesinde, tasarım "bir etkinlik bu arayüzü kullanır" diyebilir ve "etkinlik yöneticisinin çalışanları işçilere göndermek için kullandığı bir iş parçacığı havuzu var" diyebilir. MVC için bir tasarım "model için Hazırda Beklet, kullanım için denetleyici için Bahar ve görünüm için GWT kullanın" olabilir.

Tasarım çalışmaları yaptığım zaman arayüzleri çizip iskeletleri kodluyorum, ardından sonuçları programcılara aktarıyorum. Bazen ben o programcıyım. Ancak bu iki ayrı aşamadır ve her ikisi de mimarlığa göre daha somut olarak var olur.

Mimari şapkayı takmak , kodunuzu açıklamanız ve bir beyaz tahta üzerinde nesneleri düşünmeniz anlamına gelir. Nesneleri, paketleri, çerçeveleri ve aralarındaki mesajların akışını düşünün. Bir kod satırı bile düşünüyorsanız, yanlış yapıyorsunuzdur. "Bu mesaj bir dize olabilir ya da SOAP ya da her neyse" olabilir. Bu seviyede, iletişimin gerçekleşmesi gerçeği yeterlidir. Detaylar önemli değil.

Buraya bir şey ekleyebilirsem , bu: kod sanma . Hiç.

Bir şeyi başarmak için kodu nasıl yazacağınızı düşünmeyin, ancak başarmak için en iyi yöntemin ne olacağını düşünün . Yapmanız gerekenlerle ilgili açıklamanız, dille uyumlu olmalı , bu nedenle nasıl ilerleyeceğinizi tartışmak için farklı programlama dilleri kullanıcıları arasında ortak bir "dil" olan tasarım kalıplarından bahsedeceksiniz.

Özel kullanım durumunuz için bence daha fazla mimari soru aşağıdakiler boyunca olacaktır:

• Neden MVC kullanıyorsunuz? Tek bildiğin bu mu? Kullanılacak daha iyi modeller var mı? Neden?
• Hangi çerçeveyi kullanacaksınız ve neden ?
• Nasıl ölçeklenirsiniz? Kod bakımından değil, çünkü bunun önemi yok. Yatay olarak ölçeklenecek koşullar ne olacaktır; bunu yapmak için hangi hizmeti (AWS) kullanacaksınız?
• Doğrulama nasıl yapılacak? Kod bilge değil: Her istekte rastgele, benzersiz bir simge oluşturacak ve beklenen jetona karşı kontrol ettirecek misiniz? Bunu kodda nasıl yapacağınızı düşünmeyin. Bunu neden yaptığınızı düşünün - çünkü bu hemen hemen her web dilinde yapılabilir.

Temel olarak, kod hakkında hiç konuşma. Bir şeyi nasıl yapacağınızı bilmiyor olsanız bile , bir irade olduğunda, bir yolu vardır . Bulmacanın parçalarının, bir araya getirme konusunda endişelenmeden önce, en iyi nasıl bir araya geleceği hakkında daha fazla düşünün.

Sisteminizin gerçekleştirebileceği tüm işlemleri (örneğin kullanım durumlarını) düşünün. Her işlem için, her işlem için iş alanınız açısından neler olduğunu belgeleyin. Yalnızca sorunlu alanınız açısından konuşmalı ve uygulama detaylarını tanımlamamalısınız. Büyük bir blok çizin ve Sistem olarak adlandırın. Bu "büyük blok" ve işlem tanımlarının birleşimi en üst seviye sistem mimarisidir.

Bu üst düzey mimari iyi bir başlangıç ​​noktası sunsa da, gerçek bir sistem inşa ederken pek bir değeri yoktur. Bunu yararlı bir mimariye dönüştürmek için bir ayrıntı seviyesine indirmelisiniz.

Böylece, "büyük blok" yaklaşımıyla aynı genel fikri izlersiniz, sadece her işlemi gerçekleştirmek için gerekli olan "alt bloklar" eklemeye başlarsınız. Bu "alt bloklar" genellikle alan sınıfları veya modülleri olarak adlandırılır. Bunlar, işlem açıklamalarınızı (büyük blok yaklaşımından) ve çizim dizisi şemalarını kullanarak kolayca tanımlanabilir. Bunlara etki alanı sınıfları denir çünkü "gerçek" sınıflar olmaları amaçlanmamıştır, ancak sisteminizi sisteminizin sorun alanıyla tanımlamaları amaçlanmıştır.

Tüm dizi diyagramını oluşturmanın ve tüm "alt blokları" tanımlamanın sonucu, artık bir etki alanı sınıfları listesine ve işlem listelerine sahip olmanızdır. Bu genellikle, "alt bloklar" / modüllerin her birinin, tasarım ve uygulama için farklı geliştiricilere ayrılabileceği oldukça kullanışlı bir yazılım mimarisi ile sonuçlanır.

Tabii ki, olduğu gibi bırakırsanız, tasarımcılarınızın modüller arasındaki arayüzleri tanımlarken birbirleriyle çok fazla etkileşimi olacaktır. Böylece, mimar ayrıca modüller arasında kullanılacak özel arayüz mekanizmalarına ve veri tiplerine de karar verebilir.

Ayrıca, bazı "alt bloklar" başlık altında çok karmaşık olacaktır. Bu yüzden "alt blok" yaklaşımının başka bir yinelemesi gerekli olabilir, ancak bu sefer yeni tanımlanan modüllerden sadece birinde.

Son olarak, mimarın sistemin uymasını istediği arabirimler arasında bazı özel kalıplar / sınırlamalar olabilir (örneğin, doğrudan yöntem çağrılarına karşı olay geri çağrıları), bu nedenle bu kararların mimari tasarımda konuşulması gerekir. Ayrıca, mimarın herkesin kullanmasını istediği "ortak" modüller olabilir.

Bir geliştirici olarak, muhtemelen çözüm sağlama alışkanlığınız vardır. Bu çok iyi bir düşünce şeklidir, ancak mimari hakkında düşünmeye gelince sizi engelleyebilir.

İlk önce çözmeye çalıştığınız sorunu tarif etmenize yardımcı olduğunu buluyorum. Gereksinimleri nelerdir? Kısıtlamalar nelerdir? Bu gereklilikleri öğrenmek için paydaşlarla konuşabilir misiniz?

Kendi tasarım hedeflerinizi de tanımlayabilirsiniz eğer yardımcı olabilir. Çözümünüzün ölçeklendirilmesi gerekiyor mu, yoksa tek kullanıcı için bir tasarım yeterli mi? Çözümünüzün ne kadar süre geçerli kalması gerekiyor? Tek seferlik bir düzeltme mi yoksa uzun vadeli bir altyapı çözümü mü? PEr belki de bu kadar önemli: Mimarlığınızın kabul gören sınırları nedir?

Ve bu bir öğrenme deneyimi olduğundan, saçma olsalar bile, soru sormaktan çekinmeyin.