رفتن به مطلب
مرجع رسمی سی‌پلاس‌پلاس ایران

جستجو در تالارهای گفتگو

در حال نمایش نتایج برای برچسب های 'سوال'.



تنظیمات بیشتر جستجو

  • جستجو بر اساس برچسب

    برچسب ها را با , از یکدیگر جدا نمایید.
  • جستجو بر اساس نویسنده

نوع محتوا


آی‌او‌استریم

چیزی برای نمایش وجود ندارد

چیزی برای نمایش وجود ندارد

تالارهای گفتگو

  • انجمن‌های آی او استریم
    • اخبار و اعلامیه‌های سایت
    • اسناد و قوانین مرجع
    • جلسات و دوره‌همی‌های آنلاین
    • پادکست‌های آموزشی
    • معرفی محصولات نوشته شده‌ بومی
    • مرکز نظرسنجی
    • مقالات و اسناد مشاوره‌ای
    • مرکز چالش برانگیز برنامه‌نویسان
    • رمز‌های موفقیت
    • ابزار‌ها و نرم‌افزارهای کاربردی برنامه‌نویسان حرفه‌ای
  • برنامه نویسی در C و ‏++C
    • سوالات عامیانه در رابطه با ++C مدرن
    • کتابخانه‌های استاندارد STL
    • کتابخانه بوست (Boost)
    • کتابخانه کیوت (Qt)
    • کتابخانه‌‌ی SDL
    • کتابخانه‌های گرافیکی Vulkan, OpenGL, Metal, Direct3D
    • کتابخانه‌‌ی OpenCV
    • کتابخانه‌‌ی Cuda
    • کتابخانه‌‌ی OpenMP
    • کتابخانه‌‌ی OpenCL
    • کتابخانه‌های دیگر
    • کامپایلر‌ها
    • کتابخانهٔ SFML
    • ابزار‌ها
  • استارتاپی و کسب‌و‌کار
    • استارتاپ‌ها
    • سرمایه گذاری
    • شتاب دهنده‌ها
    • پارک‌های علم و فناوری و مراکز رشد
    • مصاحبه با استارت‌آپ‌ها
    • قوانین حقوقی
    • داستان‌های موفقیت
    • کارآفرینان و متخصصین
    • مشاوره اجرای کسب‌وکار
    • اخبار حوزه‌ی استارتا‌پی
    • آگهی‌های استخدامی
  • ابزار‌های ساخت و ساز
    • ابزار CMake
    • ابزار QMake
    • ابزار Qbs
    • ابزار Make و Autotools
  • طراحی و توسعه وب
  • طراحی و توسعه وب اپلیکیشن‌ها
    • طراحی و توسعه در Angular
    • طراحی و توسعه در React.JS
    • طراحی و توسعه در Vue.JS
  • طراحی و توسعه موبایل و اِمبِد‌ها و تلوزیون‌ها
    • برنامه نویسی تحت محصولات اپل
    • برنامه نویسی تحت محصولات گوگل
    • طراحی و توسعه تحت محصولات دیگر
  • برنامه‌نویسی سطح پایین و سیستم عامل‌ها
    • سیستم عامل‌های آزاد
    • سیستم عامل‌های تجاری
    • مباحث آموزشی مرتبط با سیستم‌عامل
  • شبکه و اینترنت
    • مباحث و منابع آموزشي
    • سوالات و مشکلات
  • بانک‌های اطلاعاتی
  • برنامه نویسی تحت محصولات اپل
  • برنامه نویسی تحت محصولات مایکروسافت
  • طراحی و توسعه تجربه کاربری (UX) و رابط کاربری (UI)
  • سوالات و مباحث عامیانه
  • سطل آشغال

Product Groups

  • کتاب‌ها و مقالات آموزشی

تقویم ها

دسته ها

  • علمی
  • استارتاپی
  • برنامه‌نویسی
    • زبان‌های برنامه نویسی
    • معماری‌ها
  • کامپایلر و مفسر
  • محیط‌های توسعه
  • طراحی و توسعه‌ی وب
  • مجوز‌های نرم‌افزاری
  • فناوری‌ها
    • پردازش تصویر
    • اینترنت اشیاء
    • پردازش ابری (Cloud Computing)
    • چند سکویی (Cross-Platform)
    • بیگ دیتا (Big Data)
    • هوش مصنوعی (AI)
    • سخت افزار
    • نرم‌افزار و اپلیکیشن
    • اینترنت و شبکه
    • رمزنگاری
    • امبد‌ها (Embedded)
  • طراحی
    • تجربه کاربری
    • رابط کاربری

دسته ها

  • عمومی

دسته ها

  • عمومی
  • گرافیکی
  • شبکه و ارتباطات

دسته ها

  • کامپایلر‌ها
  • محیط‌های توسعه
  • کتابخانه‌ها
  • ماژول‌ها و پلاگین‌ها
  • محصولات بومی
  • کتاب‌ها و مقالات
  • زبان‌ها و ابزار‌ها
  • طراحی و گرافیک

جستجو در ...

نمایش نتایجی که شامل ...


تاریخ ایجاد

  • شروع

    پایان


آخرین بروزرسانی

  • شروع

    پایان


فیلتر بر اساس تعداد ...

تاریخ عضویت

  • شروع

    پایان


گروه


درباره من


شماره تلفن همراه


شناسه گیت‌هاب


شناسه لینکدین


شناسه پیام رسان


شهر


آدرس پستی

