نحوه ی خواندن سورس کد(8 چیز که باید به خاطر بسپاریم)
ایمان مدائنی

خواندن کد یک مهارت مورد نیاز به خصوص برای توسعه دهندگانی که در پایگاه کد موجود کار می کنند، می باشد و اگر شما با یک دیدگاه و ابزار های مناسب سراغ این کار بروید می تواند برای شما یک تجربه ی لذت بخش و آموزنده باشد بنابراین در این مقاله می خواهیم نحوه ی خواندن کد را بررسی کنیم.

 

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

دلیلی که ما از خواندن کدهای دیگران متنفر هستیم این است که خود ما آن ها را ننوشته ایم. این به این معنی نیست که همه ی ما اعتقاد داریم که بهترین کدزن های روی زمین هستیم و هیچ کس نمی تواند به خوبی ما کدزنی کند بلکه به این دلیل است که یک روند فکری قوی وجود دارد تا اینکه کد ساخته شود که یک خواننده، تجربه ی این روند را از ابتدا نداشته است.

کدی که شما در صفحه ی نمایش می بینید ممکن است حاصل کار چندین نفر باشد و ممکن است حاصل یک پایگاه داده و همکاری پیچیده باشد ممکن است هفته ها وقت گرفته باشد تا یک نسخه که مطابق با محدودیت های مستندسازی نشده، که فقط سرگروه نویسندگان می دانند و شما هیچ کدام از آن ها را نمی دانید، تثبیت شده باشد.

به عنوان یک خواننده تمام چیزی که میبینید کد نهایی است مگر اینکه کمی در کد کنجکاو شوید در ابتدا تنها محتوایی که دارید کلمات در صفحه نمایش هستند.

1. یادبگیرید در کد عمیق شوید (کنجکاو باشید)

زمانی که شما برای اولین بار وارد یک پایگاه داده ی کامل می شوید ممکن است حسی مانند یک توسعه دهنده نداشته باشید بلکه ممکن است بیشتر حسی شبیه باستان شناسان یا محققان کتب تاریخی داشته باشید. این حس خوب است زیرا دسته ای اطلاعات ارزشمند در اختیار شما قرار گرفته است.

اگر به اندازه ی کافی خوش شانس باشید که درسمت کد کار کرده باشید و از همان ابتدا در ورژن کنترل بوده اید، خوشحال باشید زیرا شما به حجم متادیتاها دسترسی پیدا کرده اید که کار شما در درک نه تنها روی کد بلکه مفهوم آن بسیار آسان تر می کند. من در اینجا فرض می کنم که شما از Git استفاده می کنید اما اگر از SVN استفاده می کنید همین ایده ها بطور مشابه استفاده می شود.

git blame

شما می توانید از git blame در یک فایل برای گرفتن نام توسعه دهنده و آخرین تاریخ تغییرات استفاده کنید و برای هر خط می توانید از این کار استفاده کنید.با دولوپرها بیشتر آشنا شوید. اگر خوش شانس باشید تعداد دولوپرها کم است و احتمالا هنوز هم با شما کار می کنند بنابراین می توانید از آن ها به عنوان یک منبع استفاده کنید و اگر خوش شانس نباشید ممکن است تعداد زیاد باشد و شما درباره ی هیچ کدام از آن ها از قبل چیزی نشنیده باشید.  

صرف نظر از این موارد سعی کنید متوجه شوید توسعه دهندگان اصلی چه کسانی بوده اند. اگر با تابع عجیب و غریبی که متوجه نمی شوید چه کاری انجام می دهد روبرو شدید از git blame استفاده کنید تا متوجه شوید که نویسنده ی آن کیست سپس برای سوال پرسیدن راهی ارتباطی با او پیدا کنید.

git log

برای نگاه به تاریخچه ی کل روند از git log استفاده کنید. این دستور پیام های commit را چاپ می کند بنابراین برای جستجوی commit ها اینکه به کدام تابع مربوط هستند grep را فراموش نکنید: git log | grep someFunction -C 3 (-C 3 محتوای شما را در سه خط نشان خواهد داد)

git log با پرچم –p تاریخچه ی یک فایل تنها را نیز نشان می دهد:git log -p index.js. به افرادی که دیر به دیر اصلاحات را انجام می دهند توجه کنید در این صورت اگر سوالی پیش بیاید متوجه می شوید که کجا باید مراجعه کنید.

2.بازگشت در زمان

شما هر commit که می خواهید را می توانید بررسی کنید و آن را به صورتی که گویا آخرین commit در پروژه بوده است، اجرا کنید. ممکن است بخواهید آخرین commit های خوب شناخته شده را قبل از برخی باگ هایی که پیگیری آن ها از همان ابتدا دشوار است، بررسی کنید یا ممکن است کسل شده باشید و بخواهید بررسی کنید که سال ها پیش پروژه ی شما کجا بوده و آن را دنبال کنید تا به پروژه ی کنونی برسید.

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

