به جای کپی/پیست کردن کُد، آن را تایپ کنید

فرض کنید در حال نوشتن فانکشنی در زبان برنامه‌نویسی مد نظر خود هستید و ناگهان به مشکلی برمی‌خورید که موجب می‌شود صفحهٔ مرورگرتان را باز کرده و در استک اورفلو به دنبال راه‌حل باگی که با آن مواجه شده‌اید بگردید که در آخر با کپی/پیست کردن یک بلوک کُد از جواب یکی از پاسخ‌دهندگان، مشکل خود را به کلی حل می‌کنید. اگر از روش بالا زیاد استفاده می‌کنید، یعنی اینکه از روش به اصطلاح Cargo-Cult Programming استفاده کرده‌اید که اگر بخواهیم تعریفی ساده از آن ارائه بدهیم، باید بگوییم که این مدل زمانی رخ می‌دهد که دولوپرها کُدی را بدون آگاهی از سازوکار دقیق‌اش از جایی به جای دیگر کپی/پیست می‌کنند.

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

به طور کلی، اگر قصد دارید تا علاوه بر کپی/پیست کردن کُد دیگران و رفع مشکلاتی که در حین توسعهٔ نرم‌افزار برای‌تان پیش می‌آید بهترین استفاده را از کدهای دیگر دولوپرها ببرید، بهتر است نکات زیر را در نظر بگیرید:

1. ابتدا یک بخش از کد را با دقت بخوانید.
2. ببینید این کد چه ویژگی‌هایی دارد و با کدام زبان برنامه‌نویسی نوشته شده است.
3. از تمام لایبرری‌ها و فریمورک‌هایی که در کُد استفاده شده، اطلاعات کافی به دست آورید.
4. از کاربرد این لایبرری‌ها و فریمورک‌ها اطمینان حاصل کنید.
5. متوجه ارتباط بین لایبرری‌ها و فریمورک‌های استفاده شده در کد بشوید.

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

درآمدی بر روش Interleaving Practice
یکی از تکنیک‌های رایج در یادگیری، استفاده از روشی با نام Blocked Practice است که تمرکز اصلی آن بر روی تکرار چندین بارهٔ یک تَسک است اما شاید جالب باشد که بدانید این روش تأثیر چندانی در بهبود یادگیری ندارد! جایگزین بهتر آن است که تلاش کنید یک مهارت را به شیوه‌های گوناگون انجام دهید که این رویکرد اصطلاحاً Interleaving Practice گفته می‌شود. به عنوان مثال، از دستور شرطی if در انواع و اقسام پروژه‌های متنوع استفاده کنید تا از ماهیت آن به طور کامل آگاهی پیدا کنید.

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

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

<label for="name"></label>
<div class="input-wrapper">
  <input type="text" id="name">
</div>

این مثال نشان می‌دهد که وقتی قصد دارید با استفاده از این کد یک فیلد جدید بسازید، ممکن است تغییر اَتربیوت for در label را فراموش کرده و باعث گردد عملکرد مورد انتظار را هرگز شاهد نباشیم. خبر ناامیدوارکننده اینکه اساساً مشکلاتی از این دست هرگز با تست‌های خودکار (یونیت تستینگ) و غیره مشخص نخواهند شد بلکه نیاز است تا به صورت دستی و یا بواسطهٔ Code Review توسط یک تِستِر یا خودِ دولوپر آزموده شوند.

مشکلاتی که کپی/پیست کردن در تست‌ها ایجاد می‌کنند
کپی/پیست در نوشتن تست‌ها هم گریبان دولوپرهایی که دغدغهٔ رسیدن به ددلاین را دارند می‌گیرد به طوری که وقتی برای یک فانکشن جدید از تستی که قبلاً نوشته‌ایم استفاده می‌کنیم، این احتمال وجود دارد که فراموش کنیم برخی پارامترها و چیزهایی که باید حتماً در فانکشن جدید تست شوند را آپدیت کنیم و مسائلی از این دست به سادگی باعث می‌شوند که تست به ما بگوید که فانکشنی مشکلی دارد و در نتیجه شروع به بررسی‌اش کنیم اما این در حالی است که مشکل از فانکشن جدید نیست، بلکه خودِ تست است که منجر به Fail شدن شده است!

در چنین مواقعی، رویکردی تحت عنوان Test Driven Development  یا به اختصار TDD پیشنهاد می‌شود؛ به عبارتی، ابتدا به ساکن یک فانکشن تست نوشته می‌شود سپس اقدام به کدنویسی فانکشن اصلی می‌کنیم به طوری که باید بتواند آن تست را پاس کند که این رویکرد تضمین می‌کند مشکلات به اصطلاح False-Positive به حداقل برسند.