تجزیه و تحلیل اشتباهات معمول برنامه نویسان مبتدی: بخش 1

سلام دنیا! بعد از اینکه همه چیزهایی را که نیاز دارید یاد گرفتید و در نهایت به عنوان کارآموز یا جونیور استخدام شدید، احتمالاً می توانید استراحت کنید، درست است؟ مهم نیست که چگونه است! همه چیز تازه شروع شده است ... چیزهای جدید و نامفهوم زیادی در اطراف شما وجود دارد و چگونه اینطوری از دروازه بیرون نروید؟ این چیزی است که امروز در مورد آن صحبت خواهیم کرد. در این مقاله، می‌خواهم اشتباهات رایج مبتدیان را بررسی کنم و نکاتی را از تجربه خودم در مورد نحوه اجتناب از آنها ارائه کنم. بنابراین، بیایید بدون بحث بیشتر شروع کنیم:

1. ترس از کمک خواستن از همکاران با تجربه تر

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

2. سعی نکنید خودتان به دنبال اطلاعات بگردید

شاید این خطا سمت معکوس خطای قبلی باشد. منظورم زمانی است که با هر مشکل یا مشکلی شروع به کشیدن همکاران و آشنایان خود می کنید. پرسیدن خوب است، اما نباید با سوالات زیاد جلو بروید، در غیر این صورت ممکن است خسته شوید. اولین کاری که باید انجام دهید اگر نکته نامفهومی پیش آمد این است که مهارت های جستجوی خود را در بهترین موتور جستجو - گوگل به کار ببرید. شخصی قبلاً با اکثریت قریب به اتفاق خطاهای غیرقابل درک و سایر مسائل روبرو شده است. و اگر آن را در گوگل سرچ کنید و تعداد افرادی را ببینید که با مشکل مشابهی آشنا هستند و قبلاً پاسخ های جامع مناسب برای استفاده در کار خود را دریافت کرده اند بسیار شگفت زده خواهید شد. بر این اساس، اغلب می توانید بشنوید که یک همکار به یک سؤال پاسخ می دهد - "Google it". شما نباید از این پاسخ آزرده شوید، زیرا در نهایت، همکار شما یک معلم شخصی نیست که باید تمام پیچیدگی های حوزه کاری شما را منتقل کند. وسعت بی پایان اینترنت به شما در چنین راهنمایی کمک می کند. گاهی اوقات در جستجوی گوگل به یک برنامه نویس به فردی با کمربند مشکی نیز گفته می شود . بنابراین، وقتی گیر می‌افتیم، ابتدا مشکل را در گوگل جستجو می‌کنیم و اگر راه‌حلی پیدا نشد (به ندرت، اما این اتفاق می‌افتد)، سپس شروع به پرسیدن از همکارانمان می‌کنیم. ارزش آن را دارد که فوراً از آنها بپرسید، نه زمانی که نوعی اشکال یا خطای غیرقابل درک وجود دارد، بلکه هنگام انتخاب رویکردی برای حل یک مشکل. از این گذشته، آنها می توانند فراتر از شما را ببینند و بلافاصله بگویند که این یا آن رویکرد ممکن است در دراز مدت چگونه به نتیجه برسد.

3. کپی پیست کور

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

4. پرتاب راه حل اشتباه

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

5. ترس از پرسیدن سوال در مورد وظیفه فعلی

کار روی یک پروژه معمولاً به تکمیل برخی وظایف (Tasks) ختم می شود. به عنوان مثال، در جیرا . و این وظایف همیشه با جزئیات و واضح توضیح داده نمی شوند. آنها معمولاً توسط رهبران تیم نوشته می شوند و اینها نیز افراد هستند. آنها همچنین ممکن است فراموش کنند چیزی اضافه کنند یا در نظر نگیرند که شما با این یا آن عملکرد خیلی آشنا نیستید. خوب، یا شما به پروژه دسترسی ندارید (به عنوان مثال، دسترسی به پایگاه داده، به سرور گزارش و غیره). و اکنون، با دریافت این کار، با مطالعه آن برای بیش از چند ساعت، هنوز هم می نشینید و با گیج به صفحه نگاه می کنید. و به جای ادامه یافتن بی فایده، باید شروع به پرسیدن سوالات اصلی/روشن از خالق این کار کنید. فرض کنید، در برنامه‌ای که برای ارتباط در یک تیم استفاده می‌کنید (مثلاً تیم‌های مایکروسافت) یا مستقیماً به عنوان نظر در زیر این وظیفه. از یک طرف، اگر سؤالی را در یک پیام شخصی بنویسید، به احتمال زیاد پاسخ سریعتر خواهد بود، زیرا شخص بلافاصله سؤال را می بیند. از طرفی با پرسیدن سوال در جیرا شواهدی دارید که در حال انجام کاری هستید، یعنی آنالیز مشکل. راهی برای تسریع این روند وجود دارد: یک سوال به عنوان نظر در جیرا بپرسید و لینک این نظر را در یک پیام خصوصی با درخواست مشاهده ارسال کنید.

