https://virgool.io/ap-sharif/feed تجربه ها و خاطرات ارائه درس برنامه سازی پیشرفته دانشکده کامپیوتر دانشگاه صنعتی شریف fa 2026-06-13 23:13:10 https://files.virgool.io/upload/publication/xh8cq0lwddak/jcoxke.png https://virgool.io/ap-sharif https://virgool.io/ap-sharif/%D8%AA%DB%8C%D9%85-hr-%D8%AA%D9%86%D9%87%D8%A7-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%B3%D9%87-%D9%88%D8%A7%D8%AD%D8%AF-%D8%B4%D8%B1%DB%8C%D9%81-qy3kbgi26rle مستندات تیم HR درس برنامه‌نویسی پیشرفته بهار۹۹ - دانشکده مهندسی کامپیوتر - دانشگاه صنعتی شریفیا غایة آمال العارفینایجاد تیم HR (تیمی در زیرمجموعه‌ی دستیاران آموزشی درس و موازی تیم‌های پروژه، تمرین و کارگاه)، ایده‌ای بود که در ابتدای شروع ترم بهار۹۹ زده‌شد. شاید بتوان گفت این ایده در سطح تمامی دروس دانشگاه، با این تشکیلات، بی سابقه بوده‌است. علل تشکیل تیم HR را در زیر بررسی می کنیم.? گستردگی جامعه مخاطب: چیزی که در ابتدا مورد توجه دستیاران آموزشی قرار گرفت، جامعه‌ی مخاطب گسترده‌ی این درس به خصوص در بهار۹۹ بود. جامعه ای متشکل از ۱۸۱ دانشجو که مخاطب درس بودند و حدوداً ۴۵ دانشجو که وظیفه‌ی دستیاری آموزشی درس را برعهده داشتند.? اهمیت ارتباط حداکثری با مخاطبین درس: درس AP با توجه به روند تدریس، تمرین و پروژه، نیاز به ارتباط حداکثری با دانشجویان دارد. چرا که این درس با این روند، جزء پر حجم‌ترین درس‌های دوره‌ی کارشناسی از لحاظ تمرین و پروژه است. حجم درس ایجاب می کند که وضعیت دانشجویان در همه‌ی ابعاد در تصمیم‌های تیم تدریس و دستیاران دخیل شود و تصمیم‌گیری‌ها مطابق آن انجام‌شود. برای مثال عده‌ی زیادی از دانشجویان ممکن‌است برخلاف پیش‌بینی‌ها، درگیر درس، آزمون یا مسابقه‌ای باشند یا فشار درس‌های دیگر در هفته‌های بخصوص با وجود شرایط کرونا موجب کمبود وقت و خستگی زیاد دانشجویان گردد. در نتیجه باید زمان‌بندی‌ها و برنامه‌ریزی‌ها مطابق با این متغیرها منعطف‌شود.? تأمین آرامش روانی دانشجویان: در درس‌های با جمعیت مخاطب بالا عموماً مشکلی وجود دارد که شاید در نگاه اول متوجه آن نباشیم اما هر چه که به تعداد مخاطبین افزوده شده و حجم و فشار درس بالاتر برود این مشکل را احساس می کنیم. شاید گاهی با سردرگمی‌ها و پرسش‌های متعددی که در گروه‌های تلگرامی درس عموماً پس از انتشار یک تمرین یا پس از اعلام نمرات بوجود می‌آید مواجه شده‌باشید. حال فرض کنید جمعیت این گروه بسیار بیشتر شود و متغیرهای تشنج‌زا هم چند برابر افزایش پیدا کند، در این شرایط احتمالاً باید هر روز شاهد جمع آوری ایمیل توسط دانشجویان برای اعتراض و یا درخواست شفاف‌سازی برای رفع شبهات و نگرانی‌ها باشید. در نتیجه نیاز است برای آرامش هر چه بیشتر دانشجویان و همچنین تیم تدریس، این متغیرها به وسیله شفاف سازی، در دسترس‌بودن و پاسخ‌گویی مستمر کنترل شود.?تجمیع و پیگیری درخواست‌های دانشجویان: حتماً با این مشکل مواجه شده‌اید که با بالارفتن تعداد اعضای تیم تدریس درخواست‌ها و سؤالات روی تمامی اعضا پخش می‌شود و در نتیجه ممکن است پاسخی که یک عضو به درخواستی می‌دهد با عضو دیگر متفاوت باشد و در نتیجه به دلیل عدم هماهنگی، مشکلی در فعالیت های تیم تدریس و دانشجویان ایجاد شود. برای رفع این مشکلات، نیاز است که درخواست‌ها از یک کانال رد شوند تا بررسی آن‌ها توسط یک تیم انجام شود. البته این راه حل فواید دیگری هم دارد؛ برای مثال:▪️ عدم سردرگمی دانشجویان برای مراجعه به مسؤولین درس (یعنی اینکه دانشجو دیگر به دنبال این نباشد که برای حل یک مشکل باید به کدام TA مراجعه کند)▪️ بی‌نیاز شدن اعضای تیم تمرین، پروژه، کارگاه‌ها به مراجعه‌ی خصوصی به دانشجویان و پیداکردن آن‌ها برای رفع مشکلی خاص یا رسیدگی به اعتراضات وارده. نتیجه‌ی این بی‌نیازی تمرکز حداکثری این تیم‌ها به روی مسؤولیت‌شان است.?احساس نیاز به موارد بالا منجر به ایجاد تیم HR شد که در کنار تیم تمرین، پروژه و کارگاه‌ها آغاز به کار کرد. اعضای تیم HR عمدتاً از کسانی بودند که از قبل ارتباطات زیادی با دانشجویان ورودی داشتند برای مثال سرگروه اردو ورودی بودند یا در رویدادهای دانشکده‌ای با دانشجویان ورودی ارتباط می گرفتند. در ضمن نسبت به عدم تک‌جنسیتی بودن اعضای تیم HR نیز اهمیت داده‌شد. مورد بعدی که در انتخاب اعضای تیم HR در نظر گرفته‌شد این بود که اعضا بهتر است عضو تیم‌های دیگر (پروژه، تمرین و کارگاه) نباشند.و اما موضوع بعدی فعالیت‌های تیم HR است که به صورت جزئی در زیر به آن می پردازیم:? گرفتن بازخوردهای متعدد: با توجه به گسترده‌بودن جامعه‌ی مخاطب درس، احتمال بوجود آمدن مشکلات کوچک بالا می رفت. برای مثال عقب ماندن یک کلاس از سیلابس درس، بوجود آمدن مشکل در سامانه Quera و ... که تیم HR با ارتباطات گسترده خود با دانشجویان که عمدتاً به صورت "دوستانه و رفاقتی" بود از اتفاقات و مشکلات پیش‌آمده به سرعت باخبر میشد و تیم‌های مربوط را از بروز این مشکل باخبر می‌ساخت.?نظرسنجی: برای اطلاع از اوضاع کلی دانشجویان نیاز به نظرسنجی بود؛ مثلاً وضعیت پیشرفت پروژه‌ی دانشجویان. این نظرسنجی‌ها باعث می شد که برای مثال مهلت ارسال‌های پروژه مطابق با وضعیت دانشجویان تغییر کند. (تمدید شود)? پیگیری ضعف‌های شخصی افراد و افت نمره‌ها: تیم HR در مقاطعی پیگیر افت نمره‌ی شخصی افراد می‌شد. مثلا پیگیری اوضاع فردی که تمرین خود را انجام‌داده اما در پروژه، نمره‌ی بسیار کمی می گیرد.?حضور مسئولانه در گروه کلی درس: با توجه به نیاز ارتباط حداکثری، لازم بود که علاوه بر گروه‌هایی که دانشجویان هر استاد برای خود به صورت جداگانه داشتند، یک گروه کلی با حضور تمامی دانشجویان درس ایجاد شود. اهداف ایجاد این گروه علاوه بر ارتباطات بین تیم تدریس و دانشجویان به شرح زیر است:▪️ ایجاد شرایطی برای ارتباط، پرسش و پاسخ سؤال و رفع اشکال تمامی دانشجویان به همراه یکدیگر.▪️ ایجاد یک مسیر واحد برای ارتباط عمومی دانشجویان با تیم HR و بالعکسبعد از جلسات تیم HR با Head TA و سرگروه‌های دیگر در رابطه با این گروه، نتیجه این شد که:▪️ تنها اعضای تیم HR در گروه کلی عضو باشند.▪️ اعضای تیم HR تنها به سؤالات غیرفنی (تمرین و پروژه) دانشجویان پاسخ‌دهند. یعنی سؤالات فنی (مثلا رفع باگ یا نحوه‌ی استفاده از یک کتابخانه) که مربوط به تمرین و پروژه می شود تنها توسط تیم پروژه و تمرین پاسخ داده‌شود و پاسخ باقی سؤالات به عهده‌ی تیم HR باشد.▪️ تأکید به دانشجویان در رابطه با عدم ارتباط‌گیری شخصی در تلگرام (PV) با اعضای تیم‌ها به جز اعضای تیم HR. البته گاهی در موارد خاص و همچنین برای راهنماهای پروژه این محدودیت برداشته شد. (برای اطلاع دقیق‌تر از نحوه‌ی فعالیت های راهنماهای پروژه به مستندات تیم پروژه مراجعه فرمایید)علت این تاکید این است که با توجه به گستردگی مخاطبین درس، مراجعات به PV دستیاران زیاد و فشار پاسخگویی روی دستیاران بیشتر می شود. همچنین با توجه به دسترسی آسان تلگرام، دانشجو بعد از برخوردن به هر مشکلی ممکن است به دستیار مراجعه کند که این اشتباه است و باعث چند برابر شدن سؤالات می‌شود. در ضمن بهتر است همه‌ی سوالات پرسیده‌شده و پاسخ آن‌ها در اختیار همه‌ی دانشجویان به جهت جلوگیری از پرسش تکراری قرار گیرد که در صورت اجازه‌ی پرسش سوال در PV دستیار، این هدف تحقق نمی‌یابد. نکته‌ی دیگر این است که ممکن است بعضی از دستیاران علاقه‌مند به پاسخگویی در تلگرام باشند و عده‌ای دیگر از دستیاران خیر. در نتیجه برای مخاطبین درس دوگانگی TA خوب، TA بد ایجاد می‌شود که این نتیجه‌ی خوبی نیست. در آخر بهتر است که همه پرسش‌ها در یک سامانه‌ی بخصوص انجام بگیرد که به صورت عمومی در اختیار همه باشد. در مورد بعدی به این سامانه اشاره می شود.▪️ ایجاد هشتگ برای پرسش سؤالات در گروه تلگرام. با توجه به اینکه در گروه تلگرام دانشجویان از همدیگر سؤال می پرسند یا تست‌کیس طراحی می‌کنند و احتمال گم‌شدن سؤالات لابلای پیام‌ها هست در نتیجه بهتر است دانشجویان برای سؤالات، پاسخ‌ها و تست‌کیس‌ها از هشتگ مربوط استفاده کنند؛ مثلاً #Q1.▪️ ایجاد داک فیدبک برای مشکلات شخصی یا انتقادات از طریق فرم گوگل (برای اطلاع بیشتر به مستندات تیم پروژه و راهنماها مراجعه فرمایید)? اختصاص سامانه واحد برای پرسش سؤال از تیم تمرین و پروژه: دانشجویان برای پرسش سؤال‌های فنی خود از تیم تمرین و پروژه باید در سامانه Quera نوشته‌ی جدید باز کنند یا در زیر نوشته‌ی مربوط (مثلا تمرین یک) سؤالات خود را در قسمت کامنت ارسال کنند و تیم مربوطه موظف است که در سریع‌ترین زمان ممکن به سؤالات دانشجویان پاسخ‌دهد. این راهکار به تجمیع تمامی سؤالات در یکجا و دسته‌بندی آنها می‌انجامد. در نتیجه کمتر با گم‌شدن سؤالات و سؤالات تکراری مواجه می شویم.و اما دستاورد های تیم HR:? دانشجو TA را در کنار خود می‌بیند نه در مقابل: تجربه نشان‌داده که دیدگاه دانشجویان نسبت به دستیاران آموزشی عمدتاً با حس تقابل همراه بوده یعنی TA را در مقابل خود می‌بینند ولی وجود تیم HR باعث شد که این دیدگاه برای دانشجویان این درس عوض‌شود.?یک نفر هست که حرفش را گوش کند: یکی از ویژگی‌های خوب یا بد سیستم دانشگاهی این است که تقریباً دانشجو به حال خود رها می‌شود و نه کسی پیگیری می‌کند و نه کسی اهمیت می‌دهد به اوضاع دانشجویان. اما تیم HR توانست در مواقعی که دانشجویی نیاز به حرف زدن، انتقادکردن و یا حتی درددل‌کردن با کسی را داشت این شرایط را فراهم کند.? راحتی دانشجو در بیان نظر خود: تیم HR تمام تلاش خود را انجام‌داد تا دانشجویان در بیان نظرات خودشان چه در گروه، چه در داک فیدبک و چه در پیام خصوصی به HR، هیچگونه نگرانی و ترسی نداشته باشند و تا حد امکان راحت باشند که به این هدف تا حد زیادی رسیدیم.? رسیدگی به اکثر مشکلات دانشجویان: تیم HR توانست تقریباً تمامی مشکلات پیش‌آمده برای دانشجویان را پیگیری و اکثر آن‌ها را رفع کند. برای مثال در تحویل‌حضوری‌ها مشکلاتی مانند فراموش کردن تحویل‌حضوری توسط دانشجو یا TA بوجود می‌آمد که HR زمان‌های جدیدی را با TA و دانشجو هماهنگ می‌کرد. مثال دیگر، مشکلات یادگیری دانشجویان بود؛ یعنی تیم HR از طریق پرسش و گرفتن بازخورد متوجه می‌شد که گروهی از دانشجویان در قسمتی از درس یادگیری درستی نداشتند و یا عقب ماندند. در نهایت گزارش این مشکل را به تیم‌های مربوطه مثل کارگاه ارائه می‌داد.در زیر نظرات برخی از دانشجویان را نسبت به تیم HR، بدون تصحیح و ویرایش قرار داده‌ایم:? "یه چیزی که به نظر من خیلی خوب بود این بود که واقعا تیم اچ‌آر خیلی کمکمون کردن از هر نظر، توی رسوندن صدا به مسئولین تمرین و پروژه و درخواست‌های تمدید ددلاین و این صحبتا و اینکه می‌تونستیم با خیال راحت حرفمونو بزنیم و اینا خیلی نکته مثبت بارزی بود. و همینطور کمک برای حل مشکلات تحویل حضوری و اینا"? سلام :) منم میخواستم به نوبه خودم از همه HR های عزیز تشکر کنم. اولا اینکه جدا باعث شدین زیر فشار ترم ۲ له نشیم!? چون بقیه رحم نکردن واقعا(فشار خیلی زیاد بود ?)? و اینکه صدامونو به تی ای‌ها، سر تی‌ای و حتی اساتید!!!! میرسوندین هم خیلی قابل تقدیر بود(مورد داشتیم ترم ۱ جوابی نمیدادن کلا?) :) و اینکه واقعا نقطه ضعفی به ذهنم نمیرسه?، خیلی خوب بودین کلا ??. امیدوارم منم سال اینده بتونم به سال پایینیام کمک کنم :)? حضور تیم اچ آر به نظرم بسیار مفید بود و امیدوارم هر ترم چنین تیمی در نظر گرفته شود زیرا ما میتوانستیم به راحتی تمام مشکلات را با اعضای این تیم در میان بگذاریم و میدانستیم آنها برای رفع مشکل تمام تلاششان را خواهند کرد(برای مثال به خاطر امتحانات ما درخواست تمدید ددلاین فاز یک و دو پروژه را داشتیم و پس از صحبت تیم hr با مسئولین پروژه ددلاین تمدید شد) یا هر سوالی که در زمینه ی تمارین یا پروژه داشتیم را میتوانستیم مستقیما از اعضای تیم hr بپرسیم.  در پایان از اعضای تیم hr تشکر میکنم که در شرایط سخت این ترم ما را درک کردند و باعث شدند فشار کمتری بر دوشمان باشد.? یکی از مهم ترین ویژگی های تیم HR (که تیم امسال هم این ویژگی رو خیلی خوب داشتن) این هستش که دانشجوها بتونن خیلی راحت نظرها و درخواست هاشون رو بدون گذراندن فرم‌ها و داک های متعدد به استادها و مسئولین تمرین و پروژه برسونن. این «در دسترس بودن» و «صمیمیت» باعث میشد تا بچه ها تیم تی ای رو بیشتر در کنار خودشون ببینن.  ایجاد گروه بین بچه ها برای رفع مشکل هم یکی دیگه از ویژگی های مثبت تیم HR امسال بود که شرایطی رو مهیا میکرد تا بچه‌ها بتونن از راهنمایی های همدیگه حین تمرین‌ها و پروژه استفاده کنن.? در پایان این مستند از اساتید گرامی درس به خاطر اعتماد و کمک به تیم دستیاران، تشکر می‌کنیم. تقدیر دیگر ما از دانشجویان و دستیاران درس است که با اعتماد به ما و همکاری با ما، مسیر را جهت رشد و به بلوغ رسیدن تیم HR هموار نمودند. ان‌شاء‌الله که در سالیان آتی، این ایده و این تیم بتواند در راستای رشد درس برنامه‌نویسی پیشرفته و رشد دانشجویان، مؤثر باشد.با تشکر از شما که این مستند را مطالعه نمودید. به امید پیشرفت ایران عزیز...موفق باشیدامیرحسین عباسی - مرداد ۹۹ درس برنامه سازی پیشرفته شریف امیرحسین عباسی Tue, 18 Aug 2020 02:20:04 +0430 https://virgool.io/ap-sharif/%D8%AA%D8%AC%D8%B1%D8%A8%DB%8C%D8%A7%D8%AA-%D9%85%D9%86-%D8%AF%D8%B1-%D8%AF%D8%B1%D8%B3-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D9%BE%DB%8C%D8%B4%D8%B1%D9%81%D8%AA%D9%87-jqufmdkf2bwp مدتی بود که چند دوست عزیز تصمیم به بهبود وضعیت ارائه‌ی درس برنامه‌سازی پیشرفته دانشکده کامپیوتر شریف گرفته بودند و تلاش های آن‌ها منجر به ارتقای چند پله‌ای کیفیت ارائه دادن این درس و به تبع آن پیشرفت زیاد دانشجویانی که این درس را می‌گذراندند (من جمله خودم!)، شده بود. به گونه‌ای که دانشجویی که این درس را به خوبی می‌گذراند، با کیفیت بالایی مفاهیم برنامه‌سازی پیشرفته را فرا گرفته بود و آمادگی خوبی برای برنامه‌نویسی پروژه‌های متوسط دانشگاه و همچنین پروژه‌های کوچک صنعتی به صورت گروهی داشت.امّا این فرآیند باید در سال های آینده ادامه می‌یافت و صرفاً محدود به دو یا سه سال نمی‌شد. از این رو من و چند نفر از دوستانم تصمیم گرفتیم که امسال هم به کمک اساتید گرامی، تلاش کنیم که این درس در این ترم (ترم بهار 99) مثل ترم خودمان قوی، و بلکه قوی‌تر از آن ارائه شود.در این ترم درس برنامه‌سازی پیشرفته در چهار گروه مختلف ارائه شد که برای اولین بار مسئولیت هر چهار گروه با یک تیم دستیاران آموزشی بود که هماهنگ کردن این 4 گروه، مشکلات و دشواری‌های خاص خود را داشت. در ‌این ترم مجموعاً 181 دانشجو درس را اخذ کرده بودند که ارائه درس در این سطح از تعداد دانشجو سابقه نداشت و نیازمند وقت‌گذاری مضاعف از سمت دستیاران آموزشی بود که به خوبی انجام شد. البته متاسفانه 17 نفر در مهلت حذف اضطراری درس را حذف کردند و در نهایت 164 دانشجو درس را تا پایانِ ترم داشتند.اهداف کلی تمرین‌هادانشجویان برای رسیدن به اهداف درس لازم بود که ابتدا یک سری مفاهیم و مهارت‌های اولیه را در تمرین‌ها فرا بگیرند، سپس در پروژه اصلی درس با استفاده از این مفاهیم و مهارت‌ها و مهارت‌های فنی و غیر فنی دیگری مانند Git، توانایی کار کردن در تیم و تقسیم کار و...، پروژه اصلی درس را پیاده سازی کنند. در این نوشتار می‌خواهم بیشتر درباره آن چه که من و تیمم در تمرین‌های این درس انجام دادیم، صحبت کنم. ما در طول این ترم سه تمرین را برای دانشجویان منتشر کردیم و تحویل گرفتیم.تمرین اول : مفاهیم اولیه جاوا. انتشار : 7 اسفند 98. مهلت ارسال : 21 اسفند 98. (پاسخ‌ها و تست‌ها)تمرین دوم : شی گرایی. انتشار 27 اسفند ماه 98. مهلت ارسال: 18 فروردین 99. (پاسخ‌ها و تست‌ها)تمرین سوم: مفاهیم پیشرفته تر در جاوا (گرافیک، شبکه، Thread ، Unit Test ، کلاس‌ها و متدهای عام) (پاسخ‌ها و تست‌ها) انتشار بخش اول: 31 اردیبهشت 99. مهلت ارسال بخش اول: 16 خرداد 99. انتشار بخش دوم: 12 خرداد 99. مهلت ارسال بخش دوم: 30 خرداد 99.اهداف تمرین اولآشنایی با مفاهیم اولیه جاوا (حلقه، شرط، متغیر های primitive و غیر primitive و ...)آشنایی اولیه با Java Containers (مانند ArrayList ، HashMap ، LinkedList ، ...)آشنایی اولیه با Regex و چگونگی کار کردن با آن در Java.آشنایی با مفهوم Clean code و تمیز کد زدن.بدین منظور در کلاس حل تمرین در این باره توضیحات لازم داده‌شد و ما هم محتوایی برای آشنایی اولیه دانشجویان با Clean code منتشر کردیم. در این تمرین صرفاً انتظار می‌رفت که نکات اولیه کد تمیز (تو رفتگی، نداشتن کامنت بی‌مورد، نامگذاری متغیرها و رعایت اندازه مناسب برای توابع) رعایت شود. بدین منظور 25 درصد نمره تمرین اول به این مورد اختصاص یافت. لازم بود که کد تمام دانشجویان یک بار توسط دستیاران خوانده شود و نمره دهی شود و هم‌چنین نکات Clean code که احیاناً رعایت نشده، به هر دانشجو تذکر داده شود که دانشجویان به سمت زدن کد تمیز حرکت کنند. این اتفاق در تحویل مجازی تمرین رخ داد و کدهای هر دانشجو به مدت 20 دقیقه مورد بررسی قرار گرفت. که البته 20 دقیقه مقداری کم بود و بهتر بود زمان تحویل تمرین اول برای هر دانشجو 30 دقیقه در نظر گرفته شود. جزییات بیشتر درباره هر سوال و نکات ضعف و قوتی که به نظر طراحان هر سوال به نظر رسید و هم‌چنین جزییات نکات تحویل مجازی تمرین اول را در داک پیوست (که در حال تکمیل است.) بخوانید.اهداف تمرین دومآشنایی با مفهوم Class و کلاس بندی در جاواآشنایی با مفاهیمِ اولیه‌ی OOPآشنایی با مفاهیم abstract و polymorphismآشنایی اولیه با معماری MVCاین اهداف در تمرین دوم درس که شامل 3 سوال که پیاده سازی سه سیستم شی گرا بود، پیگیری شد. سوال اول پیاده سازی یک سیستم بانکی بسیار ساده، سوال دوم پیاده بازی ساده شده شطرنج و سوال سوم پیاده سازی ساده یک سیستم ذخیره سازی بود. در سوال اول دانشجویان مطابق UML ای که در اختیارشان بود، باید عمل می‌کردند. اما در دو سوال بعدی وظیفه طراحی معماری بر عهده خود دانشجویان بود. نکات ضعف و قوتی که به نظر طراحان هر سوال به نظر رسید را در داک پیوست بخوانید.ساختار UML طراحی شده برای سوال اول تمرین دومدر این تمرین هم لازم بود که کد دانشجویان مورد بررسی قرار بگیرد که نکات شی گرایی و Clean code در آن رعایت شده باشند. این اتفاق در تحویل مجازی تمرین رخ داد و کدهای هر دانشجو به لحاظ رعایت معماری MVC، تمیزی کد و نکات شی گرایی به مدت 40 دقیقه مورد بررسی و نمره دهی قرار گرفت. در این تمرین در سوال اول بخشی از نمره به تمیزی کد و طراحی براساس UML داده شده، و در سوال دوم و سوم بخشی از نمره به تمیزی کد و طراحی صحیح شی‌گرا و رعایت نکات شی‌گرایی اختصاص یافت. جزییات نکات تحویل مجازی تمرین دوم را در داک پیوست (که در حال تکمیل است.) بخوانید.یک اتفاق مثبتی که باعث کم شدن ابهامات تمرین اول و دوم شد، این بود که هر تمرین قبل از انتشار برای دانشجویان دو یا سه بار توسط دستیاران آموزشی اکسپت شد. (یعنی فرد کد سوال را بزند و در کوئرا پاسخ را Submit کند و همه تست‌های سوال را پاس کند.) یعنی علاوه بر این که خود طراح، سوال خودش را باید اکسپت می‌کرد، یک یا دو دستیار دیگر که در طرح آن سوال دخالتی نداشتند، باید آن را اکسپت می‌کردند تا ابهامات احتمالی موجود در صورت سوال پیدا و رفع شود.داوری پروژه‌ای در سوالات شئ‌گراییپیشرفت مهم دیگری که در این تمرین برای اولین بار رخ داد، استفاده از داوری پروژه ای کوئرا برای این تمرین بود. با این کار دانشجویان بر خلاف سال های قبل لازم نبود تمام کد هر سوال را در یک فایل بنویسند و مجبور به ارسال و دیباگ کردن فایل های 1000 خطی شوند؛ بلکه می‌توانستند کلاس های مختلف را در فایل های مختلف بنویسند و برای ارسال پاسخ، فایل فشرده کلاس‌ها را ارسال کنند. از دیگر مزایای داوری پروژه‌ای می‌توان به پشتیبانی از package بندی‌های مختلف، امکان استفاده از کتاب خانه‌های غیربومی مختلف مانند YaGson و... اشاره کرد. لازم می‌دانم که از تیم کوئرا که دسترسی داوری پروژه‌ای و نحوه کار با آن را در اختیار تیم دستیاران آموزشی قرار داد، تشکر کنم.البته یکی از مشکلاتی که داوری پروژه‌ای ایجاد کرد، این بود که به دلیل قدیمی بودن جاوا سرور داوری پروژه‌ای کوئرا (8)، دانشجویان از امکانات جدید جاوا در این تمرین و تمرین‌هایی که از داوری پروژه‌ای ‌استفاده می‌کردند، نمی‌توانستند استفاده کنند. (از کوئرا درخواست کردیم که جاوا سرور داوری پروژه‌ای را در صورت امکان بروزرسانی کنند.) جزییات پیاده سازی داوری پروژه ای تمرین دوم و شرح نقاط مثبت و منفی آن را در داک پیوست مطالعه کنید.اهداف تمرین سومآشنایی اولیه با کلاس ها و متد ها عام (Generic)آشنایی با گرافیک در جاواآشنایی اولیه با Unit Testآشنایی با Socket و برنامه‌نویسی شبکه در جاواآشنایی اولیه و مقدماتی با مفاهیم Thread , Concurrency و توابع Blocking , Non-blocking در جاوادو هدف اول در بخش اول تمرین سه، پیگیری شد. یک سوال نسبتا ساده از کلاس‌ها و متدها Generic که داوری پروژه ای و نمره دهی خودکار، برای آن پیاده سازی شده بود؛ و دو سوال گرافیک که باید یکی از آن ها را به انتخاب دانشجویان می‌زدند. یکی از آن ها پیاده سازی گرافیکی همان شطرنجی بود که در تمرین دوم به صورت کنسولی پیاده‌سازی کرده‌بودند و سوال دیگر پیاده‌سازی گرافیکی بازی Space Invaders بود. اتفاق خوبی که امسال افتاد، این بود که دو سوال گرافیک در تمرین 3 (پارسال) به یک سوال کاهش یافت که این مورد باعث شد که وقت دانشجویان بی‌دلیل سر پیاده‌‌سازی‌های گرافیکی بدون یادگیری خاص، تلف نشود. Space Invaders بازیسه هدف بعدی تلاش شد در بخش دوم تمرین سوم محقق شود. این بخش شامل یک سوال پیاده سازی یک شبکه بانکی شامل سرور بانک، سرور DNS و عابر بانک بود که ProtoType کلاس‌ها و توابع لازم آن در اختیار دانشجویان قرار گرفته بود و دانشجویان باید صرفا توابع مربوطه را تکمیل می‌کردند تا 6 تست (سه تست blocking , سه تست non-blocking) را پاس کند. برای آن که حل این تمرین برای دانشجویان بسیار دشوار نشود، تعدادی از تست ها در اختیار دانشجویان قرار گرفت که در دیباگ کردن کد کدشان از آن ها استفاده کنند.داوری پروژه‌ای در سوال Generic و سوال شبکهپیشرفت مهم دیگری برای اولین بار در درس برنامه‌سازی پیشرفته رخ داد، این بود که برای سوال‌ Generic و سوال پیاده‌سازی شبکه بانکی نیز، داوری پروژه‌ای پیاده‌سازی شد. به عبارتی تنها سوال گرافیک بود که در این ترم داوری خودکار نداشت. (البته برای استفاده از سیستم کشف تقلب کوئرا، یک داوری پروژه‌ای بدون تست هم برای دو سوال گرافیک، گذاشته شد.) در این دو سال با استفاده از سیستم داوری پروژه‌ای کوئرا تعدادی Unit Test بعد از هر Submit روی آن اجرا می‌شد و بلافاصله پاسخ آن اعلام می‌شد.البته برای سوال شبکه باید چک می‌شد که قوانین سوال رعایت شده باشند که چک کردن این موارد با استفاده از یک اسکریپت پایتون انجام شد. (نظیر این که کلاس‌ها علاوه بر بستر شبکه از راه های دیگری با هم ارتباط نداشته باشند، عدم استفاده از Thread.sleep و یا عدم ایجاد delay مصنوعی به هر طریقی برای دور زدن تست کیس ها و ...) جزییات داوری پروژه‌ای این سوالات و نکات مثبت و منفی‌ای که به نظر طراحان هر سوال به نظر رسید را در داک پیوست (که در حال تکمیل است.) بخوانید!این اتفاقات باعث شد که در دوران مجازی بودن ترم، دیباگ و تحویل تمرین سوم بسیار راحت‌تر انجام شود. یعنی فقط سوال گرافیک تحویل گرفته شد و نمره‌دهی دو سوال دیگر به صورت خودکار انجام شد.سایر پیشرفت‌‌ها و نقاط قوت دیگراز دیگر نقاط قوت تمرین‌ها به طور کلی در این ترم می‌توان به موارد زیر اشاره کرد: لاتک بودن داک تمام تمرین و داشتن یک قالب مشخص برای همه آن‌ها. از این قالب می‌توان برای سال‌های آینده هم استفاده کرد. هم چنین توضیحات فراوان و کامل در داک ها، باعث حداقل شدن ابهامات موجود در سوالات شده بود.پیشگیری از آسیب‌های احتمالی مجازی شدن ترم. با مجازی‌‌شدن ترم تحویل حضوری تمرین‌ها ممکن نبود. اما با تحویل و بررسی مجازی کدها به کمک سامانه Skyroom و اپلکیشن Discord این خلاء تا حد امکان رفع شد.پاسخگویی دستیاران آموزشی در کوئرا. طراحان هر تمرین موظف بودند که ابهامات مطرح شده درباره هر تمرین را در کوتاه‌ترین زمان ممکن در کوئرا پاسخ بدهند.شفافیت کامل در داک نمرات نمرات. داک نمرات که در زمان تحویل حضوری توسط دستیاران آموزشی پر می‌شود، بعد از ثبت نمرات هر تمرین در اختیار دانشجویان برای مشاهده قرار می‌گرفت که اگر احیاناً موردی اشتباه شده بود، به دستیاران اطلاع دهند. داک نمرات چهار گروه از طریق لینک های زیر قابل دسترس است:? نمرات گروه 1 (استاد مصطفی زاده)? نمرات گروه 2 (استاد ملک زاده)? نمرات گروه 3 (استاد عیسی زاده)? نمرات گروه 4 (استاد چکاه)هم‌چنین در ابتدای ترم مقرر شد که برای کل تمرین‌ها، 3 روز تاخیر بدون جریمه در نظر گرفته شود. که اگر اتفاقی برای دانشجویی رخ داد، بتواند از این سه روز تاخیرش در یک یا چند تمرین به دلخواه استفاده کند. در ضمن برای آن‌که اگر احیانا مشکلی پیش آمد، این سوپاپ اطمینان، موجود باشد. ولی برای تاخیرهای بعدی روزی 30 درصد کسر نمره در نظر گرفته شد و هم‌چنین مقرر شد که در هر تمرین بیش از سه روز اجازه استفاده از تاخیرها نباشد. هم‌چنین برای این که دانشجویانی که صرفاً یک تمرین نمره پایینی گرفته بودند، آسیب کمتری به نمره نهایی تمرین آن‌ها وارد شود، نمره‌های تمرین به سه طریق مختلف محاسبه و بیشترین آن‌ها درنظر گرفته شد.مجموعاً میانگین نمره تمرین 164 دانشجویی که درس را داشتند، 87.37 از 100 شد که تلاش تیم دستیاران آموزشی و همچنین تلاش جدی خود دانشجویان در جهت یادگیری از دلایل اصلی این میانگین بالاست.در پایان از اساتید گرامی هر چهار گروه (جناب آقای مصطفی‌زاده، ملک‌زاده، عیسی‌زاده، چکاه) بابت اعتماد فراوان به تیم دستیاران آموزشی تشکر می‌کنم. همچنین از مسئول دستیاران آموزشی، آقای محمد حقیقت بابت اعتماد و پیشتیبانی فراوان از تیم تمرین، تشکر می‌کنم و سپاسگزارم. از تمام اعضای تیم تمرین بسیار سپاسگزارم که کمک کردند تمرین‌ها این درس هر چه قد بهتر ارائه شود و بدون ایشان این مورد ممکن نبود. و از تمام اعضای تیم های دیگر دستیاران آموزشی بسیار سپاسگزارم که ارائه با این کیفیت درس مدیون زحمات تک تک آن هاست و باید یک تشکر مهم از دانشجویان بکنم که علی رغم مشکلات ترم مجازی و... به خوبی با درس همراهی کردند. ان‌شاء‌الله که این روند در ترم‌های آینده ادامه پیدا کند.در نهایت به شخصه امیدوارم توانسته باشم قدمی هر چند بسیار کوچک، در پیشرفت هر چه بیشتر دانشجویان و دانشگاه و در نهایت در جهت پیشرفت کشورم انجام داده باشم. و ممنونم ازتون که با متن همراهی کردید. :)موفق باشیدمحمدحسین قیصریه - تیر ۹۹ درس برنامه سازی پیشرفته شریف محمدحسین قیصریه Tue, 21 Jul 2020 02:29:33 +0430 https://virgool.io/ap-sharif/%D9%BE%D8%AA%D8%B1%D9%86-%D9%87%D8%A7%DB%8C-%D8%AF%D8%B3%D8%AA%DB%8C%D8%A7%D8%B1%DB%8C-%D8%A2%D9%85%D9%88%D8%B2%D8%B4%DB%8C-%D8%A8%D8%AE%D8%B4-%DB%8C%DA%A9-xuujvlavns3q چند ترم دستیار آموزشی (TA) درس برنامه‌سازی پیشرفته در دانشکده کامپیوتر دانشگاه صنعتی شریف بودم و توی این ترم‌ها چیزایی یادگرفتم که احتمالاً برای بقیه دانشجو ها و دستیاران آموزشی مفید باشه:مهم ترین موضوع: انگیزه اصلی، هدف و اولویت اول تیم دستیاران آموزشی: فقط افزایش یادگیری دانشجو هاتوی ترم های مختلف به وضوح دیدم کسایی که برای افزایش کیفیت درس و بالا بردن یادگیری دانشجو ها دستیار آموزشی شدن حتما پشتکار و دغدغه بیشتری دارن و وقت زیادی نسبت به سایر دستیاران می‌گذارن و اگه افراد اصلی تیم دستیاران آموزشی با این انگیزه بیان تاثیر مثبت قابل توجهی روی کیفیت ارائه درس، تمرین و پروژه می‌گذارن.در ادامه یه سری موارد توی ترم های مختلف انقدر تکرار شد که ما اسم پترن یا الگو رو براش گذاشتیم! توی مهندسی نرم افزار به راه حل های پر تکرار که امتحان خودشونو پس دادن و برای حل مسئله های پرتکرار استفاده میشن اصطلاحاً «Pattern» یا «الگو» میگن:الگوی اول: بازخورد سریع (fast feedback)فرض کنید یک رویه اشتباه توی تیم TA ها وجود داره یا در بخشی دچار مشکل شدیم که هنوز مسئول مربوط به اون بخش از اون مشکل آگاه نشده، باید مکانیزمی وجود داشته باشه که دانشجو ها یا حتی سایر دستیاران آموزشی که دارن اون مشکل رو می‌بینن در سریع‌ترین زمان ممکن بتونن اون مشکل رو به افراد مسئول اطلاع بدن و اگه اقدام درستی برای حل اون مشکل انجام نشد بتونن اون مشکل رو به سر تی ای اعلام کنن. ما بار ها تجربه کردیم که نظرسنجی‌های آخر ترم برای سنجش کیفیت درس کافی نیستن، وقتی به پایان یک ترم می‌رسیم خیلی از بچه ها یادشون نیست چه مشکلاتی در طول ترم وجود داشته و برای همین معمولاً بازخورد های دقیق و موثری نداریم. اگر دستیار آموزشی هستین برای این مکانیزم از همون اول ترم فکر کنین و در طول ترم تلاش کنین از کانال های مختلف از دانشجو/بقیه دستیاران آموزشی/استاد بازخورد بگیرین، اگر تعداد بازخورد ها زیاده به بازخورد هایی که تکرار بیشتر دارن اولویت بدین و اونا رو اعمال کنین، و بعد هم به صورت شفاف به اون افراد بگین که بازخورد ها رو چطوری اعمال کردین که دلسرد نشن.الگوی دوم: پروژه گروهی و کار تیمییکی از مهم ترین مواردی که دانشجو ها در این درس یاد می‌گیرن کار تیمی روی یک پروژه شی گرا هست بنابراین تلاش می کنیم پروژه سنگین تر از توان «یک» نفر طراحی بشه که افراد تشویق بشن به صورت گروهی روی پروژه کار کنن و انواع تعامل های تیمی از قبیل تقسیم کار، قانع کردن هم تیمی، پیگیری کار و تمرکز روی خروجی نهایی تیم رو تمرین کنن. همچنین تلاش می کنیم بچه های شریف که معمولاً توی دوران دبیرستان روی نمره خودشون تمرکز داشتن، یادبگیرن اگه خروجی تیم کم باشه نمره همه کم میشه و خروجی مثبت یا منفی تیم بین همه‌ اعضا مشترک هست. پیشنهاد ما اینه که تیم‌های پروژه حتماً سه نفره در نظر گرفته بشه چون مدیریت و کنترل تیم‌های چهار نفره به بالا برای بچه‌های ترم دو و سه که معمولاً تجربه‌ی کار تیمی زیادی ندارن سخته و از طرفی در تیم دو نفره هم مجال تمرین کردن خیلی از مهارت های کار تیمی پیش نمیاد.در نوشته های بعدی تلاش می‌کنم در مورد پترن های شیوه تعامل با دانشجویان قوی و ضعیف و تجربیاتی که در این زمینه داشتیم بنویسم. درس برنامه سازی پیشرفته شریف محمد حقیقت Mon, 02 Mar 2020 15:55:09 +0330