دسته‌بندی بیکن‌ها:
ما معمولاً چراغ‌های راهنما یا بیکن‌ها را به دو دسته تقسیم می‌کنیم: بیکن‌های ساده (simple beacons) و بیکن‌های مرکب (compound beacons).

بیکن‌های ساده، عناصر نوشتاری کد هستند که نیازی به توضیح ندارند مانند نام متغیرهایی که به درستی انتخاب شده‌اند. در کد پایتون قبلی، root و tree بیکن‌های ساده هستند. در برخی از کدها، عملگرهایی مانند +، >، و && و عبارات ساختاری مانند if و else را می توان بیکن‌های ساده در نظر گرفت، زیرا پردازش و فهمیدن آنها کار ساده‌ای است و می توانند به خواننده کمک کنند تا عملکرد کد را به تنهایی کشف کند.

بیکن‌های مرکب ساختارهایی بزرگ‌تری هستند که از بیکن‌های ساده تشکیل شده‌اند. بیکن‌های مرکب برای تابع‌ها که از بیکن‌های ساده تشکیل شده‌اند، معنای لغوی می‌سازند. در کد پایتون قبلی، self.left و self.right با هم یک بیکن مرکب تشکیل می‌دهند. آنها به تنهایی اطلاعات زیادی درباره‌ی کد ارائه نمی‌دهند، اما وقتی در کنار هم قرار می‌گیرند به ما دید بهتری از کد می‌دهند. اجزای کد هم‌چنین می‌توانند به عنوان بیکن‌های ترکیبی عمل کنند. به عنوان مثال، یک حلقه for می‌تواند یک بیکن مرکب باشد زیرا حاوی متغیر حلقه، مقدار اولیه‌ی آن، مقدار اضافه‌شونده در هر تکرار و مقادیر مرزی آن است.

بیکن‌ها می‌توانند اشکال مختلفی داشته باشند. قبلاً دیدیم که نام متغیرها و کلاس‌ها می‌توانند نقش بیکن را بازی کنند و حتی سایر شناسه‌ها مانند نام متدها نیز می‌توانند مانند بیکن عمل کنند. علاوه بر نام‌ها، ساختارهای برنامه‌نویسی خاص مانند جا‌به‌جایی مقدار دو متغیر (swap) یا مقداردهی اولیه (initialization) یک لیست خالی نیز می‌توانند بیکن باشند.

بیکن‌ها به چانک‌ها شباهت دارند اما اکثر محققان آن دو را مفاهیم متفاوت و جداگانه‌ای می‌دانند. بیکن‌ها نسبت به چانک‌ها معمولا کوچک‌ترند. کرازبی (Crosby) نقش بیکن‌ها را در برنامه‌نویسی بررسی کرده و به این نتیجه رسیده است که برنامه‌نویسان باتجربه‌ هنگام خواندن و درک کد به شدت از بیکن‌ها استفاده می‌کنند در حالی که این موضوع درباره‌ی برنامه‌نویسان تازه‌کار صادق نیست.

نکته: هر زمان که لحظه‌ای مکث کردید و گفتید “آها، فهمیدم” و در آن لحظه درک بهتری از عملکرد کد پیدا کردید، توقف کنید و آنچه را که شما را به این نتیجه رسانده است یادداشت کنید. این عامل می‌تواند کامنت، نام متغیر، نام متد یا حتی مقدار تغییریافته‌ی یک متغیر باشد. همه این موارد می‌توانند بیکن یا فانوس راهنمای کد باشند.

به تجربه پی برده‌ام:

اگر می‌خواهم کارهای عقب افتاده‌ام را تمام کنم، بهتر است به جای برنامه‌ریزی آنها برای کاری که دوست ندارم مهلت (ددلاین) تعیین کنم! 🙂

چگونه کد قطعه‌بندی شده یا چانک‌شده (chunkable code) بنویسیم؟ — ادامه

راهکار سه: از فانوس‌های راهنما استفاده کنید
پیش‌گفتار:
اجازه دهید ابتدا معنی بیکن (beacon) را با هم مرور کنیم. در سایت farsi123.com معنی بیکن به قرار زیر است:

