# İki Kafa Çoğu Zaman Bir Kafadan Daha İyidir Programlama derin düşünce gerektirir ve derin düşünce yalnızlık gerektirir. Programcı klişesi de öyle. Programlamaya yönelik bu "yalnız kurt" yaklaşımı, yerini daha işbirlikçi bir yaklaşıma bırakıyor ve bunun da programcılar için kaliteyi, üretkenliği ve iş tatminini iyileştirdiğini iddia ediyorum. Bu yaklaşım, geliştiricilerin birbirleriyle ve ayrıca geliştirici olmayanlarla (iş ve sistem analistleri, kalite güvence uzmanları ve kullanıcılar) daha yakın çalışmasına sahiptir. Bu geliştiriciler için ne anlama geliyor? Uzman teknoloji uzmanı olmak artık yeterli değil. Başkalarıyla çalışmak konusunda etkili olmalısınız. İşbirliği, soru sorup cevaplamak veya toplantılarda oturmakla ilgili değildir. İşe ortaklaşa saldırmak için başka biriyle kolları sıvamakla ilgili. Çift programlamanın(pair programming) büyük bir hayranıyım. Buna "aşırı işbirliği" diyebilirsiniz. Bir geliştirici olarak, eşleştirme yaptığımda becerilerim artıyor. Alanda veya teknolojide, partnerimden daha zayıfsam, onun deneyimlerinden açıkça öğrenirim. Bir yönden daha güçlü olduğumda, kendimi açıklamak zorunda kalarak bildiklerim ve bilmediklerim hakkında daha fazla şey öğreniyorum. Her zaman ikimiz de masaya bir şeyler getiriyoruz ve birbirimizden öğreniyoruz. Eşleştirirken, her birimiz ortak programlama deneyimlerimizi teknik olduğu kadar etki alanı da eldeki soruna getiriyoruz ve etkin ve verimli bir şekilde yazılım yazmak için benzersiz bir anlayış ve deneyim getirebiliriz. Alan veya teknik bilgide aşırı dengesizlik durumlarında bile, daha deneyimli katılımcı her zaman diğerinden bir şeyler öğrenir, belki yeni bir klavye kısayolu veya yeni bir araç veya kitaplığa maruz kalma. Çiftin daha az deneyimli üyesi için bu, hız kazanmanın harika bir yoludur. Eşli programlama, çevik yazılım geliştirme savunucularına özel olmasa da popülerdir. Eşleştirmeye itiraz edenler, "Neden bir programcının işini yapması için iki programcıya para ödeyeyim?" diye soruyor. Benim yanıtım, aslında, yapmamalısın. Eşleştirmenin kaliteyi, etki alanı ve teknolojiyi, teknikleri (IDE hileleri gibi) artırdığını ve piyango riskinin etkisini azalttığını (uzman geliştiricilerinizden biri piyangoyu kazanır ve ertesi gün bırakır) savunuyorum. Yeni bir klavye kısayolu öğrenmenin uzun vadeli değeri nedir? Eşleştirmeden kaynaklanan üründeki genel kalite iyileştirmesini nasıl ölçeriz? Ortağınızın zor bir sorunu çözmek için çıkmaz bir yaklaşım izlemenize izin vermemesinin etkisini nasıl ölçeriz? Bir çalışma, etkinlik ve hızda %40'lık bir artış olduğunu belirtiyor (J T Nosek, "The Case for Collaborative Programming", *Communications of the ACM*, Mart 1998). "Piyango riskinizi" azaltmanın değeri nedir? Bu kazanımların çoğunu ölçmek zordur. Kim kiminle eşleşmeli? Ekipte yeniyseniz, bilgili bir ekip üyesi bulmak önemlidir. Kişilerarası ve koçluk becerileri iyi olan birini bulmak da aynı derecede önemlidir. Çok fazla alan deneyiminiz yoksa, alan adında uzman bir ekip üyesiyle eşleştirin. İkna değilseniz, deneyin: iş arkadaşlarınızla işbirliği yapın. İlginç bir problem üzerinde eşleştirin. Nasıl hissettirdiğini görün. Birkaç kez deneyin. [Adrian Wible](http://programmer.97things.oreilly.com/wiki/index.php/Adrian_Wible) Tarafından --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://97-things-every-x-should-know.gitbook.io/97-things-every-programmer-should-know/tr/thing_85.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.