اصول اساسی مهندسی نرم افزار

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

مهندسان فقط سازنده نیستند

مهندسی نرم افزار تماماً یافتن و بکارگیری بهترین روشها برای حل مشکلات فنی نرم افزار است (به همین دلیل بسیار سرگرم کننده است).

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

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

این بدان معنا نیست که مهندسان نرم افزار دائماً با ابزاری (مانند زبانها و چارچوبها و…) برای کارآمدتر کردن طراحی “نقشه” نرم افزار خود روبرو نمی شوند … اما همیشه به کسی احتیاج است تا تشخیص دهد چه چیزی باید ساخته شود.

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

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

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

چگونه یک مهندس یک مسئله را حل می کند

رمز و راز مهمی در مهندسی وجود ندارد – شما فقط یک فرایند سیستماتیک را برای حل خلاقانه مشکلات اعمال می کنید. این فرایند به شرح زیر است:

مشکل را درک کنید
برای راه حل برنامه ریزی کنید
آن برنامه را اجرا كن
نتایج خود را برای دستیابی به دقت بیشتر بررسی کنید

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

گفتنش از انجامش راحت تر است – مهندسان اغلب دوست دارند چیزهایی را ایجاد کنند، تا جایی که ترجیح می دهند در ساختن یک چیز جالب غوطه ور شوند تا اینکه مطمئن شوند که مسئله درست را حل می کنند. صبر کنید ، به نظر می رسد کمی آشنا است …

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

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

اصول و بهترین روشهای مهندسی (نرم افزار)

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

مهمترین آنهایی که درک می شوند موارد سطح بالا هستند – شما می توانید بعداً برگردید و در مورد برخی از نرم افزارهای خاص بیشتر فکر کنید ، اگر مدتی پشت فرمان کد واقعی باشید!

شروع سطح بالا

قبل از اینکه بخواهید راه حلی را پیاده کنید ، مسئله را کاملاً حل کنید – به طور جدی مهمترین کاری است که احتمالاً می توانید انجام دهید.
تقسیم و تسخیر کنید – مشکلات بزرگتر را به چندین مشکل کوچکتر تقسیم کنید که می تواند به طور مستقل روی آنها کار شود. آنها شاتل فضایی یا اهرام را در یک قدم بزرگ نساختند. به این ترتیب مشکلات ترسناک قابل کنترل می شوند.
KISS (ساده و احمقانه نگهش دار) – KISS (Keep It Simple Stupid) ممکن است شعار مهندس باشد. ما تمایل خود را برای ساختن سیستم های بیش از حد پیچیده در بعضی مواقع اذعان کرده ایم (جلسات ناشناس برای این نوع کارها وجود دارد) و ما را مجبور می کند اعتراف کنیم که سادگی راه حل شما را بسیار بهتر می کند. این نیست که بگوییم سادگی آسان است! این اغلب نتیجه کشیدن مو و دندان قروچه است زیرا محلولهای پیچیده برای تجزیه اجزای اصلی آنها بازسازی می شوند. KISS به روشهای بیشماری دیگر نیز اعمال می شود – به عنوان مثال ، در میان مبتدیان ، تمایل واقعی به بیش از حد فکر کردن در مورد مشکلات منطقی و ارائه راه حل های عجیب و غریب وجود دارد ، در حالی که روش ساده “گنگ” به سادگی بهتر است.
به خصوص از اشتباهات خود بیاموزید – مهندسی همیشه در حال تغییر است و به ویژه مهندسی نرم افزار ممکن است یکی از سریع ترین زمینه های تغییر در کره زمین باشد. شما باید همیشه یاد بگیرید ، هم از افراد دیگر این صنعت و هم از طریق پذیرفتن اشتباهات و کد های ضعیف خود. این دستورالعمل یک حرفه طولانی و تحریک کننده در این زمینه است.
دلیل وجود این نرم افزار را به خاطر بسپارید – تصمیمات کوچک بی شماری وجود دارد که در طول کار خود به عنوان یک توسعه دهنده با آنها روبرو خواهید شد و اگر تصویر بزرگتری را نمی دانید ، ممکن است وقت خود را برای رفتن به یک مسیر اشتباه تلف کنید. این تقریباً اصل اساسی است!
به یاد داشته باشید که شما از این نرم افزار استفاده نخواهید کرد – مهندسان بسیار وسوسه دارند که راه حل هایی را برای خود طراحی کنند. به کاربر فکر کنید نه به خودتان. تصور نکنید کاربر شما همان سطح صلاحیت فنی یا آشنایی با سیستم را دارد که شما می دانید.

فکر کردن در مورد روند کار

چشم انداز روشنی برای پروژه داشته باشید – اگر دقیقاً نمی دانید چه چیزی را می خواهید بسازید ، چیز اشتباهی خواهید ساخت. اغلب ، به خصوص اگر به صورت آزاد کار می کنید یا در یک تیم کار می کنید ، این بدان معناست که سوالات مهمی از مشتری می پرسید. ضرب المثل قدیمی این است: “شما دقیقاً همان چیزی را ساختید که ما خواسته بودیم ، اما آنچه را که نیاز داریم ، درست نکردید”.
یک فرآیند دقیق داشته باشید – مهندسی نرم افزار یک فعالیت خلاقانه در طراحی است اما باید بصورت سیستماتیک انجام شود. نیازی نیست که در روند کار غرق شوید ، اما نمی توانید با عجله به راه حل برسید. ما در حال حل برخی از مشکلات بسیار پیچیده هستیم ، بنابراین شما باید مراقب یک روش منطقی و متفکرانه برای حل آنها و یک رویکرد دقیق برای مدیریت پروژه های خود باشید ، در غیر این صورت آنها به سرعت از شما دور می شوند.
برنامه ها را به سرعت توسعه دهید – این یکی از مواردی است که در بخش Agile کمی بیشتر به آن خواهیم پرداخت اما مطمئناً در اینجا قابل ذکر است. نیازهای پروژه نرم افزار به طور مداوم تغییر می کند. هرچه روند کار شما سریعتر باشد ، بهتر می توانید به آن تغییرات پاسخ دهید.
ابتدا کار را انجام دهید ، سپس درست کار کنید ، سپس زیبا به نظر برسید – این سازگاری است با مورد “توسعه سریع برنامه ها”، و دوباره بر فلسفه “اول امتحانش کنید” تأکید دارد. به طور خاص ، این مقاله می گوید که شما ابتدا باید چیزی بسازید که کار کند (حتی اگر با سیم و نوار چسب کنار هم نگه داشته شود) و سپس ببینید آیا ارزش دارد که برای درست کار کردن وقت بگذارید. تا آخرین مرحله فرآیند ، نباید واقعاً راه حل شما “خوب” به نظر برسد (به عنوان مثال ، دوباره سازی کد خود).

فکر کردن به (کد کردن) راه حل

(You Ain’t Gonna Need It) YAGNI (شما دیگر نیازی به آن نخواهید داشت!) – یک وسوسه بسیار قوی برای ساختن کدی وجود دارد که می تواند با انعطاف پذیری فوق العاده و “عالی” به هرگونه نیاز آینده پاسخ دهد. این کار را انجام ندهید! شما در حال هدر دادن تلاش خود هستید زیرا واقعاً نیازی به آن همه ویژگی یا گزینه اضافی یا انعطاف پذیری اضافی نخواهید داشت. فقط آنچه نیاز دارید بسازید. به ما و هر مهندس دیگری که به دنبال کد قدیمی است و تمام تلاش های بیهوده خود را خسته می کند اعتماد کنید.
DRY (Don’t Repeat Yourself) (خود را تکرار نکنید) – یکی از بهترین موارد در مورد کد استفاده مجدد از آن است. اگر یک کد خوب می نویسید که یک مشکل مفید را در یک مکان حل می کند ، وقتی مشکل در جاهای دیگر هم پیش آمد ، دوباره به آن مراجعه کنید. از دیدگاه شما ، هر زمان که خود را پیدا می کنید و در چند بار به صورت دستی تایپ می کنید ، راهی وجود دارد که همه آن را در یک کار واحد ترکیب کنید که چندین بار اجرا می شود.
انتزاع (Abstraction) را بپذیرید – در مهندسی نرم افزار همه چیز در مورد انتزاع یا نادیده گرفتن جزئیات و حل مشکلات مرتبه بالاتر است. به هیچ دلیلی نیازی به نوشتن کد ماشین یا کد اسمبلی ندارید – زبانهای برنامه نویسی امروزی به شما امکان می دهند فقط به کامپیوتر بگویید که چه می خواهید و آن را ارائه می دهد. این امر همچنین در مورد چگونگی برخورد شما با سیستم های پیچیده نیز صدق می کند – تمرکز خود را بر این بگذارید که از عملکرد صحیح سیستم بدون نیاز به دانستن جزئیات پیاده سازی هر یک از اجزای سازنده ، اطمینان حاصل کنید.
(Don’t Re Invent The Wheel) DRITW (چرخ را دوباره اختراع نکنید) – خوب ، ما مخفف آن را ساختیم اما مهم است. هر زمان که برای انجام کار کلی کد ساخت و ساز دارید که مستقیماً با اصول برنامه شما ارتباط ندارد ، شخص دیگری احتمالاً قبلاً آن کد را نوشته و بهتر از آن نوشته است. یا در جایی در یک وبلاگ ، در Stack Overflow ارسال شده است ، یا به عنوان یک جواهر دارای منبع آزاد است. به جای اتلاف وقت خود در اختراع چرخ ، از کد آنها بیاموزید و از آنها استفاده کنید.
کدی بنویسید که یک کار را به خوبی انجام دهد – یک قطعه کد فقط باید یک کار را انجام دهد و آن را به خوبی انجام دهد. اگر می خواهید یک راه حل معجزه آسا برای همه کارها درست کنید و همه آن را به یک قطعه کد دهید ، کابوسی برای قابلیت نگهداری دارید و احتمالاً چندین عمل را نقض می کند. KISS!
اشکال زدایی دشوارتر از نوشتن کد است – کد قابل خواندن بهتر از کد جمع و جور است. بنابراین تلاش برای ترکیب این 10 خط در یک زنجیره عملیاتی از روش هایی که از الگوهای ورودی مبهم استفاده می کنند ، متوقف شود! بعداً شخص دیگری باید آن را بخواند و اشکال زدایی کند و شما به آنها لطفی نمی کنید.
Kaizen1 (آن را بهتر از زمانی که پیدا کردید بگذارید) – نه تنها اشکالی که می خواهید حل کنید بلکه کد موجود در آن را برطرف کنید. اگر مشکل اصلی ایراد در طراحی باشد (که معمولاً وجود دارد) رفع اشکال کد کمکی نمی کند.

حساب سر انگشتی

یافتن و رفع یک مشکل نرم افزاری در تولید، 100 برابر گرانتر از یافتن و رفع آن در مرحله نیاز و مرحله طراحی است. آن اشکالات و نقایص طراحی را زود بیابید!
در همین مورد، بیش از نیمی از خطاهای موجود در طراحی در مرحله طراحی مرتکب می شوند.
تقریباً تمام مدت صرف شده برای رفع مشکلات را می توان به تعداد انگشت شماری از ماژول های مشکل دار نسبت داد.
حدود نیمی از برنامه های کاربر دارای نقایص غیر اساسی است
فقط 60٪ از ویژگیهای یک سیستم در واقع در تولید استفاده می شود

برگرفته از Rules of Thumb در مهندسی نرم افزار توسط مارکوس اسپراونک

جمع بندی

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

منبع: Basic Principles of Software Engineering

ترجمه: صالح رضائی

Kaizen: فلسفه تجارت ژاپنی در مورد بهبود مستمر شیوه های کار ، کارآیی شخصی و غیره