CodeGym /وبلاگ جاوا /Random-FA /تجزیه و تحلیل اشتباهات رایج برنامه نویسان مبتدی، pt. 2
John Squirrels
مرحله
San Francisco

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

در گروه منتشر شد
سلام مجدد به همه! ما به بررسی مشکلاتی که یک برنامه نویس جوان و نابالغ ممکن است در اولین شغل خود با آن مواجه شود، ادامه خواهیم داد. قسمت اول را می توانید در اینجا پیدا کنید . تجزیه و تحلیل اشتباهات رایج برنامه نویسان مبتدی، pt.  2 - 1بیا ادامه بدهیم.

13. عدم رعایت دستورالعمل های سبک کدنویسی.

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

14. دلسرد شدن از اشتباهات

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

15. عدم اجرای ایمنی نخ.

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

16. کار بیش از حد

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

17. بی توجهی به مهارت های انگلیسی

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

18. پیگیری تکنولوژی مرسوم، مد روز

همانطور که توسعه دهندگان مسیر خود را شروع می کنند، اغلب سعی می کنند با آخرین فناوری ها همگام شوند. آیا این کار درستی است؟ از یک طرف، بله: آخرین فن آوری ها، پروژه ها ... اما آیا ارزش آن را دارد که این موضوع را در اولویت قرار دهیم؟ شاید بهتر است برای یک متخصص در زمینه خود، «ابزار کلاسیک» را دنبال کنید؟ مطمئناً جدید خوب است، اما نباید فناوری های اساسی رشته خود را فراموش کنید. و تنها در این صورت، پس از کسب تجربه و دانش عمیق در مورد اصول، می توانید چیز جدیدی را امتحان کنید. همچنین در نظر بگیرید که فناوری‌های جدید ممکن است از برخی جهات ظریف برتر باشند، اما ممکن است در برخی دیگر مزایای خود را از دست بدهند. تا زمانی که یک توسعه‌دهنده مبتدی این معاوضه‌ها را درک نکند، بهتر است راه‌حل‌های آزمایش‌شده زمان را دنبال کنید. به عنوان مثال، اگر یک برنامه نویس در حال توسعه برنامه ای است که با برخی از داده ها تعامل دارد، برای استفاده از آخرین راه حل NoSQL عجله نکنید، فقط به این دلیل که مد شده است. یک پایگاه داده معمولی SQL آزمایش شده و واقعی (MySQL، PostrgreSQL، و غیره) به احتمال زیاد دارای اسناد و راه حل های دقیق در StackOverFlow برای هرگونه مشکل احتمالی است :)

19. یادگیری چندین فناوری و/یا زبان مختلف به طور همزمان

ما در بالا در مورد مبتدیانی که سعی در یادگیری فن آوری های مد روز دارند صحبت کردیم. خوب، در مورد مطالعه همزمان بسیاری از فناوری ها یا زبان ها چطور؟ بدیهی است که شما نام برنامه نویسانی را شنیده اید که بیش از یک زبان برنامه نویسی می دانند و بر بسیاری از فناوری ها تسلط دارند. اما من به سرعت به این نکته اشاره می کنم که این افراد در برنامه نویسی چندان جدید نیستند. اینها افرادی هستند که سالها تجربه پشت سر خود دارند. آنها بر فناوری اصلی خود مسلط شده اند و سپس فراتر و فراتر رفته اند. مبتدیانی که سعی می کنند به یکباره همه چیز را تسلط یابند، باید این ضرب المثل عالی را به خاطر بسپارند: "دو خرگوش را تعقیب کن و هیچکدام را نخواهی گرفت." نتیجه ممکن است این باشد که شما به هیچ موضوعی به خوبی تسلط نخواهید داشت، بلکه فقط موضوعات را به صورت سطحی یاد می گیرید. تقاضا برای متخصصی که یک زبان را عمیقاً می داند بیشتر از کسی است که کمی در مورد همه چیز می داند. بنابراین اگر می‌خواهید زبان‌ها و فن‌آوری‌های زیادی را بدانید، باید عاقلانه به آنها نزدیک شوید. برای شروع، باید یک زبان اصلی و اصلی را انتخاب کنید که باید عمیقاً یاد بگیرید. و تنها پس از آن باید شروع به مطالعه سایر زمینه ها کنید. به عنوان مثال، یک گورو جاوا شوید، سپس پایتون را به عنوان زبان دوم یاد بگیرید. پس از آن، ممکن است چیزی در مورد react/angular برای frontend یاد بگیرید. در این مورد، ما در مورد فناوری هایی صحبت می کنیم که قابل تعویض نیستند، مانند C# و جاوا، بلکه مکمل یکدیگر هستند و فرصت های شغلی شما را گسترش می دهند. اما باز هم تکرار می کنم: نباید سعی کنید همه چیز را یکجا یاد بگیرید. باید به صورت متوالی پیش بروید. به اصطلاح، یک خرگوش را بگیرید.

20. اهداف نادرست تدوین شده است

چگونه برای خود اهداف تعیین می کنید؟ تبدیل شدن به یک توسعه دهنده باحال؟ این را یک بار برای همیشه به خاطر بسپارید: باید اهداف مشخص یا به عبارت دیگر اهداف دست یافتنی تعیین کنید. من در مورد چه چیزی صحبت می کنم؟ به عنوان مثال، شما این هدف را برای خود تعیین می کنید: "من می خواهم ثروتمند شوم". اما چگونه می دانید که آیا به این هدف دست یافته اید یا خیر؟ یا چگونه اندازه گیری می کنید که چقدر به دستیابی به آن نزدیک هستید؟ خوب، اگر هدف خود را "من می خواهم یک میلیون دلار به دست بیاورم" تعیین کنید، کمی واضح تر است، اینطور نیست؟ هنگامی که 10000 دلار به دست آوردید، 10000 دلار به هدف خود نزدیک می شوید – فقط 990000 دلار باقی مانده است. هنوز چیزهای زیادی برای دستیابی باقی مانده است، اما می توانید پیشرفت خود را احساس کنید و بفهمید که خط پایان کجاست، بنابراین انگیزه برای ادامه دادن خواهید داشت. از نظر شغلی، چطور می‌خواهید هدف ملموس‌تری برای خود تعیین کنید؟ به عنوان مثال: من می خواهم رهبر تیم شوم. یا یک برنامه نویس ارشد یا در نهایت یک معمار. خوب، هر کار بزرگ باید به وظایف فرعی کوچک تقسیم شود. شما در ابتدای کارتان به یک رهبر تیم تبدیل نمی شوید. در صورت امکان و مناسب، ضرب الاجل تعیین کنید و روی مرحله فعلی تمرکز کنید.
  1. اگر در مورد تبدیل شدن به یک توسعه دهنده ارشد صحبت می کنیم ، اولین هدف کوچک پیدا کردن یک کارآموزی یا شغلی به عنوان توسعه دهنده جوان در یک شرکت است.
  2. در مرحله بعد، می توانید اهدافی را برای تعمیق دانش خود در مورد فناوری های خاص تعیین کنید. در رابطه با جاوا، می توانید برای گواهینامه سطح 1 اوراکل آماده شوید. ما یک چارچوب زمانی برای آماده سازی خود تعیین می کنیم و با هدف مقابله می کنیم.
  3. سپس، برای مثال، ممکن است هدفی را تعیین کنید که انگلیسی خود را یک سطح (مثلاً از B1 تا B2) ارتقا دهید. ما یک برنامه آموزشی ترسیم می کنیم، زمان را برنامه ریزی می کنیم و به سمت هدف حرکت می کنیم.
اینگونه است که می توانیم مرحله به مرحله به هدف نهایی خود برسیم (در حالی که تجربه توسعه نرم افزار را به دست می آوریم).

