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

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

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

دلیل دوم این است که اندازه‌ و ظرفیت حافظه‌ی کوتاه‌مدت بسیار محدود است. جرج میلر اعتقاد داشت که اندازه‌ی حافظه‌ی کوتاه‌مدت برابر عدد ۷ به‌علاوه-منهای ۲ است (یعنی حافظه‌ی کوتاه‌مدت بین ۵ تا ۹ جای خالی دارد). تحقیقات اخیر نشان می‌دهد که ظرفیت حافظه‌ی کوتاه‌مدت ما از این هم کمتر است و عددی بین ۲ تا ۶ است.

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

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

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

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

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

به خاطر سپردن محل‌ مهره‌ها با این شیوه فقط در صورتی امکان‌‌پذیر است که در حافظه‌ی بلندمدت شما مفهوم « گشایش سیسیلی» ذخیره شده باشد.

بعضی از شطرنج‌بازان خبره مهره‌ها را به کمک بازی‌های قبلی خود، بازی‌های معروف یا بازی‌هایی که تماشا کرده بودند به یاد می‌آوردند. مثلا بازی کاسپارف و آناندا در نیورک در سال ۱۹۹۵. بدیهی است که برای این شیوه‌ی به خاطرسپاری چینش مهره‌ها باید اطلاعاتی در حافظه‌ی بلندمدت شما ذخیره شده باشد. شطرنج‌بازان متوسط که سعی می‌کنند محل تک‌تک مهره‌ها را به خاطر بسپارند خیلی زود با این مساله رو به رو می‌شوند که فضای کافی در حافظه‌ی کوتاه‌مدت خود پیدا نمی‌کنند و به زبان عامیانه، حافظه‌شان پر می‌شود.

دکتر گروث این گروه‌ها یا قطعات اطلاعاتی را که افراد، اطلاعات را به کمک آنها با هم ترکیب و نگهداری می‌کنند، چانک یا قطعه‌ی اطلاعاتی نامید.او «گشایش سیسیلی« را یک چانک در نظر گرفت. نکته جالب در مورد چانک‌ها این است که که آنها می‌توانند فقط در یکی از جاهای خالی حافظه‌ی کوتاه‌مدت جا شود (به یاد داشته باشید که حداکثر ۶ جای خالی وجود دارد).

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

برنامه‌نویسان خبره کد را بهتر از برنامه‌نویسان مبتدی به یاد می‌آورند.
در سال ۱۹۸۱ کاترین مک‌کیتان در آزمایشگاه بل تلاش کرد آزمایش گروث را با برنامه‌نویسان تکرار کند. او ۵۴ برنامه‌نویس خبره، متوسط و مبتدی را انتخاب کرد و ۳۰ خط از یک برنامه را که با زبان الگول نوشته شده بود به آنها نشان داد. برنامه‌نویسان ۲ دقیقه وقت داشتند تا کد را بخوانند. بعد از آن باید کد را تا جایی که یادشان مانده بود بازنویسی کنند.

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

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

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

البته گیجی و سردرگمی اگر برای مدت کوتاهی طول بکشد مشکلی ایجاد نمی‌کند و موضوع مهمی نیست. اما هیچ‌کس نمی‌خواهد برای مدت طولانی و بیش از حد در گیجی و سردرگمی بماند؛

گیج‌شدن موقع کدنویسی می‌تواند به سه دلیل در مغز یک برنامه‌نویس ایجاد شود:
– کمبود دانش (lack of knowledge)
– نداشتن دسترسی آسان به اطلاعات (lack of information)
– کمبود قدرت پردازش (lack of processing power)

هنگام خواندن یا نوشتن کد، سه فرایند شناختی (cognitive processes)‌ درگیر می‌شوند:
– فرایند نخست، فرایند بازیابی اطلاعات از حافظه‌ی بلندمدت (long-term memory) است، به عنوان مثال معنی کلیدواژه‌های زبان از این حافظه استخراج می‌شود.
– فرایند دوم، فرایند بازیابی اطلاعات از حافظه‌ی کوتاه‌مدت (short-term memory) است. اطلاعات مربوط به برنامه‌‌ای که روی آن کار می‌‌کنید در حافظه‌ی کوتاه‌مدت شما ذخیره می‌شود. نام متدها یا متغیرهای برنامه بخشی از این اطلاعات هستند.
– فرایند سوم درگیر حافظه‌ی فعال (working memory) است. در اینجاست که پردازش کد اتفاق می‌افتد. به عنوان مثال موقعی که اجرای کدی را به صورت ذهنی دنبال می‌کنیم (trace) ، این فرایند شناختی درگیر می‌شود.

