آناتومی یک گزارش خطای خوب
نویسنده: وحید نصیری
تاریخ: ۱۳۹۲/۰۶/۲۴ ۲۲:۰
آدرس: www.dntips.ir
| مطالب | ۳۶۹۴ |
| نویسندگان | ۲۷۶ |
| گروههای مطالب | ۱۰۲۴ |
| نقشههای راه | ۱۱۹ |
| دورهها | ۱۴ |
| اشتراکها | ۱۷۹۱۴ |
به مشکلی در برنامهای برخوردهاید؟ کتابخانهای کار نمیکند؟ خطایی را دریافت کردهاید؟ برنامه کامپایل نمیشود؟ برنامه آنطور که مدنظر شما است رفتار نمیکند؟ برای طرح این مسایل، صرف عنوان کردن «برنامه کار نمیکنه» یا «خطا میده» منزلت خودتان را تا حد یک کاربر عادی تازه کار تنزل دادهاید. در ادامه ساختار یک گزارش خطای خوب را بررسی خواهیم کرد، تا شما را سریعتر به مقصودتان برساند و همچنین کار پیگیری برنامه نویس یا برنامه نویسهای مسئول را نیز مقداری سادهتر کند.
کارهای لازم پیش از طرح سؤال
- سعی کنید انجمنهای مرتبط را یکبار بررسی و جستجو کنید.
- عین خطای دریافتی را در گوگل جستجو کنید. اگر از برنامهها یا کتابخانههای معروف و متداول استفاده میکنید، یکی از مزیتهای مهم کار با آنها، «تنها نبودن» است! یقین داشته باشید خطایی را که دریافت کردهاید پیشتر توسط دهها نفر دیگر در سایتهای مختلف مطرح شدهاند و بالاخره با بررسی آنها میتوان به پاسخ رسید.
- شاید راهنمای برنامه در این مورد خاص مطلبی را عنوان کرده است.
و ... به صورت خلاصه باید بتوانید به این سؤال پاسخ دهید: «خودت چکار کردی؟». حداقل نشان دهید که فرد حاضر و آماده طلبی نیستید و پیشتر یک حداقل تقلایی را انجام دادهاید.
کجا باید سؤال پرسید؟
- اگر به انجمنی برای طرح سؤال خود مراجعه کردهاید، حتما زیر شاخه صحیحی را انتخاب کنید تا سؤال شما بسته نشود یا کلا حذف نگردد. برای مثال سؤال ASP.NET را در بخش سیشارپ نپرسید یا برعکس یا اگر سایتی مقالهای را منتشر کرده، ذیل آن در مورد نحوه بک آپ گرفتن از اکانت توئیتر خود سؤال نپرسید!
- اگر پاسخی را دریافت کردید، ادامه بحث را ذیل همان مطلب پیگیری کنید و مجددا مطلب جدیدی را ایجاد نکنید.
- اگر تا نیم ساعت بعد جوابی را دریافت نکردید، کل بخشهای یک سایت را با ارسال پیام خود اسپم نکنید. یکبار ارسال یک سؤال کافی است. اکثر این سایتها حالت یک «چت آفلاین» را دارند. به این معنا که ابتدا پیغام خود را میگذارید، اگر مدتی بعد (ممکن است چند ساعت بعد) شخصی آنرا مشاهده کرد و قادر به پاسخ دهی بود، به شما کمک خواهد کرد. بنابراین اگر سریعا به جواب نرسیدید، نه کل سایت را اسپم کنید و نه ... شروع به رفتارهای ناشایست کنید. اینکار با فریاد کشیدن وسط یک جمع تفاوتی ندارد. اشخاص مرتبط همواره آنلاین نیستند؛ ضمنا ممکن است واقعا پاسخی برای یک سؤال نداشته باشند. منصف باشید.
- از ایمیلهای خصوصی افراد یا قسمت پیامهای خصوصی سایتها برای ارسال سؤالات شخصی استفاده نکنید. ایمیل خصوصی، مخصوص کارهای شخصی است. قسمت پیامهای خصوصی یک سایت عموما مخصوص رسیدگی به مشکلات کاربری است. این تصور را نداشته باشید که اشخاص مشاور شخصی رایگان پروژههای تجاری شما هستند.
- بهترین محل برای پرسیدن سؤالات مرتبط با یک پروژه خاص، mailing list یا انجمن گفتگو و یا issue tracker آن پروژه است. وقت خودتان را با ارسال خطاهای یک پروژه خاص، در یک انجمن عمومی و همه منظوره تلف نکنید. کمی جستجو کنید که سایت اصلی پروژه کجا است. بعد دقت کنید آیا جایی برای پرسش و پاسخ دارد یا خیر. اکثر پروژههای خوب، مکانی را جهت جمع آوری بازخوردهای پروژه خود، اختصاص میدهند.
چطور باید سؤال پرسید؟
سؤال فنی خوب پرسیدن هم یک هنر است؛ که تعدادی از مشخصههای مهم آنرا در ذیل مرور خواهیم کرد:
- عنوان مناسبی را برای سؤال خود انتخاب کنید. «لطفا کمک کنید» یا «من مشکل دارم» یا «مشکل در پروژه»، عموما واکنشهای تندی را به همراه دارند؛ و تا حد ارسال اسپم در یک سایت بیکیفیت تلقی میشوند. ضمن اینکه انتخاب عنوانهای مناسب، جستجوهای بعدی را در سایت ساده میکنند و کمک بزرگی خواهند بود به افراد بعدی.
- محیطی را که خطا در آن رخ داده است، توضیح دهید. ذکر IIS تنها کافی نیست. کدام نگارش آن؟ در کدام ویندوز؟
برای مثال شماره نگارش کتابخانه یا نرم افزار مورد استفاده را ذکر کنید. شاید خطایی که گرفتهاید در نگارش بعدی آن برطرف شده است.
ذکر شماره نگارش VS.NET یا شماره نگارش دات نت مورد استفاده، سیستم عامل و کلا توصیف محیط بروز خطا، عموما بسیار مفید هستند.
- حتما کل خطای دریافت شده را ارسال کنید. اگر در یک برنامه C خطایی حاصل شود، احتمالا شکلی مانند Error 0xABCD را دارد. اما استثناءهای دات نت به همراه stack trace و حتی شماره سطر خطای حاصل نیز هستند. همین مساله میتواند به خطایابی نهایی بسیار کمک کند.
- سؤال خود را طوری مطرح کنید که شخص مقابل بتواند آنرا در کمترین زمان ممکن «باز تولید» کند. برای مثال ذکر خطای دریافتی بسیار خوب است. اگر دادهای که سبب بروز این خطا شده است را هم ارسال کنید، مفیدتر خواهد بود؛ یا اگر دستور پاور شل خاصی در کنسول نیوگت خطا میدهد، صرفا عنوان نکنید که جواب نگرفتهاید. چه دستوری را اجرا کردهاید؟ چه خطایی را دریافت کردهاید؟ ساختار پروژه شما چیست؟ آیا شخص مقابل میتواند بر اساس اطلاعاتی که ارائه دادید یک آزمایش شخصی را تدارک ببیند؟ آیا میتواند آنرا با توضیحات شما مجددا تولید کند؟
زمان باز تولید خطا را هم مدنظر داشته باشید. برای مثال اگر بتوانید قطعه کدی را ارائه دهید که در کمترین زمان ممکن، صرفا با کپی و پیست آن در VS.NET قابل کامپایل باشد، بسیاری علاقمند به پاسخگویی به شما خواهند شد. در غیراینصورت آنچنان انتظار نداشته باشید که شخص پاسخ دهنده وقت زیادی را برای رسیدگی به جزئیات سؤال شما صرف کند؛ یا مدتی مشغول به تهیه یک مثال جدید بر مبنای توضیحات شما شود.
حجم کدهای ارسالی شما نیز در اینجا مهم هستند. کل پروژه خود را ارسال نکنید! سعی کنید یک مثال کوچک را که بتواند سریعا خطای مدنظر شما را بازتولید کند، ارسال کنید و نه بیشتر. همچنین کدهایی که برای اجرا نیاز به GUI نداشته باشند نیز در این حالت اولویت دارند.
و به صورت خلاصه، خودتان را بجای پاسخ دهنده قرار دهید. آیا با چند جملهای که ارائه دادهاید، میتوان انتظار پاسخی را داشت یا خیر.
- ایمیل شخصی خود را در انتهای پیام ارسال نکنید. کسی اهمیتی نمیدهد! اگر سؤال شما پاسخی داشته باشد، همانجا دریافت خواهید کرد و نه در میل باکس شخصی.
- املاء و انشای متنی را که ارسال میکنید، یکبار بررسی کنید. اگر برای شما اهمیتی ندارد که چه کلمات و جمله بندی را باید بکار برد، برای شخص مقابل هم آنچنان اهمیتی نخواهد داشت که زیاد وقت صرف کند.
- از بکار بردن smileyهای بیش از حد یا قرار دادن تعداد علامت تعجبهای بیش از حد خودداری کنید. این موارد عموما به مسخره کردن شخص مقابل تفسیر میشوند.
- در بدو امر فریاد نکشید که «باگ» پیدا کردهاید؛ خصوصا اگر به mailing list اختصاصی یک پروژه پیامی را ارسال میکنید. چون اگر مشکل شما واقعا باگ نباشد، بیشتر یک توهین تلقی خواهد شد و در دفعات بعدی پاسخ دادن به شما به صورت ضمنی مؤثر خواهند بود؛ یا جواب نمیگیرید و یا جدی گرفته نخواهید شد.
- هدف از کاری را که مشغول به انجام آن بودهاید را نیز ذکر کنید. ذکر خطای دریافتی بسیار مفید است اما اگر بتوانید یک دید کلی را نسبت به کاری که مشغول به آن بودهاید، ایجاد کنید، شاید پاسخ بهتری را دریافت کنید. برای مثال جهت رسیدن به هدف و مقصود شما بهتر است از روش دیگری استفاده کنید.
- پس از اینکه پیامی را دریافت کردید، یک حداقل واکنشی را ارسال کنید. مثلا خوب بود؛ کمک کرد و یا مفید نبود. همین واکنشها در آینده به کمک نتایج جستجوهای انجام شده خواهند آمد و اشخاص بعدی حداقل خواهند دانست که پاسخ داده شده صحیح بوده است یا خیر.
و همیشه بخاطر داشته باشید: تمام خدماتی که سایتهای عمومی به شما ارائه میدهند «یک لطف» است و حقی را برای شما ایجاد نمیکنند. این اشخاص از شما پول نمیگیرند تا به سؤالات شما پاسخ دهند یا تبدیل به مشاور خصوصی رایگان شما شوند. میتوانید محیط را برای این اشخاص، با اندکی احترام، ملایمت و انصاف، دلپذیرتر کنید.
کارهای لازم پیش از طرح سؤال
- سعی کنید انجمنهای مرتبط را یکبار بررسی و جستجو کنید.
- عین خطای دریافتی را در گوگل جستجو کنید. اگر از برنامهها یا کتابخانههای معروف و متداول استفاده میکنید، یکی از مزیتهای مهم کار با آنها، «تنها نبودن» است! یقین داشته باشید خطایی را که دریافت کردهاید پیشتر توسط دهها نفر دیگر در سایتهای مختلف مطرح شدهاند و بالاخره با بررسی آنها میتوان به پاسخ رسید.
- شاید راهنمای برنامه در این مورد خاص مطلبی را عنوان کرده است.
و ... به صورت خلاصه باید بتوانید به این سؤال پاسخ دهید: «خودت چکار کردی؟». حداقل نشان دهید که فرد حاضر و آماده طلبی نیستید و پیشتر یک حداقل تقلایی را انجام دادهاید.
کجا باید سؤال پرسید؟
- اگر به انجمنی برای طرح سؤال خود مراجعه کردهاید، حتما زیر شاخه صحیحی را انتخاب کنید تا سؤال شما بسته نشود یا کلا حذف نگردد. برای مثال سؤال ASP.NET را در بخش سیشارپ نپرسید یا برعکس یا اگر سایتی مقالهای را منتشر کرده، ذیل آن در مورد نحوه بک آپ گرفتن از اکانت توئیتر خود سؤال نپرسید!
- اگر پاسخی را دریافت کردید، ادامه بحث را ذیل همان مطلب پیگیری کنید و مجددا مطلب جدیدی را ایجاد نکنید.
- اگر تا نیم ساعت بعد جوابی را دریافت نکردید، کل بخشهای یک سایت را با ارسال پیام خود اسپم نکنید. یکبار ارسال یک سؤال کافی است. اکثر این سایتها حالت یک «چت آفلاین» را دارند. به این معنا که ابتدا پیغام خود را میگذارید، اگر مدتی بعد (ممکن است چند ساعت بعد) شخصی آنرا مشاهده کرد و قادر به پاسخ دهی بود، به شما کمک خواهد کرد. بنابراین اگر سریعا به جواب نرسیدید، نه کل سایت را اسپم کنید و نه ... شروع به رفتارهای ناشایست کنید. اینکار با فریاد کشیدن وسط یک جمع تفاوتی ندارد. اشخاص مرتبط همواره آنلاین نیستند؛ ضمنا ممکن است واقعا پاسخی برای یک سؤال نداشته باشند. منصف باشید.
- از ایمیلهای خصوصی افراد یا قسمت پیامهای خصوصی سایتها برای ارسال سؤالات شخصی استفاده نکنید. ایمیل خصوصی، مخصوص کارهای شخصی است. قسمت پیامهای خصوصی یک سایت عموما مخصوص رسیدگی به مشکلات کاربری است. این تصور را نداشته باشید که اشخاص مشاور شخصی رایگان پروژههای تجاری شما هستند.
- بهترین محل برای پرسیدن سؤالات مرتبط با یک پروژه خاص، mailing list یا انجمن گفتگو و یا issue tracker آن پروژه است. وقت خودتان را با ارسال خطاهای یک پروژه خاص، در یک انجمن عمومی و همه منظوره تلف نکنید. کمی جستجو کنید که سایت اصلی پروژه کجا است. بعد دقت کنید آیا جایی برای پرسش و پاسخ دارد یا خیر. اکثر پروژههای خوب، مکانی را جهت جمع آوری بازخوردهای پروژه خود، اختصاص میدهند.
چطور باید سؤال پرسید؟
سؤال فنی خوب پرسیدن هم یک هنر است؛ که تعدادی از مشخصههای مهم آنرا در ذیل مرور خواهیم کرد:
- عنوان مناسبی را برای سؤال خود انتخاب کنید. «لطفا کمک کنید» یا «من مشکل دارم» یا «مشکل در پروژه»، عموما واکنشهای تندی را به همراه دارند؛ و تا حد ارسال اسپم در یک سایت بیکیفیت تلقی میشوند. ضمن اینکه انتخاب عنوانهای مناسب، جستجوهای بعدی را در سایت ساده میکنند و کمک بزرگی خواهند بود به افراد بعدی.
- محیطی را که خطا در آن رخ داده است، توضیح دهید. ذکر IIS تنها کافی نیست. کدام نگارش آن؟ در کدام ویندوز؟
برای مثال شماره نگارش کتابخانه یا نرم افزار مورد استفاده را ذکر کنید. شاید خطایی که گرفتهاید در نگارش بعدی آن برطرف شده است.
ذکر شماره نگارش VS.NET یا شماره نگارش دات نت مورد استفاده، سیستم عامل و کلا توصیف محیط بروز خطا، عموما بسیار مفید هستند.
- حتما کل خطای دریافت شده را ارسال کنید. اگر در یک برنامه C خطایی حاصل شود، احتمالا شکلی مانند Error 0xABCD را دارد. اما استثناءهای دات نت به همراه stack trace و حتی شماره سطر خطای حاصل نیز هستند. همین مساله میتواند به خطایابی نهایی بسیار کمک کند.
- سؤال خود را طوری مطرح کنید که شخص مقابل بتواند آنرا در کمترین زمان ممکن «باز تولید» کند. برای مثال ذکر خطای دریافتی بسیار خوب است. اگر دادهای که سبب بروز این خطا شده است را هم ارسال کنید، مفیدتر خواهد بود؛ یا اگر دستور پاور شل خاصی در کنسول نیوگت خطا میدهد، صرفا عنوان نکنید که جواب نگرفتهاید. چه دستوری را اجرا کردهاید؟ چه خطایی را دریافت کردهاید؟ ساختار پروژه شما چیست؟ آیا شخص مقابل میتواند بر اساس اطلاعاتی که ارائه دادید یک آزمایش شخصی را تدارک ببیند؟ آیا میتواند آنرا با توضیحات شما مجددا تولید کند؟
زمان باز تولید خطا را هم مدنظر داشته باشید. برای مثال اگر بتوانید قطعه کدی را ارائه دهید که در کمترین زمان ممکن، صرفا با کپی و پیست آن در VS.NET قابل کامپایل باشد، بسیاری علاقمند به پاسخگویی به شما خواهند شد. در غیراینصورت آنچنان انتظار نداشته باشید که شخص پاسخ دهنده وقت زیادی را برای رسیدگی به جزئیات سؤال شما صرف کند؛ یا مدتی مشغول به تهیه یک مثال جدید بر مبنای توضیحات شما شود.
حجم کدهای ارسالی شما نیز در اینجا مهم هستند. کل پروژه خود را ارسال نکنید! سعی کنید یک مثال کوچک را که بتواند سریعا خطای مدنظر شما را بازتولید کند، ارسال کنید و نه بیشتر. همچنین کدهایی که برای اجرا نیاز به GUI نداشته باشند نیز در این حالت اولویت دارند.
و به صورت خلاصه، خودتان را بجای پاسخ دهنده قرار دهید. آیا با چند جملهای که ارائه دادهاید، میتوان انتظار پاسخی را داشت یا خیر.
- ایمیل شخصی خود را در انتهای پیام ارسال نکنید. کسی اهمیتی نمیدهد! اگر سؤال شما پاسخی داشته باشد، همانجا دریافت خواهید کرد و نه در میل باکس شخصی.
- املاء و انشای متنی را که ارسال میکنید، یکبار بررسی کنید. اگر برای شما اهمیتی ندارد که چه کلمات و جمله بندی را باید بکار برد، برای شخص مقابل هم آنچنان اهمیتی نخواهد داشت که زیاد وقت صرف کند.
- از بکار بردن smileyهای بیش از حد یا قرار دادن تعداد علامت تعجبهای بیش از حد خودداری کنید. این موارد عموما به مسخره کردن شخص مقابل تفسیر میشوند.
- در بدو امر فریاد نکشید که «باگ» پیدا کردهاید؛ خصوصا اگر به mailing list اختصاصی یک پروژه پیامی را ارسال میکنید. چون اگر مشکل شما واقعا باگ نباشد، بیشتر یک توهین تلقی خواهد شد و در دفعات بعدی پاسخ دادن به شما به صورت ضمنی مؤثر خواهند بود؛ یا جواب نمیگیرید و یا جدی گرفته نخواهید شد.
- هدف از کاری را که مشغول به انجام آن بودهاید را نیز ذکر کنید. ذکر خطای دریافتی بسیار مفید است اما اگر بتوانید یک دید کلی را نسبت به کاری که مشغول به آن بودهاید، ایجاد کنید، شاید پاسخ بهتری را دریافت کنید. برای مثال جهت رسیدن به هدف و مقصود شما بهتر است از روش دیگری استفاده کنید.
- پس از اینکه پیامی را دریافت کردید، یک حداقل واکنشی را ارسال کنید. مثلا خوب بود؛ کمک کرد و یا مفید نبود. همین واکنشها در آینده به کمک نتایج جستجوهای انجام شده خواهند آمد و اشخاص بعدی حداقل خواهند دانست که پاسخ داده شده صحیح بوده است یا خیر.
و همیشه بخاطر داشته باشید: تمام خدماتی که سایتهای عمومی به شما ارائه میدهند «یک لطف» است و حقی را برای شما ایجاد نمیکنند. این اشخاص از شما پول نمیگیرند تا به سؤالات شما پاسخ دهند یا تبدیل به مشاور خصوصی رایگان شما شوند. میتوانید محیط را برای این اشخاص، با اندکی احترام، ملایمت و انصاف، دلپذیرتر کنید.
مطالب مشابه
-
مطالبچطور باید یک پروژه سورس باز را خوب مدیریت کرد؟مطالبنکاتی در مورد نوشتن یک مطلب خوب و گیرا در یک سایتمطالبNHibernate و سطح اول cache آنمطالبهزینه استفاده از دات نت فریم ورک چقدر است؟مطالبهزینه استفاده از دات نت فریم ورک چقدر است؟مطالبروش نصب اندروید 10 بر روی گوشیهای قدیمی سامسونگمطالبچالشهای متداول توسعهدهندگان ASP.NET Core هنگام استفاده از Nginx - قسمت اول - راهاندازی اولیه و مشکلات پیکربندیمطالب دورههاطراحی روابط و ارجاعات در RavenDBنظرات اشتراکهاراهنمای مهندسی پرامپت برای برنامهنویساننظرات مطالبمعرفی کتابخانه PdfReport
نظرات
- محسن جمشیدی در ۱۳۹۲/۰۶/۲۵ ۸:۳۰درود بر جناب نصیری عزیز
با تک تک جملاتتون موافقم و نمونه بارزی از عدم رعایت نکاتی که اشاره کردین سایت برنامه نویس هست با یک نگاه به بخش سی شارپ میتونید تمام این مواردی رو که اشاره کردین مشاهده کنید. بعد از چند سال نتونستیم جا بندازیم که دوستان عنوان مناسب برای تاپیک خودتون انتخاب کنید در شرح اون به بطور کامل به تشریح مسئله بپردازید اما دریغ از یک اثر مثبت.
یکی از مواردی هم که میشه بهش اشاره کرد نوع ادبیات و بیان احساسات هست
- استادمون گیر داده میگه...
- آقا من یه مشکل دارم
- داداش مثله اینکه نمیفهمی چی میگم
اما اینجا جای تشکر داره از افرادی که "مثلا در سایت StackOverFlow" با مدیریت خودشون (حذف یا ویرایش سوالات) باعث میشن که سوالات بی مورد و تکراری کمتر بشن و ما با یک جستجوی ساده بتونیم به جواب برسیم - مهمان در ۱۳۹۲/۰۶/۲۵ ۱۱:۱۴خیلی خوب بود، ازش پرینت کردم و به دیوار شرکت چسبوندم، کاش فقط توش مینوشتید اول به مدیر شرکت مراجعه نکنند!
- میثم ثوامری در ۱۳۹۲/۰۶/۲۸ ۹:۱با سلام خدمت آقای نصیری
معمولا زمانی که مشکلی برام پیش میاد میرم سراغ StackOverFlow.
من معمولا با پرسیدن سوال تو این وبسایت مشکل دارم البته اونم به لحاظ ضعیف بودن زبان انگلیسی بنده است.یک استاندارد برای پرسیدن سوال وجود داره و به تازگی قبل از پرسیدن سوال کلی توضیح و راهنمایی نمایش داده میشه
How to resolve errors with unsafe pointer in C#?
سوال بالا آخرین موضوعی بود که چندی پیش پرسیدم.کلی امتیاز منفی بهمراه داشت و در انتها سوالم Close شد.
- حمیدرضا م در ۱۳۹۲/۱۱/۲۴ ۱۷:۱۴سلام،
برای دوستانی که انگلیسیشون زیاد خوب نیست (مثل خودم) و کلا با انگلیسی مشکل دارن، جهت سرچ در گوگل روش زیر پیشنهاد میگردد.
معمولا بهتره توی گوگل مشکلتون رو اینطوری سرچ کنین :
مثال:how to <doing problem> in <your programming language>
این روش هم خوبه :how to convert int to string in c#
دو روش فوق معمولا در 90% موارد جواب میده.<programming language> how <problem>
نکته دوم اینه که اگر توی نتیجه سرچ لینکی از سایت StackOverFlow دیدین ، اول بهتره اون لینک رو باز کنین.
چون معمولا این سایت بصورت سوال و جوابه و سریع با دیدن کدهای نمونه ای که در پاسخها موجوده مشکلتون حل میشه و معمولا اصلا نیاز نیست متون انگلیسی رو بخونین.
مخصوصا که برای هر پاسخ یک امتیاز وجود داره که با بررسی امتیاز هر پاسخ میتوان تا حدودی به درست بودن و بهینه بودن راه حل پی برد (این مورد حدودی است)
البته سایت codeProject هم خوب است ولی تا جایی که من میدونم بصورت مقاله ای است و باید کلی توضیح و مثال و ... رو بررسی کنین تا به جواب سوالتون برسین که یکم وقت گیر تره ...
نکته بعدی: بد نیست برخی مشکلات رو بصورت فارسی هم سرچ بگیرین ، در برخی موارد مطلب فارسی هم در مورد برخی خطاها پیدا میشه (معمولا فارسی زبونا زیاد مقاله درباره خطاها نمینویسن و بیشتر تکنولوژی رو آموزش میدن ...)
{البته همه دوستان حرفه ای هستند ، به جهت دوستانی که مثل خودم زیاد با انگلیسی میونه خوبی ندارند عرض کردم}
ضمنا در تکمیل مقاله آقای نصیری باید ذکر کنم که :
*همیشه به خاطر داشته باشید که هیچکس علمشو مجانی بدست نیاورده که مجانی در اختیار شما قرار بده !
پس اگر کسی داره مقاله منتشر میکنه یا جواب سوالتونو میده ، داره به شما لطف میکنه...
پس سعی کنین همیشه ازش تشکر کنین و بهش احترام بذارین تا بیشتر تشویق بشه که مطالب بیشتری بذاره ... (به نظر من دست کسی که مجانی داره بهت چیز یاد میده ، باید بوسید؛ چون در حقیقت وقت و انرژی و علمشو داره به شما هدیه میکنه که خیلی ارزشمنده)
*نوشتن کامنت هایی که دانش نفر رو زیر سوال ببره ، مثلا "این روش که دیگه خدا بیامرز شده ، الان هر برنامه نویس حرفه ای از فلان روش استفاده میکنه" خیلی بده و نفر رو نا امید میکنه.
*لحن گفتن یک سوال یا بیان یک کامنت خیلی خیلی مهمه.
مثلا همین مقال بالا رو میشه بدین صورت هم گفت : "در تکمیل مقاله جناب X باید ذکر نمایم که روش Y نیز بسیار جالب میباشد و دارای کد نویسی بهتری است" و حتی یک لینک آموزشی خوب هم درباره روش جدید ارائه دهیم.
(اینطوری هر دو طرف سود میکنن)
همین!
موفق باشید. - حمیدرضا م در ۱۳۹۲/۱۱/۲۴ ۱۷:۱۷خداییش اینو خوب اومدی:
"- ایمیل شخصی خود را در انتهای پیام ارسال نکنید. کسی اهمیتی نمیدهد! اگر سؤال شما پاسخی داشته باشد، همانجا دریافت خواهید کرد و نه در میل باکس شخصی. "
در بسیاری از سایتها نفر سوال میکنه و میگه : لطفا جواب را به ایمیل بنده ارسال فرمایید : X@Y.Com
یا
فلان فایل رو نتونستم دانلود کنم ، لطفا به ایمیلم ارسالش کنین !
آدم میمونه بهش چی بگه !
یا حق - وحید نصیری در ۱۳۹۶/۰۸/۱۸ ۱۰:۵۷یک نکتهی تکمیلی: چگونه پرسشهای مطرح شدهی در GitHub را بر اساس قالب خاصی درخواست کنیم؟
تصور اینکه تمام پرسش کنندگان در حین طرح سؤالی، نکات مطلب جاری را رعایت کنند، بیهوده است. به همین جهت میتوان با ارائهی قالبهایی از پیش تعیین شده، آنها را مقید به پر کردن جاهای خالی کنیم. برای این منظور در GitHub
- در صفحهی اول پروژه، بر روی دکمهی ایجاد یک فایل جدید کلیک کنید:
- سپس نام فایل را دقیقا معادل github/issue_template.md. وارد کنید (این نام ویژه توسط GitHub شناسایی میشود).
- در ادامه محتوای آنرا به چیزی مانند متن ذیل تنظیم تنظیم کنید:
- در پایان، بر روی دکمهی ذخیرهی فایل جدید کلیک کنید.# Summary of the issue ## Environment ``` The in-use version: Operating system: IDE: (e.g. Visual Studio 2015) ``` ## Example code/Steps to reproduce: ``` paste your core code ``` ## Output: ``` Exception message: Full Stack trace: ```
اکنون با کلیک بر روی دکمهی new issue، این قالب از پیش تعیین شده جهت تکمیل جاهای خالی آن نمایش داده میشود و میتواند راهنمایی برای پرسش کنندگان باشد.