Işık görmek için bir kopyala / yapıştır / spagetti programcısı dönüştürmek nasıl?


35

Bu soru esinlenerek bu bir . Bu diğer sorunun yerelleşmiş sayılmasına rağmen, asıl sorunun sektörümüzde son derece yaygın bir şey olduğuna inanıyorum. Bunu okumak ve ben bu şeyleri yapıyorum düşünmek ve daha sonra onların çalışmaları hakkında herkesin umurunda ve öğrenmek istiyor nasıl cevap olabilir bazı geliştiriciler, var biliyorum, ama sadece diğer Programcılar SE mesajlar (bakarak noktada durum ), Bunun evrensel olarak doğru olmadığını biliyorum.

Diyelim ki ekibinizde (veya belki de çoğunluğun) standart çalışma prosedürünü kopyalamak / yapıştırmak olan ve yalnızca yeterli işlev çağrısı ve değişkenleri eklerseniz her şeyin çözülebileceğine inanan birisinin olduğunu varsayalım. Bu kişi TDD, DRY veya SOLID'i hiç duymamış ve meşgul oldukları sırada işyerinde 40 saatin dışında hiç bir zaman tek bir metodoloji / uygulama / tasarım kitabı okumamışlardır.

Geçmişte ben (ve diğerleri) sordum, nasıl OOD öğreteceğinizi sordum . Ama şimdi bunun doğru soru olmadığını düşünüyorum. Asıl soru, böyle bir kişiye / takıma nasıl yaklaşıp bunları daha iyi şeyler yapmayı nasıl meraklandırdığınızdır? Onlara öğrenmeleri için nasıl ilham veriyorsunuz? Bu olmadan, tüm öğretim, toplantılar, konferanslar, tartışmalar, masalarına dönüp her zaman yaptıklarını yapmaktan tamamen memnun olduklarında işe yaramaz görünüyor.

Bunun gibi bir sürü insanla çalışıyorum. Onlar aslında oldukça parlak bireyler, ancak duyduğumda nefret ediyorum, "kodlamayı bitirdim, yeniden düzenlemeye ihtiyacım var ve DXM'yi mutlu etmek için birden fazla sınıfa bölmem gerekiyor". Daha temiz, okunaklı, bakım yapılabilir kod için refactor yapmazlar, ancak sadece aksi halde azarlanırlar. Öğrenmeye yetenekli olduklarını biliyorum, genel bir motivasyon eksikliği varmış gibi görünüyor.

İş teslim ettiğimde, genellikle daha az hataya sahipti ve sahip olduğum iş hiç bir zaman sınıftaki 5000 satırlık canavarlık olmadı. Diğerleri "kodunuz bizim malzemelerimizden daha temiz ve okunabilir" gibi yorumlar yapar, bu yüzden farkı görürler. Ancak aynı zamanda, ne yaptıklarına bakılmaksızın 40 saat boyunca ödeme aldıklarına inandıkları gibi hissediyorum, bu yüzden QA'da 3 gün geçirmiş olmaları gereken bir hatayı arayarak gerçekten de umursamıyorlar. ilk sırada. Ya da bir sınıfı değiştirmek için haftalarını harcadıklarını, çünkü dokunacakları çok fazla bağımlılık var. Yine de, "belki de bu sınıf farklı yazılmış olmalıydı" hiç görünmüyor.

Bu durumlarda herhangi bir şey yapılabilir mi? Başarılı olan var mı? Yoksa bu zihniyeti projenin kritik olmayan kısımlarına ayırmak ve hasarı en aza indirmek en iyisi midir?

NOT: "Motivasyon eksikliği" dediğimde. Çalışmak ya da iyi bir iş yapmak için motivasyon eksikliği olduğunu düşünmüyorum çünkü onlar umursamayı bırakmışlardı. Ekibimizin çoğu aslında tam tersi. Kesinlikle ürünü önemsiyorlar. Geceleri ve hafta sonları çalışacak adamlarımız var. Başa çıkmaya çalıştığım kısım, gelişmiş alışkanlık ve becerilerle, aslında fazla çalışmak zorunda kalmayacaklarıydı. "40 saat" olayının bu mesajın biraz fazla olumsuz çıktığını düşünüyorum.


