چطور می‌توان پیچیدگی سورس‌کد را در یک شرکت نرم‌افزاری مهار کرد؟

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

فرض کنید مدیر یک شرکت نرم‌افزاری برای حل مشکل پیچیدگی کدها، طی یک اقدام قاطعانه‌، جلسه‌ای با اعضا تشکیل داده و دستور دهد که «کدها را ساده کنید!» یا این‌که «کیفیت کدها را ارتقاء دهید!» و بدون هیچ توضیح دیگری، جلسه را ترک ‌می‌کند. حدس بزنید چه اتفاقی می‌افتد؟ کاملاً درست حدس زدید. عملاً هیچ اتفاقی! زیرا این دستورات علاوه بر این‌که خیلی کلّی هستند، از طرف کسی صادر شده‌اند که در جریان جزئیات کدها نبوده و الزاماً دانش شخصی کافی برای ارائۀ راه‌حل در مورد این مسئله را ندارد. هرچقدر سطح این مدیر بالاتر باشد -هر چند دستور او جنب‌وجوش بیشتری در شرکت ایجاد خواهد کرد- تأثیر عملی آن کمتر خواهد بود. اما چرا؟

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

پس چاره چیست؟ چگونه باید پیچیدگی کدها را برطرف کرد؟ در پاسخ به این سوالات و سایر سوالاتی از این دست بایستی گفت که کار ساده‌ای نیست! باید از تک‌تک اعضای گروه اطلاعات بگیرید و روی این اطلاعات کار کنید تا در نهایت به راه‌حل مناسبی دست یابید. برای این منظور باید روندی مشابه مراحل زیر را طی کنید:

1. از هر یک از اعضای تیم بخواهید که فهرستی از مشکلات موجود در کدها را بنویسند؛ پیچیدگی کدها ممکن است خود را با علائم مختلفی نشان دهد. مثلاً ممکن است کار با این کدها باعث عصبی شدن فرد شود، او را سردرگم نماید، مثل چیزی به نظر برسد که به محض لمس کردن، خرد و تکه‌تکه می‌شود و توصیفاتی از این دست. شما باید سوالاتی را مطرح کنید که اعضا در پاسخ به آن تنها به یک توصیف کلّی بسنده نکرده و به سراغ اصل مطلب بروند. مثلاً بپرسید «وقتی با این کدها کار می‌کنی یا در حال تغییر و اصلاح آن‌ها هستی، چه مسائلی تو رو عصبی می‌کنه؟»  یا این‌که «آیا بخش خاصی در این کد هست که وقتی به آن می‌رسی مأیوس شده و آرزو می‌کنی کاش اصلاً چنین کدی نوشته نمی‌شد؟»

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

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

2. جلسه‌ای با اعضای گروه تشکیل داده و کامپیوتری در اختیار آن‌ها قرار دهید تا به کدهای مورد نظر دسترسی داشته باشند، سپس از آن‌ها بخواهید تا نمونۀ عینی هر مشکلی که در فهرست خود به آن اشاره نموده‌اند را برای شما مشخص کنند. هدف از این جلسه این است که مشخص شود مشکل ذکر شده در کدام دایرکتوری، کدام فایل، کدام کلاس، کدام فانکشن و یا کدام بلوک کد قرار دارد. بنابراین هیچ یک از موارد ذکر شده در فهرست را نادیده نگیرید و حتی اگر برخی مشکلات مطرح شده جنبۀ کلّی و نامشخصی دارند، برای مشخص شدن اصل مشکل، سوالات بیشتر و جزئی‌تری را از اعضا بپرسید تا این مشکل به بخش‌های کوچک‌تر و واضح‌تری شکسته شود (دقت داشته باشید که برای بررسی یک‌به‌یک مشکلات مطرح شده، نیاز به صرف زمان کافی برای هر فرد دارید. بنابراین اگر تیم بزرگی دارید آن را به گروه‌های کوچک‌تر ۶ تا ۷ نفره تقسیم نموده و هر بار با حضور یکی از این گروه‌ها چنین جلسه‌ای را برگزار کنید.) در این جلسه باید حداکثر تلاش خود را بکنید تا دقیقاً همان قطعه کد مشکل دار را بیابید تا بتوانید آن را اصلاح کنید.

3. با استفاده از اطلاعاتی که طی این جلسات به دست آورده‌اید، در ذیل هر دایرکتوری، فایل، کلاس و ... که توسط یکی از اعضای تیم برنامه‌نویسی مشخص شده، گزارشی از مشکلات آن بنویسید (دقت کنید که این گزارش صرفاً مربوط به مشکلات است و نه راه‌حل آن‌ها.) حتی بعضی از این مشکلات ممکن است بسیار ساده و سطحی باشند، مثلاً این‌که «درک کلمۀ FrobberFactory دشوار است.»

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

4. حالا وقت اولویت‌بندی است؛ کاری که باید بکنید این است که تعیین کنید کدام مشکلات فراگیرتر بوده و توسط افراد بیشتری گزارش شده است. این مشکلات، مواردی هستند که رفع آن‌ها باید در بالاترین اولویت قرار بگیرد. مرحلۀ اولویت‌بندی را کسی باید انجام دهد که دید کامل و جامعی نسبت به کل گروه دارد.

باید در نظر داشت که به جز فراگیر بودن مشکل، عوامل دیگری نیز در اولویت‌بندی تأثیرگذار هستند. مثلاً فرض کنید حل مشکل ب وابسته به حل مشکل الف است و یا حل شدن مشکل پ، حل مشکل ت را ساده‌تر می‌کند، بنابراین حتی اگر مشکلات ب و ت فراگیرتر و شدیدتر از مشکلات الف و پ باشند، در این مورد خاص به دلیل تأثیری که حل مشکلات الف و پ بر ب و ت خواهند داشت، مشکلات الف و پ در اولویت بالاتری قرار می‌گیرند.

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

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

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

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

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

6. تا اینجا شما توانسته‌اید مشکلات را پیدا کرده و مسئولیت حل هر کدام را به شخصی خاص واگذار نمایید و هر کسی می‌داند چه کاری را باید انجام دهد. اکنون وقت آن است که هر کدام از مشکلات طبق برنامۀ زمان‌بندی شده حل شوند. روش درست این است که اعضا به طور منظم و در خلال وظایف کاری عادی خود برنامه را بخش‌به‌بخش پیش ببرند. اگر تیم شما برنامه‌ریزی زمانی خاصی دارد -مثلاً بازۀ زمانی ۴ یا ۶ هفته‌ای را برای دستیابی به اهداف مشخصی در نظر می‌گیرد- شما باید در جریان این برنامه ریزی باشید و در هر بازۀ زمانی حل بخش مشخصی از مشکلات را در برنامۀ تیم قرار دهید به نحوی که حل مشکلات، روند کار عادی اعضای تیم را با اختلال مواجه نکند (شواهد حاکی از این است که هم‌زمانی رفع اشکالات و کار عادی و روزمره -اگر به درستی انجام شود- نه تنها باعث مختل و کند شدن کار عادی اعضا نمی‌شود، بلکه بهره‌وری را نیز افزایش می‌دهد چراکه نوع تنوع در کار ایشان ایجاد می‌کند.)

بنابراین شتاب‌زده عمل نکنید و برای حل سریع‌تر مشکلات، کار عادی تیم را متوقف نسازید. فقط تلاش کنید تا طبق برنامه‌ای که تعیین نموده‌اید، آهسته و پیوسته به پیش رفته و به‌تدریج و در طول زمان کیفیت کد‌ها را ارتقاء دهید. انجام این مراحل و پایبندی به این روش موجب می‌شود تا روزبه‌روز سورس‌کد پروژه‌های شما بهتر شود. همواره به یاد داشته باشید که به عنوان یک مهندس نرم‌افزار و یا مدیر، ارتقاء سطح اطلاعات و کسب تجربۀ هرچه بیشتر، نقش اساسی در موفقیت شما خواهد داشت.

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

How to Handle Code Complexity in a Software Company

0


رائفه خلیلی

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






از طریق این فرم، می توانید بدون ثبت نام نظر دهید و یا اگر قبلا ثبت نام کرده اید، با ورود ناحیه ی کاربری می توانید علاوه بر ثبت نظر، به مدیریت نظرات خود نیز بپردازید.
(فیلد اجباری)
(فیلد اجباری)
(فیلد اجباری)
(فیلد اجباری)