هر سه فرایند شناختی هنگام خواندن کد فعال هستند و البته مکمل یکدیگر نیز هستند. به عنوان مثال، اگر حافظه‌ی کوتاه‌مدت شما با نام متغیری مانند n روبه‌رو شود، مغز شما حافظه‌ی بلندمدت را برای یافتن برنامه‌های مشابه و مرتبطی که در گذشته دیده‌اید جستجو می‌کند. یا هنگامی که به کلمه‌ای مبهم برمی‌خورید، حافظه‌ی فعال شما به کار می‌افتد و مغز شما سعی می‌کند در این زمینه معنی مناسب را تعیین کند.

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

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

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

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

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

چو دخلت نیست خرج آهسته‌تر کن که می‌گویند ملاحان سرودی
اگر باران به کوهستان نبارد به سالی دجله گردد خشک رودی

عقل و ادب پیش گیر و لهو و لعب بگذار که چون نعمت سپری شود سختی بری و پشیمانی خوری.»

امور مالی شخصی (Personal Finance):
امور مالی شخصی، کاربردی از مبانی علم مالی در تصمیم‌گیری‌های پولی یک فرد یا یک خانواده است. این موضوع به چگونگی درآمدزایی، بودجه‌بندی، پس‌انداز و خرج کردن منابع مالی توسط افراد یا خانواده‌ها با در نظر گرفتن ریسک‌ها و رخدادها در زندگی آینده، می‌پردازد. [ویکی پدیا]. همان طور که از تعریف هم برمی‌آید این حوزه «کاربردی» است از «علم مالی» و در نتیجه مانند هر «کاربرد» دیگری نیازمند یادگیری و تجربه است. پیشنهاد می‌کنم اگر تاکنون آن را نیاموخته‌اید، با یک عزم عالی و برنامه‌ای مناسب، آن را هر چه زودتر بیاموزید.

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

آدرس گفتگو در یوتیوب:‌ اینجا
آدرس گفتگو در آپارات:‌ اینجا

گزیده:
شما ناچارید بر پول‌ خود کنترل داشته باشید وگرنه فقدان آن تا ابد شما را کنترل خواهد کرد. دیو رمزی

سلام ری‌را جان،

حال همه‌ی ما خوب است!

…

از نو برایت می‌نویسم

حال هیچ کدام ما خوب نیست!

باور کن ری‌را!

پ.ن.
امروز مادر یکی از دوستان عزیزم به دلیل کرونا از دنیا رفت! روح‌شان شاد!
ای داد بیداد!

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

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

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

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

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

جا خوردم! وای! چه کار جالبی! مدیریت ظرفیت پذیرش باغ به کمک سطل‌ها! وای! چه کلاس آموزشی شگفت‌انگیزی!

یادم افتاد که دیوید جی اندرسون در مقدمه‌ی کتاب کانبان خود مثالی از باغ‌های سلطنتی توکیو آورده بود. او نوشته بود که کارکنان موزه از یک سیستم کانبانِ ساده‌ ولی کارا برای مدیریت بازدیدکنندگان استفاده می‌کنند. آنها موقع ورود به هر بازدیدکننده یک کارت (شبیه به کارت بازی یا کارت دانشجویی) می‌دهند و موقع خروج، آن را بازدیدکننده پس می‌گیرند. هر وقت این کارت‌ها تمام می‌شد (ظرفیت داخل باغ تکمیل می‌شد)، بازدیدکنندگان باید پشت درب ورودی منتظر بمانند تا کارت‌ها برگردانده شود. چقدر شگفت‌انگیز!

پس‌گفتار:
با خود فکر می‌کنم که دنیا پر است از آموختنی‌ها! می‌توانم از هر پدیده و از هر فردی یاد بگیرم، حتی از بازدیدِ یک باغ میوه! امیدوارم که شاگرد بااستعدادی باشم.

گزیده:
“کانبان نه یک متدلوژی توسعه‌ی نرم‌افزار است و نه رویکردی برای مدیریت پروژه.” دیوید جی اندرسون

منابع:
عکس اول، عکس دوم

Writing code is about making your computer do what you need.

Writing good code is about enabling teams of strangers 5 years from now to make their computers do what they need.

François Chollet

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

قرارداد:
قرارداد یا عقد یا پیمان یا کنترات یک توافق الزام‌آور میان اشخاص است که حقوق و تکالیف طرفین آن را تعیین می‌کند. در تعبیر حقوقی به توافق دو یا چند اراده در جهت ایجاد یک اثر حقوقی گویند. [ویکی پدیا]
همان طور که از متن تعریف بر می‌آید قرارداد، “حقوق” و “تکالیف” طرفین را تعیین می‌کند. برای نمونه در قرارداد پروژه بین پیمانکار و کارفرما تعیین می‌شود که پیمانکار چه “تکالیف” و چه “حقوقی” دارد و همین طور کارفرما چه “تکالیف” و “حقوقی” دارد. برای مثال در یک پروژه‌ی نرم‌افزاری، پیمانکار مکلف است تا پایان ماه اول، پروتوتایپ سیستم را به کارفرما تحویل دهد و تحویل پروتوتایپ در پایان ماه اول، حق کارفرماست. برای انجام پروتوتایپ، کارفرما مکلف است تا مستندات تعیین‌شده را در اختیار پیمانکار قراردهد (تکلیف کارفرما).

به زبان ساده‌تر:
– کار: تهیه پروتوتایپ
– تکالیف کارفرما: تحویل مستندات تعیین‌شده به پیمانکار
– تکالیف پیمانکار: تحویل پروتوتایپ در مدت یک ماه

قراردادها در برنامه‌نویسی:
تا جایی که می‌دانم هر سیستم نرم‌افزاری از مجموعه‌ای از عناصر یا المان‌ها تشکیل شده است. این عناصر می‌توانند اجزایی مانند تابع (function)، کلاس (class) یا رویه‌ها (procedure) باشند. این عناصر با مکانیزم‌هایی می‌توانند با همدیگر تعامل کنند. یک تابع می‌تواند تابع دیگری را صدا کند و آن تابع نیز به نوبه‌ی خود می‌تواند تابع بعدی را صدا کند. این زنجیره‌ی تعامل یعنی کنش و واکنش بین اجزای سیستم، رفتار آن را شکل می‌دهد.

اجازه بدهید در ساده‌ترین حالت ممکن بحث را ادامه بدهیم. فرض بفرمایید دو تابع f و g وجود دارند. تابع f برای انجام کاری تابع g را صدا می‌کند. کار مورد درخواست را هم محاسبه ریشه‌ی دوم یک عدد طبیعی (1,2,3,…) تعریف می‌نماییم.
در این حالت می‌توانیم فرض کنیم که تابع f مانند کارفرما و تابع g مانند پیمانکار عمل خواهند کرد. نتیجه:
– کارفرما: تابع f
– پیمانکار: تابع g
– موضوع قرارداد: محاسبه ریشه‌ی دوم یک عدد طبیعی

حالا بیایید کمک کنیم تا بین تابع f و g قراردادی منعقد شود:
– کارفرما مکلف است که فقط اعداد طبیعی را ارسال کنید
– کارفرما محق است که ریشه‌ی دوم عدد ارسال شده را به صورت یک عدد با دو رقم اعشار دریافت کند
– پیمانکار مکلف است که ریشه‌ی دوم عدد را به دو رقم اعشار گرد کند (round)
– پیمکانکار محق است که عدد طبیعی دریافت کند در غیر این صورت مکلف است خطا یا استثناء (Exception) را گزارش نماید.

حالا که قرارداد بین کارفرما و پیمانکار منعقد شد، می‌توانیم پیاده‌سازی تابع g را شروع کنیم. پیاده‌سازی را می‌توان به سه بخش تفکیک کرد:
– بخش اول: تابع g ابتدا باید کنترل کند که عددی که دریافت کرده، یک عدد طبیعی (صحیح و بزرگتر از صفر) است. طبق قرارداد، اگر عدد دریافتی، یک عدد طبیعی نباشد، تابع g باید خطا یا استثناء را گزارش کند (بازگرداندن کد خطا یا پرتاب استثناء (Throw Exception)).

– بخش دوم: تابع g باید روشی برای محاسبه ریشه‌ی دوم یک عدد طبیعی پیاده‌سازی کند. برای انجام این کار، می‌توان از “تقریب” در ریاضیات استفاده کرد.

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

تمام!

پس‌گفتار:
این شیوه‌ی نگاه به اجزای نرم‌افزاری در قالب یک کارفرما، یک پیمانکار و یک قرارداد، روشی ساده، مفید و کاربردی برای طراحی و پیاده‌سازی در نرم‌افزار است. ایده‌ی اصلی این الگو از روش “طراحی با قرارداد” (Design By Contract) است. این روش که توسط برتراند مایر ابداع شده است در دنیای شیءگرایی بسیار معروف و جاافتاده است.

نکته‌ای که در این الگو به آن افزوده شده این است که با در نظر نگرفتن شی‌گرایی و انتقال این ایده به عناصری مانند تابع (function)، این الگو برای زبان‌هایی که ماهیت شی‌ءگرایی هم ندارند قابل استفاده است از جمله پایتون و جاوا اسکریپت.
امیدوارم که قراردادهای بسیار باارزشی منعقید کنید!

گزیده:
اگر می‌خواهید سریع‌تر پیش بروید، اگر می‌خواهید سریع‌تر کارها را تمام کنید، اگر می‌خواهید نوشتن کد برای‌تان آسان و راحت باشد، کاری کنید که خواندن کدتان آسان و راحت باشد.
رابرت سی. مارتین