نمی‌دانم از چه زمانی به این نتیجه رسیدم برخی از واژگانی که در ذهنم با یکدیگر ارتباط معنایی درستی دارند، با تغییر شرایط و موضوع،‌ نه تنها ارتباط بین آنها تغییر می‌کند بلکه گاهی هیچ ارتباطی با هم پیدا نمی‌کنند. اصرار به حفظ ارتباط قبلی بین آنها با وجود تغییر شرایط،‌ من را به بیراهه خواهد برد. به گذشته که نگاه می‌کنم این بیراهه‌ها گاهی به ناکجا آباد رسیده است.

نمونه ۱:
در درس فیزیک در بحث قانون گازها گفته‌ می‌شد که با فرض ثابت بودن دما،‌ اگر فشار گاز را افزایش دهیم، حجم آن کاهش پیدا می‌کند. در نتیجه فشار گاز و حجم آن با یکدیگر رابطه غیرمستقیم دارند، افزایش یکی به کاهش دیگری منجر می‌شود.

شوک ۱: افزایش قطعیت منجر به کاهش عدم قطعیت نمی‌شود!
پیش از آن در ذهنم این گونه بود که بدیهی است که رابطه‌ی قطعیت و عدم قطعیت (شرایط غیرقطعی) مثل رابطه فشار و حجم گازها هستند. مثل رابطه‌ی نور و تاریکی است! افزایش یکی یعنی کاهش دیگری! اگر بتوانید قطعیت را افزایش دهید، عدم‌قطعیت (شرایط غیرقطعی) را کاهش داده‌اید.

بعدها به این نتیجه رسیدم که واقعا این گونه نیست. این اتفاق زمانی افتاد که داشتم کتابی در زمینه‌ی مدیریت پروژه می‌خواندم. شما نمی‌توانید با افزایش قطعیت،‌ عدم قطعیت (شرایط غیرقطعی) موجود را کاهش بدهید! (فکر کنم شما هم دچار شوک ذهنی شدید 🙂 ).

شما نمی‌توانید با برنامه‌ریزی دقیق روزهای آینده (افزایش قطعیت)، مانع از اتفاقاتی شوید که ممکن است در روزهای آینده رخ دهد (کاهش عدم قطعیت). به همین سادگی!

پس گفتار:
حالا هم نمی‌دانم چه بخش‌های دیگری از مدل‌های ذهنی‌ام به مبحث مورد استفاده وابسته‌اند و با تغییر مبحث،‌ کارکرد خودشان را از دست می‌دهند ولی من کماکان پای‌بند مدل ذهنی گذشته‌ هستم. به قول مولانا «چه دانم‌های بسیار است لیکن من نمی‌دانم»

به نقل از همشهری آنلاین:
آمار بالای باسوادی در گیلان بی‌شک مرهون تاریخ دیرپای راه‌اندازی مدرسه روستایی به سبک نوین و همگانی است؛ مدرسه‌ای که برای نحستین بار در سال ۱۳۰۴ شروع به کار کرد و حالا ۹۶ ساله شده است.

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

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

این مدرسه در حال حاضر با نام مدرسه محمد باقر صدر شناخته می‌شود.

گزیده:
«هرگاه به مدرسه قدم می‌گذارم، با مشاهده چهره‌های کثیف و تکیده، موهای ژولیده، و برق چشمانِ این کودکان فقیر، دستخوش ناآرامی و انزجار می‌شوم و همان حالتی به‌من دست می‌دهد که بارها از دیدن شراب‌خواران مست، بر من مستولی شده‌است. ای خدای بزرگ! چگونه می‌توانم آن‌ها را نجات دهم؟ نمی‌دانم به کدامین یک کمک کنم. من آموزش و پرورش را فقط برای توده‌ها می‌خواهم و نه کسی دیگر، مگر بتوانم پوشکین‌ها و لومونسف‌های آینده را از غرق‌شدن رهائی بخشم.»
لئو تولستوی

خاطره راهی است برای نگه داشتن آن چه دوستش دارید، آن چه که هستید و آن چه هرگز نمی‌خواهید از دست بدهید. کوین آرنولد

چگونه کد قطعه‌بندی شده یا چانک‌شده (chunkable code) بنویسیم؟

