Nasıl iyi bir takım oyuncusu olunur? [kapalı]

12 yaşımdan beri programlama (saplantılı) yapıyorum. Derleme, C ++, Javascript, Haskell, Lisp ve Qi gibi dillerin spektrumunda oldukça bilgiliyim. Ama tüm projelerim tek başıma oldu.

CS veya bilgisayar mühendisliği değil kimya mühendisliği derecem var, ancak bu sonbaharda ilk kez diğer insanlarla büyük bir programlama projesi üzerinde çalışacağım ve nasıl hazırlanacağına dair hiçbir fikrim yok. Hayatım boyunca Windows'u kullanıyorum, ancak bu proje çok unix-y olacak, bu yüzden yakın zamanda kendimi çevreye alışmak umuduyla bir Mac satın aldım.

Geçen yıl bazı arkadaşlarla bir hackathon'a katılma şanslıydım - her iki CS binbaşı - ve heyecan verici bir şekilde kazandık. Ancak onlarla çalışırken iş akışlarının benimkinden çok farklı olduğunu fark ettim. Git'i sürüm kontrolü için kullandılar. O zamanlar hiç kullanmamıştım ama o zamandan beri bu konuda yapabileceğim her şeyi öğrendim. Ayrıca çok sayıda çerçeve ve kütüphane kullandılar. Rails hackathon için neredeyse bir gecede ne olduğunu öğrenmek zorunda kaldım (öte yandan, sözlüksel kapsamın veya kapanışların ne olduğunu bilmiyorlardı). Tüm kodlarımız iyi çalıştı, ama benimkini anlamadılar ve ben de onlarınkini anlamadım.

Gerçek programcıların günlük olarak yaptıkları şeylere referanslar duyuyorum - birim testi, kod incelemeleri, ancak bunların ne olduğuna dair en belirsiz duyularım var. Normalde küçük projelerimde çok fazla hatam yok, bu yüzden onlar için asla bir hata izleme sistemine veya teste ihtiyacım olmadı.

Ve son olarak, diğer insanların kodlarını anlamam uzun sürüyor. Değişken adlandırma kuralları (her yeni dile göre değişir) zordur (__mzkwpSomRidicAbbrev) ve gevşek bağlantıyı zor buluyorum. Bu, şeyleri gevşek bir şekilde birleştirmediğim anlamına gelmez - bence kendi işim için oldukça iyiyim, ancak Linux çekirdeği veya Chromium kaynak kodu gibi bir şey indirdiğimde, denemek için saatler harcıyorum tüm bu tek adlandırılmış dizinlerin ve dosyaların nasıl bağlandığını anlamak için. Tekerleği yeniden icat etmek bir programlama günahıdır, ancak çoğu zaman işlevselliği kendim yazmanın, bazı kütüphaneleri incelemek için saatler harcamaktan daha hızlı olduğunu düşünüyorum.

Açıkçası, bunu yaşamak için yapan insanların bu sorunları yoktur ve o noktaya kendim gelmeliyim.

Soru: Herkesle "bütünleşmeye" başlamak için atabileceğim bazı adımlar nelerdir?

Teşekkürler!

Bence bir grup için çalışırken hem endişeli hem de heyecanlı oluyorsunuz.

Hiçbirimiz bir grup ya da takımda çalışmayı kitaplardan öğrenmedik ya da bebek adımları ya da "Takımlarda Çalışmak için Aptallar Kılavuzu" verilmedi.

Sadece gruplar halinde çalışarak gruplar halinde çalışmayı öğreniriz.

Profesyonel programcılar hakkında duyduğunuz her şey, takımda çalışırken yavaş yavaş yerine geçecektir .. Bunların hepsini sürüm kontrolü, birim testi gibi tek tek öğreneceksiniz.

Bana göre, sonuçta

Bir ekibin parçası olun.

Bazı cümlelerinizi seçeceğim ve birkaç genel noktaya değineceğim:

(Öte yandan, sözcüksel kapsamın veya kapanışların ne olduğunu bilmiyorlardı). Tüm kodlarımız iyi çalıştı, ama benimkini anlamadılar ve ben de onlarınkini anlamadım.

...

Gerçek programcıların günlük olarak yaptıkları şeylere referanslar duyuyorum - birim testi, kod incelemeleri, ancak bunların ne olduğuna dair en belirsiz duyularım var. Normalde küçük projelerimde çok fazla hatam yok, bu yüzden onlar için asla bir hata izleme sistemine veya teste ihtiyacım olmadı.

...

Tüm bu garip adlandırılmış dizinlerin ve dosyaların nasıl bağlandığını anlamaya çalışarak saatler harcıyorum ... Sık sık, işlevselliği kendim yazmanın, bazı kütüphaneleri inceleyerek saatler harcamaktan daha hızlı olduğunu düşünüyorum.

Bence öğrenmeniz gereken en büyük şey şudur:

Belirli bir geliştirici yeteneği standardı için, bir geliştirici ekibi, ngeliştiricilerin birinin tek başına yapabileceği işin iki katından daha azını yapar n- ancak yine de herhangi bir kişinin yapabileceğinden daha fazlasını yapar .

Nedeni basit: diğer insanlarla çalışırken zamanınızın bir kısmını bu insanlarla bilgi alışverişi için harcamalısınız ; oysa yalnız çalışırken, bilgi alışverişi kafanızda gerçekleşir. Hangi doğal olarak daha hızlı.

Diğer önemli şey:

Bazı iş arkadaşlarınız kesinlikle bazı becerilerde sizden daha az yetenekli olacaktır; hatta bazıları sizden daha az mümkün olacak tüm beceri

Bu iki fikir göz önünde bulundurulduğunda, yukarıda alıntıladığım her şey mantıklı. Test ve kod incelemeleri, bir grup karışık yetenekli insan tarafından kod getirildiğinde kaliteyi sağlamak ve riski azaltmaktır . Hata izleme, yeterince büyük sistemler ürettiğinizde, hataların kaçınılmaz olmasıdır. Ve sözleşmeleri olan sonsuz kütüphaneler, sözleşmeler olmadan, her ihtiyacınız olduğunda yeniden öğrenmek veya yazmak için çok fazla kod bulunmasıdır.

Gerçekten, bir takımda nasıl çalışacağını öğrenmenin tek yolunun aslında bunu yapmak olduğunu düşünüyorum; ama umarım yukarıdakiler zihinsel olarak hazırlanmanıza yardımcı olur. İyi şanslar!

En etkili yol bir ekibin parçası olmaktır.

Bir takıma katılmak zor görünebilir, çünkü henüz birçok öğrencinin ve işi başka hiçbir geliştiriciyle çalışmayan birçok insan gibi bir ekibin parçası olmadığınızı anlıyorum.

Çok aktif ve modern herkese açık kanallarda (sorun izleyici, posta listesi, wiki, vb.) Sık iletişimi destekleyen açık kaynaklı bir projeye katılmanızı öneririm . Açık iletişim önemlidir, çünkü muhtemelen diğer insanların nasıl etkileşime girdiğini gözlemleyerek başlayacaksınız, bu nedenle çekirdek geliştiriciler veya arşivlenmemiş IRC arasında e-postaya dayanan projelerden kaçının.

Her şeyi yapan 1 kişiden oluşan bir proje yerine, oldukça sık katkıda bulunan birkaç kişiyle hoş görünen bir projeyi tercih edin . Ayrıca, daha eğlenceli ve iletişim için daha fazla fırsat sunduğu için, herkesin her şeye dokunmasına izin verilen projeleri tercih edin (her bir geliştiricinin sınırlandırılmış alanına sahip olması yerine).

Utanmaz fiş: burada çok hoş geldiniz !

Herkesin etkisi için söylediklerini tekrar etmeyeceğim "just do it", ancak bahsetmediğim ek bir nokta ekleyeceğim: iyi bir yönetici, ekibe entegre olmanıza gerçekten yardımcı olacaktır.

İşin programlama kısmı için hakkınızda doğru olan her şeye sahip olsanız da, kişisel ve yazılım geliştirme ile ilgili daha fazla şeyden eksik olabilirsiniz. İyi bir yönetici, jel yapmanıza yardımcı olmak için ekip uygulamalarında (hem yumuşak becerilerde hem de sert becerilerde) size rehberlik eder ve ayrıca umarım bu uygulamalara karşı olan bir şey yaptıysanız veya yaptıysanız size söyleyecektir; çünkü bilmediğiniz bir şeyi bozamazsınız.

Size vermek istediğim bir başka ipucu da, iki takımın aynı olmaması ve mevcut bir takımın bile bir veya daha fazla kişi katıldığında değişeceğidir.

Bir ekip, birbirlerini tanıyan ve ortak bir yol bulana kadar birlikte nasıl çalışacaklarını anlamaya çalışan bireylerin etkileşiminden kaynaklanır (bkz. Örneğin Tuckman'ın grup geliştirme aşamaları ).

Bu yüzden tavsiyem şimdi sorularınıza cevap bulmaya çalışmak değil, yeni ekipte çalışmaya başladığınızda ne olacağını görmek olacaktır. Bazı sorunlarınız iş arkadaşlarınız tarafından sorunsuz olarak kabul edilebilir, bazıları ise ilgili olarak değerlendirilir ve bunları birlikte tartışabilir veya hatta konuya ilişkin kendi görüşünüzü tanıtabilirsiniz. Ve son olarak, muhtemelen hiç düşünmediğiniz yönleri de ele alacaksınız.

ElYusubov ile çok fazla sabra ihtiyaç duyduğunuza katılıyorum ve siz ve yeni meslektaşlarınıza, takım olana kadar birlikte çalışmayı öğrenmek için bir takım verin. Eğer bir takım sporu yaparsanız, bunu zaten deneyimlemiş olmalısınız.

Diğer insanların kodlarını anlamak için çok fazla zaman harcamaya dair son bir yorum. Bir ekipte çalışmak, başka birinin kodu üzerinde çalışacağınız ve diğer geliştiricilerin de kodunuz üzerinde çalışacağı anlamına gelir. Bazen kod sıfırdan yeniden yazılamayacak kadar karmaşıktır. Tipik bir çözüm, orijinal geliştiriciden değişikliklerinizi gözden geçirmesini istemektir, böylece kodlarındaki hiçbir şeyi kırmadığınızdan biraz daha fazla güvenebilirsiniz.

Bu benim için solo bir programcıdan bir ekip programcısına geçişte büyük bir sıçrama oldu: sadece kısmen anladığınız kod üzerinde çalışıyorsunuz ve buna alışmanız gerekiyor. Bu, meslektaşlarınızla çok daha fazla iletişim, çok fazla saygı (evet, değişkenleri için garip adlandırma kuralları var, yani ne?) Ve karşılıklı güven (farklı bir kodlama stiline sahip olmalarına rağmen, çalışma kodunu sunduklarını biliyorum) .

İyi bir ekip üyesi olmak , korkusuzca iletişim kurmak, kolejlerinize güvenmek ve bir ekip olarak bir projedeki engelleri aşmak vedeliver project as a team.

O alır zaman alır hastayı ve gerektirir öğrenmek için programcı olarak rahat ve kendinden emin hissetmek için. Her programcının iyi bir Takım oyuncusu olmadığı ve takım oyuncularının başarılarını paylaştığı ve başarısızlıklardan dersler aldığı doğrudur .

İyi ekip üyesinin bazı karakterlerini vurgulamak yararlı olacaktır .

a) İyi takım üyesi, kendi kendine odaklanmak yerine hedefe yönelik bir kişidir .

b) Nitelikler: kişisel tatmin yerine büyük resim hakkında daha fazla düşünmek. Bu kilit nokta. Diğer tüm nitelikler (güvenilirlik, yapıcı iletişim gibi) bundan miras kalır

c) Nasıl geliştirilir: Gün içinde ekibinizle nasıl etkileşim kurduğunuzu belirlemeye çalışın, iyi ve kötü noktalar tanımlayın, bir sonraki toplantılarda onlara dikkat edin. Ayrıca, Takım kararlarına birçok açıdan bakmaya çalışın . Kendinizi diğerinin rollerine yerleştirin, başkalarının çalışmasını nasıl etkileyebileceğinizi düşünün.

İlk olarak, programlamanın gerçekten hoşuna giden bir kişi olduğun için tebrikler. Ancak, programlama yararlı sistemler sunmanın başlangıcı ve sonu değildir. Önünüzde bir meydan okuma olacak ve hobi programlarına geri dönüp gitmediğinizi ve sevdiğiniz şeyi yapabileceğiniz ve bunun için ödeme alabileceğiniz bir kariyere devam etmek size kalmış.

Yazılım geliştirme konusunda eğitim almamanız nedeniyle dezavantajlısınız. Bu eğitimde, CS mezunlarının ve deneyimli yazılım geliştiricilerinin ikinci nitelik olacağı öğretilen (sadece nasıl programlanacağı değil) birçok şey vardır. İşyerinde sık sık ortaya çıktığı için değil (benim için bir kez yapmasına rağmen), ancak NP-sert anlayabilecekleri ve yapamayacağınız bir terimin örneğidir. Muhtemelen hesaplamanın ardındaki biçim teorisinde herhangi bir arka planınız yoktur, ancak bu konuda bilgi edinmek istediğiniz sürece sorun değil. Belki geleceğinizde CS'de bir yüksek lisans? Kodunuzun bazılarının deyimsel olabileceği anlaşılıyor, çünkü sizin için net görünen, ancak başkalarına göre değil görünen bir programlama stiliniz var. Kod incelemelerinde dikkat edin ve eleştiriyi kabul etmeye ve öğrenmeye istekli olun. Bu iş alacak ve sinirli olabilirsiniz,

Senin için ne var paha biçilmez. Gerçekten programlamanın keyfini çıkarıyorsunuz. Bence tasarım, mimari, test, optimizasyon, vb. Gibi gelişmekte olan sistemlerin diğer yönlerinden de keyif alacaksınız. Programlama bulmacanın bir parçasıdır ve bir yazılım geliştiricisi olmak için diğer becerileri öğrenmeniz gerekecektir. Hackathonlar bir yana, birçok işletme iletişim, birbirinden öğrenme, dinleme ve planlama içerir. CS mezunu olan ve yazılım geliştirmeyi araba veya resim evi satmaktan daha çok seven, ancak gerçek bir aşka sahip olmayan birçok insanla çalıştım.