پیچیدگی سورس‌کد مشکلی است که اغلب شرکت‌های نرم‌افزاری با آن دست و پنجه نرم می‌کنند و مدیران این دست شرکت‌ها خواهان برطرف شدن آن به بهترین شکل ممکن هستند. اما حل این مسئله نیازمند توجه و تلاش پیگیر تک‌تک اعضای تیم برنامه‌نویسی است (البته می‌توان از ابزارهای مرتبط نیز استفاده نموده و کار را برای خود ساده‌تر نمود اما از آنجا که ساده‌سازی کدها غالباً نیازمند کار جزء به جزء و دقیق اعضای تیم است، ابزارها نمی‌توانند جای نیروی انسانی را بگیرند و در نهایت این تجربه، دقت‌نظر و تلاش نیروی انسانی است که می‌تواند کدهای پیچیده را ساده سازد).
فرض کنید مدیر یک شرکت نرم‌افزاری برای حل مشکل پیچیدگی کدها، طی یک اقدام قاطعانه، جلسه‌ای با اعضاء تشکیل داده و دستور دهد که «کدها را ساده کنید!» یا اینکه «کیفیت کدها را ارتقاء دهید!» و بدون هیچ توضیح دیگری، جلسه را ترک می‌کند. حدس بزنید چه اتفاقی می‌افتد؟ در چنین شرایطی، عملاً هیچ اتفاقی رخ نخواهد داد زیرا این دستورات علاوه بر اینکه خیلی کلّی هستند، از طرف کسی صادر شده‌اند که در جریان جزئیات کدها نبوده و الزاماً دانش شخصی کافی برای ارائۀ راه‌حل در مورد این مسئله ندارد. هرچقدر سطح این مدیر بالاتر باشد -هرچند دستور او جنب‌وجوش بیشتری در شرکت ایجاد خواهد کرد- تأثیر عملی آن کمتر خواهد بود!
مسئله‌ای که در مورد پیچیدگی کدها وجود دارد این است که پیچیدگی شدید کدهای نرم‌افزاری، حاصل پیچیدگی‌های کوچک در بخش‌های کوچک‌تر کدهای نوشته شده توسط هر یک از اعضای تیم کدنویسی است؛ بنابراین اگر مدیر شرکت راه‌حلی کلی برای این مسئله ارائه دهد، احتمال اینکه راه‌حل وی با تک‌تک اعضای تیم سازگار باشد بسیار اندک است و در اکثر مواقع، نتیجۀ معکوس می‌دهد و به همین دلیل است که در بسیاری از شرکت‌های نرم‌افزاری، پیچیدگی کدها یک مسئله اجتناب‌ناپذیر تلقی شده و اقدامی برای حل آن صورت نمی‌گیرد. پس چاره چیست و چگونه باید پیچیدگی کدها را برطرف کرد؟
در پاسخ به این سؤالات و سایر سؤالاتی از این دست، باید گفت که رویارویی با این مسئله کار ساده‌ای نیست بلکه باید از تک‌تک اعضای گروه اطلاعات بگیرید و روی این اطلاعات کار کنید تا در نهایت به راه‌حل مناسبی دست یابید. برای این منظور، باید شش گام زیر را یک به یک طی کنید:
گام اول
از هر یک از اعضای تیم بخواهید تا فهرستی از مشکلات موجود در کدها را بنویسند. پیچیدگی کدها ممکن است خود را با علائم مختلفی نشان دهند؛ مثلاً ممکن است کار با این کدها باعث عصبی شدن دولوپر شود، او را سردرگم نماید، مثل چیزی به نظر برسد که به محض لمس کردن، خرد و تکه‌تکه می‌شود و دیگر مسائلی از این دست.
همچنین باید سؤالاتی را مطرح کنید که اعضاء در پاسخ به آن‌ها، تنها به یک توصیف کلی بسنده نکرده و به سراغ اصل مطلب بروند. مثلاً بپرسید «وقتی با این کدها کار می‌کنی یا در حال تغییر و اصلاح آن‌ها هستی، چه مسائلی تو رو عصبی می‌کنه؟» یا اینکه «آیا بخش خاصی در این کد هست که وقتی به آن می‌رسی، مأیوس شده و آرزو می‌کنی کاش اصلاً چنین کدی نوشته نمی‌شد؟»
هر یک از اعضای گروه باید شخصاً فهرستی از مشکلات کدها تهیه کند. مهم نیست که این فهرست چه‌طور و با چه نگارش و ادبیاتی نوشته شود، مهم نوشتن فهرست مشکلات است. سپس چند روزی به اعضاء فرصت دهید تا به تدریج فهرست خود را کامل نمایند.
هم مشکلات کدبیس شرکت و هم سایر کدهایی که برنامه‌نویسان گروه با آن سروکار دارند، می‌تواند در این فهرست مطرح شود. همچنین مهم نیست که دولوپرها در سطح بسیار عمومی مشکل را مطرح نمایند و یا اینکه به صورت تخصصی به آن بپردازند (دقت داشته باشید که هدف شما در این مرحله یافتن مشکلات است و نه کشف علل آن‌ها).
گام دوم
جلسه‌ای با اعضای گروه تشکیل داده و کامپیوتری در اختیار آن‌ها قرار دهید تا به کدهای مورد نظر دسترسی داشته باشند. سپس از آن‌ها بخواهید تا نمونۀ عینی هر مشکلی که در فهرست خود به آن اشاره نموده‌اند را برای شما مشخص کنند. هدف از چنین مرحله‌ای این است که مشخص شود مشکل ذکر شده در کدام دایرکتوری، کدام فایل، کدام کلاس، کدام فانکشن و یا کدام بلوک کد قرار دارد؛ بنابراین هیچ یک از موارد ذکر شده در فهرست را نادیده نگیرید و حتی اگر برخی مشکلات مطرح شده جنبۀ کلی و نامشخصی داشتند، برای مشخص شدن اصل مشکل، سؤالات بیشتر و جزئی‌تری از اعضاء بپرسید تا این مشکل به بخش‌های کوچک‌تر و واضح‌تری شکسته شود.
دقت داشته باشید که برای بررسی یک به یک مشکلات مطرح شده، نیاز به صرف زمان کافی برای هر فرد دارید؛ بنابراین اگر تیم بزرگی دارید، آن را به گروه‌های کوچک‌تر ۶ تا ۷ نفره تقسیم نموده و هر بار با حضور یکی از این گروه‌ها چنین جلسه‌ای را برگزار کنید.
گام سوم
با استفاده از اطلاعاتی که طی این جلسات به دست آورده‌اید، در ذیل هر دایرکتوری، فایل، کلاس و ... که توسط یکی از اعضای تیم برنامه‌نویسی مشخص شده، گزارشی از مشکلات آن بنویسید (دقت کنید که این گزارش صرفاً مربوط به مشکلات است و نه راه‌حل آن‌ها). حتی بعضی از این مشکلات ممکن است بسیار ساده و سطحی باشند، مثلاً اینکه «درک کلمۀ FrobberFactory دشوار است.»
اگر در طی جلسه راه‌حل بعضی از مشکلات مشخص شده است، می‌توانید در گزارش خود به آن نیز اشاره کنید اما باز هم تأکید می‌کنیم که این گزارش اساساً باید راجع به مشکلات باشد.
گام چهارم
حال وقت اولویت‌بندی است. کاری که باید بکنید این است که تعیین کنید کدام مشکلات فراگیرتر بوده و توسط افراد بیشتری گزارش شده است. این مشکلات، مواردی هستند که رفع آن‌ها باید در بالاترین اولویت قرار بگیرد و مرحلۀ اولویت‌بندی را کسی باید انجام دهد که دید کامل و جامعی نسبت به کل گروه دارد.
باید در نظر داشت که به جز فراگیر بودن مشکل، عوامل دیگری نیز در اولویت‌بندی تأثیرگذار هستند. مثلاً فرض کنید حل مشکل ب وابسته به حل مشکل الف است و یا حل شدن مشکل پ، حل مشکل ت را ساده‌تر می‌کند؛ بنابراین حتی اگر مشکلات ب و ت فراگیرتر و شدیدتر از مشکلات الف و پ باشند، در این مورد خاص به دلیل تأثیری که حل مشکلات الف و پ بر ب و ت خواهند داشت، مشکلات الف و پ در اولویت بالاتری قرار می‌گیرند.
یکی از بزرگ‌ترین اشتباهات طراحی نرم‌افزار همین اولویت‌بندی نادرست است. در واقع، بسیار مهم است که کار درست در موقعیت درست و با ترتیب زمانی درست انجام شود. عدم رعایت ترتیب زمانی در حل مسائل و یا وادار کردن دولوپرها به حل مسائل خارج از روند تعیین شده، موجب پیچیدگی کدها می‌شود.
این بخش از اولویت‌بندی، یک کار تکنیکی است و بهتر است توسط مدیر فنی تیم انجام شود (مدیر فنی می‌تواند مدیر شرکت و یا مهندس ارشد نرم‌افزار تیم باشد). ممکن است در برخی موارد، اولویت‌بندی صورت بگیرد و سپس در حین انجام کار، مشخص شود که اولویت‌بندی صورت گرفته مناسب نبوده و تغییر آن ضروری است؛ در چنین مواردی، باید اولویت‌بندی اولیه را اصلاح نموده و ترتیب حل مسائل را تغییر دهید. حتی گاهی‌اوقات ممکن است قبل از ورود به مرحلۀ حل مسائل، به هیچ وجه امکان اولویت‌بندی وجود نداشته باشد که در چنین مواردی باید موقتاً مرحلۀ اولویت‌بندی را کنار گذاشته و آن را به زمانی دیگر موکول نمایید.
پس از تعیین اصولی اولویت‌ها، دولوپرها باید در مورد رعایت این اولویت‌بندی توجیه شده و خود را ملزم به رعایت آن‌ها بدانند. اگر هم در حین کار متوجه شدند که حل مشکلی دیگر پیش‌نیاز اولویت‌های بالاتر است، باید این آزادی عمل را داشته باشند که کار فعلی را موقتاً کنار گذاشته و به انجام موارد پیش‌نیاز بپردازند.
گام پنجم
اکنون زمان آن فرا رسیده تا رفع هر مشکل را به یکی از اعضا واگذار کنید. این یک فرآیند مدیریتی استاندارد است و نیاز به کار دقیق، شناخت و روابط بین‌فردی متقابل دارد. در حقیقت، باید بدانید کدام کار را به چه کسی بسپارید و مسئله‌ای که در این مورد وجود دارد، مشکلاتی است که تیم قادر به حل آن‌ها نبوده و یا مسئولیت حل آن فراتر از وظایف تیم شما است. در چنین مواردی، باید در کل تیم جستجو کنید، با سایر مدیران رده بالاتر گفتگو نموده و در نهایت افراد مناسبی را بیابید که بتواند حل این مشکلات را بر عهده بگیرد.
گام ششم
تا این مرحله از کار، شما توانسته‌اید مشکلات را پیدا کرده و مسئولیت حل هر کدام را به شخصی خاص واگذار نمایید و هر کسی می‌داند چه کاری را باید انجام دهد. اکنون وقت آن است که هر کدام از مشکلات، طبق برنامۀ زمان‌بندی شده حل شوند. روش درست این است که اعضاء به طور منظم و در خلال وظایف کاری عادی خود، برنامه را بخش به بخش پیش ببرند.
اگر تیم شما برنامه‌ریزی زمانی خاصی دارد (مثلاً بازۀ زمانی ۴ یا ۶ هفته‌ای را برای دستیابی به اهداف مشخصی در نظر می‌گیرد) شما باید در جریان این برنامه‌ریزی باشید و در هر بازۀ زمانی، حل بخش مشخصی از مشکلات را در برنامۀ تیم قرار دهید به نحوی که حل مشکلات، روند کار عادی اعضای تیم را با اختلال مواجه نکند (شواهد حاکی از آن است که هم‌زمانی رفع اشکالات و کار عادی و روزمره -اگر به درستی انجام شود- نه تنها باعث مختل و کند شدن کار عادی اعضا نمی‌شود، بلکه بهره‌وری را نیز افزایش می‌دهد زیرا نوعی تنوع در کار ایشان ایجاد می‌کند).
بنابراین شتاب‌زده عمل نکنید و برای حل سریع‌تر مشکلات، کار عادی تیم را متوقف نسازید. فقط تلاش کنید تا طبق برنامه‌ای که تعیین نموده‌اید، آهسته و پیوسته به پیش رفته و به تدریج و در طول زمان کیفیت کدها را ارتقاء دهید. انجام این مراحل و پایبندی به این روش، موجب می‌شود تا روز به روز سورس‌کد پروژه‌های شما بهتر شود.
دیدگاه شما چیست؟ به نظر شما آیا این روش می‌تواند مؤثر واقع شده و پیچیدگی کدها را کاهش دهد؟ تا به حال تجربه‌ای از به‌کارگیری روشی مشابه و یا متفاوت با این روش داشته‌اید؟ نظرات و تجربیات خود را با سایر کاربران سکان آکادمی به اشتراک بگذارید.