چگونه یک سوال فوق العاده بپرسیم

همه ما برنامه نویس ها در تمام مراحل کاریمان نیاز به پرسیدن سوالات متفاوت از افراد متفاوت داریم. این که سوال ما چگونه طراحی شده باشد بسیار در کیفیت و زمان دسترسیمان به پاسخ تاثیر خواهد داشت.

مهارت در پرسیدن سوالات حرفه ای همچنین می تواند تاثیر فوق العاده ای در رشد یک برنامه نویس داشته باشد. احتمالا برای شما پیش آمده که سوالی پرسیده باشید و در اولین پاسخ به شما گفته شده باشد: آفرین چه سوال خوبی! همین آفرین ها می تواند راه شما را باز کند.

هچنین با گسترش استفاده از وبسایت های پرسش و پاسخ آنلاین مهارت در پرسیدن سوالات خوب و به جا، بیشتر و بیشتر در رسیدن به هدف کمک خواهد کرد و حتی سوالات خوب می توانند در وجه شغلی یک برنامه نویس تاثیر بسیار مثبتی نیز داشته باشند. به این صورت که مثلا در سایت stackoverflow.com سوالات نیز امتیاز دهی می شوند و در امتیازات یک کاربر تاثیر زیادی دارند.

با این مقدمه، برای پرسیدن یک سوال فوق العاده در محل کار چه مواردی نیاز است؟

سعی کنید سوال نپرسید!

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

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

عنوان سوال را دقیق انتخاب کنید

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

  • زبان برنامه نویسی یا زیرساخت مورد نظر (زمانی که در یک تیم یکنواخت کار می کنید می توانید فرض کنید طرف مقابل اطلاع از زیرساخت و زبان شما دارد)
  • متن exception یا خطای منطقی ای که به آن برخوردید به طور خلاصه. مثلا: خطای cannot enumerate all types of … را می گیرم.
  • موضوعات مربوط به شرایط خاصی که دارید، مثلا اگر پایگاه داده شما متفاوت با بقیه تیم است و حدس میزنید که خطا از این مورد است حتما ذکر کنید که پایگاه داده من متفاوت است

محدوده سوال تا حد امکان کوچک باشد

وقتی سوالی مطرح می شود باید سعی کنید محدوده طرح سوال تا حد امکان کوچک باشد. به این صورت که مکان دقیق ایجاد مشکل مشخص شده باشد و روش ایجاد دوباره مشکل مشخص شده باشد. همچنین اگر وابستگی خاصی در صورت مسئله به فناوری یا زیرساخت خاصی وجود دارد حتما مشخص شده باشد. به طور مثال بگویید حدس می زنم مشکل از binding ورژن asp.net ما باشد. دست آخر کاری که دقیقا در حال انجامش بودید نیز قابل ارائه باشد، مثلا:میخواستم فاکتور خالی جدیدی ثبت کنم.

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

پروژه تستی ایجاد کنید

در صورتی که امکان این کار وجود داشت بهتر است یک پروژه تستی قابل اجرا که موضوع سوال در آن ایجاد شده باشد درست کنید. این به روند رسیدن شما به پاسخ بسیار کمک خواهد شد. به این صورت که بجای مراجعه پاسخ گو(ها) به میز شما. شما پروژه را برای مخاطبین ارسال می کنید. در ایجاد این پروژه به موضوعات زیر دقت کنید:

  • تا حد امکان داده های مورد نیاز به صورت static داخل برنامه وجود داشته باشد
  • رابط کاربری پیچیده ای نداشته باشد
  • تمام نیازمندی های نرم افزاری تا حد امکان در کنار پروژه وجود داشته باشد
  • کد ساده داشته باشد و سریع سر اصل مشکل رفته باشد

همچنین می توان گفت پروژه تستی را می توانید به عنوان یک unit test بزرگ ببینید.

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

این مطلب  در مورد پرسیدن سوالات شفاهی نوشته شده است. برخی از قوانین و اصول وبسایت هایی مانند stackoverflow با مواردی که مطرح شده متفاوت است.


 مهارت های غیر فنی یک برنامه نویس

خوب باگ بزنیم (Useful bug reports)

نگران trust level نباشید

البته اگر تا الان نگران بودید‍!

این موضوع در واقع در تمام برنامه های دات نتی وجود دارد. ولی من در مورد بحث وبسایت ها این مورد را بررسی کرده ام.

خود من به شخصه از زمانی که شروع به برنامه نویسی وب کردم همیشه چند آیتم را به صورت چک لیست در نظر داشتم وقتی سایت یا نرم افزاری را روی سروری نصب میکردم. یکی از این آیتم ها trust level هست.

مفهوم trust level در IIS همان طور که نامش میگوید، میزان دسترسی برنامه هاست شده روی IIS را تعیین میکند. به طور کلی دو دسته trust level داریم.

  • Full trust: وقتی IIS با این سطح تنظیم میشود برنامه client امکان استفاده از منابع موجودی که سیستم عامل در اختیار user تنظیم شده با process مربوط به سایت می گذارد، را دارد. در واقع خود IIS کاری برای بررسی و محدود کردن برنامه client انجام نخواهد داد و کار به سیستم عامل واگذار میشود.
  • Partial trust: این سطح خود به چند سطح زیر مجموعه تقسیم می شود. (که می توان level های خاص خودمان را هم ایجاد کنیم) و اگر هر کدام از آنها برای سایتی از طرف IIS تنظیم شده باشند خود IIS یک سری محدودیت هایی برای سایت client در نظر خواهد گرفت. مانند استفاده از reflection، نوشتن فایل،باز کردن دیالوگ هایی مانند انتخاب فایل و …

بعضی از دسترسی های بالا اگر به برنامه شما داده نشده باشند، در صورتی که از DI container یا library هایی که از code generation استفاده می کنند استفاده کنید به مشکل بر می خورید. مثلا قابلیت استفاده از ninject  را در محیطی که دسترسی به reflection ندارد از دست خواهید داد. (اگر Ninject طوری تنظیم شده باشد که با reflection کار کند)

خودم به طور وسواس گونه ای! به این موضوع اهمیت می دادم تا وقتی یک سوالی را در سایت stackoverflow دیدم. در واقع سوال این بود که برای medium trust برنامه نویسی کردن بیهوده است یا نه. جواب یکی از کارکنان مایکروسافت این مطلب را می راسند که مایکروسافت trust level های بغیر از full را deprecated اعلام کرده. یعنی در آینده از طرف مایکروسافت این نیاز وجود خواهد داشت که برنامه برای اجرا شدن باید full trust باشد. حتی کلی از تکنولوژی های در حال کار مایکروسافت پشتیبانی خود را از medium trust حذف خواهند کرد. تکنولوژیهایی مانند MVC، WebAPI، SignalR  و …

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

عادت خوب برنامه نویسی : اگر پروژه ای را شروع می کنید. از همان اول trust level پروژه را مشخص کنید تا در آینده و هنگام deploy کردن پروژه به مشکل بر نخورید. با این کار از همان ابتدا محدودیت های خود را خواهید فهمید. برای این کار در پروژه های asp.net در فایل web.config از تگ trust باید استفاده کنید. به صورت زیر: