کتاب Effective Software Development for the Enterprise

کتاب Effective Software Development for the Enterprise (توسعه نرم‌افزار موثر برای سازمان: فراتر از طراحی دامنه محور، معماری نرم‌افزار، و برنامه‌نویسی افراطی) در 8 فصل راهنمای کاربردی و گام‌به‌گام توسعه‌ی نرم‌افزار برای سازمان‌های مقیاس بزرگ است که با زبانی ساده آموزش می‌دهد.

در ادامه مقدمه‌ای از کتاب Effective Software Development for the Enterprise را از زبان نویسنده شرح خواهیم داد.

مقدمه‌ای بر کتاب Effective Software Development for the Enterprise:

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

چرا کتاب Effective Software Development for the Enterprise را نوشتم؟

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

این کار تلاشی برای رفع مشکلاتی است که همیشه من را به چالش می‌کشید. می‌دانم که همین مسائل باعث نگرانی بسیاری دیگر نیز می‌شود.

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

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

در ادامه، چند حکایت از گذشته‌ام را ارائه می‌دهم که مرا برای نوشتن این کتاب ترغیب کرد. امیدوارم برخی از خوانندگان تجربه یا شخصیت خود را در بین خطوط تشخیص دهند. این روایت همچنین توضیح خواهد داد که چه نوع مشکلاتی را در سراسر این نشریه حل خواهیم کرد.

* * *

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

کدی که خودمان نوشتیم چگونه می‌تواند ما را پس بزند؟ حتماً کاری که ما انجام می‌دهیم اشتباه است، موافق نیستید؟

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

* * *

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

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

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

ما در وهله اول انسان هستیم، پس باید برای انسان کد بنویسیم. کامپیوترها بدون توجه به اینکه کد را چگونه بنویسیم، آن را درک خواهند کرد. بنابراین نوشتن یک برنامه برای آن‌ها یک تکه کیک است. سعی کنید کدی بنویسید که انسان بتواند آن را درک کند – این یک چالش است!

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

* * *

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

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

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

* * *

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

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

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

اگرچه بسیاری نرم‌افزارهای بدون اشکال را غیرممکن می‌دانند، ما یاد خواهیم گرفت که چگونه در زندگی واقعی به این هدف برسیم.

* * *

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

او یک کتابچه راهنمای پر از مراحل عیب یابی برای انواع مختلف علائمی داشت که برنامه می‌توانست تولید کند. او هر بار در تماس با تیم توسعه مردد بود زیرا مهندسان «آدم‌های باحالی» بودند که وظایف مهم تری نسبت به پشتیبانی از برنامه (در وهله اول توسط آن‌ها نوشته شده بود) داشتند.

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

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

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

* * *

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

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

ما در مورد تکنیک‌های توسعه و معماری برای ساختن سیستم‌های نرم‌افزاری بهتر که توسعه و تغییر آسان‌تر هستند، یاد خواهیم گرفت.

یکی دیگر از عوارض جانبی که در شرایط ذکر شده اتفاق می‌افتد، کاهش سرعت توسعه است.

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

* * *

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

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

هنگامی که چنین شرایطی رخ می‌دهد، باید بپذیرید که برنامه شما مقیاس پذیر نیست.

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

* * *

این موقعیت‌ها به عنوان پایه‌ای برای شش ستون اصلی که کتاب Effective Software Development for the Enterprise بر آن‌ها بنا شده است، عمل کرد. در بخش بعدی به جزئیات بیشتری خواهیم پرداخت.

در حال حاضر، امیدوارم که اکثر شما یا تجربه خود را تشخیص داده باشید یا برای حل این نوع مشکلات در حال حاضر یا در آینده تمایل داشته باشید.

سرفصل‌های کتاب Effective Software Development for the Enterprise:

• Table of Contents
• About the Author
• About the Technical Reviewer
• Acknowledgments
• Preface
• Chapter 1 Introduction
• Chapter 2:Cross-cutting Concerns
• Chapter 3: From Customer Insights to Internal Requirements
• Chapter 4: Design and Architecture
• Chapter 5: Implementation and Coding
• Chapter 6: Testing and Quality Assurance
• Chapter 7: Deployment
• Chapter 8: Maintenance and Support
• Afterword Wrap-up
• References
• Index

جهت دانلود کتاب Effective Software Development for the Enterprise می‌توانید پس از پرداخت، دریافت کنید.