6. انتظار بیش از حد از رهبر تیم

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

• مستندات این پروژه را عمیق تر مطالعه کنید تا تعداد نقاط کور را کاهش دهید.
• از سایر اعضای تیم سوال بپرسید. کاملاً ممکن است که آنها به اندازه لید یا حتی بیشتر با این عملکرد آشنا باشند، زیرا به احتمال زیاد یکی از آنها آن عملکرد را نوشته است.

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

7. ترس از بررسی کد

بررسی کد یا بررسی کد مرحله ای قبل از آپلود کد در یک برنامه مشترک (به یک شعبه مشترک، به عنوان مثال، master یا dev) است. این بررسی توسط توسعه‌دهنده‌ای انجام می‌شود که به این کار مرتبط نیست، که می‌تواند با نگاهی تازه، خطاها، نادرستی‌ها یا کاستی‌هایی را در سبک کد که در مرحله اولیه توسعه مورد توجه قرار نگرفت، کشف کند. اگر نظراتی وجود داشته باشد، آنها به عنوان نظرات به بخش های خاصی از کد گذاشته می شوند. در این حالت، توسعه‌دهنده‌ای که این کار را انجام داده است باید خطاها را مطابق با بررسی تصحیح کند (یا تصمیمات خود را با بازبین در میان بگذارد، شاید او را به درستی تصمیم خود متقاعد کند). پس از آن، آن را برای بررسی مجدد ارسال کنید، و به همین ترتیب تا زمانی که بازبین نظری نداشته باشد. بازبین قبل از آپلود کد به عنوان یک "فیلتر" عمل می کند. بنابراین، بسیاری از برنامه نویسان تازه کار بررسی کد را به عنوان انتقاد و محکومیت درک می کنند. قدر او را نمی دانند و از او می ترسند و این اشتباه است. این بررسی کد است که به ما امکان می دهد کد خود را بهبود ببخشیم. از این گذشته، ما اطلاعات مهمی در مورد کارهای اشتباهی که انجام می دهیم و باید به چه مواردی توجه کنیم، دریافت می کنیم. لازم است به بررسی هر کد به عنوان بخشی از یادگیری نگاه کنید، چیزی که می تواند به شما در بهبود آن کمک کند. وقتی شخصی روی کد شما نظر می دهد، تجربیات و بهترین شیوه های خود را با شما به اشتراک می گذارد. در مورد من، شما نمی توانید بدون بررسی کد، برنامه نویس خوبی شوید. زیرا شما حتی نمی دانید کد شما چقدر خوب است و آیا از نظر یک فرد باتجربه از بیرون اشتباهاتی وجود دارد یا خیر.

8. تمایل به راه حل های ابهام آمیز

اغلب وظایف/مشکلات مختلف می توانند چندین راه حل متفاوت داشته باشند. و از بین تمام راه حل های موجود، مبتدیان معمولاً از پیچیده ترین و "مشکوک" ترین راه حل ها استفاده می کنند. و درست است: اگر یک برنامه نویس مبتدی همین دیروز الگوریتم های مختلف، الگوها، ساختارهای داده را مطالعه کرد، پس دستانش برای اجرای یکی از آنها خارش دارند. بله، و من می خواهم، به اصطلاح، خودم را اعلام کنم. باور کنید، من خودم اینطور بودم و می دانم که در مورد چه چیزی صحبت می کنم :) موقعیتی داشتم که مدت زیادی را صرف نوشتن یک عملکرد کردم که بسیار بسیار پیچیده بود. سپس توسط یک توسعه دهنده سطح ارشد+ بازنویسی شد. البته برایم جالب بود ببینم چه چیزی و چگونه آن را تغییر داده است. من به اجرای او نگاه کردم و از اینکه چقدر ساده تر شد شگفت زده شدم. و کد سه برابر کمتر شده است. و در عین حال تست های این قابلیت تغییر نکرد و شکست نخورد! یعنی منطق کلی ثابت می ماند. از اینجا به این نتیجه رسیدم که: هوشمندانه ترین راه حل ها همیشه ساده هستند . پس از این درک، نوشتن کد بسیار آسان تر شد و به طور قابل توجهی سطح بالایی شد. خوب پس چه زمانی ارزش استفاده از الگوها و الگوریتم ها را دارد؟ سپس، هنگام استفاده از آنها ساده ترین و فشرده ترین راه خواهد بود.

9. اختراع دوچرخه

این مفهوم به عنوان اختراع چرخ نیز شناخته می شود. ماهیت آن در این واقعیت نهفته است که توسعه دهنده راه حل خود را برای مشکلی که راه حل هایی برای آن وجود دارد، و چندین برابر بهتر از راه حل هایی که توسط برنامه نویس اختراع شده است، پیاده سازی می کند. به عنوان یک قاعده ، اختراع دوچرخه شخصی شما منجر به از دست دادن زمان و کاهش کارایی کار توسعه دهنده می شود ، زیرا ممکن است راه حلی پیدا نشود که از بهترین ها دور باشد یا اصلاً پیدا نشود. در عین حال، نمی توان امکان تصمیم گیری مستقل را کنار گذاشت. برنامه نویس باید وظایفی را که ممکن است پیش روی او ظاهر شود به درستی هدایت کند تا با استفاده از راه حل های آماده یا اختراع راه حل های خود، آنها را به درستی و به موقع حل کند. از یک سو، در دانشگاه‌ها و دوره‌های آموزشی، ما با انواع مختلفی از وظایف بمباران می‌شویم که باید به ما کمک کنند تا در ساخت دوچرخه‌ها دست پیدا کنیم. اما این فقط در نگاه اول است. در واقع هدف از این کار توسعه تفکر الگوریتمی و تسلط عمیق تر بر نحو زبان است. و چنین وظایفی همچنین به درک بهتر الگوریتم ها/ساختارها کمک می کند و در صورت لزوم به آنها مهارت هایی می دهد تا آنالوگ های پیشرفته خود را پیاده سازی کنند (اما به ندرت به این نیاز می شود). در زندگی واقعی، در اکثریت قریب به اتفاق موارد، نیازی به اختراع چرخ خود نیست، زیرا آنالوگ هایی از مدت ها قبل وجود داشته است که نیازهای ما را برآورده می کند. شاید با توجه به تجربه خود، از وجود اجرای این یا آن عملکرد مورد نیاز خود اطلاعی نداشته باشید. اینجاست که باید از اولین نکته این مقاله استفاده کنید، یعنی از همکاران با تجربه تر کمک بگیرید. آنها می توانند شما را راهنمایی کنند (مثلاً راهنمایی کنند که در کدام جهت به گوگل بروید) یا اجرای خاصی را پیشنهاد کنند (کتابخانه خاصی).

10. تست ننویسید

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

11. اظهار نظر بیش از حد

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

Cat cat = new Cat(); // cat Object

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

12. نامگذاری بد

اغلب، مبتدیان نام کلاس ها، متغیرها، متدها و غیره را جعل می کنند. مثلاً وقتی کلاسی را ایجاد می کنند که نام آن اصلاً هدف آن را توصیف نمی کند. یا یک متغیر با یک نام کوتاه، چیزی شبیه x ایجاد می‌شود ، و وقتی دو متغیر دیگر به نام‌های n و y ایجاد می‌شوند ، یادآوری کاری که x انجام می‌دهد بسیار دشوار می‌شود . در چنین مواردی، شما باید به دقت در مورد کد فکر کنید و این عملکرد را زیر میکروسکوپ مطالعه کنید (شاید با استفاده از یک دیباگر) تا به سادگی بفهمید در آنجا چه اتفاقی می افتد. اینجاست که نام گذاری صحیح در کدی که در بالا ذکر کردم به کمک ما می آید. نام‌های صحیح خوانایی کد را بهبود می‌بخشد و بر این اساس در زمان آشنایی صرفه‌جویی می‌کند، زیرا استفاده از روشی که در آن نام تقریباً عملکرد آن را توصیف می‌کند، بسیار ساده‌تر است. در کد، همه چیز از نام ها (متغیرها، متدها، کلاس ها، اشیاء فایل و غیره) تشکیل شده است، این نکته هنگام ایجاد کد صحیح و تمیز بسیار مهم می شود. شایان ذکر است که نام باید این معنی را بیان کند: به عنوان مثال، چرا متغیر وجود دارد، چه کاری انجام می دهد و چگونه از آن استفاده می شود. و من بارها و بارها متذکر می شوم که بهترین نظر برای توصیف یک متغیر، نام صحیح آن است. برای مطالعه عمیق تر نظرات و نام گذاری صحیح، به شما توصیه می کنم که کلاسیک بی انتها را بخوانید: «کد پاک. ایجاد، تجزیه و تحلیل و بازسازی، رابرت مارتین . در این یادداشت، قسمت اول این مقاله (تأملات) به پایان رسید. ادامه دارد…