لطفا جاواسکریپت مرورگر خود را فعال سازید!

نحوه فعال سازی در کروم
  1. ابتدا باید اینکارو بگنید
  2. بعدش اونکارو
نحوه فعال سازی در فایرفاکس
  1. ابتدا باید اینکارو بگنید
  2. بعدش اونکارو
10 گام برای مبدل‌ شدن به یک برنامه‌نویس چابک

10 گام برای مبدل‌ شدن به یک برنامه‌نویس چابک

رویکرد Agile (چابک) چند سالی است که وارد حوزهٔ توسعه‌ٔ نرم‌افزار شده است و تاکنون ارائهٔ مقالات، برگزاری رویدادها و نشر کتاب‌های مختلفی در این باب صورت گرفته است اما آنچه در این مقاله قصد داریم مورد بررسی قرار دهیم، این است که به چه شکل می‌توانیم به یک Agile Developer مبدل شویم!

1. برنامه‌نویسی دونفره
برنامه‌نویسی به صورت دونفره یا به‌اصطلاح Pair Programming یک راه خوب برای شروع است. پیش از این، در مقاله‌ای تحت عنوان نکاتی در مورد نحوۀ اجرای صحیح Pair Programming یا برنامه‌نویسی دونفره! به‌تفصیل در مورد راه‌کارهای انجام برنامه‌نویسی دونفره نکاتی را مطرح نموده‌ایم.

2. یونیت تستینگ
با استفاده از Unit Testing، می‌توان احتمال به‌وجود آمدن خطا در برنامه را کاهش داد؛ پیشنهاد می‌شود که برای کاهش هرگونه خطا، یونیت تست‌های خود را با استفاده از یونیت‌ تست‌های دیگری هم تست کنید!

3. بازنگری کد
تا می‌توانید همه‌چیز را Review کنید چه در حوزهٔ برنامه‌نویسی و چه در سایر حوزه‌ها تا چنین فعالیتی در ذهن شما نهادینه شود؛ برای مثال، می‌توانید لیست خرید همسرتان را بررسی کرده و در صورتی که اسامی نادقیق کالاهایی در لیست مشاهده شد -مثلاً تاید- آن‌ها را از لیست خط بزنید (لازم به ذکر است که تاید نام یکی از اولین محصولات شوینده بوده که وارد ایران شده است و به‌کار بردن این نام برای محصولات شویندهٔ دیگر، صحیح نیست!)

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

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

6. رعایت اصول قراردادی برنامه‌نویسی
Coding Conventions یا «اصول قرارداری برنامه‌نویسی» چیزی است که با رعایت آن‌ها، از سورس‌کد به‌اصطلاح تمیزی برخوردار خواهیم شد. به‌‌طور مثال، برای نامگذاری متغیرها، متدها، کلاس‌ها، فولدربندی پروژه، نامگذاری تصاویر و ... بایستی از یکسری اصول واحد تبعیت کرده و در همه جای پروژه آن‌‌ها را به‌کار برد. در این صورت، خوانایی کد چه توسط خودمان و چه توسط سایر دولوپرها به‌مراتب بیشتر خواهد شد (مثلاً، در نامگذاری متغیرها اصول نامگذاری camelCase یا PascalCase را رعایت فرمایید.)

7. پیام‌های خطای گویا
از نوشتن پیام خطای بی‌روح مانند «خطای کد 148» خودداری کنید؛ به جای آن، می‌توانید از یک پیام مفید و بامسمی مانند «خطای کد 148: شناسهٔ کاربر ناصحیح است!» استفاده کنید.

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

نکتهٔ مهمی که در این زمینه وجود دارد، این است که اصلاً در این زمینه نگاه متعصبانه نداشته باشد؛ به‌عبارت دیگر، اگر اپن‌سورسی هستید، اصلاً اشکالی ندارد که نیم‌نگاهی هم به محصولات مایکروسافتی داشته باشید و بالعکس.

9. بورد اسکرام/کانبان خود را بهبود دهید
به طور معمول، در یک بورد اسکرام یا کانبان، وظایف از حالت «باید انجام شود» به حالت «در دست اقدام» و سپس «انجام شده» تغییر می‌یابد. با این حال، تمام واقعیت‌های توسعهٔ نرم‌افزار در آن گنجانده نشده است. برای حل این مسأله، باید چند ستون تحت عناوین «شدیداً از هم‌گسیخته»، «بهبودیافته» و «بهبودیافتهٔ بهبودیافته» به آن اضافه شود (منظور از اصطلاح بهبودیافتهٔ بهبودیافته این است که گاهی‌اوقات ما سورس‌کد خود را ریفکتور کرده تا آن‌را بهبود دهیم که کار درستی است اما در آینده، می‌بینیم که سورس‌کد بهبودیافته بازهم جای کار دارد و مجدد آن‌را بهبود می‌دهیم.)

10. استفاده از ابزارهای توسعهٔ نرم‌افزار واحد در تیم برنامه‌نویسی
زمانی که همهٔ اعضای تیم در مورد به‌کارگیری سلسله ابزارهای توسعهٔ نرم‌افزار مورد نظر به‌توافق می‌رسند، همه موظف به پیروی از این تصمیم می‌شوند. مثلاً به مدیرعامل خود یادآوری کنید که هیچ‌یک از افراد تیم‌تان از Excel استفاده نمی‌کند بلکه به‌جای آن از ابزارهای LibreOffice استفاده می‌کنند؛ به همین دلیل، او نیز باید هم‌گام با سایر اعضای تیم باشد. 

خوبی این‌کار این است که اگر همهٔ اعضای تیم از -به‌طور مثال- یک IDE استفاده کنند (ویرایشگر کدی همچون Eclipse)، اگر کسی برای کاستومایز کردن محیط این IDE به مشکلی بربخورد، سایر اعضای تیم به‌سادگی می‌توانند به وی کمک کنند اما این در حالی است که اگر یکی از اعضای تیم از Eclipse، دیگری از Sublime و سومی از NetBeans استفاده کند، تیم توسعهٔ نرم‌افزار از ۳ محیط متفاوت با ۳ حال‌و‌هوای متفاوت برخوردار خواهد بود (البته یادمان نرود که دولوپرها خیلی از دیکتاتوری خوششان نمی‌آید و اگر در انتخاب IDE خود آزادی عمل نداشته باشند، ممکن است حتی تیم را ترک کنند!)

حال نوبت به نظرات شما می‌رسد؛ به نظر شما با پیروی از چه رویکردهای دیگری می‌توان به یک Agile Developer حرفه‌ای مبدل شد؟ نظرات و دیدگاه‌های خود را با ما و سایر کاربران سکان آکادمی به اشتراک بگذارید. 

منبع