راب آیزنبرگ، هکرنون -- عرق سرتا پایم را گرفته بود؛ مغزم با دستپاچگی داشت ناله می‌کرد که «آخه چرا یه دست لباس اضافه با خودت نیاوردی؟» چیزی نمانده بود اضطراب کار دستم بدهد و بدنم را به کلی از کار بیندازد. مانیتورها به من زل زده بودند و دو کیبورد نشسته در بغل هم، با تمسخر به من پوزخند می‌زدند. به نظر مغز پر از آدرنالین من، همین الان بود که بیایند و به خاطر بی‌کفایتی ذهنی و عجز تمام و کمالم در برنامه‌نویسی با تیپا به بیرون پرتم کنند. همکارم کنارم نشست؛ اصلا برای دیدن قیافه‌اش آمادگی نداشتم. قیافه اش هیجان‌زده اما آرام بود. ولی من چی؟ من داشتم بالا می‌آوردم.

این روز، ۱۴ آوریل ۲۰۰۸ بود: روزی که من برای اولین بار برنامه نویسی دونفره (Pair Programming) را تجربه کردم. از آن روز تاکنون، سال‌ها گذشته و در این مدت من بارها و بارها جلسات برنامه‌نویسی دونفره را از سر گذرانده‌ام. شاید باورتان نشود، ولی حالا عاشقش هستم. درست است که بعضی‌وقت‌ها زیر فشار تنش و هیجانش له می‌شوی، اما خیلی وقت‌ها هم شب وقت رفتن به خانه، یک خروار حس رضایت زیر بغلت داری.

اگر عادت دارید تنهایی کد بزنید، ممکن است فکر کنید که زل زدن دو نفر در کنار هم به یک کد یکسان عجب کار مسخره‌ای است. این بدبینی‌ای که دارید را تحسین می‌کنم (بلاخره کمی شکاکی در زندگی مفید است‌!) اما من معتقدم که وقتی پای یادگیری یک مهارت جدید (مثلا برنامه‌نویسی دونفره) در میان باشد، بهتر است قبل از هر قضاوتی اول به خودمان اجازه بدهیم تا کمی با این مهارت جدید بازی‌ کرده و این تجربه نو را حداقل یک بار از سر بگذرانیم. وقتی آن را بدون سوگیری تجربه کردیم، می‌توانیم به ذهن تحلیل‌گر و منتقدمان اجازه بدهیم تا برگردد و در مورد ارزشمند بودن یا نبودن آن تجربه برایمان سخنرانی کند.

اگر با من موافقید و آماده تجربه بی‌قضاوت هستید، می‌خواهم برایتان از برنامه‌نویسی دو نفره بگویم. می‌خواهم برایتان بازگو کنم که چه آموخته‌هایی با سختی کشیدن در این راه به دست آورده‌ام. امیدوارم که چه تازه‌کار باشید و چه کهنه‌کار، بتوانید از آنها بهره ببرید.

اصول اولیه برنامه نویسی دو نفره

نقش‌ها را از یاد نبرید. هر دو نفری که می‌خواهند با هم برنامه‌نویسی کنند، خودشان باید کشف کنند که چطور با هم کار کنند نتیجه‌بخش‌تر است. اما معمولا در برنامه‌نویسی‌های دونفره، یک نفر راننده است و دیگری نقشه‌خوان؛ کیبورد دست راننده است: اوست که برای پیاده کردن Feature مورد نظر کد می‌زند. در عوض نقشه‌خوان مسئولیت تفکر استراتژیک در مورد جهت کلی مسیر را به عهده دارد. خوب است که هر سی چهل دقیقه، این دو نفر نقش‌هایشان را با هم عوض کنند.

نقشه‌خوان خوبی باشید. کار نقشه‌خوان، پیدا کردن مشکلاتی است که به ذهن راننده خطور نکرده‌اند. آیا تستی را جا انداخته‌ایم؟ کدِ آماده‌ای هست که همین کارکرد مورد نظرمان را انجام دهد؟ رویکرد ساده‌تری هم برای پیش‌برد کار وجود دارد؟ به عنوان نقشه‌خوان، شما نگهبان کیفیت کار هستید و این کار کمی نیست. شجاعت بخصوصی می‌خواهد که درست همان لحظه‌ که همکارتان به خاطر خستگی می‌خواهد تستی را بی‌خیال شود یا کاری را انجام ندهد، با ملایمت بر حفظ کیفیت پافشاری کنید.

