چگونه پایه های کد بزرگ را مطالعه کنیم؟

یادم هست 5-6 سال پیش، من برای اولین بار روی یک پایه کد بزرگ کار می کردم. پروژه مهلت کوتاهی داشت و وظیفه ما این بود که به معنای واقعی کلمه کل مخزن را بازسازی کنیم. من در هفته اول ترسیدم و به مدیر فنی ما پیام دادم تا در مورد نحوه مقابله با این کد راهنمایی بخواهم! خیلی استرس داشتم
از آن زمان به بعد، در طول سال‌ها، راه‌های مختلفی را برای رویارویی با این دسته از کدهای ترسناک اولیه امتحان کرده‌ام! من مطمئن هستم که آنها در طول زمان بیشتر تکامل خواهند یافت، اما می خواهم اکنون آنها را به اشتراک بگذارم، شاید برای کسی مفید باشد. صادقانه بگویم، اکنون من از پایگاه های کد بزرگ و چالش برانگیز بسیار لذت می برم.

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

در اینجا مجموعه ای از ایده هایی وجود دارد که من استفاده کرده ام، که می توانید آنها را به سلیقه خود ترکیب و مطابقت دهید:

دنبال کردن ردپاها

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

کارهای کوچک را انجام دهید

به احتمال زیاد، زمانی که کد بزرگ است، انتظار نمی رود همه آن را بدانید. شما در بخش هایی از آن تخصص می گیرید و به تدریج دامنه دانش خود را افزایش می دهید. بنابراین برای مرحله 0، یک راه خوب، انتخاب یک کار کوچک در اجزای مجزای سیستم است (در مقابل کاری که شامل دانش چندین بخش است).
در یک محیط تولید تجاری و شرکت، این به طور طبیعی زمانی اتفاق می افتد که شما به یک تیم بپیوندید. برای یک پروژه منبع باز، این به مسائل «میوه کم آویزان» نزدیک است که اساساً مشکلاتی هستند که برای مبتدیان مناسب هستند.

سوالات خاص Edge Case را بپرسید. تندخو باشید

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

مثال: فرض کنید می خواهید در مورد یک کلاس در کد یاد بگیرید.

در اینجا سؤال “وانیل” وجود دارد:

• ویژگی ها و روش ها چیست؟

اینجاست عصبی نسخه:

• رابط عمومی چیست؟
• رابط کاربری چقدر و در چه موقعیت هایی استفاده می شود؟
• این کلاس با چه کلاس هایی مرتبط است؟ (ارتباط / ارث / تجمع / هر گونه ارتباط)

اینجا یک حتی حادتر نسخه:

• جریان زمان اجرا این شی چقدر است؟
  • چه کسی این شی را ایجاد می کند؟
  • چه زمانی ایجاد می شود؟
  • چقدر زنده است؟
  • چه زمانی می میرد؟ می توانیم دریافت کنیم حتی حادتر:
• با دانش فعلی من چه انتقاداتی به کلاس دارم؟ چگونه آن را بهتر کنم؟
  • آیا رابط عمومی / چیزهای خصوصی به درستی تنظیم شده است؟
    • آیا به اندازه کافی منسجم هستند؟
    • آیا آنها به طور منطقی با خارج جفت شده اند؟
  • آیا انتزاع مشکلی ندارد؟
    • آیا این کلاس چیزهایی دارد که بتوان آنها را به انتزاعات بالاتر منتقل کرد؟ (مانند انتقال چیزها به کلاس پایه یا سایر رابط ها؟)
    • آیا باید این کلاس را به اشیاء کوچکتر تقسیم کنم؟ مانند، آیا از ایده های مسئولیت واحد پیروی می کند؟
  • چگونه می‌توانم نام‌گذاری ویژگی‌ها و متدها را در کلاس بهبود بخشم؟

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

رسم نمودارها