Bu hangi ülke?

3
@ ThorbjørnRavnAndersen - ABD. Şimdi bir cevap yazmalısınız çünkü bu bilginin onu nasıl etkilediğini çok merak ediyorum :) Her zaman hepimiz insan olduğumuzu ve bu tür şeylerin evrensel olduğunu düşünüyorum. Ve hayır, bu sorunun dış kaynak kullanımı ile ilgisi yok.
DXM

8
Ülkeler arasındaki kültürel farklılıklar önemli olabilir ve değişime yol açma girişimleri bunu hesaba katmalıdır. Bir kültürde işe yarayan şey büyük olasılıkla bir başkasında işe yaramayacaktır. Sizin durumunuzda, en iyi yolun, yönetimin resmi olarak kabul edilebilir olanların çıtasını yükseltmesi olduğuna inanıyorum.

Yanıtlar:


18

Kendine sebebini buldun: "Öğrenmeye yetenekli olduklarını biliyorum, genel bir motivasyon eksikliği varmış gibi görünüyor."

İşleri konusunda tutkulu olan insanlar var. Ve bazen yeterince yetkin olmakla, sadece para için çalışanlar da var . Eşyalarını biliyorlar ama işlerinden hoşlanmıyorlar. Hızlı ve çirkin bir kesmek işi yapabildiği zaman, kodu okunabilir hale getirmek veya ilgi çekici bir sorunu çözmek için ek yeniden düzenleme yaparak fazladan zaman harcamazlar.

Bu fenomen her işte var. Sadece bazı işler aşırı derecede heyecan verici değil (işini seven ve daha önce çocukken bunu hayal eden bir muhasebeci gördünüz mü?), Ancak programlamada, yaptıklarını gerçekten seven bir sürü insan var (aksi halde) Programcılar. Oldukça boş olacak). Bu, her gün diğer tutkulu geliştiricilerle konuşan tutkulu geliştiriciler olarak, sadece para için programlama yapan bir kişiyi görünce şaşırmamız için daha fazla şansımız olduğu anlamına gelir.

Ne yapabiliriz? Çok fazla değil. Her durumda, sana değil, gerçekten motive olmuş insanları seçmek için insan kaynağına. Ve olmayan insanları kov.

Meslektaşlarını kendin motive etmeye çalışabilirsin, ama bu çok zor. Onlara okuması için kitap verirseniz, birkaç hafta sonra açılmadan geri gönderilirler. Onlara bir tavsiyede bulunursanız, dinlemeyecekler, çünkü umursamıyorlar².

Yapabilirsin:

  • Patronunuzu şirketinizde bir dizi katı kurallar koymaya ikna edin: stil kuralları , vb. Bu, insanları daha iyi bir iş yapmaya motive etmeyecek, ancak en azından gereksinimleri karşılayamayan kaynak kodları işleyemeyecekler. .

  • Gereksinimler üzerinde çalışın, özellikle işlevsel olmayan gereksinimler . Belirli bir projenin 5 000 satırdan daha az IL kodu içermesi gerektiğini söyleyen bir gereksinim (hayır, anlamsız LOC hakkında konuşmuyorum ) ³? Döngüsel karmaşıklıkta veya sınıf bağlaşımında belirli sonuçlar elde etmeyi gerektirmeye ne dersiniz ?

  • Şirketinizde kod incelemeleri yaparak geçirdiğiniz saatleri artırın . İncelenecek olanı belirtin: bir kontrol listeniz varsa, yeniden düzenleme, okunabilirlik, temiz ve faydalı yorumlar vb. İle ilgili noktaları ekleyin. Bir kontrol listeniz yoksa, yapmanız gerekir.

  • [Daha fazla] çift ​​programlama kullanın . Kod kalitesini yükseltmeye ve daha az motive olmuş iş arkadaşlarını motive etmeye yardımcı olabilir.

  • Fog Creek'te kullanılana benzer bir kompanzasyon sistemi kullanın .