حواستان را کاملاً به کار بدهید. دو نفره کار کردن آنقدرها هم آسان نیست؛ هم انرژی زیاد می‌خواهد و هم نظم فراوان. هر دو طرف باید خود را به تولید کد باکیفیت متعهد کنند. این یعنی از زیر کار در رفتن، چک کردن توییتر و ایمیل، و وب‌گردی در گوشی تعطیل. حواستان را کاملاً به کار پیش رو بدهید.

وقفه‌های مضر را به حداقل برسانید. هر وقفه و حواس‌پرتی، جریان کار شما را کند می‌کند و زمان خواهد برد تا بتوانید به آن تمرکز اولیه برگردید. هر چیزی که قرار است در کارتان وقفه بیندازد (مثل ایمیل، نوتیفیکیشن‌ها، نورهای چشمک‌زن، صداها) را خاموش کنید، کنار بگذارید، اصلاً بسوزانید! اگر پیام مهمی قرار است بگیرید و نگرانید که مبادا از آن غافل شوید، برای خودتان یادآور بگذارید: آن هم فقط یکی، و ترجیحاً نه با گوشی و لپتاب، بلکه با یک ساعت مچی زنگ‌دار. البته باید این را هم بگویم که هر حواس‌پرتی‌ای هم بد نیست. (قسمت سرعت شخصی در مقابل سرعت جمعی را در ادامه مطلب ببینید!)

در مورد استایل کدزنی با هم به تفاهم برسید. وقتی استایل کدها مشخص باشد و همه مدام آن را رعایت کنند، هرکدام از اعضای تیم می‌تواند به سادگی از همان وسط پروژه وارد کار شود. وقت و انرژی‌تان را سر بحث درباره جای آکولادها هدر ندهید؛ به جای آن، اول کار با هم سر یکی از راهنماهای استایل کدزنی که واضح و مشخص هم باشد، توافق کنید (مثل راهنمای استایل Ruby). حالا می‌توانید بروید و وقتتان را سر حل مسئله‌هایی بگذارید که واقعاً مهم هستند! حتی بهتر از آن، چک‌کننده‌های اتوماتیک استایل را روی پروژه‌تان فعال کنید؛ به عنوان مثال: Hound CI از Rubocop ،thoughtbot و همکاران.

از هول حلیم توی دیگ نیفتید. توی فیلم‌ها، توسعه‌دهنده‌ها قهرمانانی هستند که با آخرین سرعت دیوانه‌وار تایپ می‌کنند و اگر دود از کیبوردشان بلند نشود، در کمتر از چند ثانیه می‌توانند راه حل هر مشکلی را پیدا کنند! اما ما آدم‌های واقعی اگر اینطوری کار کنیم، تنها چیزی که تولید خواهیم کرد یک توده‌ی بی‌خود مناسب برای انداخته شدن به سطل آشغال خواهد بود. برنامه‌نویسی سریع تایپ کردن نیست، عمیق فکر کردن به مسئله‌های پیچیده است. آسه‌آسه جلو رفتن اما کار را درست انجام دادن بهتر از عجله کردن و پر از غلط پیش رفتن است. لابد می‌گویید پس ددلاین‌ها چی؟ هر چیزی با تمرین بهتر می‌شود. کافیست خودتان را عادت بدهید به درست کار کردن و اطمینان داشته باشید که سرعت هم به مرور زمان سراغتان خواهد آمد.

بلند فکر کنید. چه ایده‌ای در سر دارید؟ چرا فکر می‌کنید این روش بهتر از آن یکی روش جواب می‌دهد؟ وقتی افکارتان را به زبان بیاورید، همکارتان از آنها آگاه می‌شود و فرصتی برای همکاری و کمک به شما پیدا می‌کند. علاوه بر این، بلند فکر کردن کمک می‌کند تا خودتان هم مسئله‌های خودتان را حل کنید! (در این باره Rubber Duck Debugging را هم نگاهی بیندازید! کوئرامگ هم مطلبی در همین زمینه دارد.)

مرتب استراحت بدهید. کار دو نفره خیلی هیجان‌انگیز است، اما حسابی انرژی می‌گیرد. اگر دیدید انرژی‌تان تخلیه شده، نترسید؛ پیشنهاد استراحت بدهید. می‌شود در این فرصت در مورد آخرین جنجال مطرح در شبکه‌های اجتماعی حرف زد، قهوه دبشی خورد، با اعضای تیم گپ زد، یا اینکه صرفاً در هوای آزاد چند نفس عمیق کشید. مهم نیست در تایم استراحت چه کار کنید؛ فقط کافی است از پشت میز بلند شوید و تغییر مکان بدهید. نگران نباشید، ذهنتان قرار است در پشت پرده به تلاش برای حل مسئله‌ها ادامه بدهد؛ در نتیجه وقتی سر کار برمی‌گردید، با ایده‌های جدید و تازه‌ای وارد میدان خواهید شد.

