تجزیه و تحلیل اشتباهات رایج برنامه نویسان مبتدی، pt. 1

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

1. ترس از کمک گرفتن از همکاران با تجربه تر

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

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

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

3. کپی و پیست کورکورانه

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

4. چسبیدن به راه حل اشتباه

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

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

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

6. قرار دادن توقعات غیرواقعی بالا از سرپرست تیم

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

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

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

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

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

8. تمایل به تصمیمات مخفیانه

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

9. اختراع مجدد چرخ

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

10. عدم نوشتن تست ها

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

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

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

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

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

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

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