İnterview Röportajların konusu budur: sizi işe almadan önce , insan kaynakları sadece teknik seviyenizi değil, motivasyonunuzu da değerlendirebilmelidir . Ne yazık ki, bazı şirketler röportajın bu ikinci bölümünü unutuyor ve programlamayı çok fazla sevmeyen insanları işe alıyor. Neyse ki, çoğu durumda, bu şirketlerdeki işler hiç zevkli olmaz ve Joel testi nadiren 2'yi geçer.

² Daha az para kazansalar bile gerçekten umursamıyorlar. Çalışmalarının kendi müşterileri için web siteleri geliştirmek olduğuna inanan müşterilerimden birine (serbest çalışan biri) oldukça yakınım . Ayrıca bir tasarımcı var. Onlara, üretkenliklerini 2 ya da daha fazla arttırma yöntemleri hakkında defalarca söyledim. Yetkili birini işe almaları halinde gelirlerini en az 3 artıracaklar. Ancak yeterli paraları var ve cömert müşteriler için üretken birine kıyasla kaliteyi ya da ne kadar maliyeti olduğunu umursamıyorlar.

I Demek istediğim, Visual Studio'daki Kod Metrikleri'nde gördüğünüz IL kodunun satır sayısı, yani gerçekten bir anlam ifade eden metrik. Gerçek LOC önemli değil ve bunu ölçmek gerek yok; şimdiye kadarki en aptal metriklerden biri. IL kod satırı zorlamak, geliştiricilerin yalnızca yeniden okunamayan bir satırda on kod satırını daraltmak yerine, aslında yeniden kodlama koduna zorlanacakları anlamına gelir.


3
Aynı fikirde değilim: Çalışma motivasyonu ve öğrenme motivasyonu tamamen iki ayrı şeydir. Örneğin, bazı insanlar işlerini ve işlerini severler, ancak "KATI" nın başka bir saçmalık-bingo kelimesi olduğunu ya da "TDD" nin gerçek dünyada kullanılmayan bir fildişi-kule konsepti olduğunu düşünebilirler.
nikie,

5
@maple_shaft haklı: Bazı insanlar haftada 70 saat çalışıyor ve herhangi bir test yapmadan en fazla miktarda spagetti kodu üretiyorlar (böyle saçmalıklara zamanları yok!). Tutkulu ve yeteneklerini sürekli geliştirmeye devam etse de, 40 saat sonra eve git, çünkü zaten daha uzun süre üretken olamayacaklarını biliyorlar. İki şeyi karıştırmayın!
nikie,

13
Hayır hayır hayır. Bir işveren tarafından sömürülme isteği! = Kalite kodu üretme becerisi. Bu "efsanevi İdeal Geliştirici" ile bir araya getirmeden, endüstrimizde meydana gelen saçmalıktan "saat 2'ye kadar kalmak" için çok fazla şey var. SİZ hafta 80 saat çalışmayı seviyorsanız, size daha fazla güç. İş dışında benim için önemli olan şeyler var. Sonuç olarak, yaptığım işte kötüyüm, en iyi ihtimalle sahte. Başka hiçbir sanayi bizim sahip olduğumuz şeylerden uzaklaşamaz ve eğer değişecekse, bunu değiştirmek bize kalmıştır.
Dan Ray

6
Bir proje üzerinde çalışmak için 02: 00'a kadar çalışmak zorunda olmak, söz konusu projeye, özellikle de aile yükümlülüklerine sahip olanlar için her türlü sevgiyi öldürmenin çok etkili bir yoludur.

2
Burada belirtilen tüm noktalar geçerli olduğunu düşünüyorum, ancak bazılarınız MainMa'yı yanlış anlamış olabilir. Asla öğleden sonra 2'ye kadar çalışma demedi, çünkü son başvuru tarihleri ​​nedeniyle zorlanıyorsun. Bunun yerine, basitçe bir şeyler gördüklerinde heyecanlanmaktan bu kadar yakalanan insanlara atıfta bulundu, bazen uyumaktan ziyade halletmeyi tercih ediyorlardı. Bununla ilgili olabilirim. Benim için aşırı bir örnek, video akış kitaplığımıza tünel desteği eklemek için üzerinde çalıştığım bir görevdi. 5 gün olarak tahmin edildi, ancak yeni boru hattı mimarimizle her şey çok iyi bir araya geldi, cuma öğleden sonra başladı ...
DXM