جفت‌ها را مرتب عوض کنید. با کار دو نفره، می‌توان دانش هر عضو تیم را بین کل اعضای تیم پخش کرد. از اطلاعات بخصوص در مورد سیستم گرفته تا مسائل تخصصی و بسیار فنی، آدم از هرکسی می‌تواند یک چیزی یاد بگیرد. (و البته از چالش‌های ضریب اتوبوس جلوگیری کند!) حتی فقط با تماشای نحوه مواجهه یک نفر دیگر با یک مشکل، فرمان‌های مورد استفاده او، یا حتی صرفاً رفتار و نگرش‌اش کلی ایده می‌شود گرفت. باورتان نمی‌شود که برنامه‌نویسی با آدم‌های مختلف، چند بار باعث شده با خودم فکر کنم که «وا، چطوری من تا الان از این خبر نداشتم؟!»

تست‌های خودکار بنویسید. هیچ چیزی مثل یک مجموعه تست درست حسابی برای سنجش سیستم آدم را از کدهایش مطمئن نمی‌کند. وقتی دوتایی کار می‌کنید، هر دو باید در مورد نحوه تست کردن به توافق برسید. نظرات مختلفی در مورد نحوه انجام این کار هست؛ مثلاً تست کردن اول کار، تست کردن آخر کار، یا هر مدل دیگری که برای تیم شما جواب بدهد.

جفت کردن پینگ‌پونگی را امتحان کنید. جفت کردن پینگ‌پونگی خیلی مفرح است و ریتم قشنگی هم به کار می‌دهد! چه طور انجامش بدهیم؟ یک نفر تست را می‌سازد، آن وقت آن یکی باید کاری کند که کدها از تست سربلند بیرون بیایند. حالا جاها عوض، و این چرخه ادامه دارد!

خواب کافی داشته باشید. برنامه‌نویسی دونفره، مثل این است که آدم در عرض یک ساعت درس سه جلسه را یاد بگیرد. خواب، مکانیسم بدن ما برای هضم سیل اطلاعاتی است که داخل مغزمان می‌چپانیم. کافیست کمتر از اندازه بخوابیم تا تمرکز و توانایی تصمیم‌گیریمان پایین بیاید. این راه خوبی برای خوب برنامه‌نویسی کردن نیست. یکی از همکاران من که با هم برنامه نویسی دو نفره می‌کردیم، از فشار کار مرتب خواب می‌دید که یک Object است که هی دارد در سیستم اینور و آنور می‌شود.

خوش بگذرانید. کار دو نفره جلسه کاری نیست! لازم نیست جدی و با سگرمه‌های درهم آن را جلو ببریم. تا می‌توانید فرآیند برنامه‌نویسی‌تان را شبیه بازی کنید، جوک بگویید، کمی از آن همه جدیت کم کنید! این که چقدر می‌توانید در این روند خوش بگذارنید، به خلاقیت و ظرفیت شخص شما برای تفریح بستگی دارد!

پژوهش‌ها نشان داده‌اند که خنده و شوخ‌طبعی به یادگیری کمک می‌کند؛ بخصوص اگر در مورد کاری باشد که دارید انجام می‌دهید. فقط حواستان باشد که از آنها به عنوان راهی برای فرار از کار استفاده نکنید!

از تنوع استقبال کنید. هرکدام از ما، تاریخچه شخصی و منحصر بفرد خودش را دارد. هرچه اعضای یک تیم متنوع‌تر باشند، ایده‌های جالب بیشتری در مورد راهکار حل مشکلات خواهند داشت. از خاص بودن افراد لذت ببرید. تفاوت‌های میان آنها را جشن بگیرید. با این کار، بر سوگیری‌های درونی‌مان پیروز خواهیم شد.

اگر با برنامه‌نویسی دو نفره یا کد جلوی رویتان تازه آشنا شده‌اید...

کار هم‌تیمی‌تان را دنبال کنید و دیده‌هایتان را به ذهن بسپارید. تماشا کردن کد زدن یک نفر دیگر تجربه‌ استثنایی‌ای است؛ آدم کلی چیز یاد می‌گیرد. همه تلاشتان را بکنید تا عقب نمانید. شاید اول کار خیلی فشار بیاید و احساس کنید که همه چیز زیادی سریع پیش می‌رود، اما بعد ازچند روز کم‌کم از همه چیز سردرخواهید آورد. به مرور، اول الگوهای کوچک را شکار می‌کنید؛ مثلا «آهان، پس اینجوری تست هارو اجرا می‌کنم» یا «اینطوری اپلیکیشن Launch میشه». بعد از آن کم‌کم جا در ذهنتان برای تمرکز روی مفاهیم پیچیده‌تر باز می‌شود.

اگر سردرگم شدید، به همکارتان بگویید. آن اوایل کار، خیلی وقت‌ها ممکن است آدم حسابی گیج و سردرگم شود. موقعیت ترسناکی است، اما یادتان باشد که چنین واکنشی کاملاً طبیعی است. اگر همکار خوبی داشته باشید، احتمالاً حواس‌ش هست که در چنین مواقعی ترمز بزند و کمی سرعت را کم کند. یکی از اجزای لازم برای برنامه‌نویسی خوب دو نفره، داشتن ارتباطی صادقانه است. اگر صادقانه همکارتان را از وضعیتتان مطلع کنید، در کنار هم مسیر پیش رو را درست خواهید کرد و هر مشکلی که پیش آمد، می‌توانید با آن روبرو شوید.

سوال بپرسید. چرا این کارو کردی؟ چی تو فکرته؟ چطوری فهمیدی که از اینجا باید شروع کنی؟ ببینید چه برایتان مبهم و نامشخص است، و بعد در موردشان سوال بپرسید. اما به این هم دقت کنید که سوال‌پیچ کردن همکارتان ممکن است فرآیند فکر کردن او را مختل کرده و سرعتش را پایین بیاورد. اگر سوال‌هایتان خیلی زیاد است، می‌توانید یک صفحه کاغذ کنارتان بگذارید و آنها را بنویسید تا از یادتان نروند.

بیشتر از بیشتر بخوابید. جدی می‌گویم!

حواستان به ددلاین‌ها باشد. در یک دنیای ایده‌آل، همکارتان سرعتش را در حد شما پایین می‌آورد و به شما اجازه می‌دهد تا به مرور سرعت خودتان را زیاد کنید. اما متاسفانه دنیای واقعی آنقدر‌ها هم ایده‌آل نیست. اضافه کردن یک عضو جدید به تیم به بهره‌وری تیم صدمه می‌زند، حتی اگر یک نیروی کارکشته و Senior باشد. باید سعی کرد تا بین کاهش بهره‌وری و لزوم تحویل کار، تعادل برقرار شود. بپذیرید که همکارتان هم مثل همه آدم‌ها با ایده‌آل فاصله دارد، و ممکن است با نزدیک شدن ددلاین‌ها مضطرب یا بی‌صبر شود.

نکاتی برای کارکشته‌های برنامه نویسی دو نفره

سطح برنامه‌نویسی دوتایی‌تان را یک مرحله بالاتر ببرید. با کمی فکر و اندکی ابتکار، همیشه می‌شود راهی برای بالاتر بردن سطح برنامه‌نویسی دونفره پیدا کرد. من ماه‌ها و ماه‌ها روی یک پروژه دونفره با یک نفر ثابت کار می‌کردم. به شکل احمقانه‌ای، هیچ‌کدام از ما هیچوقت به ذهنمان خطور نکرد که با جفت دیگری که درست کنارمان نشسته بودند، یار عوض کنیم. مسخره است‌! هردو تیم در این سناریو باخته‌اند.

هیجاناتتان را مدیریت کنید. در هر روز از برنامه‌نویسی دو نفره، شما با ترس‌ها و ضعف‌های خودتان روبرو خواهید شد: تکبر، ترس از احمق به نظر آمدن، سر رفتن حوصله. این ضعف‌ها را انکار نکنید. در عوض، آنها را به رسمیت بشناسید و ببینید چه استراتژی‌ای برای کم کردنشان می‌شود پیدا کرد. این چالشی است که در تمام زندگی‌تان ادامه خواهد داشت. ویژگی‌هایی که به همکار خوب بودن در برنامه نویسی دونفره کمک می‌کنند عبارتند از صبوری، احترام، تحمل، فروتنی، شجاعت، و صداقت.

به مدل فکر کردن آدم‌ها دقت کنید. وقتی کل عمرت را با یک مغز زندگی کرده‌ باشی، به راحتی از یاد می‌بری که مغز بقیه آدم‌ها جور دیگری کار می‌کند. نه تنها بقیه با شما فرق دارند، که نحوه تفکر و پردازش ذهن هرکدام از آنها هم منحصر به فرد است. به سبک تفکر همکارتان دقت کنید؛ آیا وقت‌هایی که عمیقاً در فکر است و چیزی نمانده به راه حل برسد، شما هی حرف می‌زنید و مانعش می‌شوید؟ آیا همکارتان نیاز دارد که با سرعت کمتر (یا بیشتری) جلو بروید؟ آیا اگر با مثال حرفتان را توضیح بدهید، بهتر متوجه می‌شود؟ هرچقدر همکارهایتان را بهتر درک کنید، کار تیمی موفق‌‌تری با او خواهید داشت. آن وقت، هر دویتان رشد خواهید کرد.

روی خودآگاهی‌تان کار کنید. درست همانطور که بهتر فهمیدن همکارتان باعث پیشرفت می‌شود، دانستن این که خودتان چه جور آدمی هستید و به چه نیاز دارید هم شما را رشد می‌دهد. وقتی نیازهایتان را بهتر بشناسید، بیشتر ممکن است که آنها را برآورده کنید.

از زبان با دقت استفاده کنید. تفاوت بفرما و بتمرگ را که شنیده‌اید؟ در برنامه‌نویسی دونفره هم مثل همه جاها، به نحوه حرف زدن خود دقت کنید و مچ خودتان را وقت گفتن جملات قضاوت‌بار بگیرید. به عنوان مثال وقتی کسی می‌گوید که «پس چرا کار X رو نکردی؟» در واقع دارد زیرپوستی القا می‌کند که «پسر، تو واقعاً احمقی!». به جای این عبارت قضاوت‌بار، می‌توانید از این عبارت‌ها استفاده کنید:

• راستی به کار ایکس هم فکر کردی؟
• یه مشکلی که این کار داره می‌تونه این باشه که...
• دارم فکر می‌کنم که این کار جواب میده یا نه...
• به نظرت اگه کار X رو بکنیم چه اتفاقی می‌افته؟
• · اوکی هستی که کار X رو هم امتحان کنیم؟

سرعت شخصی (Local) در مقابل سرعت جمعی (Global). خیلی‌ وقت‌ها افراد به اشتباه فکر می‌کنند که به نفع تیم است اگر خودشان تا جایی که می‌توانند سریع کار کنند (سرعت شخصی). این درست نیست! هدف ما باید این باشد که اعضای تیم به شکل دسته‌جمعی بتوانند بیشترین ارزش را با بیشترین سرعت ممکن ایجاد کنند (سرعت جمعی). افراد به شکل‌های مختلفی در دام تفکر مبتنی بر سرعت شخصی می‌افتند. مثلاً وقتشان را روی کارهای اشتباهی می‌گذارند، به تعمیر کردن یک Build خراب کمک نمی‌کنند، و برای جواب دادن به سوال مهمی که یکی دیگر از اعضای تیم مطرح کرده، وقت اختصاص نمی‌دهند.

حرف‌های سخت را رک و راست بگویید. برنامه‌نویسی دونفره کمی شبیه ازدواج است: باید با هم کنار آمد، اما صادق هم بود. همکارتان بوی عرق می دهد؟ نفسش بدبو است؟ سر کیبورد غذا می‌خورد؟ خب، همه ما بعضاً ممکن است روز بدی را گذارنده باشیم و خیلی حوصله نداشته باشیم به خودمان برسیم. اما اگر این جور چیزها مرتباً تکرار می‌شوند و روی اعصاب شما هستند، خوب است مطرحشان کنید. این کار جرات می‌خواهد، اما با گفتنشان در درازمدت هم به خودتان لطف کرده‌اید و هم به همکارتان. بعضی وقت‌ها، صرف مطرح کردنش هم باعث می‌شود آدم حس بهتری پیدا کند.

قوانین را دور بزنید. دو نفره کار کردن هنر است، درست مثل برنامه نویسی. قوانین کمی هستند که نشود تغییرشان داد. آزاد اندیش باشید و از امتحان کردن چیزهای جدید استقبال کنید. به نتایج این امتحان کردن‌ها دقت کنید و اگر می‌توانید آنها را اندازه بگیرید. هرچیزی که جواب می‌داد، باز هم تکرارش کنید.

ترجمه بر اساس:

"Pair Programming: A (Semi-) Definitive Guide" by Rob Isenberg @ Hackernoon

کوئرامگ مجله‌ی تخصصی کوئرا برای توسعه‌دهندگان است که هر هفته با مطلب‌هایی در زمینه تکنولوژی، رشد فردی و آینده برنامه‌نویسی به‌روزرسانی می‌شود. برای اطلاع از آخرین مطلب‌های ما، می‌توانید توئیتر یا کانال تلگرام ما را دنبال کنید.