3. خواندن مشخصات (بررسی جزئیات)

مشخصات از کامنت های جدید است. مشخصات یکتا را برای متوجه شدن از اینکه چه توابع و ماژول هایی استفاده شده است و چه اهدافی را باید دنبال کنند، بخوانید. مشخصات ضمیمه ای را برای اینکه متوجه شوید کاربران چگونه باید با اپلیکیشن شما تعامل برقرار کنند و چه جریان کاری را اپلیکیشن شما پشتیبانی می کند مطالعه کنید.

4.به کامنت ها به عنوان یک سرنخ نگاه کنید

اگر شما بایک تابع گیج کننده روبرو شدید و کامنت مرتبط با آن نیز شما را بیشتر سردرگم کرد به این فکر کنید که ممکن است کامنت به روزرسانی و نگهداری نشده است. چشمان برنامه نویسان معمولا خطوط سبزرنگ را درنظر نمی گیرد بنابراین ممکن است توضیحی بدهند که برای متد قبل از به روزرسانی بوده و متد فعلی دیگر آن کار را انجام نمی دهد و کسی به این موضوع نیز توجه نکرده است.

5.اصل؛ نقطه شروع (Main) را پیدا کنید

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

احتمالا شما این موارد را در باقی پروژه همه جا می بینید. اینجا احتمالا برخی از ماژول ها همه منظوره باشند و از مابقی کد جدا باشند. این موارد عملیات های کوچک تر و ساده را ارائه می دهند که شما باید قبل از کار با اپلیکیشن های بزرگ تر با آن ها آشنا شوید.

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

سعی کنید ارجاعات به این ماژول ها را از فایل های منبع دیگر پیدا کنید تا متوجه شوید کی و چگونه استفاده می شوند. این کار باعث می شود تا متوجه شوید چگونه این موارد در تمام اپلیکیشن استفاده می شود.

6. به سبک کدنویسی توجه کنید

دلیلی که شما یک اپلیکیشن را یاد می گیرید این است که نهایتا باید برای آن کد بنویسید بنابراین باید به سبک اپلیکیشن توجه کنید. البته این کار هم شامل موارد سطحی مانند نام گذاری، رعایت فاصله ها و هم شامل کد می شود.

سطح عمومی abstract چیست؟ اگر کد شما در به شدت abstract است و از لایه های زیادی تشکیل شده است شما نیز باید به همان سبک کدزنی کنید.

اگر شما به اندازه ی کافی در تاریخچه ی کد کنجکاو شوید احتمالا می توانید نقطه ی دقیقی که یکی از توسعه دهندگان تصمیم به abstract سازی یک قطعه کد را گرفته پیدا کنید. قبل از abstract سازی، کد به چه صورتی بوده و بعد از آن کد به چه صورتی شده است؟ سعی کنید از همین روند در کدزنی خود استفاده کنید.

در یک سطح دقیق تر چه نوع کد هایی را اعضای دیگر تیم برای اینکه کار ها انجام شود، بررسی می کنند؟ اگر توسعه دهندگان با حلقه روی نقشه ها کار کرده اند احتمالا شما نیز باید از حلقه روی نقشه ها استفاده کنید.

اگر شما با سبکی مواجه شدید که به آن علاقه ندارید با تیم خود صحبت کنید تا شاید سبک را در آینده تغییر دهند اما از سبک های مختلف در یک فایل استفاده نکنید. هرچه یک فایل طوری به نظر برسد که گویا یک نفر آن را نوشته است همانقدر بهتر است.

7.انتظار کدهای بی ارزش را داشته باشید

شما ممکن است توابعی را پیدا کنید که هیچگاه از آن ها در کد استفاده نشده است یا حتی ممکن است یک فایل را پیدا کنید که بطور کلی در پروژه استفاده نشده است. شما ممکن است کدهای غیر کامنت پیدا کنید که سال ها از آن ها استفاده نشده است (git blame). سرعت خود را برای فکر کردن درباره ی چنین کد هایی پایین نیاورید و از اینکه چنین کد هایی را رها کنید نترسید.

اگر کد به دلیلی نوشته شده باشد کسی در بازبینی کد برای آن یک پرچم تنظیم خواهد کرد. شما سربارهای روحی را برای خواننده ی بعدی که بعدها وارد کار خواهد شد را کاهش خواهید داد.

8. مسیر خود را گم نکنید

زمانی که خود را در بیراهه پیدا کردید این نکات را فراموش نکنید. انتظار نداشته باشید که این روند کاملا هموار باشد و همه چیز را 100% متوجه شوید. به جزئیات توجه کنید و یادبگیرید چگونه برای پیدا کردن جواب سوال های خود در کد کنجکاو شوید. با این کار ها کدها را به سرعت متوجه خواهید شد.

نظرات کاربران در رابطه با این دوره

جهت ثبت نظر باید در سایت عضو شوید و یا وارد سایت شده باشید .
logo-samandehi