مخصوص اعضای ویژه 
چرا این موضوع مهم است؟ خوب، واضح است:
حل کردن پیچیدگی کد معمولا احتیاج به کار دقیق هر کدام از کارکنان دارد.
اگر یک مدیر فقط بگوید "کد را ساده کنید" معمولا اتفاقی نمی‌افتد. زیرا: 1) آن‌ها به اندازه کافی مشخص نیستند، 2) آن‌ها لزوما دانش لازم برای هر بخش خاصی از کد را ندارند، 3) بخشی از درک مسأله در واقع روند حل آن است، و مدیر شخصی نیست که راه‌حل را بنویسد.
اگر شما مدیر مهندسی نرم‌افزار هستید، بسیار وسوسه‌انگیز است تا راه‌حل‌های گسترده‌ای را برای مشکلات موجود در زمینه‌های گوناگون پیشنهاد دهید. مشکل پیچیدگی کد این است که معمولا این مسأله متشکل از پروژه‌های کوچک مختلف است که نیاز به کار دقیق توسط برنامه‌نویسان خاص دارد. بنابراین اگر سعی کنید همه چیز را با همان راه‌حل گسترده مدیریت کنید، این راه‌حل برای بیشتر مواقعی که نیاز به مدیریت دارد متناسب نیست. تلاش شما در راه‌حل گسترده باعث نتیجه معکوس می‌شود، زیرا مهندسان نرم‌افزار احساس می‌کنند که کارهای زیادی انجام می‌دهند اما در واقع یک کد پایه ساده و قابل نگهداری را تولید نمی‌کنند. (این یک الگوی رایج در مدیریت نرم‌افزار است و این اعتقاد که پیچیدگی کد اجتناب‌ناپذیر است و هیچ کاری برای آن نمی‌توان کرد را گسترش می‌دهد).
بنابراین اگر یک کد اولیه پیچیده دارید و می‌خواهید آن را حل کنید، چه کاری می‌توانید به عنوان یک مدیر انجام دهید؟ خوب، ترفند این است که اطلاعات را از هر کدام از کارمندان بگیرید و سپس با آن‌ها کار کرده تا به آن‌ها در حل مسائل کمک کنید. مراحل این کار تقریبا این گونه است:
1. از هر یک از اعضای تیم خود بخواهید تا لیستی از آنچه که کار آن‌ها را در کدنویسی مختل میکند بنویسند. نشانه‌های پیچیدگی کد چیزهایی مانند واکنش‌های احساسی در رابطه با کد، آشفتگی و سردرگمی در مورد کد، احساس در مورد این مسأله که اگر به قسمتی از کد دست بزنید خراب می‌شود، مشکلات بهینه‌سازی و غیره است. بنابراین باید به سؤالاتی همانند این سؤالات پاسخ دهید: آیا در کد قسمتی وجود دارد که تغییر دادن آن باعث عصبی شدن‌‌مان می‌شود؟ یا آیا بخشی وجود دارد که کارمان را مختل کرده و ما را ناامید میکند؟
هر مهندس نرم‌افزار باید لیست خود را تهیه کند. ما توصیه نمی‌کنیم که سیستمی را برای جمع‌آوری این لیست پیاده کنید. فقط افراد مسائل را با هر شیوه‌ای که برایشان ساده‌تر است، برای خودشان بنویسند. چند روز به آن‌ها فرصت دهید تا این لیست را بنویسند. آن‌ها ممکن است طی این زمان به چیزهای دیگری فکر کنند.
لیست نباید فقط در مورد کد پایه شما باشد، بلکه می‌تواند در مورد هر کدی که توسعه‌دهنده با آن کار کرده یا از آن استفاده کرده است باشد.
در این مرحله به دنبال نشانه‌ها هستیم، نه علت. توسعه دهندگان می‌توانند موارد موجود در این لیست را به صورت کلی یا به طور مشخص بنویسند.
2. جلسه‌ای با تیم خود بگذارید و هر فرد لیست خودش را با رایانه‌ای که بتواند به کد پایه دسترسی داشته باشد همراه خود بیاورد. تعداد ایده‌آل برای این جلسه تیمی حدود شش یا هفت نفر است، بنابراین ممکن است بخواهید تیم‌ها را تقسیم‌بندی کنید.
در این جلسه شما می‌خواهید طبق لیست‌ها پیش روید و نامی از پوشه‌های خاص، فایل، کلاس، متد یا بلوک‌هایی از کد را فراهم کنید تا هر نشانه‌ای را به دست آورید. حتی اگر کسی چیزی شبیه به این جمله را بگوید "کل کد پایه تست واحد ندارد" ممکن است بگویید "در مورد زمان خاصی که برای این کار از شما گرفته می‌شود توضیح دهید" و با توجه به پاسخ مهم‌ترین فایل‌ها را برای نوشتن تست به روش صحیح انتخاب کنید. همچنین باید مطمئن شوید که توضیح مختصری در مورد مشکلات به دست آورده‌اید، که ممکن است چیزی شبیه این باشد "بازسازی کد پایه سخت است چون نمی‌دانیم آیا بخش‌های مربوط به دیگران را خراب می‌کنیم یا نه". بنابراین راه‌حل ممکن است تست واحد باشد، اما باید اول تا جایی که ممکن است مشکل را محدود کنید. (این درست است که تقریبا برای همه قسمت‌های کد باید تست نوشته شود، اما اگر هیچ تستی ننوشته‌اید، باید با انجام کارهای قابل انجام در رابطه با این موضوع شروع کنید).
به طور کلی، ایده در این باره این است که دقیقا باید بدانید کدام قسمت کد مشکل دارد. ممکن است واقعا یک مشکل بزرگ وجود داشته باشد، اما این مسأله می‌تواند به مسائل مشخصی از قسمت‌های خاص کد که تحت تأثیر قرار گرفته‌اند، یکی پس از دیگری، شکسته شود.
3. با استفاده از اطلاعاتی که از جلسه به دست آمده است، باگی که مشکل (فقط مشکل نه راه‌حل) را برای هر پوشه، کلاس، فایل و غیره توصیف میکند، بیان می‌شود. باگ به همان اندازه که درک FrobberFactory سخت است می‌تواند ساده باشد.
اگر یک راه‌حل در طی جلسه پیشنهاد شد، می‌توانید به آن توجه کنید، اما در درجه اول خود باگ مهم است.
4. حالا وقت اولویت‌بندی است. اولین کاری که باید انجام دهید این است که ببینید کدام مسائل تعداد بیشتری از توسعه‌دهندگان را تحت تأثیر قرار داده است. این‌ها مهم‌ترین مسائل در اولویت‌بندی هستند. معمولا این قسمت از اولویت‌بندی توسط فردی انجام می‌شود که دیدگاه گسترده‌تری نسبت به توسعه‌دهندگان در تیم یا شرکت دارد. اغلب این شخص مدیر است.
گاهی وقت‌ها مسائلی که باید حل شوند به طور مستقیم با سختی آن‌ها ارتباط ندارد. مثلا مسأله X باید قبل از مسأله Y حل شود، یا حل مسأله A باعث می‌شود مسأله B آسان‌تر حل شود. این بدان معناست که مسأله A و X باید اول حل شوند. اغلب زنجیره‌ای از مسائل و مشکلاتی شبیه این مثال وجود دارد و ترفند آن این است که باید مسأله موجود در پایین پشته را پیدا کنید. مدیریت این بخش از اولویت‌بندی که به طور نادرست انجام می‌شود، یکی از رایج‌ترین و عمده‌ترین اشتباهات در طراحی نرم‌افزار است.
بخش اولویت‌بندی یک کار فنی است که بهتر است توسط عضو فنی تیم انجام شود. گاهی وقت‌ها این شخص مدیر است، اما بعضی اوقات هم مهندس نرم‌افزار ارشد است.
گاهی وقت‌ها شما واقعا نمی‌دانید که کدام مشکل باید اول حل شود و نمی‌توانید قطعه کدی که راحت‌تر می‌توانید آن را اصلاح کنید را بیابید. با این حال، اگر می‌دانید که چگونه مرتبسازی را پیش ببرید، خوب است که این کار را انجام دهید. اما اگر متوجه شدید که باید راه‌حل را پیدا کنید تا مرتبسازی را مشخص کنید، در آن لحظه فقط آن راه‌حل را نگه دارید.
چه شما این کار را به صورت مرتب پیش ببرید یا در طی توسعه آن را انجام دهید، مهم است که برنامه‌نویسان درک کنند که وقتی یک کار اساسی وجود دارد. آن‌ها باید توانایی این را داشته باشند که از کار فعلی خود به آنچه که آن‌ها را واقعا مسدود میکند تغییر کنند. محدودیتی برای این کار وجود دارد، مثلا بازنویسی کل سیستم به یک زبان دیگر فقط برای درست کردن یک فایل به صرفه نیست، اما به طور کلی "یافتن مسأله در پایین پشته" یکی از مهم‌ترین وظایف توسعه‌دهنده هنگام انجام این مرتبسازی برای تمیزی است.
حالا هر باگ را به یک کارمند خاص اختصاص دهید. این روند یک فرآیند مدیریتی خوب و استاندارد است، در حالی که قطعا شامل برخی از کارها و ارتباطات دقیق است و تصور می‌کنیم که مدیران مهندسی نرم‌افزار قبلا با این روند آشنا بوده‌اند.
یک نکته جالب در اینجا این است که برخی باگ‌ها ممکن است مربوط به کد باشند که توسط تیم شما انجام نشده است. در این صورت باید به طور مناسب با سازمان‌دهی کار کنید تا تیم مناسب برای دادن مسئولیت این مسأله به آن‌ها را پیدا کنید.
در برخی از سازمان‌ها، اگر مشکل تیم دیگر خیلی پیچیده و مفصل نباشد، ممکن است تیم شما فقط تغییرات مربوط به خودش را انجام دهد و می‌توانید بر اساس آنچه که فکر می‌کنید برای بهره‌وری کلی بهتر است عمل کنید.
6. حالا که همه این باگ‌ها را دارید، باید نحوه پرداختن به این مسائل را پیدا کنید. به طور کلی، کار درستی که باید انجام دهید این است که مطمئن شوید توسعه‌دهندگان به طور منظم مسائل مربوط به کیفیت کد را رفع می‌کنند.
اگر تیم شما برای یک دوره زمانی مثل سه ماه یا شش هفته برنامه‌ریزی کرده است، باید تمیزکاری کد را در هر برنامه قرار دهید. بهترین راه برای انجام این کار این است که ابتدا توسعه دهندگان تمیزکاری کد را انجام دهند تا جنبه‌های خاص کاری خود را ساده‌تر کنند و سپس جنبه های کاری را انجام دهند. روی هم رفته این امر، کار آن‌ها را کند نمی‌کند. یعنی اگر این کار درست انجام شود، معمولا توسعه‌دهندگان می‌توانند میزانی از کار خود را در یک چهارم کار مشابه انجام دهند.
توسعه را به طور کامل متوقف نکنید تا فقط روی کیفیت کد کار کنید. در عوض مطمئن شوید که کار کیفیت کد به طور مداوم انجام می‌شود و کیفیت کد پایه همیشه در حال اصلاح و بهبود است.
اگر این کارها را انجام دهید، این روند باید در مسیر بهبود کد پایه به خوبی قرار گیرید. در واقع این روند یک روند کلی است. با این حال، مطالب بالا به علاوه برخی از مفاهیم رایج و تجربیات باید برای بهبود عمده‌ای در کیفیت کد کافی باشند و شاید حتی زندگی شما را به عنوان یک مهندس نرم‌افزار یا مدیر بهبود بخشد.
نظرات کاربران در رابطه با این دوره