جنگولرن

جنگولرن

سری مهندسی نرم افزار: پست 4 از لینکدین Saeed Shahrivari Joghan لینک تو پست‌های قبلی راجع به محورهای سه گانه این سری صحبت کردم یعنی: نرم‌افزار، مهندسی نرم‌افزار و مهندس نرم‌افزار. تو این پست می‌خوام راجع به مفهوم «نرم‌افزار خوب» صحبت کنم. اول دو تا نکته…

سری مهندسی نرم‌افزار: پست 5
از لینکدین Saeed Shahrivari Joghan
لینک

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

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

حالا چه کنیم که نرم‌افزاری داشته باشیم که توسعه، تغییر و نگهداریش راحت باشه؟ از دید من کافیه که حین فرآیند تحلیل، طراحی و توسعه نرم‌افزار دو تا اصل رو رعایت کنیم:
۱- سادگی: همه چیز باید تا حد ممکن ساده نگه داشته باشه یا همون قاعده KISS
۲- رعایت اصل تفکیک دغدغه‌ها (Separation of Concerns): یعنی نرم‌افزار رو طوری به بخش‌های متمایز تفکیک کنیم که هر بخش به دغدغه متمایز بپردازه. حرف راجع به این موضوع مفصله.
اصل اول که بر همه عیانه اما معمولاً من در بین دوستان خیلی اصل تفکیک دغدغه‌ها رو نمی‌شنوم. خب این اصل رو برای اولین بار آقای دایکسترای بزرگ که یه دانشمند هلندیه در سال ۱۹۷۴ مطرح کرده و چون مثل آدمهایی مثل عمو باب معروف اهل شومن بودن نیست شاید خیلی شناخته‌شده نباشه. فعلاً تا اینجای کار داشته باشیم و برای اینکه پست طولانی نشه ایشالا در پست‌های بعد بیشتر به این دو اصل می‌پردازم.

پانوشت: بد نیست به کارهایی که آقای دایکسترا کرده یه نگاهی بندازید.

https://lnkd.in/didwSMYU

👍1

www.tgoop.com/djangolearn_ir/623

2.19K viewsJan 22, 2024 at 06:27

سری مهندسی نرم‌افزار: پست 5
از لینکدین Saeed Shahrivari Joghan
لینک

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

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

حالا چه کنیم که نرم‌افزاری داشته باشیم که توسعه، تغییر و نگهداریش راحت باشه؟ از دید من کافیه که حین فرآیند تحلیل، طراحی و توسعه نرم‌افزار دو تا اصل رو رعایت کنیم:
۱- سادگی: همه چیز باید تا حد ممکن ساده نگه داشته باشه یا همون قاعده KISS
۲- رعایت اصل تفکیک دغدغه‌ها (Separation of Concerns): یعنی نرم‌افزار رو طوری به بخش‌های متمایز تفکیک کنیم که هر بخش به دغدغه متمایز بپردازه. حرف راجع به این موضوع مفصله.
اصل اول که بر همه عیانه اما معمولاً من در بین دوستان خیلی اصل تفکیک دغدغه‌ها رو نمی‌شنوم. خب این اصل رو برای اولین بار آقای دایکسترای بزرگ که یه دانشمند هلندیه در سال ۱۹۷۴ مطرح کرده و چون مثل آدمهایی مثل عمو باب معروف اهل شومن بودن نیست شاید خیلی شناخته‌شده نباشه. فعلاً تا اینجای کار داشته باشیم و برای اینکه پست طولانی نشه ایشالا در پست‌های بعد بیشتر به این دو اصل می‌پردازم.

پانوشت: بد نیست به کارهایی که آقای دایکسترا کرده یه نگاهی بندازید.

https://lnkd.in/didwSMYU

BY جنگولرن