Eski iş arkadaşımı kullanma

Oldukça genç bir programcıyım ve orta ölçekli bir şirketin BT bölümünde çalışıyorum. Bir iş arkadaşım var ve gerçekten iyi bir Visual Basic 6 programcısı. Ve ben gerçekten iyi demek istiyorum. Dürüst. İlk fincan kahvemi almam ve makinemi açmam gerektiğinde çok az böcek içeren çalışma uygulamaları yapabilir. O sadece bu kadar iyi.

Mesele şu ki, bir ekiple çalışıyoruz ve çalışma tarzı tamamen eskidi. Sürüm yazılımına inanmıyor (kodunuzun doğru olduğundan emin olmanız durumunda, tüm bu saçmalıklara ihtiyacınız yok). Dağıtıma inanmıyor (çalışan bir çalıştırılabilir dosya sunabilirim. Bunun nasıl dağıtıldığı, sistem yöneticilerinin çözmesi gereken bir şeydir). Soyutlamaya inanmıyor. ('bir alt yordam oluşturmak istiyorsanız, devam edin, ancak o alt yordamdan herhangi bir alt yordam çağırmayın. Bu şekilde karışıklaşır ve kodun izlenmesi zordur. Bu yoldan her biri yoldaki her adımı takip edebilir. 'ya da' evet, bu kütüphaneyi sizin için yapmak için kullandığınızdan emin olun, ancak bu şekilde neler olduğunu gerçekten anlamıyorsunuzdur ') ve kesinlikle OOP'a inanmıyor. (VB.net'te çalışıyoruz)

Yaptığı işte çok iyi, uygulamaları benden çok daha hızlı sunabiliyor. Ama bu sadece bir takımda çalışmıyor. Diğer takım üyemiz sessiz ve aynı fikirde olmasına rağmen konuşmayı sevmiyor. Müdürümüz geçerli puanlar aldığımı düşünüyor ama programcı değil.

Yazdığı programları sürdürmek konusunda gerçekten çok zorlanıyorum ve bu iyi bir takım atmosferi yaratmıyor. Sizce yapılacak en iyi şey nedir?

Bu, "O iyi bir adam ama ..." dan birinin gerçeğinin geldiğini bildiğin birine benziyor. Ve gerçek, kulağa gerçekten iyi bir mühendis sayılmaz gibi geliyor. İyi yazılım sadece çalışma ve geliştirme hızı ile ilgili değildir. Bahsettiğiniz diğer şeylerle de ilgili - sürdürülebilirlik, uyumluluk, soyutlama (gelecekteki verimlilik için), vb.

Demek ki, elinizde bir problem geliştirici var gibi görünüyor. Senin için daha kötüsü, kanıtlanmış ve muhtemelen kendi yoluna koyulmuş olmasıdır. Ne yapabilirsin?

• Etrafında çalış.
• Projelerinizi olduğu kadar sıkı bir şekilde hazırlamaya çalışın.
• Ve yapamazsan daha iyi bir sonuç çıkar.
• Zaman içinde, reddettiği kanıtlanmış kavramları sizin için karşılığını almaya başlayacak.

Öte yandan, onunla çalışmak zorunda kalırsanız, bırakın.

Meslektaşını değiştirmeye çalışma. Onu çalışan bir yazılım sunabilecek biri olarak tanımlıyorsun. Ya takıma entegre etmek için muhtemelen çok geç.

Yani iki seçeneğiniz var:

• Kendini uyarla . Belki zamanla onu bir kaynak kontrol sisteminin faydası konusunda ikna edebileceksiniz? Etki çemberinizi arttırmanız gerekecek . Değişime karşı ne kadar dirençli olursa, o kadar çok zamana ihtiyacınız olacak.

• Kendini Kaldır dan team. Bunu haklı çıkarmak için birçok noktanız var. Belki de yalnız başına kendi uygulamalarını sürdürmeli ve kendini yeni şeylere adamalısın.

• Kendini Kaldır dan company. Bazen bu tek çözümdür.

Yerinde olsam şu anda kendi kaynak kontrol sistemimi kurardım. Kodladığınız her şey için kullanmaya başlayın ve diğer ekip üyelerinin hesaplarının olması ve erişebilmesi için yönetin. Diğer iş arkadaşlarınız muhtemelen onu kullanma konusunda istekli olacaklardır.

Bu tür uygulamalara inanmayan meslektaşınızın ikna etmesi kolay olmayabilir. Ancak, onunla çalışmak zorunda kaldığınız herhangi bir kod, onunla çalışabilmeniz için sürüm kontrolüne girmelidir. Değişikliklerinize erişmesi gerektiğinde, kodunuzu depodan nasıl çıkaracağınıza ilişkin talimatları adım adım uygulayarak ona basit bir adım gönderin.