12

"Kodlamayı bitirdim, sadece DXM'i mutlu etmek için yeniden sınıflandırma ve çoklu sınıfa bölme ihtiyacı var".

Bu düşünce hattı, herhangi bir takımda bir kanserdir ve derhal dikkate alınmazsa tüm ekibin motivasyonunu öldürür. Elbette kıdem ve / veya hak olarak size teknik otorite pozisyonunda olmanız, ekibinize iyi uygulamaları etkileme ve uygulamada yardımcı olma yetkisi verme gerçeğinden bahsediyorum.

Bunların hepsi iyi ve güzel, ancak eğer ekibiniz bu süreçlerde açıkça satılsaydı, sürece saygı duymadığınızı ve sizde saygı duymadığınızı açıkça gösteren birbirinizle ilgili açıklamalarda bulunmazlar. Yine de bu en iyi uygulamaları ekibinizin sahip olduğu bir sürecin değil , sizin kendi haklarınızla savunacakları, sizin neden olduğunuz bir engel olarak görüyorlar .

Daha önceki yorumlarda, diğer ekip üyelerinin gerçekten bu uygulamaları ve standartları iyi takip edip bunları doğru şekilde uyguladığını belirtiyorsunuz. Öncelikle onlardan destek almak, onlara neyin işe yaradığını, neyin işe yaramadığını, neyi sevdiklerini ve nelerin değiştiğini görmek istediklerini sorun. Bunu yapar ve görüşlerini ciddiye alırsanız, üstlerinden kendilerine verilen bir prosedür yerine topluluk kararlarıymış gibi standartlar hakkında çok farklı hissederler.

Ekibe yazılım geliştirme sürecini veya yazılım kalitesini nasıl geliştirdiklerini belirterek en iyi uygulamalar ve standartlar için destek sağlıyorsunuz.

Tartışma için meselelere oy verin ve sonuçları belgeleyin; ideal olarak her kararın meşruiyet adına oybirliği ile verilmesi gerekir; ancak, sert engeller ile uğraşıyorsanız bu imkansız olabilir ve her konuyu durdurabilir. Bu durumda çoğunluk oyu kullanın. Çoğunluğu önerilen standartlara ve uygulamalara aykırıysa, o zaman odayı zaten kaybettiniz, o zaman sadece pes edin.

Onlar edecektir sahibi olanlar standartları ve prosedürleri ile olacak zorlamak bunu yapmak zorunda kalmamak için onları. Bir teknik lider olarak, düzenlemeleri ve kararları beyan etmek zorunda değilsiniz, bu lider olmak için kötü bir yoldur.

Ekip, prosedürlere sahipmiş gibi hissettiğinde, sizi belirli prosedürlere ve en iyi uygulamalara göre etiketlemeye başlayan ekip üyeleri, böyle düşünmek için gayrı meşru olacaktır. Ekibiniz diğerlerinde bu tutumu düzeltmeye yardımcı olacaktır.



5

