اکثر ما به عنوان برنامه نویس، به این شکل بوده که از توابع کوچک شروع کرده ایم و ساختارهای پیچیده تر را به تدریج یاد گرفته ایم؛ به عنوان مثال، به همه گفته اند که یک تابع بنویس که دو عدد را باهم جمع کند و حاصل را به عنوان خروجی بدهد؛ دانشجو هم احتمالا پس از مدتها تفکر عمیق، اندیشیدن و عرق ریختن، این کار بسیار پیچیده و چالش برانگیز را انجام داده است. این روش که به ما مساله ای داده شود و بعد خط به خط کد بزنیم تا به هدف برسیم به صورت پیش فرض در اکثر برنامه نویسان وجود دارد؛ با این حال، این روش کدزنی کاملا اشتباه است و بدلیل نحوه یادگرفتن برنامه نویسی، به صورت عمیق در همه ما نهادینه شده است. شاید برایتان سوال پیش آمده باشد که چطور بازیهایی که صدها هزار خط کد دارند، مدیریت می شوند؟ اگر سهوا خطی از کد بعدها اشتباها پاک شود، از کجا تیم توسعه متوجه می شود؟ git را فراموش کنید. خطاهای سهوی به احتمال زیاد بین کامیت ها گم می شود. در برنامه نویسی، اصطلاحی وجود دارد به نام test driven development. ایده کلی به این شکل است که اگر مساله ای دارید، نیایید و خط به خط، چیزی که از شما خواسته شده را بنویسید و بعد اجرا کنید که ببینید آیا درست کار می کند یا نه. این کار دو اشکال اساسی دارد. اول اینکه scalable نیست؛ زیرا اگر کد برنامه چند هزار خط باشد، این کار بسیار طاقت فرسا می شود. بدتر از این مورد، ممکن است شما کدی را بنویسید و کامل تست کنید و همه چیز مناسب باشد و از آن در جاهای مختلف استفاده کنید و همه چیز خوب باشد ولی بعد از مدتی به این نتیجه برسید که لازم است جاهایی با توجه به نیاز روز، تغییر کند. در این شرایط لازم است دستی تمامی جاهایی که قبلا کدتان استفاده شده را بررسی و دیباگ کنید. به صورت خلاصه اشاره کنیم، در توسعه TDD، به این شکل باید کار کنید که اول تست بنویسید که در تست ها تمامی نیازهای مساله گنجانده شده باشد. بعد شروع به پیاده سازی توابع و کلاسهای اصلی کنید که از آنها قرار است استفاده کنید؛ با این کار، در ابتدا که توابع و کلاسها پیاده نشده اند، به تعداد زیادی خطا دارید. با خواندن خطاها، کد لازم را پیاده سازی می کنید و خطا از بین می رود. یعنی به صورت واقعی به نیازها جواب می دهید و بعدها خیلی راحت همه تست ها قابل استفاده مجدد هستند. در این شرایط تستها همواره هستند و شما اگر نیاز باشد جایی را تغییر دهید، تستها به شما می گویند آیا کدهای قبلی خطا پیدا کرده اند یا نه. از سویی دیگر، این نوع کدزنی در بروزرسانی های کتابخانه های مورد استفاده بسیار مناسب است. اگر کتابخانه ای را بروزرسانی کردید و مشکلی برای کدتان به وجود آمد، با اجرای تست، بلافاصله متوجه می شوید.
شاید با خود فکر کنید که این نوع کد زنی به یادگیری عمیق چه ارتباطی دارد؟ جدای از چک کردن ابعاد تنسورها که بدیهی ترین نوع استفاده از این نوع روش است، در یادگیری عمیق موارد متنوعی هستند که لازم است با تست بررسی شوند؛ برای مثال، توزیع داده های ورودی، توزیع کلاسها یا بررسی data cleaning.
