سلام 👋
اینجا هستید چون کسی در پاسخ به پیشنهادتان دربارهی اینکه Exercism چطور میتواند بهتر شود، شما را به این مطلب ارجاع داده است؟
پیش از آنکه تیم ما وقت بگذارد و ایدهتان را بررسی کند، امیدوارند این مطلب را بخوانید و در نظر بگیرید که آیا ممکن است پیشتر به ایدهتان فکر شده باشد و چه دامهایی ممکن است داشته باشد.
با افزودن این ملاحظات و دامهای احتمالی به پیشنهادتان، و با فکر کردن به اینکه چرا ایدهتان تا حالا پیاده نشده است، احتمالاً پاسخ سریعتر و مثبتتری میگیرید.
خب، «حصار چسترتون» یعنی چه؟
«حصار چسترتون» ایدهای است برگرفته از جملهای از کتاب «The Thing» نوشتهی جی.کی. چسترتون، نویسنده، که در سال ۱۹۲۹ منتشر شد.
این نقلقول بعدها معروف شد، چون جان اف. کندی آن را نقل کرد.
متن اصلی نقلقول این است:
در چنین حالتی نهاد یا قانونی وجود دارد؛ بگذارید برای سادگی بگوییم حصاری یا دری که روی جادهای برپا شده است.
نوع مدرنتر اصلاحگر با خوشحالی به آن نزدیک میشود و میگوید: «فایدهاش را نمیبینم؛ بیایید آن را برداریم.»
در پاسخ، اصلاحگر داناتر بهتر است بگوید: «اگر تو فایدهاش را نمیبینی، من قطعاً اجازه نمیدهم آن را برداری. برو و فکر کن. بعد، وقتی برگشتی و به من گفتی که فایدهاش را میبینی، ممکن است اجازه بدهم نابودش کنی.»
ایدهی حصار چسترتون این است که اگر نمیدانید چیزی چرا آنجاست، احتمالاً نمیدانید چرا باید برداشته شود.
به همین ترتیب، اگر نمیدانید چرا چیزی آنجا نیست، احتمالاً نمیدانید چرا کنار گذاشته شده است.
یک قاعدهی ساده برای بهخاطر سپردن این است: «تا وقتی نمیدانید حصاری از ابتدا برای چه برپا شده، آن را برندارید.»
این مفهوم چطور به Exercism مربوط میشود؟
در Exercism، خوشبختانه همیشه افراد زیادی به جامعهمان میپیوندند و افکار و ایدههایشان را مطرح میکنند.
بسیاری از این ایدهها تازه، نوآورانه و هیجانانگیزند و ذهن ما را باز میکنند. پس اگر ایده یا پیشنهادی دارید، از آن استقبال میکنیم!
اما بیشتر وقتها، افراد ایدههایی مطرح میکنند که پیشتر بارها دربارهشان بحث شده است.
پاسخ دادن به چنین ایدههایی و دوباره پرداختن یا دوباره توجیه کردن تصمیمهایمان میتواند برای تیم ما بسیار فرساینده باشد.
هدف این مقاله کمک به محافظت از آن زمان و انرژی است.
Exercism را هزاران فرد بسیار بااستعداد طراحی، مهندسی و ساختهاند.
این محصولی بسیار عامدانه است: چیزها آنجا هستند چون طراحی شدهاند که باشند، و چیزها اغلب کنار گذاشته شدهاند چون طراحی شدهاند که کنار گذاشته شوند.
تقریباً همهچیز در Exercism بارها بحث، بررسی و بازمهندسی شده است.
پس پیش از مطرح کردن ایدهتان، لطفاً از خودتان بپرسید آیا ممکن است ما قبلاً به آن فکر کرده باشیم، و چرا ممکن است کارها را متفاوت از آنچه شما پیشنهاد میکنید انجام داده باشیم.
و یادتان باشد، هرچه ایدهتان واضحتر به نظر برسد، احتمال اینکه بارها دربارهاش بحث و گفتوگو شده باشد بیشتر است؛ پس وقتی آن را مطرح میکنید، همراه با ملاحظات و دامهای احتمالی مطرحش کنید.
اگر دلتان میخواهد بگویید «چرا فقط ...»، تقریباً قطعاً در همین دسته میگنجد.
هرگز از مطرح کردن نترسید، اما لطفاً اول خوب دربارهاش فکر کنید!
مثال هم دارید؟
یک دلخوری رایج این است که دانشآموزان به راهنماها code ارسال میکنند، ولی آن code testها را پاس نمیکند.
یک پیشنهاد بههماناندازه رایج این است: «چرا پیش از اینکه کسی code را ارسال کند، testها را فقط بهطور خودکار در CLI اجرا نکنیم؟»
به نظر ایدهی خیلی خوبی میرسد: CLI میتواند صرفاً یک دستور را فراخوانی کند تا testها را اجرا کند و اگر خراب بودند اجازه ندهد دانشآموز ارسال کند.
خب، اول از همه، «صرفاً فراخوانی یک دستور برای اجرای testها» یعنی چه؟
یعنی نوشتن یک اسکریپت برای هر یک از ۵۲ زبان Exercism که بتواند testها را اجرا کند و نتیجه را بررسی کند.
این کمی زحمت دارد، اما شدنی است.
اما یعنی آن اسکریپت را طوری بنویسیم که روی Windows، MacOSX و Linux اجرا شود، در هر نسخه و پیکربندی ممکن. این حجم عظیمی از کار است (اگر نگوییم بیپایان).
ممکن است بپرسید: «چرا باید هر پیکربندی را پوشش دهد؟»
خب، چون اگر کسی نتواند این اسکریپت را اجرا کند، عملاً او را از استفاده از Exercism بازمیدارید.
این یعنی اسکریپت هرگز نباید از کار بیفتد.
اگر به هر دلیلی اسکریپت اجرا نشود، دانشآموز کاملاً متوقف میشود.
وجود یک bug در یکی از آن 52*3*n اسکریپتها یعنی دانشآموز دیگر نمیتواند در آن سیستمعامل از آن ترک استفاده کند.
چطور میخواهید این را test کنید؟
نمیتوانید.
اما میگویید میشد صرفاً یک فلگ --skip-tests اضافه کرد.
این پیشنهاد خوبی است، اما ما را به همان نقطهی شروع برمیگرداند: اینکه افراد میتوانند هر وقت بخواهند testها را دور بزنند.
فقط حالا در وضعیتی هستیم که در آن احتمال ارسال testهای خراب کمی کمتر است، پس راهنماها انتظار کمتری از این بابت دارند؛ یعنی وقتی testها واقعاً خراب باشند، ضربهاش سنگینتر و گیجکنندهتر است.
ممکن است بگویید: «اما مردم معمولاً چنین کاری نمیکنند.» درست است، برای بعضی زبانها که اجرای testها ۰٫۵ ثانیه طول میکشد.
اما برای زبانهایی که اجرای testها ۲۰ ثانیه طول میکشد، اینکه برای ارسال ۲۰ ثانیهی اضافه منتظر بمانند برای دانشآموزان بهشدت آزاردهنده است، و در نتیجه رد کردن testهای نهایی عادی میشود.
مهم نیست این گفتوگو به کجا میرسد؛ روشن است که پیچیدگی این ماجرا بسیار بیشتر از آن است که در نگاه اول به نظر میرسد. چالشهای فنیای هست که باید در نظر گرفت، مشکلات گردش کار که باید دربارهشان فکر کرد، و این واقعیت که ترکها آنقدر با هم متفاوتاند که کاری که برای یکی سریع و آسان است، برای دیگری دردناک است.
پس بهجای مطرح کردن این پیشنهاد که «چرا پیش از ارسال، testها را اجرا نکنیم»، بیایید یک سؤال بپرسیم: «چرا مردم راهحلهایی منتشر میکنند که testها را پاس نمیکنند؟»
و آنوقت ماجرا جالب میشود.
پاسخ کلی این است که گیر کردهاند یا گیج شدهاند.
و به کمک نیاز دارند.
یعنی ارسال testهای خراب، نشانهی مهمی برای راهنماهاست که این دانشآموز به کمک نیاز دارد.
بله، این آزاردهنده است، چون راهنماها فوراً نمیدانند code «درست» است یا نه. اما میتوانند code را دانلود و اجرا کنند تا آن را بررسی کنند (که بیشتر راهنماها برای راهحلهای غیرساده همین کار را میکنند) و بعد با اطمینان ۱۰۰٪ بدانند درست است یا نه.
و دانشآموزانی که گیر کردهاند و به کمک نیاز دارند، در نهایت بیشتر گیر نمیکنند و به کمک بیشتری نیازمند نمیشوند، بلکه به راهنمایی میرسند که میتواند سریعتر اصلاحات را ببیند و پیشنهاد کند.
توجه: ما در واقع این مشکل را با اجرای testها در سمت سرور حل میکنیم؛ کاری بزرگ و پرهزینه، اما ارزش این تلاش را دارد، هم برای تجربهی بهتر دانشآموز و هم، مهمتر از آن، برای صرفهجویی در وقت و انرژی راهنماها.
مورد دیگری هم هست؟
سه مورد:
-
این مقاله دربارهی «تفکر مرتبه دوم» خواندنی است. نقلقول «تا وقتی نمیدانید حصاری از ابتدا برای چه برپا شده، آن را برندارید» از همین مطلب است.
- کتاب «The Thing» نوشتهی جی.کی. چسترتون اینجا در دسترس است: https://archive.org/details/G.K.ChestertonTheThing.
- ممکن است ایدهی شما واقعاً تازه و عالی باشد. از مطرح کردنش نترسید و خجالت نکشید!
