چیزهای اضافی را لود نکنید!

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

در چنین مواقعی می‌بایست تمام تلاش خود را به‌کار بندیم تا وابستگی‌های پروژه همچون ماژول‌ها، لایبرری‌ها و غیره کاملاً شفاف بوده و اگرهم تمایل نداریم تا مثلاً لایبرری‌های بلااستفاده را حذف کنیم، حتماً می‌بایست به‌نوعی مشخص شوند (که این کار را با کامنت‌گذاری صحیح می‌توان انجام داد).

این قضیه نه‌تنها در مورد لایبرری‌های به‌اصطلاح Third Party صدق می‌کند، بلکه در مورد کلاس‌ها، متدها و حتی متغیرها هم صادق است؛ به‌عبارت‌دیگر، گاهی در سورس‌کد برخی پروژه‌ها فانکشن‌هایی را می‌بینیم که در هیچ کجای پروژه فراخوانی نشده‌اند و اما کماکان وجود داشته و حتی کامنت‌ هم نشده‌اند!

نکته در صنعت توسعهٔ نرم‌افزار منظور از اصطلاح Third Party، کامپوننت‌های توسعه داده شده توسط هر تیم توسعه، شرکت و یا گروهی به‌غیر از توسعه‌‌دهندهٔ اصلی یک محصول (لایبرری، زبان‌برنامه‌نویسی، فریمورک و غیره) است که چنین کامپوننت‌هایی یا به‌صورت اپن‌سورس و رایگان و یا به‌صورت پولی عرضه می‌گردند. در چنین شرایطی، وقتی که می‌خواهیم اقدام به حذف بخش‌هایی از سورس‌کد کنیم که دیگر مورد استفاده قرار نمی‌گیرند -همچون لایبرری‌های قدیمی یا حتی کلاس‌های بلااستفاده- حتماً می‌بایست به‌خاطر داشته باشیم اصلاً نباید این اطمینان را داشته باشیم که ۱۰۰٪ در هیچ‌کجای پروژه از موارد مدنظر استفاده نشده‌ است.

برای اطمینان حاصل کردن از این موضوع، ابتدا باید لایبرری را به‌صورت موقت حذف کرده سپس به انحاء مختلف شروع به تست پروژه کنیم تا مطمئن شویم که بدون حضور مثلاً لایبرری X، پروژه کماکان بدون مشکل کار می‌کند.

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