İyi soru! Bence cevap neden insanların yeteneklerini geliştirmek istemediğine bağlı. Olası cevaplar:

  • Yeni bir şeyler öğrenmek için çok meşgul olduklarını düşünüyorlar ya da yeni şeyler yapmanın (tüm bu testleri yazmak gibi) onları daha uzun süreceğini düşünüyorlar ve bunun için zamanları yok. O zaman bariz cevap şu olurdu: onlara daha fazla zaman verin. Şey Öğrenme ya hep bitti işler farklı olmasa da bunu TDD gibi bir şey çalışıyor olacak daha seferinde İlk birkaç kere alın. Eğer programcılarınız o zamana sahip olmazlarsa, denemediğiniz için onları suçlayamazsınız.
  • Kendi yetenekleri hakkında farklı algılara sahipler, yani yüksek kalitede kod üreten çok iyi programcılar olduklarını düşünüyorlar. Bu zor psikolojik alandır, çünkü bu inancı yıkmak çok aşağılayıcı olabilir. Belki bir tür gayrı resmi rekabet yardımcı olabilir (kim en az hata / özellik üretir? En kısa kod? Bir kod incelemesinde en az WTF / dakika?).
  • Gerçek bir motivasyon sorunu olabilir (yani kapanma zamanına kadar sadece "zamanlarını yapmak ve yalnız kalmak" istiyorlar). Neyse ki, bu çok genel / programlama ile ilgili değil, çünkü bunun için bir cevabım yok.
  • Yeni başlayanlar ve daha iyisini bilmiyorlar. Bu durumda, eğitim, kod incelemeleri yardımcı olabilir veya bir ekip üyesinin her ay yeni bir teknik kitap tartışması gereken bir "kitap kulübü" olabilir.
  • Daha önce gümüş mermiler görmüşlerdi (ve acı bir şekilde hayal kırıklığına uğradılar) ve onları satmaya çalıştığınız şeyin teoride kulağa hoş gelen ve pratikte az kullanılan bir başka sözcük olduğunu düşünüyorlar. Bu durumda, kod incelemeleri ve çift programlama oturumları sırasındaki avantajları göstermek işe yarayabilir. Bunu yaptığınızda tamamen bilmediğiniz bir şey olmaya çalışın.

En iyi çözüm gerçekten kök soruna bağlıdır: Örneğin, resmi kodlama yönergeleri, metrikler ve incelemeler yeni başlayanlar için işe yarayabilir, ancak "kendi becerilerinin yanlış algılanması" altındaki insanlar kendilerine karşı mücadele edebilir veya metrikleri oynayabilir. Onları işlerini yapmanın karşıtı bürokratik engeller olarak görüyorlar.


Güzel nokta. Özellikle ilkini seviyorum - ve hatta genelleştireceğim: İlk önce, iş başında öğrenmenin teşvik edildiğini ve bunun için zaman ayırmanın açıkça doğru olduğunu açıkça söylemeniz gerekir.
29'da sleske

Eğer insanlar yeteneklerini farklı algılarsa, belki de sadece farklı parametrelerde başarıyı ölçüyorlar? Kodun kalitesini ölçüyorsanız ve kodun ne kadar hızlı oluşturulabileceğini düşünüyorlarsa, sonuç farklı olacaktır - bu tür durumlarda, başarıyı nasıl ölçtüklerini sormaları gerekir. Farklı insanlar bunun hakkında düşünmek için farklı yollar var.
tp1

3

Asıl soru, böyle bir kişiye / takıma nasıl yaklaşıp bunları daha iyi şeyler yapmayı nasıl meraklandırdığınızdır? Onlara öğrenmeleri için nasıl ilham veriyorsunuz? Bu olmadan, tüm öğretim, toplantılar, konferanslar, tartışmalar, masalarına dönüp her zaman yaptıklarını yapmaktan tamamen mutlularsa, işe yaramaz görünüyor.

Bu kadar! Bu gerçekten gerçek bir soru.

Bir miktar artalan vermek için, çok fazla resmi eğitime koyma vaktimiz yok - ama bazen yaparsam - hala ışık görmüyor. Örgün eğitimin kendisi bir süreç haline geldiği şirketlerin de bir parçası oldum. O kadar sıklıkla tanık oluyorum ki onlara nasıl düşüneceklerini öğretmiyorlar .

Öyleyse onlara poz verdiğim soru, onlara nasıl öğretileceği değil - nasıl öğrenmelerini sağlamaktır? Fark incedir ancak tüm farkı yaratacak olan budur.

Haklı mıyım bilmiyorum; ama genellikle bir Matrix diyaloğuna inanıyorum - “Bu bizi yönlendiren soru!” En önemlisi, düşünmelerini sağlamak, nedenini sormalarını sağlamak! Ve elbette, çoğu, bazı tasarım kalıpları hakkında zaten her şeyi bildiklerini düşünenlerin çoğu, çünkü üniversite kurslarında iyi puanlar alıyorlar - orada en zor olanları.

