یکی از جملات مشترک بین بسیاری از دولوپرها در هر سطحی، گزارهٔ «از خواندن کد دیگران متنفرم» است! به هر حال، توان خواندن و بررسی کد دیگر دولوپرها یک مهارت لازم و ضروری است، خواه به این کار علاقه داشته باشیم و خواه از آن بیزار و یکی دیگر از دلایلی که اکثر دولوپرها از خواندن کد دیگران دوری می‌کنند این است که آن کد توسط خودشان نوشته نشده است و بیم آن می‌رود که در درک آن دچار مشکل شوند. به نظر می‌رسد که دلیل اصلی اجتناب اکثر دولوپرها از خواندن سورس‌کد سایر همکارانشان این باشد که وقتی کد می‌زنیم، الگوریتم‌های مختلفی در ذهنمان شکل می‌گیرد، به مسئله از زوایای مختلفی نگاه می‌کنیم، ارتباط کدی که می‌زنیم با سایر بخش‌های اپلیکیشن را نیز مد نظر داریم و به طور کلی، در حال انجام کاری خلاقانه هستیم؛ اما کسی که اقدام به خواندن کد می‌کند، ذهنش درگیر هیچ‌کدام از مسائل بالا نمی‌شود و در کل کاری منفعلانه انجام می‌دهد و همین می‌شود که از این کار لذت نخواهد برد.
کدی که روی صفحه می‌بینید ممکن است چندین نفر را به خود درگیر کرده باشد؛ ممکن است کلی بحث و همکاری رویش انجام شده باشد و همچنین ممکن است هفته‌ها روی این کد برای مطابق شدن آن با یکسری محدودیت‌های مستندنشده کار شده باشد. در یک کلام، سورس‌کد فقط برای دولوپر اصلی گویا و شفاف بوده و این در حالی است که شما از هیچ‌کدام زیر و بم‌های آن خبر ندارید (به عنوان یک خوانندهٔ سورس‌کد، شما فقط محصول تمام‌شده و به عبارتی کیوردها، متغیرها، فانکشن‌ها و ... روی صفحه را می‌بینید و اگر به این قانع نباشید، بایستی کمی کنجاوی‌تان را بیشتر کرده و به رمزگشایی سورس‌کد بپردازید.)
به هر حال، این شتری است که به احتمال قریب به یقین روزی درب خانهٔ اکثر دولوپرها خواهد خوابید و از همین روی بهتر است با راه‌کارهایی که سرعت بخشیدن به این کار از یکسو و همچنین لذت‌بخش کردن این فرایند از سوی دیگر را امکان‌پذیر می‌سازد آشنا شوید و این همان چیزی است که در ادامه قصد داریم مورد بررسی قرار دهیم.
کنجکاو باشید
وقتی برای اولین بار در یک کدبیس شروع به کنکاش می‌کنید، ممکن است خودتان را یک دولوپر احساس نکنید؛ بلکه بیشتر احساس یک باستان‌شناس یا کارآگاه خصوصی داشته باشید! اگر این‌قدر خوش‌شانس باشید که با کدبیسی کار کنید که از ابتدا در ورژن کنترل بوده باشد، بهتر است جشن بگیرید چرا که می‌توانید به حجم قابل‌توجهی از متادیتاها دسترسی داشته باشید که به فهم شما، نه تنها روی کد بلکه روی کانتکس، بسیار کمک می‌کند (در ادامه فرض بر این گذاشته می‌شود که از سیستم ورژن کنترل Git استفاده شده است.)
Git Blame: از git blame می‌توانید استفاده کنید تا نام دولوپر، آخرین تاریخ تغییرات و حتی کامیت هر یک خط کد را به دست آورید اما اگر بدشانسی بیاورید، ممکن است ده‌ها دولوپر که حتی اسم‌شان هم به گوش‌تان نخورده، کدهای موجود را نوشته باشند! جدای از این مسائل، سعی کنید حس و طرز تفکر دولوپرهای اصلی را در خود ایجاد کنید. اگر هم به توابع عجیب‌و‌غریبی برخوردید، از git blame برای پیدا کردن دولوپر اصلی کمک بگیرید تا بتوانید از آن‌ها اطلاعات لازم را کسب کنید.
Git Log: از git log برای دیدن تاریخچهٔ کلی ریپازیتوری استفاده کنید به طوری که این دستور پیام‌های کامیت‌ها را چک می‌کند. اگر دنبال موضوع خاصی در پیام‌های کامیت می‌گردید، بهتر است grep را فراموش نکنید. برای دیدن تاریخچهٔ یک فایل نیز بهتر آن است که به دستور git log فِلگ p- را هم اضافه کنید. به افرادی که آخرین تغییرات را در فایل‌ها انجام داده‌اند دقت کنید، چرا که اگر سؤالی برایتان پیش آید، منبع مناسبی برای جواب‌های شما هستند (البته اگر تیم را ترک نکرده باشند.)
به زمان گذشته برگردید
می‌توانید هر کامیتی که می‌خواهید را بررسی کرده و در صورت نیاز آن را اجرا کنید به طوری که گویی آخرین نسخه از نرم‌افزار است. البته بهتر است اول کامیت‌های روشن و شفاف را بررسی کنید و بعد به سراغ کامیت‌هایی که مرتبط با رفع باگ هستند بروید. اگر پروژه بر روی گیت‌هاب یا سایر سرویس‌های مشابه مثل گیت‌لب باشد، می‌توانید دید مناسبی با خواندن مسائل و مشکلات، پول ریکوئست‌ها و بررسی کدها به دست آورید. به مشکلاتی که بیشترین بحث و گفت‌وگو‌ها را ایجاد کردهاند بیشتر دقت کنید زیرا ممکن است نقاط مشکل‌زایی باشند که احتمالاً با آن‌ها برخورد خواهید داشت و سودش این است که قبل از برخورد با مشکل، نحوهٔ رفع کردنش را یافته‌اید.
جزئیات را بررسی کنید
مشخصات پروژه کارکردی همچون کامنت‌های داخل سورس‌کد دارند. به عبارتی، مشخصات و جزئیات ماژول‌ها را بخوانید تا بدانید که توابع و کلاس‌های هر ماژول چه کاری انجام می‌دهند و برای مدیریت آن‌ها چه شرایط خاصی طراحی شده است. علاوه بر این، توضیحات مرتبط با نحوهٔ بهکارگیری نرم‌افزار را نیز بخوانید تا درک مناسبی از اینکه کاربران با این نرم‌افزار چه‌طور ارتباط خواهند داشت و برنامه از چه فرایندهای کاری برخوردار است داشته باشید.
اهمیت کامنت‌ها را نادیده نگیرید
اگر به تابعی گیج‌کننده برخوردید و خواندن کامنت مربوط به آن تابع موضوع را پیچیده‌تر کرد، به این فکر کنید که کامنت مد نظر احتمالاً آپدیت نشده است. چشمان اکثر دولوپرها در طول چندین سال کدنویسی به گونه‌ای برنامه‌ریزی می‌شوند تا به صورت خودکار خطوط مرتبط با توضیحات کامنت‌های سورس‌کد را رد کنند و این در حالی است که ممکن است در کامنتی که هیچ توجهی به آن نمی‌کنیم، نحوهٔ بهکارگیری بخشی از کد که داریم آن را بررسی می‌کنیم توضیح داده شده باشد.
نقطهٔ شروع سورس‌کد را بیابید
موضوع پیش‌پا افتاده‌ای به نظر می‌رسد اما مطمئن شوید که می‌دانید شروع کار از کجای کد است و از آن پس، کدام‌یک از سایر بخش‌های کد یکی پس از دیگری به اجرا در می‌آیند. نکته‌ٔ مهم اینکه به فایل‌هایی که به اصطلاح ایمپورت شده‌اند، کلاس‌هایی که آبجکتی از روی آن‌ها تعریف شده و فایل‌های پیکربندی نگاهی بیاندازید. برخی از ماژول‌ها ممکن است برای اهداف کلی نوشته شده باشند و از کدبیس جدا باشند؛ این ماژول‌ها عملکرد جزئی‌تر و قابل‌هضم‌تری دارند که باید با آن‌ها آشنا بشوید که این آشنایی قبل از رفتن به سراغ کد برنامه اصلی، الزامی به نظر می‌رسد.
دستور git blame را روی چنین فایل‌هایی اجرا کنید و ببینید کدام قسمت‌ها اخیراً تغییر کردهاند. قسمتی از کد که به تازگی تغییر کرده ممکن است به شما سرنخ‌هایی از چالش‌هایی که تیم توسعه در هفته‌های اخیر با آن‌ها دست‌وپنجه نرم کردهاند بدهد (شاید لایبرری جدیدی به کار گرفته باشند و یا شاید پیوسته درگیر تنظیم لایبرری‌ای بوده‌اند که به خوبی عمل نمی‌کرده است و شاید هم کدهایی باشند که به طور معمول باید آپدیت می‌شده‌اند.) سعی کنید که ارجاعات به این ماژول‌ها را در سورس‌های دیگر بیابید تا تصور بهتری از مکان و زمان استفاده از این ماژول‌ها به دست آورید. این موارد می‌تواند دید کلی بهتری از کاربردشان در برنامه اصلی به شما بدهند.
سبک کدنویسی موجود را فرا بگیرید
تنها دلیلی که شما زمان گرانبهای خود را صرف یادگیری چیزهایی در مورد سورس‌کد مد نظر می‌کنید این می‌باشد که قرار است کدهای جدیدی به این نرم‌افزار بیافزایید و یا نگهداری آن را برعهده گیرید؛ پس بهتر است تا به اصطلاحاً Coding Style دقت کنید. قطعاً این مسئله شامل موضوعات سطحی مانند شیوه‌های نام‌گذاری کلاس‌ها و متغیرها، فاصله‌بندی و غیره می‌شود، اما مهم‌تر از همه، آشنایی با شیوهٔ کدنویسی دولوپرهای قبلی است.
پاسخ به این سؤال که «سطح به اصطلاح Abstraction سورس‌کد چقدر است؟» سرنخی برای ادامهٔ کار می‌تواند باشد به طوری که اگر کدی با لایه‌های انتزاعی بسیاری نوشته شده است، از شما نیز انتظار می‌رود همین نوع کدنویسی را ادامه دهید که در غیر این صورت، دولوپری که پس از شما قرار است روی این سورس‌کد کار کند، به مراتب گیج‌تر از شما خواهد شد. در یک کلام، سعی کنید از Coding Style یکسانی در زمان نوشتن کدها استفاده کنید.
اگر به شیوه‌ای از کدنویسی برخوردید که مخالف آن هستید، بهتر است قبل از خودسرانه کنار گذاشتن آن، با هم‌تیمی‌هایتان درباره‌اش صحبت کنید تا احتمال تغییرش در آینده را ممکن سازید. حتماً از ترکیب کردن چندین سبک کدنویسی مختلف در یک فایل یا ماژول بپرهیزید؛ هرچه بیشتر به نظر برسد که فایل را یک نفر نوشته، بهتر است و به عنوان یک قانون کلی، انطباق و همسانی در کد، به مراتب از زیبایی‌اش مهم‌تر است.
انتظار کدهای بی‌ارزش را داشته باشید
ممکن است توابعی را بیابید که هیچ‌گاه استفاده نشده‌اند (حتی ممکن است فایل‌هایی را با همین شرایط بیابید!) ممکن است به کدهای کامنت‌گذاری شده‌‌ای بربخورید که سال‌ها است تغییر نکرده‌اند که با استفاده از دستور git blame می‌توان به این موضوع پی برد. زیاد وقت‌تان را روی فکر کردن به این موارد هدر ندهید زیرا اگر این کدها لازم بودند، قطعاً یک نفر در بررسی‌های قبلی این‌ها مشخص می‌کرد پس شاید بتوانید آن‌ها را حذف کنید و با این کار، فشار کاری دولوپر بعدی را نیز کم خواهید کرد (البته نیاز به توضیح نیست که اتخاذ چنین تصمیمی بسیار پرریسک است.)
کم نیاورید
در فرایند سورس‌کد خوانی، زمان‌های زیادی پیش می‌آید که خود را در مخمصه می‌یابید که در چنین شرایطی، انتظار یک روند خطی را نداشته باشید و همچنین دلیلی هم ندارد که حتماً همه‌چیز را 100٪ متوجه شوید. به جزئیات مهم دقت کنید و راه کنکاش برای پیدا کردن جواب سؤالتان را بیابید. اگر هم پس از چندین ساعت سروکله زدن با سورس‌کد دیدید که دارید بیش از پیش سردرگم می‌شوید، بهتر است که کار را کنار گذاشته و کمی استراحت کنید و زمانی که انرژی لازم برای انجام این کار را داشتید، مجدداً به این کار بپردازید.
حال نوبت به نظرات شما می‌رسد. آیا تاکنون تجربهٔ خواندن کدهایی که توسط سایر دولوپرها نوشته شده را داشته‌اید؟ اگر پاسخ شما آری است، می‌توانید چالش‌هایی که با آن‌ها در فرایند بررسی سورس‌کد مد نظر داشته‌اید را با ما و سایر خوانندگان سکان آکادمی به اشتراک بگذارید.
