آغاز Python
خیدو فان روسوم کار روی Python را در اواخر ۱۹۸۹ آغاز کرد؛ تجربهٔ زبان ABC در شکل‌گیری ایده‌های او مؤثر بود. نخستین انتشار عمومی Python در ۱۹۹۱ انجام شد.
چرا خوانایی مهم است؟
کد بیشتر از آنکه نوشته شود، خوانده و تغییر داده می‌شود. این نگاه برای تیم‌ها پرسشی عملی می‌سازد: آیا همکار بعدی می‌تواند هدف و محدودیت‌های کد را بفهمد؟ خوانایی جای آزمون را نمی‌گیرد، اما هزینهٔ فهم را کاهش می‌دهد.
خوانایی، قراردادی میان انسان‌ها
خوانایی تنها زیبابودن تورفتگی نیست. نام‌ها باید منظور را منتقل کنند، جریان اجرای برنامه قابل دنبال‌کردن باشد و رفتار پنهان تا حد امکان کاهش یابد. در یک تیم، کد توسط فردی خوانده می‌شود که شاید در زمان نوشتن آن حضور نداشته است. تصمیم‌های ظاهراً کوچک، مانند نام یک پارامتر یا شکل گزارش خطا، روی هزینهٔ فهم اثر می‌گذارند.
در روایت آغاز Python، تجربهٔ ABC و تمایل به محیطی قابل گسترش اهمیت دارند. این زمینه نشان می‌دهد یک زبان از صفر و بدون تأثیر ساخته نمی‌شود؛ طراح از تجربهٔ ابزارهای قبلی، نیاز کاربران و محدودیت‌های پیاده‌سازی می‌آموزد. نام و سلیقهٔ ظاهری زبان فقط بخشی از این تصمیم‌هاست.
گسترش‌پذیری همراه با مرز روشن
امکان افزودن قابلیت جدید، زمانی مفید است که قرارداد اتصال آن مشخص باشد. اگر هر افزونه بتواند بی‌قاعده وضعیت داخلی برنامه را تغییر دهد، انعطاف به شکنندگی تبدیل می‌شود. ورودی، خروجی، خطا و چرخهٔ عمر یک افزونه باید روشن باشد؛ همان اصولی که برای یک ماژول معمولی مهم‌اند.
برای مثال، یک پردازشگر فایل می‌تواند خواندن قالب‌های مختلف را به اجزای جدا بسپارد. برنامهٔ اصلی باید بداند هر جزء چه داده‌ای تحویل می‌دهد و با فایل خراب چگونه رفتار می‌کند. انتخاب زبان خوانا این مسئله را آسان‌تر بیان می‌کند، اما طراحی قرارداد همچنان بر عهدهٔ ماست.
برداشت آموزشی IROSG
یک اسکریپت کوتاه را که فقط خودت می‌فهمی انتخاب کن. نام‌های مبهم را عوض کن، ورودی‌ها را بررسی کن و بخشی را که به فایل یا شبکه وابسته است از منطق اصلی جدا کن. سپس از فرد دیگری بخواه تنها با خواندن کد و آزمون‌ها، هدف آن را توضیح دهد.
هدف تمرین، زیادکردن تعداد کلاس‌ها یا پیچیده‌کردن ساختار نیست. معیار، کاهش ابهام و آسان‌شدن تغییر است. خوانایی جای امنیت، مدیریت وابستگی یا آزمون را نمی‌گیرد؛ این‌ها باید در کنار هم باشند. متن اصلی فان روسوم در منابع، روایت مستقیم‌تری از انتخاب‌های آغازین زبان ارائه می‌کند.
خوانایی را در یک مسئلهٔ واقعی بسنجیم
دو برنامهٔ کوتاه را تصور کنید که هر دو یک فهرست داده را پردازش می‌کنند. یکی همهٔ تصمیم‌ها را در عبارت‌های فشرده جا داده و دیگری مراحل را با نام‌های روشن جدا کرده است. کوتاه‌تر بودن لزوماً به معنی قابل فهم‌تر بودن نیست. برای ارزیابی، از خواننده بخواهید بدون اجرای برنامه توضیح دهد ورودی چیست، چه چیزی حذف می‌شود و خروجی چه معنایی دارد. این تمرین مستقل است و ادعای بازسازی تصمیم‌های تاریخی خیدو را ندارد.
خوانایی را نباید با توضیح‌نویسی برای تک‌تک خطوط یکی دانست. اگر نام تابع هدف را روشن می‌کند، تکرار همان نام در یک توضیح کمکی نمی‌کند. در مقابل، دلیل یک قاعدهٔ استثنایی یا فرض دربارهٔ واحد داده می‌تواند بسیار ارزشمند باشد. از خود بپرسید همکار آینده برای تغییر امن این بخش چه چیزی را باید بداند. پاسخ به همین سؤال، مرز مناسبی میان توضیح مفید و شلوغی متن ایجاد می‌کند.
تمرین طراحی یک تابع کوچک
تابعی برای خلاصه‌کردن دادهٔ ساختگی در نظر بگیرید. پیش از نوشتن آن، نوع ورودی، حالت خالی و رفتار در برابر مقدار نامعتبر را مشخص کنید. سپس برای هر حالت یک نمونهٔ کوچک بسازید. این کار کمک می‌کند تعریف مسئله از جزئیات نوشتن زبان جدا شود. اگر هنوز نمی‌دانید ورودی نامعتبر باید رد شود یا نادیده گرفته شود، افزودن یک کتابخانهٔ تازه پاسخ این ابهام نیست.
در دور دوم، نام متغیرها و ترتیب مراحل را بازبینی کنید. آیا اطلاعات مربوط به یک تصمیم در چند جای دور از هم پراکنده شده است؟ آیا یک تابع چند مسئولیت نامرتبط دارد؟ هدف، رسیدن به شکل ظاهری ثابت برای همهٔ برنامه‌ها نیست؛ باید مسیر فهم متناسب با مسئله روشن شود. نتیجهٔ خوب می‌تواند تابعی کوتاه‌تر یا حتی کمی بلندتر باشد، مشروط بر اینکه قرارداد و منطق آن بهتر دیده شوند.
خطاها را به بخشی از رابط تبدیل کنیم
وقتی تابع نتواند کار را انجام دهد، مصرف‌کننده باید بداند چه اتفاقی افتاده است. برگرداندن یک مقدار خالی برای همهٔ شکست‌ها ممکن است تفاوت میان نبود داده، ورودی نامعتبر و اختلال خدمت را پنهان کند. روش مناسب به قرارداد برنامه بستگی دارد. در تمرین، هر نوع شکست را جدا تعریف کنید و بنویسید چه اطلاعاتی برای تصمیم بعدی لازم است.
گزارش خطا نباید اطلاعات محرمانه را آشکار کند. در یک نمونهٔ آموزشی، از مسیرها، شناسه‌ها و داده‌های ساختگی استفاده کنید. سپس بررسی کنید آیا پیام برای توسعه‌دهنده قابل پیگیری و برای کاربر قابل فهم است. این دو مخاطب نیاز یکسانی ندارند. طراحی خطا، فقط انتخاب عبارت مناسب نیست؛ تعیین می‌کند برنامهٔ بالادست چه چیزی را می‌تواند تکرار کند و چه چیزی نیاز به اصلاح ورودی دارد.
محیط اجرا بخشی از نتیجه است
کدی که امروز اجرا می‌شود باید با نسخهٔ زبان و وابستگی‌های مشخص قابل بازتولید باشد. تفاوت محیط می‌تواند نتیجهٔ آزمون را تغییر دهد و عیب‌یابی را دشوار کند. برای یک پروژهٔ کوچک، نسخه‌های لازم و روش راه‌اندازی را در یک مستند کوتاه ثبت کنید. این پیشنهاد به معنی استفادهٔ فوری از آخرین نسخه در محیط عملیاتی نیست؛ هر ارتقا باید با سازگاری و آزمون همراه باشد.
برای تمرین، پروژه را در محیطی تمیز راه‌اندازی کنید که به تنظیم‌های شخصی نویسنده وابسته نباشد. اگر مرحله‌ای فقط به خاطر چیزی که قبلاً روی دستگاه نصب بوده موفق می‌شود، آن وابستگی را ثبت کنید. سپس آزمون‌ها را با دادهٔ ساختگی اجرا کنید و نتیجه را نگه دارید. چنین کاری کیفیت همکاری را بهتر می‌کند و نشان می‌دهد خوانایی، علاوه بر متن کد، شامل قابل فهم بودن مسیر اجرا نیز هست.
کتابخانهٔ آماده و مسئولیت انتخاب
استفاده از یک کتابخانه می‌تواند کار را ساده کند، اما مسئولیت فهم قرارداد آن را حذف نمی‌کند. ورودی مجاز، رفتار خطا، محدودیت منابع و وضعیت نگه‌داری باید با نیاز پروژه سنجیده شوند. تعداد قابلیت‌های فهرست‌شده یا شهرت یک نام، جای آزمون یکپارچه با کاربرد واقعی را نمی‌گیرد. انتخاب خوب باید توضیح دهد چرا این وابستگی برای مسئلهٔ مشخص مناسب است.
پس از مطالعهٔ معرفی خیدو، یک بخش از پروژهٔ خود را برای خوانایی و بازتولیدپذیری بازبینی کنید. سه نتیجه ثبت کنید: کدام فرض روشن‌تر شد، کدام آزمون اضافه شد و کدام توضیح غیرضروری حذف شد. برای تاریخ Python و منشأ ایده‌ها به منابع اصلی رجوع کنید. کاربرد آموزشی این بخش، دعوت به کدنویسی قابل فهم است، نه نسبت‌دادن تمام سلیقه‌های امروزی ما به سازندهٔ زبان.
