چطور با سوال پرسیدن، برنامه‌نویس بهتری شویم

سوال پرسیدن بخش حیاتی از ساختن تجربه شخصی و برنامه‌نویس بهتری شدن است. چرا و چطور بپرسیم؟

این مطلب ترجمه خلاصه شده و آزادی از نوشته‌ای به همین نام از آقای Steve Gordon است.

سوال پرسیدن یک کار مثبت است

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

سوال پرسیدن به همه ما در هر سطحی از دانش و تجربه کمک می‌کنه اما دلایل مختلفی باعث می‌شه از پرسیدن بترسیم

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

البته که یک راه حل این است که یک تکنولوژی یا الگوی برنامه‌نویسی را پیدا کنید و به همان بچسبید. این راه حل در سازمان‌های بزرگ که سرعت تغییرات کمتری دارند استفاده می‌شود. با این حال باز هم تغییرات هستند مثلاً ممکن است یک API مورد استفاده به دلایل امنیتی منسوخ شود و برنامه‌نویسان مجبور به درک و استفاده از جایگزین‌های امن‌تر شوند.

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

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

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

به عنوان یک برنامه‌نویس لازم نیست همه سوالات شمما در حوزه کدنویسی باشد. ممکن است درباره برنامه‌ریزی اجرای کارها یا موارد دیگری سوال داشته باشید. این‌ها هم موضوعات منطقی برای سوال پرسیدن هستند.

اگر تا اینجا را خواندید می‌خواهم شما را تشویق به پرسیدن کنم. پرسیدن باعث جلورفتن دانش ما می‌شود.

آماده شدن برای سوال پرسیدن

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

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

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

سوال پرسیدن در گیت‌هاب یا Stackoverflow

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

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

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

سوال پرسیدن از همکاران

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

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

چطور سوال بپرسیم؟

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

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

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

بعضی سوالات را می‌توان در چت پرسید ولی بعضی دیگر نیاز به گفتگوی حضوری دارند.

وقتی سوالات پیچیده‌تر از آن هستند که در چت بپرسیم

چت یک ابزار خوب برای شروع است اما همانطور که اشاره شد مناسب همه سوالات نیست. اگر قرار به ملاقات حضوری یا ویدئو کنفرانس بود، ابتدا از چت داخلی برای هماهنگی زمان ملاقات یا ویدئو کنفرانس استفاده کنید.

یک استثنا برای این پیشنهاد هست. اگر فکر می‌کنید prooduction را پایین آوردید، خیلی سریع با یک نفر صحبت کنید!

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

اینجا به پایان مقاله آقای Gordon می‌رسیم. سعی کردم نکات اصلی رو پوشش بدم. شما هم اگر در این خصوص نکته‌ای به نظرتون می‌رسه در کامنت‌ها بفرمایید.

بروزرسانی

اشکان در کانال یوتوبش، ویدئویی ساخته تحت عنوان «حرفه‌ای‌ها چگونه سوالات برنامه‌نویسی خودشون رو می‌پرسند؟» که پیشنهاد می‌کنم ببینید