چگونه از مشکلاتی که در آینده ممکن است برای نرم‌افزار یا دولوپر به‌ وجود بیایند جلوگیری ‌کنیم؟

چگونه از مشکلاتی که در آینده ممکن است برای نرم‌افزار یا دولوپر به‌ وجود بیایند جلوگیری ‌کنیم؟

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

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

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

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

این قبیل مشکلات با داشتن تیمی که بر کدنویسی یکدیگر نظارت داشته و به‌ اصطلاح Code Review می‌کنند به‌ آسانی قابل‌اجتناب هستند به طوری که این کار هم باعث کنترل و بهتر شدن کیفیت کار می‌شود و هم ابزاری برای ایجاد مالکیت جمعی برای سورس‌کد پروژهٔ ایجاد می‌کند (به خاطر داشته‌ باشیم که اگر در کدنویسی روش Pair Programming اِعمال شود، به‌ احتمال زیاد دیگر به Code Review توسط دیگر اعضای تیم نیازی نخواهد بود که در آیتم بعد بیشتر در مورد این مفهوم خواهیم گفت.)

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

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

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

اما همواره به یاد داشته باشیم که کدنویسی ساده به معنی کدنویسی سریع و پُر از اشکال و باگ نیست بلکه شما باید در عین ساده‌نویسی، با دقت کامل کدنویسی کنید که برای کسب اطلاعات بیشتر حول این موضوع، می‌توانید به مقالهٔ KISS: رویکردی که کمک می‌کند به دولوپر بهتری مبدل گردیم! مراجعه نمایید.

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

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

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

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


online-support-icon