4 نتیجه پیدا شد

  1. سلام، با پیشرفت فناوری های ابری کلی سوال پیش آمده برام، اولین سوال اینه میشه از فناوری ابری برای ذخیره داده های سی پلاس پلاس استفاده کرد؟ بنظر شما کدوم پایگاه داده بهتر و امن تر و سریع تره؟
  2. سلام، من توی Qt تازه کارم و رشته ام الکترونیک هستش. من توی برنامه ام یه QStringList ماکزیمم 10 عضوی دارم هر عضو هم نهایت 20 کاراکتر داره اعضای QStringList بجز عضو صفرم در طول برنامه ممکن تغییرات داشته باشند برنامه ای که نوشتم بخوبی کار میکنه تنها مشکلم این که بعد از بسته شدن برنامه QStringList برمی‌گرده به حالت اولیه که فقط عضو صفرم مقدار داره و بقیه اعضا پاک میشن. عضو صفرم QStringList چون اول برنامه مقدار اولیه بهش دادم بعد از بستن و باز کردن برنامه همون مقدار رو در خودش داره ولی بقیه اعضای QStringList چون در طول برنامه یا به لیست اضافه یا از لیست کم میشن بعد از بستن برنامه پاک میشن. فکر کنم بخاطر اینکه حافظه گرفته شده بعد از بستن برنامه آزاد میشه حالا من چطور این لیست رو روی توی برنامه ذخیره کنم که بعد از بستن و باز کردن برنامه تغییرات QStringList l من باقی بمونه. امیدوارم منظورم رو بدرستی رسونده باشم.
  3. کامبیز اسدزاده

    سند نحوهٔ پرسش و پاسخ هوشمندانه

    مقدمه در دنیای برنامه‌نویسی، نوع جوابی که برای سوالات فنی خود می‌گیرید، هر چقدر که به سختی جواب دادن سوال بستگی دارد، همانقدر هم به روش پرسیدن شما بستگی دارد. با مطالعهٔ این راهنما قادر خواهید بود طوری سوال کنید که به احتمال بیشتری جواب رضایت بخشی دریافت کنید. هدف ما از این سند در مرجع برنامه نویسی ایران، این است که فرهنگ مکاتبه و رسیدگی به مشکلات همدیگر را در زمینه‌های مرتبط افزایش و بهینه سازی کنیم. بنابراین، امروزه که برنامه‌نویسی بیش از پیش گسترده شده، می‌توانید از وجود افراد با‌تجربه استفاده کنید و جواب‌های خوبی دریافت کنید. با این حال حتی اگر افراد با‌تجربه هم برای پرسیدن سوال روش‌های توصیه شده در این راهنما را به کار گیرند جواب‌های مفید‌تری دریافت می‌کنند. اولین چیزی که باید درک کنیم این است که افراد با‌تجربه سوال های سخت و طولانی را دوست دارند که به خوبی ذهن را درگیر می‌کند. اگر به ما یک سوال جالب توجه بدهید که به آن فکر کنیم از شما سپاس‌گزار خواهیم شد. سوالات خوب محرک ذهن بوده و یک هدیه هستند. سوالات خوب به ما کمک می‌کنند تا فهم خود را توسعه دهیم و عموماً باعث آشکار شدن مشکلاتی میشود که ممکن است ما ندانیم یا به آنها توجهی نکرده باشیم. در میان افراد با‌تجربه یک سوال خوب یک چالش مهیج است. با این وجود بسیاری از تازه‌کار ها گمان میکنند که افراد با‌تجربه در مقابل سوالات ساده با دشمنی و تکبر برخورد می‌کنند و به نظر می‌رسد که واکنش گستاخانه‌ای با افراد تازه‌کار و ناآگاه دارند. اما به هیچ وجه این‌طور نیست! چیزی که بدون شرمندگی باید بگوییم، خصومت با افرادی است که ظاهراً تمایلی به تفکر در موضوع ندارند و جواب دادن به سوالشان را به نوعی وظیفهٔ افراد با تجربه می‌دانند. از دید افراد با‌تجربه چنین افرادی باعث هدر رفتن وقت می‌شوند پس وقت خود را صَرف جواب دادن به سوالات بهتر میکنند. همچین افراد با‌تجربه بسیار داوطلب هستند و در زمان‌هایی که مشغول نباشند به پاسخ دادن به سوالات می‌پردازند. در آن مواقع غرق سوالات هستند. پس بدون ترس سوالات را فیلتر می‌کنند و ترجیح می‌دهند که به سوالاتِ بهتر جواب دهند. نوع رفتار شما شایستگی شما را برای دریافت جواب نشان می‌دهد. افراد شایسته زیرک، اندیشمند، هشیار و علاقمند به شرکت فعالانه در توسعهٔ یک راه‌حل هستند. بهترین راه برای گرفتن یک جواب سریع و خوب اینست که آن را مانند یک شخص زرنگ و مطمئن بپرسید، شخصی که واقعاً نیاز به کمک در یک مشکل خاص دارد. قبل از این که سوال کنید قبل از پرسیدن یک سوال فنی از طریق ایمیل، شبکه اجتماعی یا انجمن یک وبسایت، این کار‌ها را انجام دهید: سعی کنید جواب خود را با جستجو در ویکی‌پدیا و یا در قسمت‌های ویکی سایت مربوطه پیدا کنید. سعی کنید جواب خود را با جستجو در آرشیو انجمنی که می‌خواهید بفرسیتد، پیدا کنید. سعی کنید جواب خود را با جستجو در وب پیدا کنید. سعی کنید جواب خود را با خواندن manual (راهنما) پیدا کنید. سعی کنید جواب خود را با خواندن FAQ (سوالات متداول) پیدا کنید. سعی کنید جواب خود را از طریق بازبینی یا آزمایش پیدا کنید. سعی کنید جواب خود را با پرسیدن از یک دوست باتجربه پیدا کنید. اگر یک برنامه‌نویس هستید، سعی کنید جواب خود را با خواندن کدمنبع پیدا کنید. از فنونی استفاده کنید. برای مثال متن پیغام ارور را در گوگل جستجو کنید. حتی اگر به نتیجه ای نرسید، گفتن اینکه «من عبارت زیر را گوگل کردم، اما چیز امیدوار کننده‌ای پیدا نکردم» چیز خوبی برای یک گروه پستی یا خبری است، حداقل به این دلیل که مشخص می‌شود جستجو کمکی نمی‌کند. وقت بگذارید. انتظار نداشته باشد که بتوانید مشکل پیچیدهٔ خود را با چند ثانیه گوگل کردن حل کنید. FAQ ها را بخوانید و بفهمید، آرام و باتمرکز بنشنید و کمی در مورد مشکل خود فکر و گمانه‌زنی کنید. به یکباره تمام سوالات خود را ارسال نکنید فقط به خاطر اینکه اولین جستجوی شما به هیچ جوابی نرسید (یا به جواب‌های زیادی رسید). سوال خود را آماده کنید. به آن فکر کنید. سوالات شتاب‌زده به جواب‌های شتاب‌زده منجر خواهد شد، یا اصلاً به هیچ جوابی نمی‌رسد. هر چه بیشتر این را نشان دهید که برای حل مسئلهٔ خود قبل از درخواست کمک، فکر و تلاش کرده‌اید، همانقدر احتمال بیشتری خواهد رفت که واقعاً به شما کمک کنند. از پرسیدن سوال اشتباه، اجتناب کنید. اگر سوالی بپرسید که بر اساس فرض‌های ناقص و اشتباه است، یک فرد با تجربه ممکن است با این تصور که «یک سوال احمقانه است...» بخواهد به شما یک جواب لفظی و بی‌فایده بدهد، و به امید اینکه شما درس بگیرید از تجربهٔ گرفتن آنچه پرسیدید، نه آنچه مورد نیاز شما بود. ما وقتی می‌توانید به جواب برسید که یک سوال قابل توجه و برانگیزندهٔ ذهن بپرسید، سوالی که بطور ضمنی باعث کمک به تجربهٔ جامعه می‌شود، نه آنکه فقط بصورت انفعالی خواستار دانش از دیگران باشید. از طرف دیگر، روشن ساختن اینکه شما توانایی و تمایل کمک در پروسهٔ حل مسئله را دارید، شروع بسیار خوبی است. «آیا کسی می‌خواهد منبعی معرفی کند؟»، «مثال من چه چیز کم دارد؟»، و «چه وبسایتی را بهتر است بررسی کنم» به احتمال بیشتری جواب خواهند گرفت نسبت به این سوال که «لطفاً روش دقیق کاری که باید انجام دهم را بنویسید.». چون [در حالت اول] شما این را روشن می‌سازید که واقعاً راغب به تکمیل پروسه [ی حل مشکل] هستید اگر شخصی فقط مسیر صحیح را به شما نشان دهد. وقتی سوأل می‌کنید: انجمن خود را به دقت انتخاب کنید به این حساس باشید که کجا سوال خود را مطرح می‌کنید. شما احتمالاً نادیده گرفته خواهید شد اگر: سوال شما دارای عنوان مناسب نباشد. یک سوال بسیار ابتدایی را در انجمنی پست کنید که انتظار سوالات فنی پیشرفته را دارند. یا بالعکس. یک سوال مشترک را در چند گروه خبری پست کنید. در گروهی باشید که عنوان و موضوع آن مشخص است، اما با این حال بگویید کسی چیزی بلد هست یا خیر! یک ایمیل شخصی به کسی بفرستید که نه سابقه آشنایی با شما دارد، و نه شخصاً مسئول حل مشکل شماست. افراد با تجربه سوالاتی که بیجا در مکان خاصی پست شود را پاک می‌کنند تا کانالهای ارتباطی‌شان را از غرق شدن در بی‌ربطی حفظ کند. شما نمی‌خواهید این اتفاق برایتان بیفتد؛ بنابراین اولین قدم این است که انجمن درست را انتخاب کنید. باز هم، گوگل و سایر روشهای جستجوی وب، دوست شما هستند. از آنها استفاده کنید. رها کردن یک ایمیل به سوی شخص یا انجمنی که با آن آشنا نیستید، در بهترین حالت یک ریسک است. در مورد اینکه آیا سوال شما مورد استقبال واقع می‌شود یا نه، حدس‌های خوشبینانه نزنید. اگر مطمئن نیستید آن را جای دیگری بفرستید یا اینکه از فرستادن آن خودداری کنید. به یکباره سوال خود را به همهٔ کانال های کمک‌رسانی ارسال نکنید، این کار مانند فریاد زدن است و افراد را عصبانی می‌کند. به آرامی از میان آنها گام بردارید. عموماً سوالاتی که در یک انجمن عمومی و درست (بجا) پرسیده شوند، احتمال اینکه جواب مفید بگیرند بیشتر است تا آنهایی که در جای خصوصی پرسیده می‌شوند. چندین دلیل برای این وجود دارد. یک دلیل ساده، مقدار منابع پاسخگو است. یکی دیگر تعداد بازدیدکنندگان است؛ افراد با‌تجربه ترجیح می‌دهند به سوالاتی جواب دهند که افراد بیشتری را آموزش دهد، تا سوالاتی که فقط به درد افراد کمی بخورد. به وضوح، برنامه‌نویسان چیره‌دست و سازندگان نرم‌افزارهای محبوب، همواره بسیار بیشتر از توان پاسخ‌گویی‌شان، پیغام‌های انبوه و بی‌هدف دریافت می‌کنند. شما با اضافه شدن به این سیل، یکی از آن موارد بسیار زیاد هستید. از عناوین پرمعنا و دارای موضوع مشخص، استفاده کنید در لیست‌های پستی، گروه‌های خبری یا انجمن‌های وب، عنوانِ موضوع، فرصت طلایی شماست تا با حدود ۵۰ کاراکتر یا کمتر، توجه متخصصانِ قابل را جلب کنید. با عناوینی مثل «لطفاً به من کمک کنید»، آن را هدر ندهید (پیغام‌هایی با این‌گونه عناوین به راحتی دور انداخته می‌شوند). سعی نکنید با عمق اضطراب خود، افراد با تجربه را تحت تأثیر قرار دهید؛ در عوض، از آن فضا برای یک توصیف بسیار مختصر از مشکل خود استفاده کنید. نامطلوب: کمک! کتابخانه X روی لپ‌تاپ من درست کار نمی‌کند! هوشمندانه: با استفاده از امکانY از کتاب‌خانه X برنامه من کار نمی‌کند! هوشمندانه تر: با استفاده از امکان Y در کتاب‌خانه X نسخه 5.8 برنامه من کرش (Crash) می‌کند. تصور کنید که به یک لیست از سوالات یک آرشیو نگاه می‌کنید، که فقط خطوط عنوان‌ها نمایش داده می‌شوند. عنوان پست خود را طوری انتخاب کنید که بخوبی سوال شما را منعکس کنید، تا شخص بعدی که آرشیو را جستجو می‌کند، بتواند دنبال آن ریسمان (thread) را بگیرد و به یک جواب برسد، بجای اینکه دوباره آن سوال را پست کند. رسیدن یک سوال در یک پاسخ، به خودی خود مورد شک است، چون آن فقط توسط افرادی دیده خواهد شد که این ریسمان را دنبال می‌کنند. پس یک ریسمان (تاپیک) جدید را آغاز کنید، مگر اینکه مطمئنید می‌خواهید فقط از افرادی بپرسید که در حال حاضر در این ریسمان فعال هستند. پاسخ دادن را آسان کنید پایان دادن سوال با این عبارت که «لطفاً پاسخ خو را به ... بفرستید»، جواب گرفتن شما را کاملاً بعید می‌سازد. بصورت واضح، از لحاظ دستوری صحیح، و با املای صحیح بنویسید مهم است که سوال خود را واضح و خوب بیان کنید. قبل از ارسال سوال خود یکبار متن سوالتان را بررسی و سعی خود را بکنید تا زبان (بیان) خود را بهبود دهید (صیقل دهید). لازم نیست که رسمی و سنگین باشد. در واقع افراد با تجربه به آن طرز بیانی بها میدهند که غیر رسمی، عامیانه، شوخ‌طبعانه و همراه با دقت و ظرافت باشد. اما باید دقیق باشد؛ باید نشانه‌هایی از اینکه که شما اندیشه و توجه می‌کنید را داشته باشد. این نکته بسیار مهم است که به زبان رسمی آن کانال ارتباطی سوال خود را ارسال کنید. برای مثال اگر در انجمنی که زبان رسمی آن فارسی است سوال خود را به زبان انگلیسی (یا فینگلیش) بنویسید سوال شما معمولا یا پاک خواهد شد و یا نادیده گرفته می‌شود. اگر دارید سوال خود را در انجمنی می‌پرسید که از زبان بومی شما استفاده نمی‌کند، شما یک میزان محدودی از خطاهای املایی و دستوری خواهید داشت، اما از روی تنبلی دچار خطاهای بیش از حد نشوید (بله، افراد معمولاً می‌توانند آن تفاوت را تشخیص دهند). همینطور اگر نمی‌دانید که شخص پاسخگو چه زبانی دارد، به انگلیسی بنویسید. افراد با‌تجربه مشغول، سوالات با زبانی که نمی‌فهمند را نادیده می‌گیرند، و انگلیسی زبان کاری اینترنت است. با نوشتن به زبان انگلیسی، این احتمال را که سوالتان بدون خوانده شدن پاک شود، به حداقل می‌رسانید. سوال خود را در قالب‌های استاندارد و در دسترس مطرح کنید نامه خود را به صورت پاراگراف‌هایی که از خطوط به هم پیچیده شده تشکیل شده‌اند، نفرستید. این کار، پاسخ گویی به قسمت‌های مختلف نوشته شما را دشوار می‌کند. هرگز تصور نکنید که مخاطبین شما قادر به خواند فایل‌های اختصاصی مانند Microsoft word یا Excel هستند. افراد مختلف از سیستم عامل‌های مختلف و برنامه‌های متفاوتی برای ویرایش متن استفاده می‌کنند پس بهترین گزینه این است که فایل خود را به صورت متنی ارسال کنید. در صفحات گفتگو، از اشکال خندان (Smile) و امکانات HTML استفاده نکنید. یکی دو تا از این اشکال ایرادی ندارد. اما در صورت استفاده بیش از حد. بهای سوال شما را کاهش می‌دهد و احتمال نادیده گرفته شدن سوال شما افزایش پیدا می‌کند. اگر شما از یک پردازش‌گر ایمیل با صورت گرافیکی کاربری مانند MS، Outlook، Netscape، Messenger و یا از این‌گونه‌ها استفاده می‌کنید، آگاه باشید که در صورتی که از تنظیمات پیش‌فرض آن استفاده می‌کنید، ممکن است این قوانین نقض شوند. بیشتر این پردازشگرها دارای یک دستور در فهرست خود به نام view source هستند از این گزینه در پوشه نامه‌های فرستاده خود استفاده کنید و فرستادن نوشته ساده (plain tent) بدون ضمایم غیر ضروری را بررسی کنید. درباره مشکل خود دقیق و آگاه باشید نشانه‌های مشکل ایجاد شده یا bug ها را به دقت و روشنی شرح دهید. محیطی که در آن این مشکل ایجاد می‌شود را شرح دهید. (سیستم عامل، کاربرد و ...) شرکت فروشنده و مدل آنرا هم معرفی کنید مثلاً (Fedora Coret یا Slackware 91 و ...). مطالعاتی که بر روی این مشکل انجام داده‌اید را شرح دهید. مراحل تشخیص مشکل و رفع آنرا که انجام داده‌اید، قبل از طرح سوال، شرح دهید. هرگونه تغییر در سخت‌افزار یا نرم‌افزار که اخیراً انجام شده است را شرح دهید. تلاش کنید تا به سوالاتی که پیش‌بینی می‌کنید از شما پرسیده شوند، پیش‌تر پاسخ دهید. حجم مطالب دلیلی بر دقیق بودن آن نیست باید دقیق و آموزنده بنویسید. این هدف با نوشتن حجم زیادی از داده‌ها و کدها در نامه تقاضای کمک محقق نمی‌شود. اگر یک مشکل بزرگ و پیچیده دارید، سعی کنید تا آنرا تا حد ممکن خلاصه و مرتب ارائه کنید. این امر حداقل سه فایده دارد. اول اینکه معلوم شود که شما برای خلاصه کردن سؤال خود تلاش کرده‌اید یا تمایل بیشتری برای پاسخ به شما وجود خواهد داشت. دوم اینکه با خلاصه‌سازی پاسخ مفیدتری هم خواهید گرفت؛ و سوم اینکه در حین خلاصه کردن و پیرایش گزارش خود ممکن است بتوانید مشکل را حل کنید یا راه حل کوتاه‌تری برای آن پیدا کنید. بدون اطمینان ادعای یافتن یک bug را نکنید! هنگامی که با یک نرم‌افزار به مشکل برخوردید، بدون اطمینان کامل ادعای یافتن یک bug جدید را مطرح نکنید. راهنمایی: تا هنگامی که با یک ضمیمه به کد منبع نتوانید مشکل را برطرف کنید یا با آزمایش رگرسیون با ورژن قبلی که نشان دهنده یک رفتار نادرست باشد، شما نباید مطمئن شوید. این امر در مورد وب سایت‌ها و مدارک هم صدق می‌کند سندی را به عنوان bug یافتید، باید متنی را جایگزین آن کنید یادآوری می‌شود که کاربران بسیاری هستند که مشکل شما را تجربه نکرده‌اند. همچنین شما با خواندن مطالب و وب سایت‌های مرتبط، در مورد آن نرم‌افزار آموزش دیده‌اید در غیر این صورت شما کاری را اشتباه انجام می‌دهید و نه نرم‌افزار. افرادی که یک نرم‌افزار را تهیه می‌کنند، تلاش می‌کنند تا آن نرم‌افزار حداکثر کارایی مطلوب را داشته باشد. اگر شما ادعا کنید که یک bug در آن یافته‌اید، در واقع کامل بودن کار آنها را زیر سؤال برده‌اید و این باعث رنجاندن آنهان می‌شود، حتی اگر حق با شما باشد. به خصوص ذکر کلمه bug در عنوان نامه، کار سیاست مدارانه‌ای نیست. وقتی که سوال خود را مطرح می‌کنید، بهتر است فرض کنید که شما کار اشتباهی را انجام می‌دهید، حتی اگر مطمئن باشید که یک bug واقعی را یافته‌اید. اگر واقعاً این طور باشد، در مورد آن در پاسخ‌ها خواهید شنید. با این کار نگهدارنده‌های نرم‌افزار از شما عذرخواهی خواهند کرد، همچنین اگر شما اشتباه کرده باشید، باید از آنها عذرخواهی کنید. به جای حدس‌های خود نشانه‌های مشکل را شرح دهید نوشتن در مورد اینکه خودتان علت مشکل پیش آمده را چه می‌دانید، مفید نیست (اگر فرضیات شما به‌کلی اشتباه باشد آیا با دیگران مشورت می‌کنید؟). لذا سعی کنید که به دوست‌داران کامپیوتر از علائم و نشانه‌های اولیه مشکل موجود بگویید و نه از فرضیات و تئوری‌های خود. بگذارید آنها خود تفسیر کنند و مشکل را تشخیص دهند اگر احساس می‌کنید که ذکر کردن حدس خودتان می‌تواند مهم باشد، آنرا روشن و تحت عنوان حدس خودتان بیان کنید و همچنین ذکر کنیدن که چرا این پاسخ نمی‌تواند جوابگوی مسئله باشد. هدف را مشخص کنید، نه مرحله اگر به دنبال این هستید که بدانید چطور باید کاری را انجام دهید (مثل گزارش کردن یک اشکال یا bug )، با شرح دادن هدف خود شروع کنید. بعد از آن فقط برخی از مراحل خاص که برای رسیدن به آن طی کردید و موفق نشدید را شرح دهید. اغلب، افرادی که به کمک تکنیکی نیاز دارند، هدف بلند مرتبه‌ای را در ذهن می‌پرورانند و در راهی که فکر می‌کنند تنها راه رسیدن به هدف است گمراه می‌شوند. آنها برای کمک گرفتن مرحله به مرحله می‌آیند اما نمی‌دانند که مسیر اشتباه است تلاش قابل توجهی برای گذر از این مرحله مورد نیاز است. سوال نامطلوب: چگونه می‌توان در برنامه FooDraw مقادیر RGB رنگ را بر مبنای شانزده‌تایی انتخاب کرد؟ سوال هوشمندانه: من تلاش می‌کنم که جدول رنگ‌ها را روی یک تصویر با مقادیر انتخابی خودم قرار دهم. در حال حاضر تنها راهی که به نظرم می‌رسد اینست که هر ردیف از جدول را اصلاح کنم اما نمی‌توانم در برنامه FooDraw رنگ‌ها را بر مبنای مقادیر RGB شانزده‌تایی انتخاب کنم. سوال دوم هوشمندانه بود. جواب این سوال ابزار بهتری برای آن کار را پیشنهاد می‌دهد. سوال را صریح مطرح کنید برای سوال‌هایی که انتهای مشخصی ندارد، بازه زمانی محدودی برای پاسخگویی به آنها در نظر گرفته نمی‌شود. کسانی که می‌خواهند پاسخ‌های مفیدی به شما بدهند، مشغول‌ترین افراد هستند. (چون در اغلب کارها به تنهایی کار می‌کنند). این گونه افراد نسبت به سوال‌هایی با بازه زمانی نامحدود حساسیت دارند و تمایل چندانی به پاسخ‌گویی به آنها ندارند. شما هنگامی که یک پاسخ مفید دریافت می‌کنید که از پاسخگویی خود در مورد چیزی که می‌خواهید به‌طور صریح پرسیده باشید (از اشاره‌گر استفاده کند، که بفرستید، پیوست را بررسی کنید یا هر چیز دیگر). این کار تلاش پاسخگو را بر روی هدف شما متمرکز می‌کند و به طور ضمنی حدی از نظر زمانی برای پاسخگویی و صرف انرژی برای کمک به شما ایجاد می‌کند. این کار خوبی است. برای درک دنیایی که متخصصین در آن زندگی می‌کنند، به مهارت به عنوان یک منبع و زمان فراوان برای پاسخگویی به یک مورد کمیاب فکر کنید. هر چه زمان کمتری را برای پاسخگویی به سوال خود به طور ضمنی در نظر بگیرید، احتمال اینکه جواب واقعاً مناسب از جانب یک فرد خبره و پرمشغله دریافت کنید، بیشتر می‌شود بنابراین بهتر است که برای سوال خود قالبی در نظر بگیرید که زمان مورد نیاز به پاسخگویی به آن را از جانب یک فرد خبره به حداقل برساند. اما این کار اغلب مشابه ساده‌سازی یک سوال نیست. به عنوان مثال، ممکن است برای شرح مناسبی از X یک راهنمایی بکنید؟ معمولاً سوال هوشمندانه‌تری است نسبت به اینکه ممکن است لطفاً X را توضیح دهید! اگر شما یک کد نادرست دارید، بهتر است در مورد اینکه چه اشکالی دارد بپرسید تا اینکه درخواست کنید کسی آنرا اصلاح کند. سوالهای بی‌معنی را حذف کنید از به پایان رساندن درخواست سوال خود با جملات بی‌مفهومی مانند کسی می‌تواند به من کمک کند؟ یا آیا جوابی وجود دارد؟ پرهیز کنید. اولاً، اگر شرح خود را تا نیمه نوشته بودید، این گونه سوال‌ها زائد هستند. دوماً، به دلیل زائد بودن آنها کاربران آنها را آزاردهنده تلقی می‌کنند و احتمال دارد که جواب‌هایی بی عیب و نقص ولی بی اعتنا مانند بله، به شما می‌توان کمک کرد. یا خیر، هیچ کمکی نمی‌توان کرد به شما بدهند. به طور کلی، از سوالهای آری یا خیر باید اجتناب شود مگر اینکه تنها جواب بله یا خیر برای شما کافی باشد. سوال خود را با کلمه «فوری» نشانه‌دار نکنید، حتی اگر برای شما اینگونه باشد: این مشکل شماست، نه دیگران. اظهار ضرورت کردن نتیجه معکوس می‌دهد. بیشتر کاربران به راحتی اینگونه سوال‌ها را که با خودخواهی و گستاخی درخواست توجه فوری و ویژه می‌کنند را حذف می‌کنند. تنها یک شبه استثناء وجود دارد. اگر شما در یک محل با مرتبه بالا و با یک نرم‌افزار کار می‌کنید و از نظر زمانی تحت فشار هستید، گفتن مودبانه محدودیت زمانی خود می‌تواند مؤثر باشد تا دیگران را به پاسخ دادن به شما ترغیب کند. البته این کار ریسک بالایی دارد، چون معیار جالب بودن مسائل از نظر کاربران دیگر با شما متفاوت است. به عنوان مثال فرستادن نامه از یک ایستگاه فضایی بین‌المللی قانع کننده است اما از جانب یک انسان با احساس خوب و مهربان یا یک سیاستمدار خیر. در واقع، نوشتن کلمه «فوری» باعث می‌شود که از سوال شما اجتناب و دوری شود حتی اگر از نظر آنها مهم باشد. اگر فکر می‌کنید که این امری مبهم است، دوباره این مطالب را بخوانید تا کاملاً آنرا درک کنید، قبل از آنکه نوشته‌ای را به جایی بفرستید. ادب و احترام را رعایت کنید مؤدب باشید. از جملاتی مانند «لطفاً» و «با تشکر از توجه شما» یا «ممنون از ملاحظه شما» استفاده کنید. به طور واضح بیان کنید که شما اینکه دیگران وقت خود را برای کمک به شما رایگان صرف می‌کنند، تحسین کنید. صادق بودن، به اندازه واضح، دقیق، با دستور زبان صحیح و مشروح بودن و پرهیز از قالب‌های مالکانه، مهم نیست و حتی جایگزین آنها هم نمی‌تواند باشد. کاربران بطور کلی علاقه دارند که گزارش‌های دقیق تکنیکی از bug ها و ایرادها را هر چند بی ادبانه دریافت کنند تا نوشته‌های مؤدب ولی ابهام‌آمیز. (اگر این امر برای شما مبهم است، به یاد داشته باشید که سوال‌ها را با چیزی که توسط آن می‌توان یاد گرفت ارزش‌گذاری می‌کنند). به هر حال اگر مشکلات تکنیکی خود را ردیف کنید، مؤدب بودن شانس شما را برای دریافت پاسخ مفید افزایش می‌دهد. باید ذکر شود که تنها مخالفتی که از سوی کاربران قدیمی نسبت به این نوشته دریافت کرده‌ایم، در رابطه با توصیه‌های قبلی ما برای تشکر پیشاپیش است. برخی از کاربران احساس می‌کنند که این دلالتی به منظوری دارد و نه تشکر. توصیه ما اینست که هم پیشاپیش تشکر کنید و هم بعد از پاسخ‌گویی و یا ادب و احترام را به روشهای دیگری بیان کنید قبلاً با جملاتی مثل: «با تشکر از توجه شما» یا «ممنون از ملاحظه شما». روش حل را با یادداشت مختصری پاسخ دهید بعد از اینکه مسئله حل شد، یادداشتی به همه کسانی که به شما کمک کرده‌اند بفرستید، آنها را از نحوهٔ حل مطلع کنید؛ و باز هم از یاری آنها تشکر کنید. پاسخ شما نباید طولانی و شامل جملاتی ساده مثل: «ایراد از کابل شبکه بود، با تشکر از همه» باشد. حتی اگر پاسخ ندهید، بهتر از این جملات است. پاسخ کوتاه و خلاصه‌ای شیرین بهتر است از یک مقاله طولانی مگر اینکه عمق تکنیکی مسئله زیاد باشد. ذکر کنید که چه عملی مشکل را حل کرد اما لزومی ندارد که تمام مراحل حل مشکل را گزارش کنید. برای برخی از مسائل مناسب است که خلاصه‌ای از مراحل رفع مشکل را گزارش کنید. وضعیت نهایی مسئله خود را شرح دهید. توضیح دهید که چه روشی شما را به حل رساند و بعد از آن به داده‌هایی که جواب نمی‌رسد اشاره کنید. روشهای اشتباه را باید بعد از جواب صحیح و دیگر مطالب خلاصه بیاورید تا اینکه خلاصه شما تبدیل به یک داستان کارآگاهی نشود. از افرادی که به شما کمک کردند نام ببرید، با این کار با آنها دوست هم می‌شوید. در نهایت، این گونه خلاصه نویسی به تمام کسانی که کمک کرده‌اند، احساس رضایت‌مندی و نزدیکی به مسئله می‌دهد و این کم ارزش نیست. اگر شما یک تکنسین یا فرد باتجربه نیستید، مطمئن باشید که این احساس برای راهنماها و متخصصینی که از آنها کمک گرفته‌اید، بسیار مهم است. اگر نفهمیدید... اگر جواب را نفهمیدید، فوراً تقاضای روشن کردن پاسخ نکنید. از همان اندازه‎هایی که برای پاسخ اولیه خودتان (دستورالعمل‎ها ( FAQS)، وب و دوستان ماهر) برای فهمیدن جواب استفاده کنید. سپس اگر باز هم نیاز به شفاف سازی نشان دهید که چه چیزی یادگرفته‎اید. برای مثال تصور کنید که من به شما می‎گویم: "به‎نظر می‎رسد که شما Zentry گرفته شده‎ای دارید، باید آنرا تمیز کنید." در این صورت یک جواب نامناسب این خواهد بود: « Zentry چیست؟» و یک جواب خوب این خواهد بود "بسیار خوب، من صفحه اصلی را خواندم و به Zentry ها تحت عنوان سوئیچ‎های –Z و –P اشاره شده است اما هیچ یک از تمیز کردن Zentry چیزی نگفته‎اند. آیا اینها درست است یا من نکته‎ای را متوجه نشده‎ام؟" اخلاق حرفه ای داشته باشید با توجه به راه‎های مفصلی که در این‎جا گفته شد یا راه‎های مشابه بعید است که در راه‌های ارتباطی با افراد باتجربه اشتباه کنید. به‎طور دقیقی با جملات متفاوت به شما گفتیم که چگونه می‎توان اشتباه کرد. اگر چنین اتفاقی افتاد بدترین کار اینست که از این تجربه خود ناله کنید، ادعا کنید که شفاهاً مورد توهین قرار گرفته‎اید، تقاضای عذرخواهی کنید، نقستان را حبس کنید، به شکایت کردن تهدید کنید، از افراد شکایت کنید و غیره. در عوض پیش بروید. این امری طبیعی است. درواقع مناسب و سالم است. گاهی اوقات افراد بدون هیچ دلیل روشنی شخصاً شما را مورد حمله قرار می‎دهند حتی اگر شما اشتباهی نکرده باشید (یا فقط در ذهن آنها دچار اشتباه شده‎اید) در این موارد، شکایت کردن روشی واقعاً اشتباه است. این افرادِ متجاوز، نادان هم هستند که بدون هیچ دلیلی، خود را با تجربه می‎دانند یا با آزمایش‎های روان‎شناسی می‎خواهند بدانند که اشتباه کرده‎اید یا خیر. خوانندگان دیگر هم آنها را نادیده می‎گیرند و یا با روش خودشان با آنها برخورد می‎کنند رفتار این‎گونه افراد خود آنها را دچار مشکل می‎کند که به شما ربطی ندارد. اجازه ندهید که داخل این‎گونه بحث‎ها به دام بیفتید. بعد از اینکه بررسی کردید که آیا آنها واقعاً توهین هستند و نه اشاره‎ای به اشتباه شما و نه اشاره‎ای به اشتباه شما و نه اشاره‎ای زیرکانه به جواب واقعی سوال شما اغلب توهین‎ها نادیده گرفته می‎شوند. به اطلاعات موجود در فایل های ارسالی و ضمیمه توجه کنید در بسیاری از مواقع ممکن است سوال شما همراه با فایل (یا فایل های) ضمیمه‌ای باشد که مشکل را دقیق‌تر به پاسخ دهند‌گان شرح میدهد. حتما قبل از ارسال فایل ضمیمه به موارد زیر توجه کنید: فایل ارسالی حاوی اطلاعات شخصی افراد نباشد. این موارد حریم شخصی افراد را نقض میکند و ممنوع می‌باشد. در صورتی که سوال شما مربوط به نحوهٔ نمایش آن اطلاعات است میتوانید با ابزار ویرایش تصویر یا فایل، اطلاعات شخصی را حذف کنید. توصیه می‌شود که در زمان جستجوی محتوا از طریق موتور‌های جستجو‌گر مانند گوگل، به توصیه‌های رسمی در نحوهٔ جستجوی پیش‌رفته توجه کنید.
  4. کامبیز اسدزاده

    مقدمه در دنیای برنامه‌نویسی، نوع جوابی که برای سوالات فنی خود می‌گیرید، هر چقدر که به سختی جواب دادن سوال بستگی دارد، همانقدر هم به روش پرسیدن شما بستگی دارد. با مطالعه‌ی این راهنما قادر خواهید بود طوری سوال کنید که به احتمال بیشتری جواب رضایت بخشی دریافت کنید. هدف ما از این سند در مرجع برنامه نویسی ایران، این است که فرهنگ مکاتبه و رسیدگی به مشکلات همدیگر را در زمینه‌های مرتبط افزایش و بهینه سازی کنیم. بنابراین، امروزه که برنامه‌نویسی بیش از پیش گسترده شده، می‌توانید از وجود افراد با‌تجربه استفاده کنید و جواب‌های خوبی دریافت کنید. با این حال حتی اگر افراد با‌تجربه هم برای پرسیدن سوال روش‌های توصیه شده در این راهنما را به کار گیرند جواب‌های مفید‌تری دریافت می‌کنند. اولین چیزی که باید درک کنیم این است که افراد با‌تجربه سوال های سخت و طولانی را دوست دارند که به خوبی ذهن را درگیر می‌کند. اگر به ما یک سوال جالب توجه بدهید که به آن فکر کنیم از شما سپاس‌گزار خواهیم شد. سوالات خوب محرک ذهن بوده و یک هدیه هستند. سوالات خوب به ما کمک میکنند تا فهم خود را توسعه دهیم و عموماً باعث آشکار شدن مشکلاتی میشود که ممکن است ما ندانیم یا به آنها توجهی نکرده باشیم. در میان افراد با‌تجربه یک سوال خوب یک چالش مهیج است. با این وجود بسیاری از تازه‌کار ها گمان میکنند که افراد با‌تجربه در مقابل سوالات ساده با دشمنی و تکبر برخورد می‌کنند و به نظر می‌رسد که واکنش گستاخانه‌ای با افراد تازه‌کار و ناآگاه دارند. اما به هیچ وجه این‌طور نیست! چیزی که بدون شرمندگی باید بگوییم، خصومت با افرادی است که ظاهراً تمایلی به تفکر در موضوع ندارند و جواب دادن به سوالشان را به نوعی وظیفه‌ی افراد با تجربه می‌دانند. از دید افراد با‌تجربه چنین افرادی باعث هدر رفتن وقت می‌شوند پس وقت خود را صَرف جواب دادن به سوالات بهتر میکنند. همچین افراد با‌تجربه بسیار داوطلب هستند و در زمان‌هایی که مشغول نباشند به پاسخ دادن به سوالات می‌پردازند. در آن مواقع غرق سوالات هستند. پس بدون ترس سوالات را فیلتر می‌کنند و ترجیح می‌دهند که به سوالاتِ بهتر جواب دهند. نوع رفتار شما شایستگی شما را برای دریافت جواب نشان می‌دهد. افراد شایسته زیرک، اندیشمند، هشیار و علاقمند به شرکت فعالانه در توسعهٔ یک راه‌حل هستند. بهترین راه برای گرفتن یک جواب سریع و خوب اینست که آن را مانند یک شخص زرنگ و مطمئن بپرسید، شخصی که واقعاً نیاز به کمک در یک مشکل خاص دارد. قبل از این که سوال کنید قبل از پرسیدن یک سوال فنی از طریق ایمیل، شبکه اجتماعی یا انجمن یک وبسایت، این کار‌ها را انجام دهید: سعی کنید جواب خود را با جستجو در ویکی‌پدیا و یا در قسمت‌های ویکی سایت مربوطه پیدا کنید. سعی کنید جواب خود را با جستجو در آرشیو انجمنی که می‌خواهید بفرسیتد، پیدا کنید. سعی کنید جواب خود را با جستجو در وب پیدا کنید. سعی کنید جواب خود را با خواندن manual (راهنما) پیدا کنید. سعی کنید جواب خود را با خواندن FAQ (سوالات متداول) پیدا کنید. سعی کنید جواب خود را از طریق بازبینی یا آزمایش پیدا کنید. سعی کنید جواب خود را با پرسیدن از یک دوست باتجربه پیدا کنید. اگر یک برنامه‌نویس هستید، سعی کنید جواب خود را با خواندن کدمنبع پیدا کنید. از فنونی استفاده کنید. برای مثال متن پیغام ارور را در گوگل جستجو کنید. حتی اگر به نتیجه ای نرسید، گفتن اینکه «من عبارت زیر را گوگل کردم، اما چیز امیدوار کننده‌ای پیدا نکردم» چیز خوبی برای یک گروه پستی یا خبری است، حداقل به این دلیل که مشخص می‌شود جستجو کمکی نمی‌کند. وقت بگذارید. انتظار نداشته باشد که بتوانید مشکل پیچیدهٔ خود را با چند ثانیه گوگل کردن حل کنید. FAQ ها را بخوانید و بفهمید، آرام و باتمرکز بنشنید و کمی در مورد مشکل خود فکر و گمانه‌زنی کنید. به یکباره تمام سوالات خود را ارسال نکنید فقط به خاطر اینکه اولین جستجوی شما به هیچ جوابی نرسید (یا به جواب‌های زیادی رسید). سوال خود را آماده کنید. به آن فکر کنید. سوالات شتاب‌زده به جواب‌های شتاب‌زده منجر خواهد شد، یا اصلاً به هیچ جوابی نمی‌رسد. هر چه بیشتر این را نشان دهید که برای حل مسئلهٔ خود قبل از درخواست کمک، فکر و تلاش کرده‌اید، همانقدر احتمال بیشتری خواهد رفت که واقعاً به شما کمک کنند. از پرسیدن سوال اشتباه، اجتناب کنید. اگر سوالی بپرسید که بر اساس فرض‌های ناقص و اشتباه است، یک فرد با تجربه ممکن است با این تصور که «یک سوال احمقانه است...» بخواهد به شما یک جواب لفظی و بی‌فایده بدهد، و به امید اینکه شما درس بگیرید از تجربهٔ گرفتن آنچه پرسیدید، نه آنچه مورد نیاز شما بود. ما وقتی می‌توانید به جواب برسید که یک سوال قابل توجه و برانگیزندهٔ ذهن بپرسید، سوالی که بطور ضمنی باعث کمک به تجربهٔ جامعه می‌شود، نه آنکه فقط بصورت انفعالی خواستار دانش از دیگران باشید. از طرف دیگر، روشن ساختن اینکه شما توانایی و تمایل کمک در پروسهٔ حل مسئله را دارید، شروع بسیار خوبی است. «آیا کسی می‌خواهد منبعی معرفی کند؟»، «مثال من چه چیز کم دارد؟»، و «چه وبسایتی را بهتر است بررسی کنم» به احتمال بیشتری جواب خواهند گرفت نسبت به این سوال که «لطفاً روش دقیق کاری که باید انجام دهم را بنویسید.». چون [در حالت اول] شما این را روشن می‌سازید که واقعاً راغب به تکمیل پروسه [ی حل مشکل] هستید اگر شخصی فقط مسیر صحیح را به شما نشان دهد. وقتی سوال می‌کنید: انجمن خود را به دقت انتخاب کنید به این حساس باشید که کجا سوال خود را مطرح می‌کنید. شما احتمالاً نادیده گرفته خواهید شد اگر: سوال شما دارای عنوان مناسب نباشد. یک سوال بسیار ابتدایی را در انجمنی پست کنید که انتظار سوالات فنی پیشرفته را دارند. یا بالعکس. یک سوال مشترک را در چند گروه خبری پست کنید. یک ایمیل شخصی به کسی بفرستید که نه سابقه آشنایی با شما دارد، و نه شخصاً مسئول حل مشکل شماست. افراد با تجربه سوالاتی که بیجا در مکان خاصی پست شود را پاک می‌کنند تا کانالهای ارتباطی‌شان را از غرق شدن در بی‌ربطی حفظ کند. شما نمی‌خواهید این اتفاق برایتان بیفتد؛ بنابراین اولین قدم این است که انجمن درست را انتخاب کنید. باز هم، گوگل و سایر روشهای جستجوی وب، دوست شما هستند. از آنها استفاده کنید. رها کردن یک ایمیل به سوی شخص یا انجمنی که با آن آشنا نیستید، در بهترین حالت یک ریسک است. در مورد اینکه آیا سوال شما مورد استقبال واقع می‌شود یا نه، حدس‌های خوشبینانه نزنید. اگر مطمئن نیستید آن را جای دیگری بفرستید یا اینکه از فرستادن آن خودداری کنید. به یکباره سوال خود را به همه‌ی کانال های کمک‌رسانی ارسال نکنید، این کار مانند فریاد زدن است و افراد را عصبانی می‌کند. به آرامی از میان آنها گام بردارید. عموماً سوالاتی که در یک انجمن عمومی و درست (بجا) پرسیده شوند، احتمال اینکه جواب مفید بگیرند بیشتر است تا آنهایی که در جای خصوصی پرسیده می‌شوند. چندین دلیل برای این وجود دارد. یک دلیل ساده، مقدار منابع پاسخگو است. یکی دیگر تعداد بازدیدکنندگان است؛ افراد با‌تجربه ترجیح می‌دهند به سوالاتی جواب دهند که افراد بیشتری را آموزش دهد، تا سوالاتی که فقط به درد افراد کمی بخورد. به وضوح، برنامه‌نویسان چیره‌دست و سازندگان نرم‌افزارهای محبوب، همواره بسیار بیشتر از توان پاسخ‌گویی‌شان، پیغام‌های انبوه و بی‌هدف دریافت می‌کنند. شما با اضافه شدن به این سیل، یکی از آن موارد بسیار زیاد هستید. از عناوین پرمعنا و دارای موضوع مشخص، استفاده کنید در لیست‌های پستی، گروه‌های خبری یا انجمن‌های وب، عنوانِ موضوع، فرصت طلایی شماست تا با حدود ۵۰ کاراکتر یا کمتر، توجه متخصصانِ قابل را جلب کنید. با عناوینی مثل «لطفاً به من کمک کنید»، آن را هدر ندهید (پیغام‌هایی با این‌گونه عناوین به راحتی دور انداخته می‌شوند). سعی نکنید با عمق اضطراب خود، افراد با تجربه را تحت تأثیر قرار دهید؛ در عوض، از آن فضا برای یک توصیف بسیار مختصر از مشکل خود استفاده کنید. نامطلوب: کمک! کتابخانه X روی لپ‌تاپ من درست کار نمی‌کند! هوشمندانه: با استفاده از امکانY از کتاب‌خانه X برنامه من کار نمی‌کند! هوشمندانه تر: با استفاده از امکان Y در کتاب‌خانه X نسخه 5.8 برنامه من کرش (Crash) می‌کند. تصور کنید که به یک لیست از سوالات یک آرشیو نگاه می‌کنید، که فقط خطوط عنوان‌ها نمایش داده می‌شوند. عنوان پست خود را طوری انتخاب کنید که بخوبی سوال شما را منعکس کنید، تا شخص بعدی که آرشیو را جستجو می‌کند، بتواند دنبال آن ریسمان (thread) را بگیرد و به یک جواب برسد، بجای اینکه دوباره آن سوال را پست کند. رسیدن یک سوال در یک پاسخ، به خودی خود مورد شک است، چون آن فقط توسط افرادی دیده خواهد شد که این ریسمان را دنبال می‌کنند. پس یک ریسمان (تاپیک) جدید را آغاز کنید، مگر اینکه مطمئنید می‌خواهید فقط از افرادی بپرسید که در حال حاضر در این ریسمان فعال هستند. پاسخ دادن را آسان کنید پایان دادن سوال با این عبارت که «لطفاً پاسخ خو را به ... بفرستید»، جواب گرفتن شما را کاملاً بعید می‌سازد. بصورت واضح، از لحاظ دستوری صحیح، و با املای صحیح بنویسید مهم است که سوال خود را واضح و خوب بیان کنید. قبل از ارسال سوال خود یکبار متن سوالتان را بررسی و سعی خود را بکنید تا زبان (بیان) خود را بهبود دهید (صیقل دهید). لازم نیست که رسمی و سنگین باشد. در واقع افراد با تجربه به آن طرز بیانی بها میدهند که غیر رسمی، عامیانه، شوخ‌طبعانه و همراه با دقت و ظرافت باشد. اما باید دقیق باشد؛ باید نشانه‌هایی از اینکه که شما اندیشه و توجه می‌کنید را داشته باشد. این نکته بسیار مهم است که به زبان رسمی آن کانال ارتباطی سوال خود را ارسال کنید. برای مثال اگر در انجمنی که زبان رسمی آن فارسی است سوال خود را به زبان انگلیسی (یا فینگلیش) بنویسید سوال شما معمولا یا پاک خواهد شد و یا نادیده گرفته می‌شود. اگر دارید سوال خود را در انجمنی می‌پرسید که از زبان بومی شما استفاده نمی‌کند، شما یک میزان محدودی از خطاهای املایی و دستوری خواهید داشت، اما از روی تنبلی دچار خطاهای بیش از حد نشوید (بله، افراد معمولاً می‌توانند آن تفاوت را تشخیص دهند). همینطور اگر نمی‌دانید که شخص پاسخگو چه زبانی دارد، به انگلیسی بنویسید. افراد با‌تجربه مشغول، سوالات با زبانی که نمی‌فهمند را نادیده می‌گیرند، و انگلیسی زبان کاری اینترنت است. با نوشتن به زبان انگلیسی، این احتمال را که سوالتان بدون خوانده شدن پاک شود، به حداقل می‌رسانید. سوال خود را در قالب‌های استاندارد و در دسترس مطرح کنید نامه خود را به صورت پاراگراف‌هایی که از خطوط به هم پیچیده شده تشکیل شده‌اند، نفرستید. این کار، پاسخ گویی به قسمت‌های مختلف نوشته شما را دشوار می‌کند. هرگز تصور نکنید که مخاطبین شما قادر به خواند فایل‌های اختصاصی مانند Microsoft word یا Excel هستند. افراد مختلف از سیستم عامل‌های مختلف و برنامه‌های متفاوتی برای ویرایش متن استفاده می‌کنند پس بهترین گزینه این است که فایل خود را به صورت متنی ارسال کنید. در صفحات گفتگو، از اشکال خندان (Smile) و امکانات HTML استفاده نکنید. یکی دو تا از این اشکال ایرادی ندارد. اما در صورت استفاده بیش از حد. بهای سوال شما را کاهش می‌دهد و احتمال نادیده گرفته شدن سوال شما افزایش پیدا می‌کند. اگر شما از یک پردازش‌گر ایمیل با صورت گرافیکی کاربری مانند MS، Outlook، Netscape، Messenger و یا از این‌گونه‌ها استفاده می‌کنید، آگاه باشید که در صورتی که از تنظیمات پیش‌فرض آن استفاده می‌کنید، ممکن است این قوانین نقض شوند. بیشتر این پردازشگرها دارای یک دستور در فهرست خود به نام view source هستند از این گزینه در پوشه نامه‌های فرستاده خود استفاده کنید و فرستادن نوشته ساده (plain tent) بدون ضمایم غیر ضروری را بررسی کنید. درباره مشکل خود دقیق و آگاه باشید نشانه‌های مشکل ایجاد شده یا bug ها را به دقت و روشنی شرح دهید. محیطی که در آن این مشکل ایجاد می‌شود را شرح دهید. (سیستم عامل، کاربرد و ...) شرکت فروشنده و مدل آنرا هم معرفی کنید مثلاً (Fedora Coret یا Slackware 91 و ...). مطالعاتی که بر روی این مشکل انجام داده‌اید را شرح دهید. مراحل تشخیص مشکل و رفع آنرا که انجام داده‌اید، قبل از طرح سوال، شرح دهید. هرگونه تغییر در سخت‌افزار یا نرم‌افزار که اخیراً انجام شده است را شرح دهید. تلاش کنید تا به سوالاتی که پیش‌بینی می‌کنید از شما پرسیده شوند، پیش‌تر پاسخ دهید. حجم مطالب دلیلی بر دقیق بودن آن نیست باید دقیق و آموزنده بنویسید. این هدف با نوشتن حجم زیادی از داده‌ها و کدها در نامه تقاضای کمک محقق نمی‌شود. اگر یک مشکل بزرگ و پیچیده دارید، سعی کنید تا آنرا تا حد ممکن خلاصه و مرتب ارائه کنید. این امر حداقل سه فایده دارد. اول اینکه معلوم شود که شما برای خلاصه کردن سؤال خود تلاش کرده‌اید یا تمایل بیشتری برای پاسخ به شما وجود خواهد داشت. دوم اینکه با خلاصه‌سازی پاسخ مفیدتری هم خواهید گرفت؛ و سوم اینکه در حین خلاصه کردن و پیرایش گزارش خود ممکن است بتوانید مشکل را حل کنید یا راه حل کوتاه‌تری برای آن پیدا کنید. بدون اطمینان ادعای یافتن یک bug را نکنید! هنگامی که با یک نرم‌افزار به مشکل برخوردید، بدون اطمینان کامل ادعای یافتن یک bug جدید را مطرح نکنید. راهنمایی: تا هنگامی که با یک ضمیمه به کد منبع نتوانید مشکل را برطرف کنید یا با آزمایش رگرسیون با ورژن قبلی که نشان دهنده یک رفتار نادرست باشد، شما نباید مطمئن شوید. این امر در مورد وب سایت‌ها و مدارک هم صدق می‌کند سندی را به عنوان bug یافتید، باید متنی را جایگزین آن کنید یادآوری می‌شود که کاربران بسیاری هستند که مشکل شما را تجربه نکرده‌اند. همچنین شما با خواندن مطالب و وب سایت‌های مرتبط، در مورد آن نرم‌افزار آموزش دیده‌اید در غیر این صورت شما کاری را اشتباه انجام می‌دهید و نه نرم‌افزار. افرادی که یک نرم‌افزار را تهیه می‌کنند، تلاش می‌کنند تا آن نرم‌افزار حداکثر کارایی مطلوب را داشته باشد. اگر شما ادعا کنید که یک bug در آن یافته‌اید، در واقع کامل بودن کار آنها را زیر سؤال برده‌اید و این باعث رنجاندن آنهان می‌شود، حتی اگر حق با شما باشد. به خصوص ذکر کلمه bug در عنوان نامه، کار سیاست مدارانه‌ای نیست. وقتی که سوال خود را مطرح می‌کنید، بهتر است فرض کنید که شما کار اشتباهی را انجام می‌دهید، حتی اگر مطمئن باشید که یک bug واقعی را یافته‌اید. اگر واقعاً این طور باشد، در مورد آن در پاسخ‌ها خواهید شنید. با این کار نگهدارنده‌های نرم‌افزار از شما عذرخواهی خواهند کرد، همچنین اگر شما اشتباه کرده باشید، باید از آنها عذرخواهی کنید. به جای حدس‌های خود نشانه‌های مشکل را شرح دهید نوشتن در مورد اینکه خودتان علت مشکل پیش آمده را چه می‌دانید، مفید نیست (اگر فرضیات شما به‌کلی اشتباه باشد آیا با دیگران مشورت می‌کنید؟). لذا سعی کنید که به دوست‌داران کامپیوتر از علائم و نشانه‌های اولیه مشکل موجود بگویید و نه از فرضیات و تئوری‌های خود. بگذارید آنها خود تفسیر کنند و مشکل را تشخیص دهند اگر احساس می‌کنید که ذکر کردن حدس خودتان می‌تواند مهم باشد، آنرا روشن و تحت عنوان حدس خودتان بیان کنید و همچنین ذکر کنیدن که چرا این پاسخ نمی‌تواند جوابگوی مسئله باشد. هدف را مشخص کنید، نه مرحله اگر به دنبال این هستید که بدانید چطور باید کاری را انجام دهید (مثل گزارش کردن یک اشکال یا bug )، با شرح دادن هدف خود شروع کنید. بعد از آن فقط برخی از مراحل خاص که برای رسیدن به آن طی کردید و موفق نشدید را شرح دهید. اغلب، افرادی که به کمک تکنیکی نیاز دارند، هدف بلند مرتبه‌ای را در ذهن می‌پرورانند و در راهی که فکر می‌کنند تنها راه رسیدن به هدف است گمراه می‌شوند. آنها برای کمک گرفتن مرحله به مرحله می‌آیند اما نمی‌دانند که مسیر اشتباه است تلاش قابل توجهی برای گذر از این مرحله مورد نیاز است. سوال نامطلوب: چگونه می‌توان در برنامه FooDraw مقادیر RGB رنگ را بر مبنای شانزده‌تایی انتخاب کرد؟ سوال هوشمندانه: من تلاش می‌کنم که جدول رنگ‌ها را روی یک تصویر با مقادیر انتخابی خودم قرار دهم. در حال حاضر تنها راهی که به نظرم می‌رسد اینست که هر ردیف از جدول را اصلاح کنم اما نمی‌توانم در برنامه FooDraw رنگ‌ها را بر مبنای مقادیر RGB شانزده‌تایی انتخاب کنم. سوال دوم هوشمندانه بود. جواب این سوال ابزار بهتری برای آن کار را پیشنهاد می‌دهد. سوال را صریح مطرح کنید برای سوال‌هایی که انتهای مشخصی ندارد، بازه زمانی محدودی برای پاسخگویی به آنها در نظر گرفته نمی‌شود. کسانی که می‌خواهند پاسخ‌های مفیدی به شما بدهند، مشغول‌ترین افراد هستند. (چون در اغلب کارها به تنهایی کار می‌کنند). این گونه افراد نسبت به سوال‌هایی با بازه زمانی نامحدود حساسیت دارند و تمایل چندانی به پاسخ‌گویی به آنها ندارند. شما هنگامی که یک پاسخ مفید دریافت می‌کنید که از پاسخگویی خود در مورد چیزی که می‌خواهید به‌طور صریح پرسیده باشید (از اشاره‌گر استفاده کند، که بفرستید، پیوست را بررسی کنید یا هر چیز دیگر). این کار تلاش پاسخگو را بر روی هدف شما متمرکز می‌کند و به طور ضمنی حدی از نظر زمانی برای پاسخگویی و صرف انرژی برای کمک به شما ایجاد می‌کند. این کار خوبی است. برای درک دنیایی که متخصصین در آن زندگی می‌کنند، به مهارت به عنوان یک منبع و زمان فراوان برای پاسخگویی به یک مورد کمیاب فکر کنید. هر چه زمان کمتری را برای پاسخگویی به سوال خود به طور ضمنی در نظر بگیرید، احتمال اینکه جواب واقعاً مناسب از جانب یک فرد خبره و پرمشغله دریافت کنید، بیشتر می‌شود بنابراین بهتر است که برای سوال خود قالبی در نظر بگیرید که زمان مورد نیاز به پاسخگویی به آن را از جانب یک فرد خبره به حداقل برساند. اما این کار اغلب مشابه ساده‌سازی یک سوال نیست. به عنوان مثال، ممکن است برای شرح مناسبی از X یک راهنمایی بکنید؟ معمولاً سوال هوشمندانه‌تری است نسبت به اینکه ممکن است لطفاً X را توضیح دهید! اگر شما یک کد نادرست دارید، بهتر است در مورد اینکه چه اشکالی دارد بپرسید تا اینکه درخواست کنید کسی آنرا اصلاح کند. سوالهای بی‌معنی را حذف کنید از به پایان رساندن درخواست سوال خود با جملات بی‌مفهومی مانند کسی می‌تواند به من کمک کند؟ یا آیا جوابی وجود دارد؟ پرهیز کنید. اولاً، اگر شرح خود را تا نیمه نوشته بودید، این گونه سوال‌ها زائد هستند. دوماً، به دلیل زائد بودن آنها کاربران آنها را آزاردهنده تلقی می‌کنند و احتمال دارد که جواب‌هایی بی عیب و نقص ولی بی اعتنا مانند بله، به شما می‌توان کمک کرد. یا خیر، هیچ کمکی نمی‌توان کرد به شما بدهند. به طور کلی، از سوالهای آری یا خیر باید اجتناب شود مگر اینکه تنها جواب بله یا خیر برای شما کافی باشد. سوال خود را با کلمه «فوری» نشانه‌دار نکنید، حتی اگر برای شما اینگونه باشد: این مشکل شماست، نه دیگران. اظهار ضرورت کردن نتیجه معکوس می‌دهد. بیشتر کاربران به راحتی اینگونه سوال‌ها را که با خودخواهی و گستاخی درخواست توجه فوری و ویژه می‌کنند را حذف می‌کنند. تنها یک شبه استثناء وجود دارد. اگر شما در یک محل با مرتبه بالا و با یک نرم‌افزار کار می‌کنید و از نظر زمانی تحت فشار هستید، گفتن مودبانه محدودیت زمانی خود می‌تواند مؤثر باشد تا دیگران را به پاسخ دادن به شما ترغیب کند. البته این کار ریسک بالایی دارد، چون معیار جالب بودن مسائل از نظر کاربران دیگر با شما متفاوت است. به عنوان مثال فرستادن نامه از یک ایستگاه فضایی بین‌المللی قانع کننده است اما از جانب یک انسان با احساس خوب و مهربان یا یک سیاستمدار خیر. در واقع، نوشتن کلمه «فوری» باعث می‌شود که از سوال شما اجتناب و دوری شود حتی اگر از نظر آنها مهم باشد. اگر فکر می‌کنید که این امری مبهم است، دوباره این مطالب را بخوانید تا کاملاً آنرا درک کنید، قبل از آنکه نوشته‌ای را به جایی بفرستید. ادب و احترام را رعایت کنید مؤدب باشید. از جملاتی مانند «لطفاً» و «با تشکر از توجه شما» یا «ممنون از ملاحظه شما» استفاده کنید. به طور واضح بیان کنید که شما اینکه دیگران وقت خود را برای کمک به شما رایگان صرف می‌کنند، تحسین کنید. صادق بودن، به اندازه واضح، دقیق، با دستور زبان صحیح و مشروح بودن و پرهیز از قالب‌های مالکانه، مهم نیست و حتی جایگزین آنها هم نمی‌تواند باشد. کاربران بطور کلی علاقه دارند که گزارش‌های دقیق تکنیکی از bug ها و ایرادها را هر چند بی ادبانه دریافت کنند تا نوشته‌های مؤدب ولی ابهام‌آمیز. (اگر این امر برای شما مبهم است، به یاد داشته باشید که سوال‌ها را با چیزی که توسط آن می‌توان یاد گرفت ارزش‌گذاری می‌کنند). به هر حال اگر مشکلات تکنیکی خود را ردیف کنید، مؤدب بودن شانس شما را برای دریافت پاسخ مفید افزایش می‌دهد. باید ذکر شود که تنها مخالفتی که از سوی کاربران قدیمی نسبت به این نوشته دریافت کرده‌ایم، در رابطه با توصیه‌های قبلی ما برای تشکر پیشاپیش است. برخی از کاربران احساس می‌کنند که این دلالتی به منظوری دارد و نه تشکر. توصیه ما اینست که هم پیشاپیش تشکر کنید و هم بعد از پاسخ‌گویی و یا ادب و احترام را به روشهای دیگری بیان کنید قبلاً با جملاتی مثل: «با تشکر از توجه شما» یا «ممنون از ملاحظه شما». روش حل را با یادداشت مختصری پاسخ دهید بعد از اینکه مسئله حل شد، یادداشتی به همه کسانی که به شما کمک کرده‌اند بفرستید، آنها را از نحوه‌ی حل مطلع کنید؛ و باز هم از یاری آنها تشکر کنید. پاسخ شما نباید طولانی و شامل جملاتی ساده مثل: «ایراد از کابل شبکه بود، با تشکر از همه» باشد. حتی اگر پاسخ ندهید، بهتر از این جملات است. پاسخ کوتاه و خلاصه‌ای شیرین بهتر است از یک مقاله طولانی مگر اینکه عمق تکنیکی مسئله زیاد باشد. ذکر کنید که چه عملی مشکل را حل کرد اما لزومی ندارد که تمام مراحل حل مشکل را گزارش کنید. برای برخی از مسائل مناسب است که خلاصه‌ای از مراحل رفع مشکل را گزارش کنید. وضعیت نهایی مسئله خود را شرح دهید. توضیح دهید که چه روشی شما را به حل رساند و بعد از آن به داده‌هایی که جواب نمی‌رسد اشاره کنید. روشهای اشتباه را باید بعد از جواب صحیح و دیگر مطالب خلاصه بیاورید تا اینکه خلاصه شما تبدیل به یک داستان کارآگاهی نشود. از افرادی که به شما کمک کردند نام ببرید، با این کار با آنها دوست هم می‌شوید. در نهایت، این گونه خلاصه نویسی به تمام کسانی که کمک کرده‌اند، احساس رضایت‌مندی و نزدیکی به مسئله می‌دهد و این کم ارزش نیست. اگر شما یک تکنسین یا فرد باتجربه نیستید، مطمئن باشید که این احساس برای راهنماها و متخصصینی که از آنها کمک گرفته‌اید، بسیار مهم است. اگر نفهمیدید... اگر جواب را نفهمیدید، فوراً تقاضای روشن کردن پاسخ نکنید. از همان اندازه‎هایی که برای پاسخ اولیه خودتان (دستورالعمل‎ها ( FAQS)، وب و دوستان ماهر) برای فهمیدن جواب استفاده کنید. سپس اگر باز هم نیاز به شفاف سازی نشان دهید که چه چیزی یادگرفته‎اید. برای مثال تصور کنید که من به شما می‎گویم: "به‎نظر می‎رسد که شما Zentry گرفته شده‎ای دارید، باید آنرا تمیز کنید." در این صورت یک جواب نامناسب این خواهد بود: « Zentry چیست؟» و یک جواب خوب این خواهد بود "بسیار خوب، من صفحه اصلی را خواندم و به Zentry ها تحت عنوان سوئیچ‎های –Z و –P اشاره شده است اما هیچ یک از تمیز کردن Zentry چیزی نگفته‎اند. آیا اینها درست است یا من نکته‎ای را متوجه نشده‎ام؟" اخلاق حرفه ای داشته باشید با توجه به راه‎های مفصلی که در این‎جا گفته شد یا راه‎های مشابه بعید است که در راه‌های ارتباطی با افراد باتجربه اشتباه کنید. به‎طور دقیقی با جملات متفاوت به شما گفتیم که چگونه می‎توان اشتباه کرد. اگر چنین اتفاقی افتاد بدترین کار اینست که از این تجربه خود ناله کنید، ادعا کنید که شفاهاً مورد توهین قرار گرفته‎اید، تقاضای عذرخواهی کنید، نقستان را حبس کنید، به شکایت کردن تهدید کنید، از افراد شکایت کنید و غیره. در عوض پیش بروید. این امری طبیعی است. درواقع مناسب و سالم است. گاهی اوقات افراد بدون هیچ دلیل روشنی شخصاً شما را مورد حمله قرار می‎دهند حتی اگر شما اشتباهی نکرده باشید (یا فقط در ذهن آنها دچار اشتباه شده‎اید) در این موارد، شکایت کردن روشی واقعاً اشتباه است. این افرادِ متجاوز، نادان هم هستند که بدون هیچ دلیلی، خود را با تجربه می‎دانند یا با آزمایش‎های روان‎شناسی می‎خواهند بدانند که اشتباه کرده‎اید یا خیر. خوانندگان دیگر هم آنها را نادیده می‎گیرند و یا با روش خودشان با آنها برخورد می‎کنند رفتار این‎گونه افراد خود آنها را دچار مشکل می‎کند که به شما ربطی ندارد. اجازه ندهید که داخل این‎گونه بحث‎ها به دام بیفتید. بعد از اینکه بررسی کردید که آیا آنها واقعاً توهین هستند و نه اشاره‎ای به اشتباه شما و نه اشاره‎ای به اشتباه شما و نه اشاره‎ای زیرکانه به جواب واقعی سوال شما اغلب توهین‎ها نادیده گرفته می‎شوند. به اطلاعات موجود در فایل های ارسالی و ضمیمه توجه کنید در بسیاری از مواقع ممکن است سوال شما همراه با فایل (یا فایل های) ضمیمه‌ای باشد که مشکل را دقیق‌تر به پاسخ دهند‌گان شرح میدهد. حتما قبل از ارسال فایل ضمیمه به موارد زیر توجه کنید: فایل ارسالی حاوی اطلاعات شخصی افراد نباشد. این موارد حریم شخصی افراد را نقض میکند و ممنوع میباشد. در صورتی که سوال شما مربوط به نحوه‌ی نمایش آن اطلاعات است میتوانید با ابزار ویرایش تصویر یا فایل، اطلاعات شخصی را حذف کنید.
×
×
  • جدید...