Onları böyle sorular haline nasıl getirirsin? Genel yaklaşımım "yüzmeyi öğrenmek istiyorlarsa onları havuza atmak" tır . İnsanların aynı fikirde olamayacağı konusunda hemfikirim; ve onlarla aynı fikirde olmamayı memnuniyetle kabul edeceğim. Onları havuza attığınızda - aslında otomatik olarak yüzmeyi öğrenmezler; ancak, onları düşündüren bir hayatta kalma içgüdüsüne yol açar - bir kez olur, doğal olarak NASIL ve NEDEN'i düşüneceklerdir.

İnsanlara verdiğim pratik bir örnek, bir tanesini almayı umduklarından daha karmaşık bir projeye sokmak ve kendi savaşlarıyla savaşmalarına izin vermek. Kodu çözmeye ve izlemeyi zor bulmaya başladıklarında - iyi bir soru sormaya başladıklarını anlıyorsunuz.

Bu biraz aşırıcı gelebilir, bu kaynak israfı olabilir . Ve eminim, bunu yapmamam için bana tavsiyelerde bulunacak başkaları da var. Ama bu benim için çalıştı!

Hangi ödeme paketleri ve İK etiketleri ne olursa olsun, temel motivasyon problemini çözmez . Bunun için tek yol onların meydan okuması; Bu temel insan ruhundan kıvılcım çıkarsanız - her şey işe yarıyor. Yapamazsan, gevşek bir oyun.

Not: Sadece tesadüfen burada yanıt gönderdi https://softwareengineering.stackexchange.com/questions/127021/how-do-you-train-freshers/127034 - ve ben tüm dayak var; Öncelikle çoğu insan bir şekilde işletmelerin kaynakları boşa harcayamayacağına inanıyor! Eminim bu cevap burada da benzer bir tedavi olabilir. Ancak gerçek şu ki, insanları çalışmaya ve onları iyi bir iş yapmaya inandırmaya zorlamak, kursun müfredatının nasıl oluşturulacağına dair insan psikolojisinin bir konusudur.

Her neyse, burada tanımladığınız görev, büyük bir değişiklik yapma iç tutkusunu tutuşturmaya dayanıyor. Ve sistem büyüdükçe zorlaşır. Hala işe yaramayacak iş ruhuyla yerleşik genç arkadaşlarla başla ve statükoya meydan oku.


matrisi getirdiğiniz için teşekkür ederim, şimdi hayatımın 2 saatini tekrar izleyerek geçirmek zorundayım :) Komik ama "taze" lerin onlara attığınız her şeyi emecek olanlar olduğunu gördüm. İyi bir CS programından mezun olmuş biri olarak, "eğitimleri" hakkında ne düşündüğümü çok net bir şekilde ortaya koyuyorum ve çoğunlukla benimle aynı fikirde. En büyük sorunların bunu 10, 15, 20+ yıldır yapan adamlar olduğunu düşünüyorum. Ayrıca "ateşe karşı deneme" yaklaşımınıza katılıyorum. Ne yapmamam gerektiğini tam olarak böyle öğrendim. Sorun şudur: a) çoğu takımın göze alamayacağı ve b) takımda çalışırken uzun zaman alacağı ...
DXM

.. ayarı ("yarı-çevik" demeye cesaret ediyorum, benden nefret etmeyin :)), ateşkes için gereken tek mülkiyete sahip değiliz. Başarısız olan bir şey yazarlarsa, birisi içeri girip düzeltir. Su birikintisine girmiş ve çoğunlukla yapmış biri olarak, tüm ekibinizin göletten geçmesine gerek kalmadan bu zihniyeti aktarmak için yapılabilecek bir şey olup olmadığını merak ediyorum.
DXM

@DXM Tüm ekibin bir kerede gölete atılmaması konusunda endişelerinize katılıyorum . Evet. Mesele şu, bir kısmını tek tek atmaya başla! En azından bu aramızda iyi bir anlaşma. Bence yıllarca gelişen zihniyet - biraz zaman ve değişime azim alacaktır.
Dipan Mehta

Size daha somut şeyler vermek için @DXM - bir seferde küçük girişimler deneyin - başarıları gösterin ve yönetimin burada iyi iş yapmak için iş anlamına geldiğini gösterin . Ve zihin setinin tanıtımını yapın - her seferinde bir adım. sebat bir zorunluluk olurdu, ama son şirketimde böyle bir şeyi başardım. Zaman içinde yönetim ekibime bunu nasıl iyi yapabileceğinin bir örneği olarak vermeye devam etti.
Dipan Mehta

1
Cevabınızı seviyorum, özellikle de sizin için işe yararsa, bu nedenle aşağıdakiler bir eleştiri değil, sadece bir not: ne yazık ki, bu her durumda işe yaramaz. Motive edilmeyen geliştiricilerin büyük projeler başlattığı birkaç durum vardı. Her seferinde aynı sona erdi: proje başarısız oldu ve yönetimi ya da meslektaşlarını ya da yeterli zaman ya da kaynak olmadığı ya da gereksinimlerin yeterince açık olmadığı gerçeğini suçladılar. Yüzmeyi öğrenenlerle suyu daha fazla suçlayacak olanları arasındaki farkı neyin oluşturduğunu merak ediyorum.
Arseni Mourzenko

2

Sizin de belirttiğiniz gibi, motivasyonu. Bilmiyorum onları umursamayarak onları yanılma. Ne yapacaklarını açıkça biliyorlar. Sadece umursamıyorlar . Eğer durum buysa, buradaki asıl soru şudur: yönetiminiz onları bu kadar motive etmeden tutan yanlış yapan nedir? Takımın en yeni üyesi siz misiniz? Belki de daha önce tüm bunlardan geçmişlerdir, ancak yalnızca yönetimlerinde sorunlara yol açmıştır. Bu yüzden, sadece işlerini sürdürmek için gereken en düşük miktarda işi yapmaya devam ediyorlar çünkü işveren tarafından daha fazla cevap verileceğini düşünmüyorlar.


Ben takım lideriyim ve neredeyse 9 yıl boyunca takımdayım ancak yaklaşık bir yıl önce liderlik yapmıştı. "İşe ya da kodumun kalitesini önemseme" ile "yeni beceriler öğrenmeyi önleme" arasında bir fark olduğunu düşünüyorum. Aslında yönetim tarafında pek çok gelişme kaydettik ve ekip arkadaşlarımızın çoğu şimdi oldukça mutlu. Ancak, bazıları her zaman yaptıklarını yaparken oldukça memnunlar. Aslında sorulmadan bile fazladan saatler harcadılar, çok tepkiliydi, ancak zaman zaman% 75'inde kendi hatalarını ayıklamaktan oldukça memnun görünüyorlar.
DXM

1
Öyleyse, her meslekte olduğu gibi, herkes çan eğrisinin üst yarısında olmayacak. Mümkün sadece sadece maaş için bazı millet var.
GrandmasterB

Bilirsin, her yıl bir ekip teklifi seçeriz ve 2011 yılı "budur" dır, ama yeni bir yıla başlamak üzereyiz ve en azından şu an için, ne olduğunu kabul etmeyi reddediyorum. Her ne kadar çoğu zaman olduğu konusunda seninle aynı fikirdeyim. Bu soru hakkında daha fazla düşünüyordum ve aslında potansiyeli olan bir fikrim var. Kendi soruma cevap veremediğimden (kişisel bir şey, sistem sınırlaması değil), programcılar yeniden açılmaya 2 kişi daha oy verirse, burada yazacağım :)
DXM

2

Onun Takımınızın o zaman iyileşme (kişisel ve kod) ekibinizin bir çekirdek özniteliği, soru o tarafından desteklenecek emin olmak için çalışabilir eğer - bir yönetim ve liderlik sorunudur geliyor bana senin yönetimi - çünkü zaman alacak işler yapmak isteyeceksiniz (yeni teknik borcu azaltmanız ve mevcut teknik borcu ödeyeceğiniz için net kazanç elde edecekler).

Bu yüzden, ekibin gelişmesini istediğinizi, bunun iyi bir şey olduğu (kendi ekibinin kod kalitesini yükseltmek için çalıştığı) iyi bir şey olduğunu kabul ettiklerini ve daha sonra bunu yapmak için bir program başlattığınızı kabul ediyorsunuz. oldu - çok kolay geliyor ... Öyle olmadığını biliyorum!

