مشاهده خبر بازگشت به لیست اخبار

چگونه با پیچیدگی کدها در نرم افزار شرکت، رفتار کنیم.(1)

نوشته شده توسط: فروزان
در تاریخ:

http://www.codesimplicity.com/post/how-to-handle-code-complexity/

 

چگونه با پیچیدگی کد در نرم افزار شرکت رفتار کنیم.

بخش اول

این مقاله یک بیانه آشکار است که پیامد های ظریفی دارد.

تنها برنامه نویسان مستقل، می توانند پیچیدگی های کد را برطرف کند.

به این معنا که، برطرف کردن پیچیدگی های کد نیاز به توجه یک فرد به کد دارد، قطعا آنها می توانند از ابزار مناسب برای آسان شدن کار استفاده کنند. اما در نهایت این هوش، توجه و کار انسان است که کد را ساده می کند.

پس چی؟ چرا این مسئله مهم است؟ خوب، به طور واضح تر :

حل پیچیدگی های کد معمولا نیاز به کار دقیق در سطح عامل است.

اگر یک مدیر فقط می گوید: " کد را ساده کن!" و در آن شرایط آن را رها  کند، معمولا هیچ اتفاقی نمی افتد، زیرا 1) به اندازه کافی خاص نیستند 2) آنها لزوما دانش مورد نیاز در مورد هر قطعه کد را ندارند. و 3) بخشی از درک مشکل در واقع پیش رفتن در فرآیند حل آن است و مدیر آن شخصی که راه حل را می نویسد نیست.

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

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

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

مراحل تقریبا به این شکل است:

1-    از هر کدام از اعضا بخواهید هر آنچه در مورد کد، آنها را ناامید کرده است را لیست کنند. علائم پیچیدگی کد چیزهایی همانند عکس العمل های عاطفی به کد ، ابهامات درباره کد، احساس اینکه در صورت لمس آن بخش خواهد شکست، مشکلات بهینه سازی و غیره، می باشد. بنابراین شما پاسخ سوالاتی از جمله " آیا بخشی از سیستم وجود دارد که در صورت تغییر آن، شما عصبی شوید؟ " یا " آیا بخشی از کد وجود دارد که با کار کردن با آن ناامید شوید؟"  را می خواهید.

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

لیست لزومی ندارد تنها درباره کدهای خود شما باشد، می تواند راجع به هر کدی که توسعه دهنده با آن کا ر یا از آن استفاده می کند، باشد.

در این مرحله شما دنبال علائم می گردید نه به دنبال علت . توسعه دهندگان می توانند برای این لیست،  به خوبی یا به ویژه ای که آنها می خواهند باشند.

2-    با تیم خود جلسه ای را تشکیل دهید، و بخواهید هر شخص لیست خود و کامپیوتری که با استفاده از آن به کد دسترسی پیدا می کند را بیاورد. اندازه ایده آل برای یک جلسه تیمی همانند این ، حدود 6 یا 7 نفر می باشد،  بنابراین ممکن است شما بخواهید موارد را به زیر- تیم بشکنید.

در این جلسه شما می خواهید لیست را مرور کنید و نام پوشه خاص، فایل، کلاس، روش، یا بللوکی از کد را به منظور ایجاد ارتباط بین علائم، بدست آورید. حتی اگر کسی چیزی شبیه به این می گوید که" کل کد تست واحدی نداشته است"، شما باید پاسخ دهید" در مورد زمان خاصی که شما را تحت تاثیر قرار داده است بگویید" و از پاسخ آنها برای محدود کردن بلافاصله فایل هایی که برای تست واحد مهم است استفاده کنید." همچنین می خواهید از دریافت شرحی از مشکل اطمینان حاصل کنید. چیزی بیشتر شبیه به این که " بهبود کد مشکل است زیرا من نمی دانم ماژول شخص دیگری را می شکنم " پس ممکن است راه حل تست واحد باشد، اما در ابتدا می خواهید تا حد امکان جایی که مشکل نهفته است را محدود کنید( این درست است که تقریبا تمام کد ها باید تست واحد شوند اما اگر هیچ تست های واحدی ندارید شما نیاز به شروع به انجام برخی از کارهای شدنی بر روی موضوع دارید.)

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

3-    از اطلاعات جلسه استفاده کنید، باگ توصیف مشکل برای هر پوشه،  فایل، کلاس و غیره  را بایگانی کنید( نه راه حل ها فقط مشکلات ). یک باگ می تواند به سادگیه "سختی درک FrobberFactory" باشد.

اگر راه حلی در طول جلسه پیشنهاد شد، می توانید آن را در باگ یادداشت کنید اما خود باگ در درجه اول باید در مورد مشکلات باشد.

 

با ادامه این مقاله در بخش بعدی با ما همراه باشید.

 

.

 

 


هیچ دیدگاهی تاکنون برای این خبر ثبت نشده است.

اولین نفر باشید!
دیدگاه خود را ثبت کنید: