4 نکته برای تقویت بازی نویسی (برنامه نویسی بازی)

1. نحوه عملکرد IDE ها را بیاموزید

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

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

2. یاد بگیرید که چگونه پیام های تعهدی خوب بنویسید

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

پیام‌های commit که به خوبی نوشته شده‌اند همچنین می‌توانند به اسناد مفیدی برای سایر اعضای تیم شما تبدیل شوند که ممکن است ندانند (یا به خاطر بسپارند) برخی چیزها در کد شما چگونه کار می‌کنند. و اگر کسی بخواهد به تاریخچه شما برگردد، لاگ های commit به خوبی نوشته شده نیز ارزشمند خواهند بود!

3. حداقل یک زبان برنامه نویسی را یاد بگیرید

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

برای خواندن کد دیگران نیز زمان آسان تری خواهید داشت زیرا همه این زبان ها دارای ویژگی های مشابه بسیاری هستند. و در نهایت، اگر هر گونه اشکالی پیش بیاید که نیاز به مداخله دستی از طرف شخص دیگری داشته باشد، دانستن یک زبان برنامه نویسی زندگی را برای همه افراد درگیر آسان تر می کند زیرا توانایی خودکارسازی کارهای تکراری تا حد زیادی اصطکاک را کاهش می دهد و کارها را کارآمدتر می کند!

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

4. یاد بگیرید چگونه تست بنویسید

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

این امر به ویژه اگر با وابستگی های خارجی زیادی مانند کتابخانه های شخص ثالث و غیره کار می کنید بسیار مهم است. در چنین مواردی، شکستن چیزها بدون اینکه متوجه شوید بسیار آسان است زیرا چیزی را در یک مکان تغییر داده اید اما فراموش کرده اید که بررسی کنید آیا روی چیزی تأثیر می گذارد یا خیر. در بخش دیگری از سیستم که به آن متکی است (این امر به ویژه در مورد ORM ها صدق می کند).

به عنوان مثال، اگر هر بار یک قطعه خاص از داده ها از پایگاه داده در حافظه بارگذاری شود، تغییر ساختار آن ممکن است به این معنی باشد که سایر بخش های سیستم نیز نمی توانند داده ها را از پایگاه داده در حافظه بارگذاری کنند!

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

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

منبع