نقدهای سفری در میان کد: خوب، بد، و «صبر کن، چی؟» لحظه ها

بیایید صادق باشیم، بررسی کد مانند این است که برای اولین بار به کسی نشان میدهید که آشپزی شما را انجام میدهد. فکر میکنید عالی است، اما بعد یکی وارد میشود و میپرسد: “آیا میخواستی اینقدر نمک اضافه کنی؟” ناگهان، شما تعجب می کنید که چگونه از خوردن غذای خود این مدت جان سالم به در برده اید. زمانی که کد با دقت ساخته شده شما در معرض دنیای وحشی همکاری منبع باز قرار می گیرد، تقریباً این احساس می شود.
اسپویلر: در عین حال هم وحشتناک و هم عالی است.
بین غوطه ور شدن در کد شخص دیگری (و بی سر و صدا بودن به این فکر کردن که چرا آنها این کار را کردند) و قرار دادن کد خودم زیر میکروسکوپ، این سفر چیزی کمتر از چشم باز کردن بود. بنابراین، چگونه از این ماجراجویی کدنویسی جان سالم به در بردم؟ بیایید آن را تجزیه کنیم.
رویکرد بررسی کد: Async در مقابل Sync
در طول این فرآیند، من در درجه اول از یک رویکرد ناهمزمان (ناهمگام) برای بررسی کد استفاده کردم که شامل ایجاد و پاسخ به مشکلات در GitHub بود. من نظرات غیر همگام را ترجیح می دهم زیرا به من این آزادی را می دهند که با سرعت خودم مرور و پاسخ دهم. این امر به ویژه زمانی مفید است که سعی می کنید سایر تعهدات را کنار بگذارید (یا آنها را به تعویق بیندازید).
اما گاهی اوقات، ارتباط همگام از طریق Slack نجات دهنده بود. وقتی در حال حاضر به پاسخ نیاز دارید، هیچ چیز مانند یک رفت و برگشت سریع نیست. برای کسانی که “صبر کن، این چه کاری انجام می دهد؟” چند لحظه، پرش به یک چت همه چیز را سریعتر کرد. با این حال، async روشی سرد است که به شما امکان میدهد بدون حواسپرتی به عمق کد بروید.
مرور کد شخص دیگری
تست و بررسی کد شخص دیگری؟ حالا این یک ماجراجویی است. در ابتدا، مجبور شدم عمیقاً در پایگاه کدهای ناآشنا فرو بروم. مثل تلاش برای هدایت دستورالعملهای مبلمان IKEA شخص دیگری اما در یک زبان برنامهنویسی بود.
مثل کارآگاه بودن در یک پرونده جدید بود – به جز اینکه به جای حل یک جنایت، سعی می کردم بفهمم چرا کد آنها مانند یک بچه بدرفتار عمل می کند. یک دقیقه میگویید: «اوه، این هوشمندانه است» و لحظهی بعد، به یک URL API رمزگذاریشده مانند «واقعا؟» خیره میشوید.
راستش سخت ترین قسمت راه اندازی محیط آنها بود. README آنها مراحل کلیدی را از دست داده بود، بنابراین من مجبور شدم به طور کامل شرلوک هلمز را ادامه دهم تا کارها درست شود. اما هنگامی که کد را شکستم (جناسی در نظر گرفته شده)، به مشکلات جالبی برخوردم – مانند تلاش برای پردازش فایلهای موجود یا یافتن خطاها با استثنای کلی مثل اینکه در یک شب دنج است.
بررسی کد من
تصور کنید ساعت ها خانه خود را تمیز می کنید، اما وقتی شخصی وارد خانه می شود، بلافاصله گرد و غبار روی پنکه سقفی را نشان می دهد. بله، این همان چیزی است که احساس می کرد. بازبینی کننده من به اندازه کافی خوب بود که به من اطلاع داد که می توانم مدیریت خطاهای خود را بهبود بخشم، و شاید ارسال یک پیام “کاربر پسند” ایده بدی نباشد زمانی که نسل README کار می کند.
قسمت تعجب آور؟ این تغییرات کوچک تفاوت بزرگی ایجاد کرد. ناگهان، کد من فقط کاربردی نبود، بلکه جلا داده شد. دریافت بازخوردی که در واقع تجربه کاربر را بهبود میبخشد، باعث میشود فرآیند کمتر شبیه به انتقاد و بیشتر شبیه یک تلاش گروهی باشد.
چه نوع مسائلی در تست و بررسی شما پیش آمد؟
اوه، از کجا شروع کنم؟ چند گوهر بود:
- URL API هاردکد شده در api_handler.py: مثل این است که کلید خانهتان را زیر تشک خوشآمدگویی بگذارید و امیدوار باشید هیچکس قفلها را عوض نکند. من پیشنهاد کردم URL API را به یک فایل پیکربندی یا متغیر محیطی منتقل کنید – زیرا هیچ کس چیزهای کدگذاری شده را دوست ندارد (به جز شاید شخصی که این کار را انجام داده است).
- مدیریت استثناهای عمومی در complexity_analyzer.py: گرفتن همه خطاها با یک استثنای عمومی مانند انداختن یک تور غول پیکر بر روی همه چیز است و امیدواریم که نتیجه بگیرد. اسپویلر: اینطور نیست. من به آنها پیشنهاد دادم با استثناهای خود برای اشکال زدایی آسان تر، خاص باشند.
- عدم مدیریت فایل در main.py: اسکریپت حتی زمانی که فایلها وجود نداشتند، همچنان اجرا میشد. مثل تلاش برای پختن یک کیک بدون آرد بود – مطمئناً، می توانید امتحان کنید، اما نتیجه خوبی نخواهد داشت. من توصیه کردم اسکریپت متوقف شود و در واقع فایل های از دست رفته را مدیریت کند.
- اسناد متناقض: خواندن اسناد مانند حل یک معما بود. برخی از پرونده ها مستند بودند، برخی دیگر؟ نه چندان. من آنها را تشویق کردم تا کمی سازگارتر شوند – زیرا در دنیای کدنویسی، یک رشته مستند خوب ارزش طلا را دارد.
آیا توانستم تمام مشکلات را برطرف کنم؟
قطعا! رفع مشکلات مانند آن لحظه ای بود که در نهایت هدفون خود را باز کردید – فوق العاده رضایت بخش. من مدیریت خطا را پاک کردم، یک بازه زمانی برای درخواستهای API اضافه کردم (بیتر از انتظار بیپایان)، و انتخاب مدل را قابل تنظیم کردم، زیرا چرا وقتی میتوانید انعطافپذیر باشید، کدهای سخت ایجاد کنید؟ این روند باعث شد احساس کنم به عنوان یک توسعه دهنده به سطح بالایی رسیده ام. چه کسی می دانست که چند ترفند می تواند همه چیز را بسیار روان تر کند؟
نتیجه یادگیری
تمام این تجربه یک معدن طلای یادگیری بود. اگر بخواهم آن را بجوشانم:
-
مستندسازی پادشاه است: رد شدن از اسناد مانند این است که خود آینده خود را (یا هر روح فقیری که رمز شما را لمس می کند) را در بیابان گم کنید بدون نقشه.
-
بررسی کد شما را بهتر می کند: اینکه کسی به نقاط کور شما اشاره کند همیشه سرگرم کننده نیست، اما ضروری است. این شما را وادار می کند به چیزهایی مانند تجربه کاربر و کد تمیز و قابل نگهداری فکر کنید.
-
بازخورد دوست شماست: مطمئناً، وقتی کسی به اشتباهی اشاره میکند، احساس ناراحتی میکند، اما آن تکههای کوچک بازخورد تفاوت بزرگی ایجاد میکند. حالا به خاطر آن کدنویس بهتری هستم.
در پایان، بررسی کد فقط برای رفع اشکال نبود، بلکه در مورد رشد بود. و سلام، دفعه بعد، احتمالاً کد خودم را برای URL های کدگذاری شده دوباره بررسی خواهم کرد. 😅