Onu daha modern süreçlere dahil etmek için savaşmalı ya da onun üstüne çıkmanıza gerek yok. Bazen sadece kendi yoluna gitmek ve eylemde lider olmak, birini sözlerle ikna etmeye çalışmaktan daha etkilidir. Bebek adımları. Sürüm kontrolüne daha duyarlı olmaya başlarsa, alt yordamları yeniden gözden geçirmeye ve değişikliklere karşı korunmak için birim testleri eklemeye başlayın. Testleri otomatikleştirin ve check-in yaptıktan hemen sonra sonuçlara nasıl erişebileceğini gösterin.

Çoğu zaman insanlar sadece dirençlidir çünkü değişimi sevmezler. Ancak değişiklikler onlara kademeli olarak ve takip etmelerini kolaylaştıracak şekilde sunulursa, faydaları çok hızlı bir şekilde görürler.

Her şeyden önce, onu mümkün olduğunca basit hale getirin (Basit Aptalca Tutun). Bu uygulamaları kendi şartlarıyla izlemeye başlamasına izin verin. Ama seni aşağı sürüklemesine izin verme.

Dürüst olacağım, onun güzel bir resmini çizmiyorsun. Arkaik yöntemler, bakımı zor yazılımlar, yeni çalışma yöntemlerine inat, soyutlama vb.

Söylediklerinize göre, hızlı uygulama geliştirmeye yönelik yeniden kullanılabilir kütüphaneleri ve tasarım desenlerini kullanmadan sizden daha hızlı bir şekilde hatasız yazılım üretiyorsa, o zaman kendiniz hakkında kendisinden daha fazlası ...

..hakkında .. onunla çalışmamaya ve işiyle ilişkilendirmeme yolunu bul. İşine karşı tipik bencil bir tavrı var gibi görünüyor. Böyle biriyle çalışamazsınız, yalnızca çalıştıklarını ve onlardan sonra toparlanmalarını gözlemleyebilirsiniz (şu anda olduğu gibi).

Bunu daha önce görmüştüm ,

Neredeyse bahis yapmaya neredeyse istekliyim: Bu tip bir adam sadece "hızlı" görünüyor, çünkü kafasında denenmiş ve test edilmiş bir dizi "desen" var. Line of Business uygulamalarının % 99'u CRUD , temel şeyler.

Muhtemelen kendi mevcut kodundan bir ton Kopyala ve Yapıştır kullanıyor (bunda yanlış bir şey yok).

Fakat..

Uzaktan karmaşık bir şeyle karşılaştığı an düşer, neden? çünkü artık temel "kalıpların" hiçbirine uymuyor.

Küçük bir meydan okuma ...

Yan tarafta OOP'den gerçekten yararlanan ve yeniden kod kullanımından oluşan karmaşık bir proje oluşturacağım.

Ardından ona bu projeyi gösterin ve özellik için özelliğini uygulamasını isteyin.

Daha sonra, kodunu kendi yöntemini uygulamış olsaydı neredeyse 10 kat daha büyük ve 10 kat daha çirkin olacağına bahse girerdim .

Buna iş tarafından bak.

Hata kodunu oluşturmak için daha fazla zaman ayırın. Daha az gelir üretiyorsun, bu yüzden emiyorsun.

Zamanla bunu tersine çevirirseniz, bunu tersine çevirebilirsiniz.

Ama belki, sadece belki, bu antika programcı size hızlı bir şekilde kod üretme hakkında birkaç şey öğretebilir, bu yüzden hatasızdır? Belki de teknikleri senin sandığın kadar eski değildir?

Birisinin çok iyi uygulamalar olmadan böyle harika bir kod üretebileceğinden şüphelendiğimi biliyorum. Bu uygulamaları öğrenebilir ve bunları "en iyi uygulamalar" ve anladığınız modaya uygun şeylere uygulayabilirsiniz.

Yöneticiniz bir programcı değilse, anlayacağı bir şekilde deneyin.

• Sourecontrol'ü kullanmalıyız çünkü yapmazsak kurtarmada büyük sorun yaşayabiliriz

• Bu beni alır x o bazı oldukça basit işlemleri takip reddetmesi nedeniyle uzun süreyi.

Öte yandan, mükemmele yakalanmadığınızdan emin olun, yani bu uygulamamız gereken en iyi uygulamadır. İş arkadaşınızın ekleyebileceği çok şey var, onu yavaşça doğru yönde dürtmek zorunda kalabilirsiniz.

İş arkadaşınız bir takımda hiç gelişmemiş gibi görünüyor. Bu tür bir solo guru türü bir ortak iyi bir grup dinamiğine izin vermez. Bu yüzden üstünüze söyleyin ve yanlısı ve aleyhte olanları bunu yaparken eşinizle görüşmeye çalışın. Güzel bir şekilde yapabilirseniz, ama o reddederse komuta cahininde yukarı çıkın.