راهکار یک: از الگوهای طراحی (design pattern) استفاده کنید
اگر می خواهید کدی بنویسید که به راحتی قطعه‌بندی (چانک‌شده)‌ شده باشد، از الگوهای طراحی استفاده کنید. یافته‌های والتر تیچی (Walter Tichy)، استاد علوم کامپیوتر در موسسه فناوری کارلسروهه‌ی آلمان به صورت اتفاقی ارتباط بین قطعه‌بندی کدها با الگوهای طراحی را مورد بررسی قرار داده است. او به دنبال بررسی الگوهای طراحی بود و به ویژه علاقه داشت تا بررسی کند که الگوهای طراحی تا چه میزان می‌تواند هنگام نگهداری کد (افزودن ویژگی جدید یا رفع خطا) (maintenance) به برنامه‌نویسان کمک می‌کند.

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

نتایج این مطالعه نشان می‌دهد که دانستن الگوهای طراحی احتمالاً باعث افزایش توانایی شما برای قطعه‌بندی یا چانک‌سازی کدها را افزایش می‌دهد و به دنبال آن، به شما در پردازش سریع‌تر کد کمک می کند.

راهکار دو: توضیح (comment) بنویسید
آیا باید برای کد، توضیح (کامنت)‌ بنویسیم یا کد باید “خود بیان” (document itself) باشد؟ این پرسش یکی از پرسش‌های چالش‌برانگیز در دنیای برنامه‌نویسان است که نظرات متفاوت و متضادی درباره‌ی آن وجود دارد. محققان به این پرسش پرداخته‌اند و به یافته‌های جالبی رسیده‌اند.

تحقیقات نشان می‌دهد وقتی کدی حاوی توضیحات است، برنامه‌نویسان زمان بیشتری را برای خواندن آن صرف می‌کنند. ممکن است فکر کنید این یافته نشانه‌ی بدی است چون به این معنی است که خواندن توضیحاتِ همراه کد باعث کندی در خواندن و فهمیدن کد می‌شود. اما در واقع، این یافته نشان می‌دهد که وقتی برنامه‌نویسان کد را می‌خوانند به توضیحات همراه آن توجه می‌کنند و آن را می‌خوانند. به عبارت دیگر، این یافته نشان می‌دهد اضافه کردن توضیحات به کد، کار عبث و بی‌ارزشی نبوده است.

مارتا الیزابت کرازبی (Martha Elizabeth Crosby)، محقق دانشگاه هاوایی، مطالعاتی روی روش کدخوانی برنامه‌نویسان و نقش توضیحات همراه کد در کدخوانی انجام داده است. کار کرازبی نشان داد که برنامه‌نویسان مبتدی بیشتر از برنامه‌نویسان باتجربه و حرفه‌ای‌ به توضیحات کد توجه می‌کنند. یافته‌های کرازبی نشان می‌دهد افزودن توضیحات به کد می‌تواند روش خوبی برای کمک به برنامه‌نویسان تازه‌کار برای فهمیدن کد باشد.

پایان‌نامه کویین فن ( Quiyin Fan) در سال 2010 در دانشگاه مریلند با عنوان “The Effects of Beacons, Comments, and Tasks on Program Comprehension Process in Software Maintenance,” نشان داد که توسعه‌دهندگان هنگام خواندن کد، وابستگی شدیدی به توضیحات کد دارند. به ویژه توضیحات کلانی مانند “این تابع یک درخت دودویی را چاپ می‌کند” می‌تواند به برنامه‌نویسان کمک کند تا قطعات بزرگتر کد را تکه‌تکه کنند و بفهمند. از سوی دیگر، توضیحات جزیی مانند “یکی به n اضافه می‌کنیم” پس از خطی که متغیر n را یکی افزایش داده است (n = n+1)،‌ نه تنها کمکی به خواندن و فهم کد نمی‌کند بلکه فرایند قطعه‌بندی (چانک‌سازی) را دچار اختلال و کندی می‌کند.

منابع:
منبع: کتاب «مغز برنامه‌نویس» از انتشارات منینگ

گزیده:

لگوهای طراحی نباید بدون تفکر و بدون یک فرایند تصمیم‌گیری (بدون قید و شرط) مورد استفاده قرار گیرند. اغلب آنها با اضافه کردن سطوحی برای ارتباط غیرمستقیم اجزا باعث انعطاف‌پذیری و تغییر‌پذیری می‌شوند و این سطوح اضافه‌شده می‌توانند موجب افزایش پیچیدگی طراحی یا کاهش کارایی گردند. در نتیجه، الگوهای طراحی فقط زمانی باید استفاده شوند که انعطاف‌پذیری ایجادشده توسط آنها واقعا ضرروی باشد.
اریک گاما یکی از GoF