Nesneye Dayalı uygulamaların nasıl yayılacağı hakkında ipuçları [kapalı]


14

Yaklaşık 250 geliştiricisi olan orta ölçekli bir şirkette çalışıyorum. Ne yazık ki, birçoğu prosedürel bir düşünce tarzına sıkışmış durumda ve bazı ekipler aslında uygulama zengin mantık içerdiğinde sürekli olarak büyük İşlemsel Komut Dosyası uygulamaları sağlıyor . Ayrıca tasarım bağımlılıklarını yönetemezler ve başka bir çok hizmete (büyük Çamur Topu'nun temiz bir örneği) bağlı hizmetler ile sonuçlanmazlar .

Sorum şu: Bu tür bilgilerin nasıl yayılacağını önerebilir misiniz?

Sorunun yüzeyinin, bu uygulamaların kötü bir mimariye ve tasarıma sahip olduğunu biliyorum. Başka bir sorun da, herhangi bir test yazmaya karşı çıkan bazı geliştiricilerin olmasıdır.

Bunu değiştirmek için yaptığım birkaç şey (ama ya başarısızım ya da değişiklik çok küçük)

  • Tasarım ilkeleri (SOLID, temiz kod, vb.) İle ilgili sunumlar yapmak.
  • TDD ve BDD ile ilgili atölye çalışmaları.
  • Koçluk ekipleri (bu sonar, findbugs, jdepend ve diğer araçları kullanmayı içerir).
  • IDE ve Yeniden Düzenleme görüşmeleri.

Gelecekte yapmayı düşündüğüm birkaç şey var (ama iyi olmayacaklarından endişe ediyorum)

  • Farklı ekiplerde OO düşünce tarzını yayan OO evangelistlerinden oluşan bir ekip oluşturun (bu kişilerin birkaç ayda bir ekip değiştirmesi gerekir).
  • Tasarım inceleme oturumları yürütmek, tasarımı eleştirmek ve iyileştirmeler önermek için (zaman kısıtlamaları nedeniyle iyileştirmeler yapılmasa bile, bunun yararlı olabileceğini düşünüyorum)

.

Koçluk yaptığım takımlarda bulduğum bir şey, onları terk eder etmez, eski uygulamalara geri dönüyorlar. Onlarla çok fazla zaman geçirmediğimi biliyorum, genellikle sadece bir ay. Ne yaparsam yapayım yapışmaz.

Üzgünüm, bu soru hayal kırıklığına sıçradı, ancak bunu yazmanın alternatifi, ben geçene kadar kafamı duvara vurmaktı.


modüler programlamaya bak - en.wikipedia.org/wiki/Modular_programming
Yusubov

ElYusubov, "standart", yine her takımın takip etmediği TDD yapmaktır. Hatta bazı takımlar BDD'yi oldukça iyi sonuçlarla bile yapıyor. (TDD ve BDD dışarıda, modüler programlama gibi).
Augusto

10
Lütfen, OO'yu sorunlarınızı çözecek veya çözecek bir cennet gönderimi olarak görmeyin. Bu elbette çok dar görüşlü. OO'nun faydaları olabilir, ancak konuyla ilgili bazı farklı görüşler var: existentialtype.wordpress.com/2011/03/15/… OO'ya veya hatta paradigmalara odaklanmamaya çalışın, ancak sizin için çalışan en iyi uygulamaları arayın, cs. brown.edu/~sk/Publications/Papers/Published/…
AndreasScheinert

Andreas, FP öğrenmek ve OO ilkelerini uygulamak için insanları çok isterim !!! Sana% 100 katılıyorum. Sorun şu ki, birkaç geliştirici çalışmaya başladığından beri aynı şeyleri yapmakta rahat oluyorlar ve yolculukta çözüm becerilerini geliştirmediler.
Augusto

3
"Kelimeyi yaymaya" çalışmayın. Bir kaideden vaaz edilen kıyamet ve yıkım yeterlilikleri, 21. Yüzyıl Köylüleri ile olduğu gibi 21. Yüzyıl Üniversite Mezunları ile de düşmez.
mattnz

Yanıtlar:


19

OOP'u zorlamaya çalışmayın, sadece işleri daha da kötüleştirir. OOP genel olarak kötü bir fikir olduğu için değil: değil. Ama öyle görünüyor ki, bu kıl yumağı kodundan kim sorumlu olursa olsun, bu sorunları önlemek için araçlardan değil, aynı zamanda deneyimden ve daha da önemlisi motivasyondan yoksundur.

Temiz kod yazma arzusu olan insanlar, herhangi bir paradigmada, ister OOP, prosedürel, fonksiyonel, vb. ihtiyacı anlamak, zaten orada olan araçlar gibi istismar bu araçları ile sonuçlanacak. Bir sınıfa gruplandırılmış ilişkisiz yöntemler, ilişkisiz sınıflardan miras alınan sınıflar, bilinçli tasarım yerine deneme-yanılma hata ayıklamasına dayalı yöntem görünürlüğü, kısaca statik ve statik olmayan yöntemler olması gereken statik yöntemler göreceksiniz. , zamanını boşa harcıyorsun.

Bunun yerine, sürdürülebilirlik ve zarafet için bilinci artırmaya yatırım yapıp yapamayacağınızı görün. Sonuçta, OOP'un temel hedefleri diğer herhangi bir karmaşıklık yönetimi stratejisinden farklı değildir (programlama paradigmalarının aslında hepsi budur): kapsülleme, modülasyon, gevşek bağlantı, düşük bağımlılık derecesi, değişebilir durumu ve kapsamını korumak minimum, vb. vs. OOP kesinlikle bunu başarmak için gereken araçları sağlayan tek paradigma değildir.

Bu da beni son noktaya getiriyor: OOP harika bir fikir ve bazı problemler için iyi çalışıyor, ancak (ve hem kendi deneyimlerimden bahsediyorum hem de burada bazı harika zihinlerin görüşlerini yorumluyorum) birçok türde sorunları, tamamen uygun değildir. OOP'a yeni geldiğinizde ve yarı prosedürel spagetti kodu bildiğiniz tek alternatif olduğunda, OOP doğal olarak cennetten bir hediye olarak görünür (ve göreceli olarak) ve muhtemelen yaklaşmanız muhtemeldir. OOP çekiçiniz için çivi olarak tüm problemler. Bu sadece doğaldır ve OOP'yi sınırlamalarına (ve ötesine) yönlendirmek, OOP becerilerinizi geliştirmenin iyi bir yoludur, bu yüzden hepsi olumsuz değildir. Ama belki (sadece belki) bu kod tabanının OOP'ye ihtiyacı yoktur. Belki yordamsal bir mimariden çok daha fazla yararlanır,

TL; DR: Herhangi bir şeyi evangelize etmek istiyorsanız, belirli bir paradigma veya metodoloji değil, (platformdan bağımsız) iyi kodlama uygulamaları olmasına izin verin.


4
+1: OOP'nin onları kaydetmeyeceğini tanımak için. Evangelistler sık ​​sık unutmak .....
mattnz

1
+1: Ama yapabilseydim 10 kez yükselirdim. OOP'nin kod yapılandırması için prosedürel programlamaya göre daha iyi destek sunduğu doğru olsa da, sadece OOP yeterli değildir. SCRUM, TDD ve diğerleriyle aynı. Bunların hepsinin yararlı araçlar olduğunu düşünüyorum, ancak (1) her programcının basit, temiz, modüler kod yazma konusundaki temel tutumunun, (2) tüm ekip tarafından tanınan bir veya daha fazla mimarın çalışmalarının yerini alamazlar. genel kod mimarisinin tutarlı olmasını sağlayın. Bu önkoşullar olmadan bir ekip kolayca nesneye yönelik büyük bir çamur topu üretebilir.
Giorgio

5

Zaten değiştirmek istemeyen kimseyi değiştiremezsiniz. Bu yüzden koçluk yaptığınız takımlar eski yöntemlerine geri döndüler.

Öyleyse, sorunuz şu olmalıdır: "geliştiricilerin OO yaklaşımlarına nasıl geçiş yapmasını istiyorum?"

Basit başlayın, küçük başlayın, işlerin oradan oluşmasına izin verin. Kodun, diğer geliştiricilerin veya şirketin soyut veya felsefi faydaları yerine bireysel geliştiricinin avantajlarını gösterin.

Çeşitli OO tekniklerinin nasıl yazacakları daha az koda ve daha hızlı geliştirme sürelerine yol açacağını gösterin . Hemen hemen her geliştirici, işini kolaylaştıracak bir teklif dinleyecektir.

Sonra OO tekniklerinin nasıl daha kolay korunan koda yol açacağını göstermeye başlayın. Bu tür ortamdaki herkes , üretim uygulamasının üçte birini ortadan kaldıran " değişim " yapma korkusuyla yaşar . Kapsülleme bu riskten kaçınmanın anahtarıdır ve uygulamanın her (yakında) katmanının diğer katmanlarla olan sözleşmesini sürdürmesine izin verir.

Verilerin nasıl aktarıldığına bakarım. Her seferinde uzun bir değişkenler listesiyse, bir yapının içindeki bazılarını (veya soluk soluk! Bir sınıf !!!) ön adım olarak tamamlamayı düşünün. Verileri bir nesneye sarmak, katmanlar arasındaki sözleşmelerin başlangıcıdır.

Daha geniş bir düzeyde - henüz yapmadıysanız bu çaba için yönetim satın almayı düşünün. Yönetim, azalan hataların ve değişiklik yapma riskinin somut faydalarını görmelidir. Sonunda, yeniden düzenleme süreci daha hızlı geliştirme sürelerine yol açmalıdır, ancak bu uzun vadeli bir faydadır.

İnceleme ekipleri ve OO evangelistleri hakkındaki fikirleriniz iyi. Bu gündemi iten sizden daha fazlası olmalı.


Cevap verdiğin için teşekkürler Glen! Önerdiğiniz şeyi yaptığımı hissediyorum. Oldukça iyi bir yönetim satın alımı var ve bazı takımların liderleri, iyi uygulamaları takip etmeyen takımlar tarafından yavaşlatılmaktan yoruldular ve sonuç olarak işlerini zorlaştırıyor. İlk cümlede söyledikleriniz çok doğru ve bu sorunun bir parçası. Bence bazı insanlar yanlış şeyler yapmak için çok alışkındır ve geliştirmek için motivasyonları yoktur.
Augusto

4

Benim deneyimim, ussal zihniyetten OO zihniyete geçişin büyük bir engel olduğu. Birçok geliştiricinin dayanamadığı azim gerektirir. Bunun nedeni esas olarak OO'nun temellerinin gözden geçirilmesidir.

Farklı ekiplerde OO düşünce tarzını yayan OO evangelistlerinden oluşan bir ekip oluşturun (bu kişilerin birkaç ayda bir ekip değiştirmesi gerekir).

iyi bir fikir. Bu ayrıntılı olmalı ve OO sıfırdan bahsedilmelidir. OO öğrenirken tarihsel fıkralar çok yardımcı oldu.

Ayrıca şunu da öneririm,

  • Motivasyon anahtar olduğundan, OO'nun çalışmalarını, özellikle de kod sürdürülebilirliğini nasıl geliştirebileceğini ayrıntılarıyla motive edin.
  • Kod incelemesi yapın ve kompozisyon, kalıtım, polimorfizm ve kalıpları uygulayarak nasıl yeniden düzenleme yapılacağını gösterin.
  • SCRUM gibi iyi bir süreç getirin ve geliştiricileri buna dahil edin.
  • 'Yeniden Düzenleme' ve 'Desenlere Yeniden Düzenleme' gibi kitapların okunmasını zorunlu hale getirin.

Cevabınız için teşekkürler Shuvo. Zaten SCRUM ve kod incelemeleri yapıyoruz (ancak genellikle gözden geçiren OO prensiplerini bilmeyen insanlardan biridir) ... Ve önerdiğiniz ilk şeyde başarısız oluyorum. .. Bazı kitap okumayı zorunlu hale Hakkında ama :( çok az başarı ile motive ekipleri çalışıyorum insanlar bir kopyasını alıp okumadı olarak bunu okumasını diğer insanları engelleyerek, o işi hiç görmedim.
Augusto

1

Shuvo Naser ile aynı fikirdeyim. Bu büyük bir engel, bu yüzden daha çok bir tırmanış gibi davranın. OOP kullanarak tüm uygulamanın nasıl tasarlanacağını öğrenmek zaman alacaktır.

  1. OOP'yi anlayanları tanımlayın ve ekip liderlerine, eğitmenlere, tasarımcılara, kod gözden geçirenlere vb.
  2. Mevcut bir projeyi eğitim referansı olarak kullanın. Muhtemelen 1 numaradakiler bu takımdaydı.
  3. Mevcut bazı projeleri yeniden gözden geçirin. Bu, bazı kişilerin prosedür kodları ile OO kodları arasında bir köprü kurmasına yardımcı olabilir. Temel bilgilerle başlayın. Bu ilkeleri ne zaman, nerede ve neden kullandığınızı görmek zorundalar.
  4. Onları ne yaptığını bilen insanlarla tasarım oturumlarına dahil edin.
  5. Onları tasarım rehberliği sağlayabilecek biriyle birlikte ekiplere koyun ve projenin OO ilkelerine sadık kaldığından emin olun (Bunu yapmak istemenizin sebebi, gelişmeyi geliştireceğidir.).

Evlat edinme nadiren faydaları görmekten önce gelir. Karmaşık tasarımdan bahsediyoruz ve TPS Rapor Kapak Sayfalarını kullanmıyoruz .


-1. Bu cevap, sanki normal geliştirici için değil, yönetici gibidir. İnsanları "taşıyamaz" ve insanları "dahil edemez". IMO.
Euphoric

+1. Bu bir yönetim sorunudur ve bir sorun olarak ele alınmalıdır. Tarzı belirleyen orta ve alt yönetimdir (takım lideri yönetimdir). Bir şirketteki değişim, ancak yönetime şeffaf olduğunda aşağıdan gelir. OOP'ye geçmek, üstte düşünme konusunda bir değişiklik gerektirir. Geliştirme sürecini prosedürel / şelale tutmak OOP için biraz anathemadır.
David Hammen

@Euphoric - sadece yönetim onayına ihtiyacınız var. OP "koçluk yaptığım takımlardan" bahsetti. Belki de yönetim değildir ama nasıl çalıştıkları üzerinde etkisi vardır.
JeffO

@JeffO Evet, haklısın. Ancak, yönetim bu tür çabaları desteklemek istiyorsa her şey düşüyor. Son işimde böyle bir şey yapmak imkansızdı, çünkü yönetim geliştiricilerin eğitimi ile ilgilenmiyordu.
Euphoric

Beyler yorumlarınız için teşekkürler. Yönetici değilim, sadece sinirli bir mimarım. Özellikle daha hızlı, daha ucuz ve daha iyi anlamına gelirse, yöneticilerle biraz ilgim var. Ne yazık ki, şirkette her projeye yardımcı olacak yeterli mimar yok ve kalitenin yeterince iyi olmadığı projelerin çoğunda özel bir mimar yok.
Augusto

1

Zaten İyi Fikirleriniz Var

Sorunuzda belirttiğiniz fikirler mükemmel görünüyor. Başarı bulamamanız büyük bir sürpriz. 2012 ve nesne yönelimli devrim uzun zamandan beri en son teknolojiden son teknolojiye geçti. Çok düşük bir dönüş ve çok az işe alımınız olmadıkça, birkaç düzine hatta yüz iyi katı nesne yönelimli programcıya sahip olmamanız zor olurdu.

Çevik mi Nesne mi Odaklı?

TDD gibi bazı Agile teknolojilerinden ve bazı yeni konseptlerden bahsediyorsunuz, bu yüzden hala bazı yönetim ekipleri tarafından aktif olarak mücadele edilen bir şeyi kucaklamamaları için çok sert olmayın. Bazıları Agile'ı kucakladığını iddia ediyor, ancak bunun hakkında konuştuklarında, bunun ne anlama geldiği anlamına geliyor. Organizasyon, kararlar veren ve uyum sağlayan ekipler tarafından değil, güçlü hiyerarşik sözleşme tarzı kontrol ile karakterize edilir.

Ama nesneye geri dönelim. Nesne yönelimli analiz veya tasarımdan bahsetmiyorsunuz ve hangi programlama dilinin hangi nesne yönelimli programlama diline yol açtığından emin değilim. UML'nin birçok nesne yönelimli programcı arasında popülerlik sorunları yaşadığını biliyorum. OOAD konusunda iyi bir eğitim almış olmanın doğal dilini öğrenmek istediğiniz bir ülkenin kültürünü ve tarihini öğrenmek gibi olabileceğine inanıyorum. Örneğin, Yunanca öğrenmek istersem, alfabeyi, kelimeleri ve dil bilgisini öğrenebilirdim, ama zengin tarihi ve kültürü görmezden gelirsem, çok özleyeceğim. Her durumda, nesneye yönelik bir programlama dili hakkında her şeyi öğrenirsiniz, ancak OOAD hakkında hiçbir şey öğrenmezseniz, önemli bir fırsatın kaybolduğunu düşünüyorum.

Aşılması Gereken Sorunlar?

Köprü çok mu uzakta? İnsanlardan haftada küçük bir şey öğrenmelerini istersen, yılda, katılan insanlar arasında çok fazla değişiklik olacak. Onlardan bildikleri her şeyi değiştirmelerini isterseniz, birkaç kişi tarafından memnuniyetle karşılanacak, birçokları için zor ve diğerleri için imkansız olacaktır. Kaynak kontrolü gibi bazı değişiklikler yerelleştirilmiştir. Daha önce yapmamanızdan geçiş yapıyorsunuz, hafızanın sınırlarını vurgulamayan bir eğitime sahiptiniz, birisi size ilk kez buralarda yürüdü ve sonra günlük oldukça kolaydı.

Diğer değişiklikler yaygındır. Örneğin, C dökümü ve Java'ya geçiş, yeni bir IDE, yeni derleyici, yeni dil, yeni API, yeni dağıtım modeli vb. çoğu zaman bir pilot program veya kurumsal yeniden yapılandırma ile bağlantılı olarak gerçekleşir.

Devrime liderlik etmek? Şu anda işi yapan insanların ödüllendirilme geçmişi varsa ve şirket başarısız olma tehlikesi içinde değilse, değişim motivasyonları nedir? Yönü işaret etmek ve tahmin edemeyecekleri sonuçlardan sorumlu tutmak isteyen bir yabancı gibi görünüyorsanız, tüm risk gibi görünebilir, ödül yok gibi görünebilir.

Pozisyon Gücü veya Fikir Liderliği? Birçok kuruluş pozisyon gücüne göre çalışır. Yöneticilerden, bölüm başkanlarından, direktörlerden ve Başkan Yardımcılarından görünür desteğe sahip değilseniz, yalnızca bir fikir liderisiniz. Bazı insanlar bir fikre sahip olmak ve ikinci bir fikri eğlendirmek gibi tehlikeli bir konumdadır. Onları söylemek yerine gösterebilirseniz, bu şüpheci sessizlere ve yetenekli müttefiklere ilgi duymanın çok yoludur.

Destek Tabanı Çok Küçük mü? Bu 250 kişi arasında bir triyaj yapın ve bunları üç kategoriye ayırın: kucaklamaya hazır, öğrenmeye istekli ve öğrenmek istemiyor. Değişiklik yapmakla ilgilenmeyen bazı insanlarla hayal kırıklığına uğramak için iyi nedenleriniz var. Bir ip de itiyor olabilirsiniz. Bu boşa harcanan çabadır. Değişimi kimin desteklediğine dair bir fikriniz varsa, onları neyin ilgilendirdiğini öğrenebilirsiniz.

Etik ve pratik seçimin, orta gruba yardım ile yardımcı olabileceği tıbbi bir triyajın aksine, yargı ve tercihinize göre enerjinizi ve zamanınızı yatırım yapabilirsiniz. Başarınız için neden yeni fikirleri benimsemeye hazır olan grubu geliştirmiyoruz? Birincisi az olabilirler, ancak bir kartopu gibi, bir savunucu olarak görünürlük ve güvenilirliğiniz artacaktır. Yakında insanlar bir sonraki eğitimin ne zaman olacağını soracaklar.

Uzun Vadede mi? Sizden sonra bir şeyler taşımak için bir şampiyon geliştirinceye kadar, ilişki kurmak için zaman ayırmayı beklemelisiniz. Bir aydan fazla koçluk yaptığınız ekiplerle kalmanız gerekebilir. Ekip kendileri için geliştirilmiş uygulamalara sahip olana kadar, sadece bir teknoloji veya metodoloji polisisiniz. Mentorluk yıllar alabilen bir süreçtir. Geliştiricilerinizin önemli olduğunu düşündüğünüz şeyleri yapmak istemediği birçok şey var (özellikle birim testlerden bahsettiğinizi düşünüyorum). Bunun getirdiği değere ilişkin ortak bir vizyon oluşturmak biraz zaman alabilir. Bunu tecrübe ile biliyorum, çünkü bir zamanlar Fortune 500 şirketinde kalite için büyük bir üne sahip bir kod kapsama aracını savundum, ancak yöneticiler ve akranları buna bağlıyken dikkatli idi.

Uzman mı, Tabandan mı? Mentorluktan çok daha hızlı, her ekip üyesinden gelen taban desteğini teşvik etmek olacaktır. On yazılım uzmanından oluşan bir ekiple başlayarak, bir kişinin sürekli süreçte çalışmasını ya da on kişinin süreçte yüzde on oranında çalışmasını seçseydim ikincisini seçerdim. Taban süreci, savunucuların yaklaşımın etkisini hissetmelerine ve yaklaşımın, çalışmanın sahibi olan ekibin sorunlarını en iyi şekilde çözecek şekilde tasarlanmasına izin verir.

Özgürlük Çizgisini görüyor musunuz? "En İyi Uygulamaları" tanıtmanın bir parçası, insanların işleri ortak bir şekilde yapma özgürlüğünden vazgeçmelerini sağlamaktır. Geliştiricilere birçok seçenek bırakma fırsatı arıyorsanız, programcının takdirini vermek daha lezzetli olacaktır. Seçtikleri, özgürlük çizgisi diyebileceğimiz bir bölüm tarafından zorunlu kılınan şeyden tanımlanıyor. Örgütsel, bölgeye / bölgeye özgü, ekip ve kişisel uygulamalar hakkında benzer, iyi gerekçeli bölümlere ihtiyaç duyulabilir.


0

Bu bir yorum olmalıydı, ama görünüşe göre henüz bir şey hakkında yorum yapamadığım için bir cevap da olabilir.

Bu tür atılımlarda şimdiye kadarki en önemli şey (ister OOP ister başka bir paradigma kayması, örneğin fonksiyonel programlama veya gelecek yıl ne olursa olsun) DO KOD DEĞERLENDİRMELERİ VE AKRANLI PROGRAMLAMA . Onlara eşlik edin, takımlara kendilerine yardımcı olacak şeyler yapmanın farklı bir yolunda yürüyün.

Nesne yönelimli programlamaya yönelik kişisel yolum, bazı rasgele asshat kod incelemeleri yaparken modüler bir şekilde ve tam manevra durumu olmadan mantain durumu için beni azarladığında başladı; kodu şöyle düşün

extern float clients_total;

void client_add(float sum);  
void client_substract(float sum);
float client_get_total();

(clients_total öğesinin, özellikle kötü planlanmış bir örnek olması nedeniyle tamamen gereksiz olabileceğini unutmayın)

Ve bunu sadece daha kıdemli bir iş arkadaşım ekranımı gösterdiğinde ve "bak, aynı şeyi bir kereden fazla yazarsanız, bir prosedür veya işlev kullanın ve sadece tekrar tekrar çağırın" dediğinde bunu yaptım.

Görüşmeler ve toplantılar ve isteğe bağlı uygulamalar, onları bir paradigma değişikliği yapmayacak veya yeni bir uygulama getirmeyecektir, çünkü saf meraktan başka gerçek bir dürtü yoktur. Öte yandan, kötü bir şey yapmamak ya da genellikle bir şey üzerinde kaşlarını çatmak benimseme oranını çok iyi arttırır.

Gerçi yaptıklarına uygun tasarımı dahil edene kadar ortaya çıkan sızlanma ve sınıf odaklı gelişime hazırlıklı olun. Biraz içinde ölmeni sağlayacak çok şey göreceksin, ama öğrenmenin yolu böyle görünüyor.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.