Burada yaptığınız gibi sade ve basit yöneticinizle konuşun. Burada büyüme için potansiyel var - iş arkadaşınız söylediğiniz kadar iyiyse, kaynak kontrolü ve .Net'i uygun OO kavramlarıyla kullanmaya başlaması için onu ikna etmemelidir.

Nerede olduğunuzun nasıl göründüğünün daha geniş bir resmini çekmek için başkalarıyla konuşurdum. Belki de orada bazı ayrılıklar vardır, bu yüzden onun kodu başkaları ile çok fazla karıştırmak zorunda kalmaz, çünkü onu kendi alanlarına ayırma potansiyeli vardır, bunun için bir şekilde ele alınabilir. Bir geliştirici yerine direktör veya CIO.

Spagetti kodunun ülkeye girebileceği birçok yapı taşı olma eğiliminde olan bazı büyük kurumsal sistemler olduğundan, ne tür daha büyük sistemler kurduğunu görmek için onunla konuşmak isteyebilirsiniz. "Oh, bu yüzden OOP iyi olabilir! " ancak bu bazen birinin araç kutusunda ne kadar yararlı bir şey olabileceğini görmek için oldukça yararlı olduğu kanıtlar.

Apati, kod tasarlama eğiliminde olduğumda, temel konuya yakın olduğunu düşündüğüm bazı şeyleri reddetmesinin nedeninin olup olmadığını görmek için başka bir şüpheli olabilir;

Sizi aksi ispat etmek için ona iyi bir şekilde meydan okuyun, aletlerin ve uygulamaların harika tarafını gösterin. Patronlaşma.

Örneğin, belki de bir versiyon olarak versiyonlamaya inanmaz, ancak ona bir dallanma / birleşme ve bir dizi dosyaya ihtiyaç duymadan çeşitli deneysel özellikler üzerinde nasıl çalışabileceğini gösterin.

OOP ile ilgili olarak, ona komut düzeni, görev düzeni ve ona nasıl değerli zaman kazandırabileceği ve tüm ekibiniz gibi bazı serin / karmaşık tasarım kalıplarını gösterin.

En ufak bir ilgisi yoksa ... ... o kaybedilmiş bir dava olabilir, ama sonra yine, takımının ve onu geride bırakman için gerekli araçların var. Yöneticinize görebildiği, yöneticinize şeffaflık getireceğini ve iş arkadaşınızı resimden uzak tutacağını (e-posta kullanıyorsanız, bitbucket.org'un ücretsiz özel depoları vardır) gösteren / e-postaları gösteren taahhüt mesajları gösteren bir depo yazılımı kullanmayı deneyin.

Sonunda, kelimelerle ikna etmeye çalışmayın ama reddedilemez davranışlarla, inatçı insanlarla başa çıkmanın en iyi yolu IMHO (ters psikoloji bazen de çalışır, lol).

Peki, bahsettiğin teknikler açık bir şekilde iyi, ama aynı zamanda onları ideoloji olarak zorlayıp zorlamadığını kendine sorman gerekiyor. Genç programcıların kolejde neleri topladıkları konusunda biraz kadınsı olma eğiliminde olduklarını biliyorum. bu tekniklerin sonuçlardan dolayı iyi olduğunu unutmayın: sürüm kontrolü eşzamanlı geliştirme, tasarımın daha net izlenmesi, geliştirme, test etme, hata düzeltme aşamaları sağlar. Eğer projeleriniz gerçekten kısa vadeli ise, bunların çoğu uygun değil ve sizi daha az çevik hale getirecek. bu sadece en iyi uygulamanın mümkün olan en iyi uygulamaları kullanmak anlamına gelmediği durum değildir. soyutlama, örneğin, kesinlikle, bir yardımdan, en azından bazı zamanlardan daha fazla sorumluluk olabilir. sürüm kontrolü, geliştirme zaman çizelgelerini, karmaşık kodları, çoklu programcıları genişlettiğinizde en mantıklı olanıdır - parça parça ile çekiş yapmak zor olan bir tür sinerji vardır.

Bence başlanacak yer potansiyel yeniden kullanıma dikkat çekmek - projeler geçtikçe, ortaklıklar veya daha genel çerçeveler hakkında düşünmek. Projelerin önüne çıkmaya çalışmak güçlü bir hamle olacak ve daha fazla teknikte çalışmanıza izin verebilir ...

Süpervizörünüzden HERKES için "sürüm" yazılımının neden iyi olduğu konusunda bir sunum yapmasını istemeniz gerekir . İş arkadaşını dışarı atma.

Kaynak kontrol yazılımı konusunda şüphem var, çünkü insanları her zaman kötüye kullandıklarını görüyorum - işten kaçınmanın bir yolu.

İş arkadaşlarım sürekli birbirlerinin ayak parmaklarına basıp sürekli birleşiyorlar. Ancak faydaları hakkında iyi bir dostane ders güzel bir şey olurdu ve tartışmaları teşvik ederdi.