آنچه در این مقاله قصد داریم مورد بررسی قرار دهیم، این است که به چه شکل می‌شود به دولوپری مبدل شویم که می‌تواند گوی سبقت را از دیگران برباید!
برنامه‌نویسی دونفره
Pair Programming (برنامه‌نویسی به صورت دونفره) یک راه خوب برای شروع است. پیش از این، در مقاله‌ای تحت عنوان نکاتی در مورد نحوۀ اجرای صحیح Pair Programming یا برنامه‌نویسی دونفره! به تفصیل در مورد راه‌کارهای انجام برنامه‌نویسی دونفره نکاتی را مطرح نموده‌ایم.
یونیت تستینگ
با استفاده از Unit Testing، می‌توان احتمال به وجود آمدن خطا در برنامه را کاهش داد. در همین راستا، پیشنهاد می‌شود که برای کاهش هرگونه خطا، یونیت تست‌های خود را با استفاده از یونیت تست‌های دیگری هم تست کنید!
بازنگری کد
تا می‌توانید همه‌چیز را Review کنید؛ چه در حوزهٔ برنامه‌نویسی و چه در سایر حوزه‌ها تا چنین فعالیتی در ذهن شما نهادینه شود که در این راستا، می‌توانید به مقالات زیر نیز مراجعه نمایید:
- Code Review: راه‌کارهایی امن به منظور تضمین امنیت سورس‌کد
- چگونه به شکلی حرفه‌ای دست به Code Review بزنیم؟
ساده زیبا است
هرگز پیچیده کدنویسی نکنید. همان‌طور که در حوزهٔ طراحی گفته می‌شود «ساده زیبا است»، در حین کدنویسی هم باید این قانون را رعایت کرد چرا که در صورت ویرایش کردن کدها در آینده، خواه توسط خودتان و خواه توسط سایر دولوپرها، این سادگی کمک بسیار زیادی به درک سریع سورس‌کد خواهد کرد.
استفاده از دیزاین پترن‌ها
Design Pattern (الگوی طراحی) کیفیت سورس‌کد شما را بسیار افزایش می‌دهد که برای کسب اطلاعات بیشتر، می‌توانید به دورهٔ آشنایی با الگوهای طراحی مراجعه نمایید.
رعایت اصول قراردادی برنامه‌نویسی
Coding Conventions (اصول قرارداری کدنویسی) چیزی است که با رعایت آنها از سورس‌کد به اصطلاح تمیزتری برخوردار خواهیم شد. به طور مثال، برای نامگذاری متغیرها، متدها، کلاس‌ها، فولدربندی پروژه، نامگذاری تصاویر و ... بایستی از یکسری اصول واحد تبعیت کرده و در همه جای پروژه آنها را به کار برد. در این صورت، خوانایی کد، چه توسط خودمان و چه توسط سایر دولوپرها، به مراتب بیشتر خواهد شد (مثلاً، در نامگذاری متغیرها اصول نامگذاری camelCase یا PascalCase را رعایت فرمایید.)
پیام‌های خطای گویا
از نوشتن پیام خطای بی‌روح مانند «خطای کد 148» خودداری کرده و در عوض می‌توانید از یک پیام مفید و بامسمی مانند «خطای کد 148: شناسهٔ کاربر ناصحیح است!» استفاده کنید (برای کسب اطلاعات بیشتر، می‌توانید به مقالهٔ رقم زدن تجربهٔ کاربری بهتر با نمایش Error Message (پیام خطا) مناسب مراجعه نمایید.)
آشنایی با سایر زبانهای برنامه‌نویسی
از یک برنامه‌نویس خوب انتظار می‌رود که بتواند به غیر از زبان برنامه‌نویسی اصلی خود، با سایر زبانهای برنامه‌نویسی هم کد بزند یا حداقل بتواند سورس‌کد نوشته شده با سایر زبان‌ها را بخواند و درک کند. در همین راستا، توصیه می‌شود که در اوقات فراغت خود شروع به مطالعه در مورد سایر زبانهای برنامه‌نویسی کنید.
نکتهٔ مهمی که در این زمینه وجود دارد، این است که اصلاً در این زمینه نگاه متعصبانه نداشته باشد؛ به عبارت دیگر، اگر اپن‌سورسی هستید، اصلاً اشکالی ندارد که نیم‌نگاهی هم به محصولات مایکروسافتی داشته باشید و بالعکس!
بورد اسکرام/کانبان خود را بهبود دهید
به طور معمول، در یک بورد اسکرام یا کانبان، وظایف از حالت «باید انجام شود» به حالت «در دست اقدام» و سپس «انجام شده» تغییر می‌یابند. با این حال، تمام واقعیت‌های توسعهٔ نرم‌افزار در آن گنجانده نشده است که برای حل این مسأله باید چند ستون دیگر تحت عناوین زیر به آن بیفزایید:
- شدیداً از هم‌گسیخته
- بهبودیافته
- و بهبودیافتهٔ بهبودیافته
منظور از اصطلاح بهبودیافتهٔ بهبودیافته این است که گاهی‌اوقات ما سورس‌کد خود را ریفکتور کرده تا آن را بهبود بخشیم که کار درستی است اما در آینده، می‌بینیم که سورس‌کد بهبودیافته باز هم جای کار دارد و مجدد آن را ریفکتور می‌کنیم تا بهبود یابد.
استفاده از ابزارهای توسعهٔ نرم‌افزار واحد در تیم برنامه‌نویسی
زمانی که همهٔ اعضای تیم در مورد به‌کارگیری سلسله ابزارهای توسعهٔ نرم‌افزار مورد نظر به توافق می‌رسند، همه موظف به پیروی از این تصمیم می‌شوند. مثلاً به مدیرعامل خود یادآوری کنید که وقتی هیچ‌یک از افراد تیم‌تان از Excel یا Word استفاده نمی‌کند بلکه به جای آنها از پکیج LibreOffice استفاده می‌کند، به همین دلیل وی نیز باید هم‌گام با سایر اعضای تیم باشد.
خوبی چنین کاری این است که اگر همهٔ اعضای تیم به طور مثال از یک IDE خاص استفاده کنند (نرم‌افزاری همچون Eclipse یا IntelliJ IDEA)، اگر کسی برای کاستومایز کردن محیط این IDE به مشکلی برخورد و یا دیگر چالش‌ها کار با این دست نرم‌افزارها، سایر اعضای تیم توسعهٔ نرم‌افزار به سادگی می‌توانند به وی کمک کنند اما این در حالی است که اگر یکی از اعضای تیم از Eclipse، دیگری از Sublime، سومی از NetBeans و چهارمی از IntelliJ IDEA استفاده کند، تیم توسعهٔ نرم‌افزار از چهار محیط متفاوت با چهار حال‌و‌هوای متفاوت برخوردار خواهد بود (البته یادمان نرود که دولوپرها خیلی از دیکتاتوری خوششان نمی‌آید و اگر در انتخاب IDE خود آزادی عمل نداشته باشند، ممکن است حتی تیم را ترک کنند!)
حال نوبت به نظرات شما می‌رسد. به نظر شما با پیروی از چه رویکردهای دیگری می‌توان به یک دولوپر تراز اول و حرفه‌ای مبدل شد؟ نظرات، دیدگاه‌ها و تجربیات خود را با سایر کاربران سکان آکادمی به اشتراک بگذارید.