21. نظریه بدون عمل

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

22. کمال گرایی بیش از حد

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

23. عدم اندیشیدن به معماری

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

24. سندرم ایمپوستور

تجزیه و تحلیل اشتباهات رایج برنامه نویسان مبتدی، pt.  2 - 4سندرم ایمپوستور یک پدیده روانی است که در آن فرد نمی تواند دستاوردهای خود را به ویژگی ها، توانایی ها و تلاش های شخصی نسبت دهد. علیرغم شواهد بیرونی از عملکرد ثابت آنها، افراد مستعد ابتلا به این سندرم همچنان معتقدند که کلاهبردار هستند و سزاوار موفقیتی نیستند که به دست آورده اند. بسیاری از توسعه دهندگان این سندرم را دارند. شاید به ما پایداری می دهد که ما را به سمت دانش و فناوری های جدید سوق می دهد. شما به همکاران باتجربه تر و کارآمدتر نگاه می کنید و احساس ناراحتی می کنید، مثل اینکه ارزش حقوق خود را ندارید. باور کنید این درست نیست. توسعه دهندگانی هستند که بهتر یا بدتر از شما هستند و همیشه خواهند بود. شخص دیگری به شما نگاه می کند و احساس ناراحتی می کند و فکر می کند که او هرگز شبیه شما نخواهد شد. و این طبیعی است. بازخورد تیم شما، بررسی کدها و بحث ها به مقابله با این احساس کمک می کند. باور کنید، نظر یک فرد خارجی شما را شگفت زده خواهد کرد، اما به شرطی که واقعاً از کار و پیشرفت حرفه ای خود غافل نشوید. اگر از آن چیزها غافل شوید، پس شغل اشتباهی را انتخاب کرده اید. در این حرفه، شما باید همیشه چیز جدیدی یاد بگیرید و برای بهترین ها تلاش کنید. اما من فکر می کنم مردمی که اینجا جمع می شوند به دور از تنبلی هستند. در عوض، مردم اینجا با استواری به سمت هدف گرامی خود حرکت می کنند. اگر این شما را توصیف می کند، پس چیزی برای ترس ندارید.

25. به ندرت متعهد می شوند

به یاد داشته باشید که اغلب commit ها را انجام دهید! نه هر نیم ساعت، حواست باشه اگر یک هفته را صرف اجرای برخی از عملکردها می کنید، پس نباید یک commit را در جمعه شب انجام دهید، بلکه مثلاً پنج commit را انجام دهید. تقریباً هر کار بزرگی را می توان برای راحتی به کارهای کوچکتر تقسیم کرد. بنابراین شما این وظایف کوچکتر را تکمیل کرده و متعهد می شوید. و فراموش نکنید که بلافاصله این commit ها را به سرور راه دور ارسال کنید. در غیر این صورت، ممکن است تمام هفته را متعهد کنید و سپس کامپیوتر شما روز جمعه در وقت ناهار دچار مشکل سخت افزاری شود، و سپس یک هفته کامل را بیهوده از دست داده باشید! اما اگر commit های خود را در یک سرور راه دور آپلود کرده باشید، آنگاه فقط با آخرین کامیت خود شاخه را روی رایانه دیگری کشیده و به کار خود ادامه می دهید. یک چیز دیگر: عملکردهای جدید را در جمعه شب به سرور تولید زنده ارسال نکنید. فقط به من اعتماد کن. شما به آن نیاز ندارید. این احتمال وجود دارد که خطاهای غیرمنتظره آشکار شوند و آخر هفته خود را صرف رفع آنها کنید. و این سرگرم کننده نیست. آخر هفته باید استراحت کنید. من حدس می زنم این همه برای امروز است. PS آخرین نکته: کدهای زیادی بنویسید. PPS مقدار بسیار زیادی کد بنویسید، زیرا این تنها راه برای به دست آوردن تجربه بسیار مورد نیاز است.
نظرات
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION