۵ استراتژی کدنویسی که کمک به تبدیل شدن به دولوپر بهتری می‌کنند

۵ استراتژی کدنویسی که کمک به تبدیل شدن به دولوپر بهتری می‌کنند

مشکلات و دغدغه‌های بسیاری در هنگام کدنویسی پیش‌روی دولوپرها -مخصوصاً آن‌هایی که می‌خواهند بسیار نوآورانه‌تر عمل کنند- وجود دارد؛ اما در این مسیر، یک سری نکات هستند که در فرم‌دهی کدنویسی و توسعهٔ نرم‌افزار می‌توانند بسیار کارآمد و کاربردی باشند و از مشکلاتی که در آینده ممکن است برای نرم‌افزار یا دولوپر به‌وجود بیایند جلوگیری ‌کنند که در این مقاله سعی کرده‌ایم آن‌ها را در قالب ۵ گروه دسته‌بندی کنیم.

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

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

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

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

به خاطر داشته‌ باشیم که اگر در کدنویسی روش Pair Programming یا «برنامه‌نویسی ۲ نفره» اعمال شود، به‌احتمال زیاد دیگر به Code Review توسط دیگر اعضای تیم نیازی نخواهد بود که در مورد بعد، بیشتر در مورد این مفهوم خواهیم گفت.

۳. برنامه‌نویسی ۲ نفره
Pair Programming یا «برنامه‌نویسی ۲ نفره» رویکردی بسیاری ایده‌آل جهت اشتراک‌گذاری دانش و معلومات در یک تیم نرم‌افزاری است؛ این‌که ۲ برنامه‌نویس در سطوح علمی متفاوت کنار یکدیگر بنشینند، بهترین راه برای آموزش و تعلیم دولوپری است که سطح علمی پایین‌تری داشته و تازه‌کار است و از آنجایی که آموزش دادن به دیگری بهترین راه برای تقویت و تثبیت دانش یک فرد است، کسی که حرفه‌ای‌تر و رده بالاتر است هم می‌تواند از این کار سود ببرد.

به خاطر داشته باشید که برای انجام این کار، هر دو فرد -هم فرد حرفه‌ای و هم فرد مبتدی- باید به‌صورت چرخشی از کیبورد استفاده کرده و کدنویسی کنند و این کار نباید به‌صورت «من یاد می‌دم تو فقط گوش کن» باشد بلکه باید از مهارت‌های دو طرف در کدنویسی استفاده شود.

۴. کدنویسی ساده
برنامه‌ریزی برای مسائلی که هنوز پیش نیامده و در حال حاضر غیرضروری هستند باعث می‌شود که سورس‌کد بی‌دلیل پیچیده شود؛ سعی نکنید از هم‌اکنون به فکر نیازهای پروژه‌ٔتان در ۲ سال آینده باشید چراکه در این مدت خیلی چیزها تغییر خواهند کرد، پس بگذارید بسته به نوع و زمان تغییرات، همان موقع برایش چاره‌اندیشی کنید چراکه در غیر این صورت وقت‌تان را بیهوده صرف پیچیده‌تر کردن چیزی می‌کنید که خیلی ساده‌تر از این‌ها حل می‌شود.

اما همواره به یاد داشته باشیم که کدنویسی ساده به معنی کدنویسی سریع و پر از اشکال و باگ نیست بلکه شما باید در عین ساده‌نویسی، با دقت کامل و صحیح کدنویسی کنید.

۵. الگوهای طراحی
اکثر مشکلات برنامه‌نویسی، به یکی از چند دستهٔ موجود مربوط می‌شوند که اتفاقاً تعداد آن‌ها خیلی هم زیاد نیست؛ این مشکلات کلی و معمول، خیلی وقت پیش حل شده و به خوبی در Design Patternها یا «الگوهای طراحی» دسته‌بندی شده‌اند.

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

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

به غیر از موارد فوق، چه استراتژی‌های دیگری را می‌شناسید که می‌توان با به‌کارگیری آن‌ها، به دولوپر حرفه‌ای‌تری مبدل شد؟ نظرات و دیدگاه‌های خود را با ما و سایر کاربران سکان آکادمی به اشتراک بگذارید.

منبع