Thread by @BashirSadjad

سرمایه‌گذاری گوگل برای تولید ابزارهای افزایش بهره‌وری، زیاد است. متاسفانه خیلی از این ابزارها در دسترس عموم نیست. ولی این‌جا، در ادامه مجموعه #نرم‌ابزار مروری کنیم بر ابزار مهمی که در دسترس شرکت‌های کوچک هم هست: محیط برنامه‌سازی یک‌پارچه (Integrated Development Environment).//

اول شروع کنم از بی‌سوادی خودم: تا ۱۲ سال پیش، تقریبا تمام تجربه‌ی حرفه‌ای برنامه‌نویسی من در ویم (vim) بود. با ورود به گوگل، برایم به‌سرعت روشن شد که بدون ابزار یک‌پارچه خوب، امکان درک یک سامانه بزرگ بسیار دشوار است، مثلا وقتی کد بعضی سرویس‌های جی‌میل را بررسی می‌کردم. //

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

در این رشته می‌پردازم به ۷ ویژگی مهم در افزایش بهره‌وری، با چند مثال از زبان‌های مختلف و چند پیشنهاد.

۱) کشف خطاهای ایستا در زمان تولید کد: اجرای مترجم (compiler) می‌تواند همزمان با نوشتن برنامه انجام شود. در این‌حالت منتظر ماندن برای ساخت برنامه (build) خیلی کم‌تر است //

چون مشکلات اولیه همه‌ی پرونده‌ها قبلا در محیط یک‌پارچه حل شده. همین‌جا توجه کنیم که زبان‌ها «گونه پویا» (dynamically typed) کمبود بزرگی در این زمینه دارند. احتمالا فراوان شنیده‌اید که برای پروژه‌های بزرگ از زبان‌های گونه پویا باید پرهیز کرد (ولی اگر مجبورید، ادامه را ببینید). //

۲) کامل‌سازی خودکار (auto-completion): یکی از لذت‌های برنامه‌نویسی وقتی است که محیط یک‌پارچه، آن‌چه می‌نویسم را کامل می‌کند. تسریع تولید کد با چنین قابلیتی بدیهی است. نکته مهم در این‌جا تمایز قائل شدن بین درک زمینه برنامه (context) و صرفا کامل کردن کلمه‌هاست (string matching). //

۳) پرش به تعریف (jump to declaration): وقتی تعریف یک تابع یا کلاس را می‌خوانیم، باید بتوان به‌راحتی رفت به جایی که آن تابع تعریف شده. محیط یک‌پارچه، درخت ترکیب مجرد (abstract syntax tree) برنامه را می‌سازد و از روی آن ارتباط بین هر کلمه با تعاریف دیگر را تشخیص می‌دهد. //

۴) پیدا کردن همه ارجاع‌ها (references): خیلی وقت‌ها لازم است با دیدن یک کلاس، تابع، یا تعریف دیگر، همه‌ی استفاده‌ها از آن در کل سامانه بررسی شود، مثلا برای دیدن پیاده‌سازی‌های یک کلاس مجرد. این قابلیت در واقع معکوس پرش به تعریف است و باز ساخت درخت ترکیب برای این‌کار لازم است. //

۵) قالب‌بندی (formatting): قبلا در این رشته که مربوط به بازبینی کد است، به اهمیت قوائد و شیوه‌های شکلی برنامه اشاره کردم. وقتی بازبینی در زبانی انجام می‌شود که ابزار مناسبی برای کنترل و تصحیح قالب‌ برنامه ندارد (مثلا کجا باید فاصله گذاشت کجا نه) //

https://twitter.com/BashirSadjad/status/1359959259539210243

روند بازبینی، مخصوصا برای تغییرات بزرگ مصیب است. برعکس وقتی ابزارهای خودکار برای قالب‌بندی وجود دارد، استاندارد کردن قالب کد خیلی ساده می‌شود و اصولا بازبینی متمرکز می‌شود روی مسائل مهم‌تر. پیکربندی این قالب‌ها با استانداردهای گوگل این‌جا موجود است: //
github.com/google/stylegu…

۶) به‌سازی (refactoring): به‌سازی انواع فراوانی دارد، مثل استخراج یک تابع از دل تابع دیگر. ساده‌ترین به‌سازی که پرکاربرد است، تغییر نام یک متغیر یا تابع یا گونه است. شاید چنین تغییری به‌نظر ساده باشد، ولی اعمال چنین تغییری در یک پروژه‌ی چند صد هزار خطی بدون ابزار مشکل است. //

۷) اشکال‌زدایی (debug): امکان اجرای همه یا قسمتی از یک سامانه‌ی بزرگ و بررسی تغییرات حافظه با اجرای تکه تکه‌ی این سامانه، بعضی وقت‌ها تنها راه یافتن خطاهای پیچیده است. البته اگر این امکان زیاد نیاز می‌شود، شاید نشانه‌ی پایین بودن پوشش تست‌های واحد باشد.//

https://twitter.com/BashirSadjad/status/1368607297115746310

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

یک دلیل مهم، دشواری خواندن متن این برنامه‌ها برای کسانی غیر از نویسندگان اصلی است. به‌بیان دیگر، نوشتن اولیه یک سامانه با این زبان‌ها ساده‌تر است ولی خواندن آن توسط دیگران، خصوصا برای سامانه‌های بزرگ مشکل است. این مشکل را در بعضی زبان‌ها تا حدی می‌شود حل کرد، مثلا در پایتون //

به‌خصوص از نسخه‌ی ۳.۵ به بعد، امکان «گونه راهنما» (type hint) به زبان اضافه شده و تجربه‌ی من در پروژه‌هایی که کد پایتون بزرگ داشته‌اند این است که استفاده‌ی عمومی از این راهنما‌ها، حداقل برای واسط عمومی (public interface) واحدها، به خوانایی کمک می‌کند. //
python.org/dev/peps/pep-0…

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

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

github.com/google/closure…

حاشیه: این مترجم جاوا اسکریپت متن‌باز است و آن پروژه‌ی محیط یک‌پارچه برای جاوااسکریپت هم بر اساس همین مترجم پیاده‌سازی شد. هرچند متاسفانه آن محیط، متن‌باز نشد، ولی امکاناتی مثل ساخت تدریجی (incremental build) که به مترجم اضافه شد، قابل دسترس است: //

github.com/google/closure…

نهایتا یک پیشنهاد: وقتی برای پروژه‌ای بزرگ مشغول انتخاب زبان‌های برنامه‌نویسی می‌شویم،‌ خوب است در کنار عوامل دیگر (مثل وضعیت کتاب‌خانه‌های لازم،‌ دانش اعضای تیم، اهمیت کارآیی برنامه‌ها، و …) به ابزارهایی که برای آن زبان‌ها داریم هم توجه کنیم، از جمله محیط‌های یک‌پارچه. //

پیوست: اغلب مثال‌های کدی که عکس آن‌ها در این رشته استفاده شد، از این مخزن کد و در محیط IntelliJ است:
github.com/GoogleCloudPla…

اگر از پایتون قبل از نسخه ۳.۵ استفاده می‌کنید (چرا؟) این مخزن از روش قدیمی «راهنمای گونه» استفاده می‌کند:
github.com/googlegenomics…