Bunun iki bölüm olduğunu düşünüyorum - eğitim ve çalışma uygulamaları.

  • Eğitim haftada bir öğle yemeğine başlayabilir - herkes birlikte yemek yiyor, Q&A ile 20 ~ 30 dakikalık bir sunum yapıyorsunuz. İstediğiniz temel bilgilerle başlarsınız - SOLID ilk 2 ~ 4 haftayı işgal edebilir - zamanla ekibin rotasyonda konuşmasını sağlayabilir ve kiminle ne konuşacağınıza karar vermeyi kararlaştırabilirsiniz. Konuşmacıların çalışma içinde biraz zaman ayırmasına izin verin. Bunun ötesinde yerel kullanıcı gruplarının katılımını teşvik edin (mümkünse en azından kısmen sosyal olanı yaparak)
  • Çalışma pratikleri ... şu anda ne yaptığınıza ve hangi araçlara sahip olduğunuza bağlı, ancak kodlama standartlarını kabul etmeye, akran kod incelemesini (sağlam mı?), Birim sınamasını (önce mutlaka test etmemeye gerek kalmadan) kabul etmek isteyebilirsiniz. sürekli bir entegrasyon sunucusu çalıştırmak ve daha otomatik testlere bakmak (birim testlerine ek olarak). Ancak bunların büyük ölçüde onay / anlaşma (build / CI sunucusu değil!) İle tanıtılması gerekir ve kaliteyi bir ekip olarak ileri götürmek istemeniz gerekir. Her zaman birinin geliştirebileceği şeyler vardır (Kaizen)

Kanban'a bakmaya değer (değişim / gelişme için itici güç olarak görülür).

Son bir düşünce - Ben bir meslek programcısıyım ve ekibimin aynı olmasını istiyorum, ancak haftada 40 saatten fazla çalışmak aslında iyi bir şey değil, bu yüzden hedefinin işini yapan bir ekibin olması gerekir. etkili ve iyi normal çalışma haftası içinde ve bu bakımından çalışma pratiği geliştirmek için argüman daha olası örneğin olmasıdır: bug-sabitleme size güven verir (önceki) o zaman birim testleri ekleyerek başarısız durumda göstermek için isesabit; bir derleme sunucusuna sahip olmak, çözümlerinizi temiz bir şekilde oluşturabilmeniz konusunda size güven verir - bu derleme aynı zamanda dağıtım paketleri de oluşturuyorsa, dağıtımın büyük ölçüde basitleştirildiği anlamına gelir; SOLID kodu, tanımı gereği, değiştirilmesi kolaydır; ve borsa karşısında ne kadar az teknik borç alırsanız o kadar az geri ödersiniz ...


0

30 yıl önce kazayla programlamaya girdim. Başkalarının kodunu korumak / desteklemek için atanarak temel yazılım mühendisliği ilkelerini öğrenmeye motive oldum. Bu ödevlerde, bir kod okuyucunun kodu nasıl yaşadığını öğrendim - kod okuyucuyla nasıl empati kurulacağını. Kötü yazılmış kodumun acısını başkalarına da çekmek istemedim!

Diğer insanların kodunu korumak / desteklemek için yeni programcıların atanması bu uygulama sihirli bir mermi değildir ve katı kod üretilmemekten daha sık nasıl üretileceğini öğrenmek için motivasyon sağlıyor gibi görünmektedir.


1
Ben de kazayla olmasa da aynı şekilde başladım. Bu, Dipan Mehta'nın görevinde söylediklerine çok benzer. Su birikintisine bir insanı atıyorsun, çok derin olmadığından emin ol ve yüzmelerine izin ver. Sen yüzmeyi öğrenenlerden birisin, ama bu evrensel değil (yorumuna cevabına bakınız). Ayrıca, bu tür bir yaklaşımın, kökleşmiş alışkanlıkları olanlara göre yeni insanlar için daha iyi çalıştığını düşünüyorum. Öyleyse, sadece yüzmeleri gerekmiyor, aynı zamanda mevcut uygulamalara da aykırı.
DXM
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.