همه می گویند کلید فرود یک کار نرم افزاری ، سنگ زنی Leetcode است. صدها مشکل را حل کنید ، و پیشنهادات وارد می شود.
اما در اینجا حقیقت خشن وجود دارد – کد کد کافی نیست.
شما می توانید الگوریتم ها ، چالش های برنامه نویسی ACE را به خاطر بسپارید و در عین حال در توسعه نرم افزار در دنیای واقعی مبارزه کنید.
زیرا وقتی در کار هستید ، بزرگترین مشکلات شما درختان باینری یا برنامه نویسی پویا نخواهد بود.
آنها کد های رمزگذاری شده ، کاربران غیرقابل پیش بینی و کار با افرادی خواهند بود که مانند شما فکر نمی کنند.
در اینجا 7 دلیل حل مشکلات LeetCode به شما در تبدیل شدن به یک توسعه دهنده نرم افزار خوب کمک نمی کند.
1. AI می تواند مشکلات LeetCode را حل کند – این کجا شما را ترک می کند؟
تمام LLM ها می توانند مشکلات LeetCode را در عرض چند ثانیه حل کنند. دقت فقط با گذشت زمان بهبود می یابد.
بنابراین چه ارزشی که می توانید به یک سازمان بیاورید؟
2 کاربران غیرقابل پیش بینی هستند
این یک شوخی قدیمی است.
یک QA وارد یک نوار می شود. سفارش یک آبجو. سفارشات 999999999 آبجو. سفارش یک مارمولک. سفارشات -1 آبجو. سفارش یک رشته از شخصیت های تصادفی. اولین کاربر واقعی راه می رود و می پرسد حمام کجاست. و کل نوار آتش می گیرد.
کاربران دنیای واقعی از قوانین از پیش تعریف شده پیروی نمی کنند.
آنها مقادیر غیر منتظره ای را وارد می کنند ، UI شما را می شکنند و موارد لبه ای را که هرگز در نظر نگرفته اند پیدا می کنند.
در ویدیوی زیر ، ببینید که کاربران از ویژگی های جدید Bounce برای مرسدس استفاده می کنند.
نوشتن کد تولید به معنای پیش بینی خرابی و طراحی برای مقاومت است – چیزی که LeetCode به شما آموزش نمی دهد.
3. کد شما جزیره ای نیست
بیشتر برنامه های دنیای واقعی با چندین سیستم خارجی-APIS ، بانک اطلاعاتی ، خدمات شخص ثالث-تعامل دارند.
این سیستم ها داده های غیر منتظره را تغییر داده ، شکست و باز می گردانند.
رسیدگی به این تغییرات با حداقل اختلال ، یک مهارت مهم است که Leetcode کاملاً نادیده می گیرد.
من یک مسئله را به یاد می آورم که برچسب های روی بسته ها همه مخلوط شدند.
چگونه می توانید مسئله مسئله را پیدا کنید؟
شما هرگز یاد نمی گیرید که با استفاده از LeetCode ، مسائل را در بسیاری از سیستم ها عیب یابی کنید.
4. کد شما فقط بخش مشخصات فنی نرم افزار است. بخش بزرگتر مردم است.
توسعه نرم افزار یک ورزش تیمی است. شما با مهندسین ، مدیران محصول ، طراحان و آزمایش کنندگان QA همکاری خواهید کرد.
با شخصیت های سخت و اولویت های متناقض روبرو خواهید شد.
مهمتر از همه ، بازخورد دریافت خواهید کرد.
مهندسان QA کد شما را بشکنند ، مهندسان ارشد طرح های شما را به چالش می کشند و ذینفعان تجارت نیازهای خود را تغییر می دهند.
یادگیری رسیدگی به این کار با بلوغ و حرفه ای ضروری است – Leetcode شما را برای آن آماده نمی کند.
5. دیدن تصویر بزرگتر بیشتر از رفع اشکالات است
بعضی اوقات ، یک اشکال ممکن است یک مشکل آسان به نظر برسد. اما اگر برای درک پیامدهای رفع سیستم وقت نگذارید ، ممکن است منجر به تعداد زیادی از اشکالات جدید شود که هرگز به آن فکر نکرده اید.
درک علت اصلی ریشه اشکال و تجزیه و تحلیل تأثیر در سیستم کلی برای انجام کارهای توسعه خوب بسیار مهم است.
سوالات کلیدی که می توانید بپرسید:
- آیا شما 100 ٪ از علت اصلی اطمینان دارید؟ بهترین راه برای تعیین این است که آیا می توانید اشکال را بازتولید کنید.
- وقتی این رفع مستقر شود ، آیا ویژگی همزمان وجود دارد که این امر روی آن تأثیر بگذارد؟
- آیا این سناریو یک طرفه است ، یا این امکان را دارد که اغلب تکرار شود؟
- آیا الزامی وجود دارد که در آینده نزدیک تحت تأثیر قرار گیرد؟
6. روشی برای توسعه نرم افزار وجود دارد
بیشتر اوقات این روش چابک است.
درک اسپرینت ها ، ایستادن ، بررسی کد و چرخه انتشار برای کار مؤثر در یک تیم بسیار مهم است.
بدون این ، شما فقط در حال نوشتن کد در خلاء هستید. هیچ شرکتی از این طریق فعالیت نمی کند.
7. کد نوشتن آسان است – نوشتن کد ساده سخت است
“یک کد یک بار نوشته شده است اما هزار بار بخوانید.” – رابرت سی مارتین
هرکسی می تواند کدی را که کار می کند بنویسد.
توسعه دهندگان بزرگ کدی را می نویسند که تمیز ، قابل درک و قابل نگهداری باشد.
توسعه دهندگان آینده (از جمله خود آینده شما) باید بتوانند بدون ناامیدی آن را بخوانند و گسترش دهند.
شیوه های برنامه نویسی خوب شامل موارد زیر است:
- نوشتن کد تمیز و قابل خواندن
- الگوهای طراحی زیر (با این یکی مراقب باشید)
- نوشتن تست های معنی دار
- مستندات موارد لبه و محدودیت ها
خط پایین
LeetCode مفید است ، اما کافی نیست. تمرکز فقط روی آن ، نقاط کور عظیم ایجاد می کند.
بهترین توسعه دهندگان فراتر از الگوریتم ها هستند. آنها یاد می گیرند:
- نحوه نوشتن کد قابل حفظ و ساختار یافته
- نحوه اشکال زدایی و عیب یابی سیستم های دنیای واقعی
- نحوه تعامل نرم افزار با زیرساخت ها و خدمات خارجی
- چگونه می توان در تیم ها به طور مؤثر کار کرد
اکنون ممکن است تعجب کنید که وقتی تازه شروع به کار یا تغییر نرم افزار می کنید ، یک مرحله عملی که می توانید بردارید چیست.
یک اقدام مهم این است که شما می توانید یک پروژه در دنیای واقعی بسازید. اکنون احتیاط هایی برای آن وجود دارد.
من آن را در یک پست دیگر اضافه خواهم کرد. اما به بیشتر مشکلات مورد بحث در پست کمک می کند.
چالش خواننده:
حتی اگر از LeetCode پرش کنید و روی یک پروژه در دنیای واقعی کار کنید ، فکر می کنید کدام یک از این چالش ها هنوز برای یادگیری تلاش می کنید؟
پاسخ دهید تا به من اطلاع دهید. منتظر پاسخ شما هستم