نمودارها دست کم گرفته می شوند. برای من شوکه کننده است که وقتی نشان می دهد یک کد در اینترنت چگونه کار می کند چقدر از آن استفاده نمی شود. نمودارهای استاندارد در زمینه نرم افزار از دستورالعمل های زبانی به نام UML پیروی می کنند. UML دسته ای از نمودارها را ارائه می دهد که هر کدام برای موقعیت های مختلف قابل استفاده هستند: نمودار توالی، نمودار کلاس، نمودار مورد استفاده، نمودار استقرار، نمودار همکاری و بسیاری موارد دیگر. اگر می خواهید در مورد UML بیاموزید، مارتین فاولر یک کتاب کوتاه عالی به نام دارد UML مقطر. (وب سایت او/ آمازون)
شما مجبور نیستید از UML استفاده کنید. می توانید از هر روش بصری که به ذهنتان می رسد استفاده کنید. UML فقط یک زبان استاندارد است که مهندسان در سراسر جهان می دانند.
در مورد رسانه، می توانید از کاغذ استفاده کنید، اما انتخاب چندان مناسبی برای اصلاح نیست. من شخصاً دوست دارم از draw.io، یک پلتفرم نمودار آنلاین منبع باز، رایگان استفاده کنم. دسته ای از پولی ها نیز موجود است.

از نقاط شکست استفاده کنید

اگر می خواهید به جریان زمان اجرا کد بروید، نقاط شکست کمک بزرگی هستند. همه چیز به IDE شما، دامنه نرم افزار شما (وب، دسکتاپ و غیره) بستگی دارد، اما مفهوم یکسان است. ابتدایی ترین راه استفاده از لاگ است. اما اغلب اوقات، نقاط شکست اطلاعات بیشتری در مورد پشته تماس، مقادیر متغیر و غیره به شما می دهند.

کد را برای دیگران توضیح دهید

این یک کمک بزرگ و بزرگ است. این روش تحقیقات علمی زیادی دارد و اثربخشی بالایی دارد (Google Scholar).

سوال لبه: به چه کسی؟

• به نویسندگان خود کد، اگر در تیم شما هستند.
  • آنها می توانند شما را اصلاح کنند اگر اشتباه می کنید، زیرا آنها به معنای واقعی کلمه کد را نوشته اند.
  • آن‌ها می‌توانند این دیدگاه را ارائه دهند که چرا در وهله اول به روشی که کدگذاری کردند. آگاهی از زمینه کمک زیادی می کند. به عنوان مثال، ممکن است کد کثیف باشد، اما زمینه ممکن است این باشد که زمان کافی نداشته باشند. بنابراین طبیعی است که شما کد را به راحتی درک نکنید.
• اگر کسی در اطراف ندارید، می توانید با صدای بلند درباره کد صحبت کنید، انگار در حال ضبط ویدیو هستید. حتی بهتر است اگر دوستی برای گوش دادن به کد داشته باشید، شاید آنها نیز چیزی از آن به دست آورند.
• من از این خیلی استفاده می کنم: عمداً کد را برای کسی که هیچ ایده ای در مورد پروژه ندارد توضیح دهید و از آنها بپرسید که چقدر سخنرانی شما را درک می کنند. این بینش را به 2 روش ارائه می دهد:
  • آیا می توانید نحوه برقراری ارتباط خود را از نظر فنی بهبود بخشید؟
  • آیا از ابتدا کد را به درستی درک کردید؟

ترکیب و مطابقت

شما می توانید ایده ها را به هر شکلی که می توانید تصور کنید ترکیب و مطابقت دهید. مثلاً می‌توانید سؤالات واقعاً سختی را طراحی کنید، سپس برای پاسخ، نمودارهای خاصی را ترسیم کنید و سپس آنها را به یک دوست ارائه دهید.

فعلا همین

احتمالاً بعداً موارد بیشتری را به این مقاله اضافه خواهم کرد. امیدوارم به کسی کمک کند، زیرا من شخصاً در ابتدا خیلی سختی کشیدم.