#پست_مجدد این پست تا به حال بیش از ۱۱۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد.

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

در مقاله زیر تجربه استفاده از دو ابزار Team Foundation Server و یکپارچگی آن با سرویس‌های Azure در یک پروژه عملی شرح داده شده است. در این فرایند Feature‌ ها به عنوان زبان مشترک بین تیم فنی و بیزنس طراحی می‌شوند. سپس این Feature ها به Backlog Item ها شکسته می‌شوند. یک Backlog Item در حقیقت یک نیازمندی‌است است که آنقدری کوچک شده که بتوان آن را به تنهایی تست کرد. به طوری که اگر تست تمام Backlog Item های یک Feature پاس شود، به معنی قابل تحویل بودن آن به تیم بیزنس باشد. سپس Task ها مجموعه کارهایی (فنی و غیر فنی) است که باید انجام شود تا بتوان تست یک Backlog Item را پاس کرد.

در مقاله زیر به طور خلاصه توضیح داده شده‌است که چگونه Sprint ها انجام می‌شوند.

https://mehrandvd.me/2017/02/24/azure-experience-handling-requirements/

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/3NGm30b5IjZ

#مهران_داودی (https://ow.ly/GwIl309lFEm)

کانال تلگرام:
@SoftwarePhilosophy


___

در صورتی که از کندی Visual Studio رنج می‌برید و علاقه مند هستید سرعت کار ویژوال استدیو را بالاخص در زمان دیباگ و اجرای برنامه‌ها تا چندین برابر بهبود دهید، راهکارهای ارایه شده در این مقاله را که همگی تست شده اند و بعضا دارای PowerShell Script آماده به اجرا هستند استفاده کنید و از بهبود به دست آمده لذت ببرید.

https://docs.bit-framework.com/docs/good-to-know/visual-studio-speedup.html



⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/GrJ430eStMy

#یاسر_مرادی (https://ow.ly/Ph6w30ebM21)

✅ با سپاس از آقای سعید صالحی برای مشارکت در تهیه این مطلب
https://github.com/1saeedsalehi


کانال تلگرام:
@SoftwarePhilosophy

___

پنجمین نسخه از Swarm دوست‌داشتنی

احتمالا اپلیکیشن Foursquare همچنین Swarm را می‌شناسید. برای من Foursquare نمونه یک محصول بسیار موفق‌ست (حتی بالاتر از Instagram و Facebook)‌ که پیشرفت و پا گرفتنش را در ایران، لحظه به لحظه پیگیری کرده‌ام. هوشمندی بینظیری که در Gamification داشت و روش‌های اغواگرانه‌ای که برای وادار کردن کاربر به فعالیت استفاده می‌کرد از مهمترین دلایلی بود که من را به این محصول علاقمند می‌کرد.

بعدها که اپلیکیشن Swarm با هدف جدا کردن تکه‌ی شبکه اجتماعی Foursquare معرفی شد، فعالیت و پیگیری‌های من هم کمی کمتر شد ولی این تیم همیشه تاثیر خود را در کار حرفه‌ای من داشته‌ست. بطوریکه وقتی خواندم که اپلیکیشن جدید Foursquare بطور کامل در Sketch App طراحی شده، مهاجرت به این ابزار را برای خود یک الزام می‌دیدم.

تیم دیزاین این مجموعه، هم‌اکنون نسخه 5.0 از اپلیکیشن Swarm را منتشر کردند که دستخوش تغییراتی بسیاری شده‌است.
مقاله امروز، داستانی‌ست از زبان یکی از طراحان محصول این تیم که به بررسی روند این بازطراحی می‌پردازد و نکات جالبی در آن نهفته‌ست:
- می‌توان متوجه دید و دغدغه‌های یک تیم دیزاین در این سطح، در روند بازطراحی محصول شد.
- می‌توانید نمونه‌ای از Style Guideهایی را که در تیم‌های دیزاین دیگر ساخته می‌شود، ببینید.
- متوجه می‌شوید که یکی از وظایف شما به عنوان دیزاینر، به اشتراک‌گذاری ایده‌ها و طرح‌ها و گرفتن بازخوردهاست. در هر سطحی که باشید.
و …

پیشنهاد می‌کنم همین حالا این داستان زیبا را مطالعه کنید.

https://medium.com/foursquare-direct/how-we-designed-foursquare-swarm-5-0-d774b3164f3f

(زمان حدودی مطالعه، ۱۰ دقیقه)

#تیم #بازطراحی #محصول #Swarm
@Dexign دیزاین

___

🎩 هیچ کس حاضر به استفاده از MVP ناقص شما نیست!

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

مشتریان با محصول ساده مشکلی ندارند، ولی ناقصی که کار نمی کند را نخواهد پذیرفت. ایجاد MVP به معنی ایجاد یکسری قابلیت ناقص نیست...

ادامه مقاله را در لینک زیر مشاهده کنید:

🌐 https://goo.gl/Q6bHMW

@iranagile

#پست_مجدد این پست تا به حال بیش از ۱۲۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد.

مفهوم Concurrent Programming و تفاوت آن با Parallel Programming همیشه یکی از مباحث چالش برانگیز برای برنامه نویسان بوده است. مفهوم اجرای همزمان یا Concurrent حتی قابل اجرا روی یک نخ یا یک cpu است. در حالی که اجرای موازی یا Parallel نیاز به چند نخ دارد. مقاله زیر به زیبایی و بسیار خلاصه این دو مدل برنامه‌نویسی را توضیح داده‌است. همچنین نحوه استفاده از امکانات .net core را برای پیاده‌سازی این مفاهیم را به همراه مثال‌هایی خوانا شرح داده‌است.

مفاهیم TPL, PLINQ, Async, Immutable Collection و مفاهیم دیگر در این مقاله با ذکر مثال‌هایی جالب شرح داده شده‌اند.

https://www.dotnetcurry.com/dotnet/1360/concurrent-programming-dotnet-core

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/xoWQ30bbJFn

#مهران_داودی (https://ow.ly/GwIl309lFEm)

کانال تلگرام:
@SoftwarePhilosophy


___

#خلاصه_مطالب «فلسفه نرم‌افزار» در هفته گذشته:

۱. شرح استفاده از دو ابزار Team Foundation Server و یکپارچگی آن با سرویس‌های Azure در یک پروژه عملی

https://t.iss.one/SoftwarePhilosophy/928

۲. راهکارهایی برای افزایش سرعت Visual Studio

https://t.iss.one/SoftwarePhilosophy/929

۳. نسخه پنجم Swarm (دیزاین)

https://t.iss.one/SoftwarePhilosophy/930

۴. هیچ کس حاضر به استفاده از MVP ناقص شما نیست (Iran Agile)

https://t.iss.one/SoftwarePhilosophy/931

۵. توضیحاتی در رابطه با مفاهیم مفاهیم TPL, PLINQ, Async, Immutable Collection

https://t.iss.one/SoftwarePhilosophy/933

ـــــــــــ

@SoftwarePhilosophy

#پست_مجدد این پست تا به حال بیش از ۱۴۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد.

حذف حجم زیادی از سطرها از دیتابیس با اجرای دستور DELETE می‌تواند بسیار پر هزینه و زمان‌بر باشد. برای بهبود عملکرد و سرعت عملیات حذف باید Foreign Key ها، Index ها را هم بررسی کرد. ولی پس از بررسی و بهبود توسط این عوامل، راه بعدی استفاده از Delete Chunks است. شکستن DELETE های بزرگ به تکه‌های کوچک‌تر می‌تواند کمک زیادی به بهبود سرعت کند.

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


https://sqlperformance.com/2013/03/io-subsystem/chunk-deletes

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/CcQz30bhNiQ


#مهران_داودی (https://ow.ly/GwIl309lFEm)

کانال تلگرام:
@SoftwarePhilosophy


___

بسیاری از برنامه نویسان و طراحان نرم افزار خاطره خوشی از معماری سرویس‌گرا ندارند. این مسأله دلایل بسیاری دارد که از جمله آنها می توان به پیچیدگی‌های فراوان ESB (Enterprise Service Bus) ها اشاره کرد. معماری سرویس‌گرا تلاشی بود برای جلوگیری از مشکلاتی که معماری یکپارچه (Monolithic) به تیم و محصول تحمیل می‌کرد. هرچند معماری سرویس‌گرا اقبال خوبی از سمت سازمان‌ها و شرکت‌های بزرگ کسب کرد ولی عمر زیادی نداشت و امروز از توجه کمتری برخوردار است. از طرفی محصولات یکپارچه بزرگ سازمانی و مشکلاتشان همچنان وجود دارند.
میکرو سرویس مفهمومی است که سعی میکند با استفاده از تجربه معماری سرویس‌گرا نقص‌های آن را برطرف کرده و به کمک طراحان بیاید.
در معماری میکروسرویس سیستم به اجزاء کوچکتری تقسیم می‌شود که هرکدام به طور مستقل عمل می‌کنند و یک عمل خاص را به خوبی انجام می‌دهند. این میکروسرویس‌ها درکنار همدیگر همان کار یک نرم افزار یکپارچه را انجام خواهند داد، آن‌ها توانایی این را دارند که زندگی را برای طراحان ساده‌تر و زیباتر کنند!

لینک زیر مقدمه مناسبی برای آشنایی دنیای میکروسرویس‌ها است.

https://www.nginx.com/blog/introduction-to-microservices/

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/4aX530f2OZz

#مهدی_بلوچی (https://ow.ly/5kxI30exl7k )

کانال تلگرام:
@SoftwarePhilosophy


___

۱۰ موقعیتی که طراحان تجربه کاربری از آن متنفر هستند!

اخیرا در توییتر هشتگی راه افتاده بود با عنوان ShitDevelopersSay که خیلی از برنامه‌نویسان و حتی مدیران فنی ایرانی در توییتر با این هستگ توییت کردند.
تمام توییت‌ها درباره جملاتی بود که معمولا توسعه‌دهندگان یا برنامه‌نویسان استفاده می‌کنند. مانند: «کدهاش رو نوشتم، فقط تست‌اش مونده.» یا «برنامه‌نویسی قبلی‌تون کد نزده، گند زده!»

این جملات تکراری، خنده‌دار و البته تامل‌برانگیز، ‌در تمامی مشاغل وجود دارد. به همین بهانه، امروز مقاله‌ای را از John Saito، کسی که به قول خودش «کلمــات» را برای شرکت و سرویس معظم Dropbox دیزاین می‌کند، بررسی می‌کنیم. این مقاله از زاویه‌ای دیگر، به بررسی موقعیت‌ها و جملاتی می‌پردازد که طراحان تجربه کاربری، بخصوص Copy Writerها از آن متنفرند.

پیشنهاد می‌کنم همین حالا این نوشته کوتاه و لذت‌بخش را مطالعه کنید:

https://medium.com/@jsaito/10-things-ux-writers-hate-to-hear-a3d561a63ae8

(زمان حدودی مطالعه، ۶ دقیقه)

#جملات #طراحی_محصول #Copy_Writer
@Dexign دیزاین

___

#پست_مجدد این پست تا به حال بیش از ۱۱۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد.

رعایت Coding Style در هنگام برنامه‌نویسی، تاثیر زیادی در کیفیت کد تولید شده می‌گذارد. اغلب برای زبان‌هایی مانند C#, Java و یا JavaScript قوانین زیادی برای استایل وجود دارد. این قوانین کمتر در مورد زبان‌هایی مانند SQL رایج است در حالی که رعایت آنها در چنین زبان‌هایی بسیار مهم است. مقاله جالب زیر یک سری از اصول Coding Style در زبان SQL را شرح داده‌است. خلاصه نکات این مقاله عبارتند از:
• Formatting SQL Code
• Functional Misuse
• Variables and Parameters
• Wonderful world of collations

https://www.simple-talk.com/sql/t-sql-programming/basics-good-t-sql-coding-style/

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/XSIA30c5GS3


#مهران_داودی (https://ow.ly/GwIl309lFEm)

کانال تلگرام:
@SoftwarePhilosophy


___

از پروژه بعدی این اشتباه رو تکرار نمی کنم، ولی چرا باز تکرار می شود؟

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

🔴 پروژه‌های نرم‌افزاری خطی نیستند

بسیاری از اوقات ما در پروژه‌ها، نیازمندی‌ها را اشتباه تشخیص می‌دهیم و بالطبع فیچرهای اشتباهی را برای مشتری عرضه می‌کنیم، یا در انتخاب تکنولوژی اشتباه می‌کنیم و هزینه تولید و توسعه بالا می‌رود، یا بعداً می‌فهمیم معماری یا طراحی, مناسب این پروژه نبوده است.

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

علت اینکه تجربیات دقیق ما در آینده به درد نمی‌خورند این است که:

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

🔴 راه چاره چیست؟

اگر قرار باشد تجربیات گذشته در آینده به درد نخورد پس چاره چیست؟ چه‌کار باید کرد؟

مدل فکر کردن را باید یاد گرفت نه اینکه یک ایده را عیناً پیاده‌سازی کرد

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

اینکه من قبلاً این کار رو کردم، خوب نبود و این سری باید این کار رو بکنیم چون حتماً جواب می‌گیریم، دلیل خوبی نیست.

بیرون از جعبه باید فکر کرد

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

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

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

🔴 در عدم قطعیت، بهترین انتخاب در کار نیست

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

بهبود مستمر کلید موفقیت

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

اما یادگیری‌های ما برای همان پروژه است و نه پروژه بعدی. پروژه بعدی یادگیری خودش را نیاز خواهد داشت.

اسپرینت ها به سبک ایرانی

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

نتیجه‌گیری

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

یکی از مسایل مهم در دنیای نرم افزار، مساله تغییرات همزمان داده و جلوگیری از آن است. در SQL Server با داشتن یک Transaction از نوع Isolated می‌توان از تغییر همزمان یک آیتم جلوگیری کرد. حال اگر فرآیندهای کاری در .NET پیاده سازی شوند و نرم افزار توزیع شده (دارای چند سرور) باشد، چگونه در کد می‌توان از تغییر همزمان جلوگیری نمود؟ کتابخانه DistrubtedLock در .NET به این امر می‌پردازد و اجازه می دهد تا با استفاده از مکانیزم‌های مختلف در .NET ، یک Lock بین چند سرور نرم افزار ایجاد نمود و از همزمانی جلوگیری نمود.

https://github.com/madelson/DistributedLock/tree/master/DistributedLock

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/jSR630f9rrn

#علیرضا_وفی (https://ow.ly/Vna930dsUGr)

کانال تلگرام:
@SoftwarePhilosophy


___

#خلاصه_مطالب «فلسفه نرم‌افزار» در هفته گذشته:

۱. نوشتن کوئری‌های DELETE بهینه برای حجم دیتای زیاد
#sql #optimization
https://t.iss.one/SoftwarePhilosophy/936

۲. آشنایی با معماری میکروسرویس
#microservice #architecture
https://t.iss.one/SoftwarePhilosophy/937

۳. ده موقعیتی که طراحان تجربه کاربری از آن متنفر هستند! (دیزاین)
#design
https://t.iss.one/SoftwarePhilosophy/938

۴. اصول Coding Style در زبان SQL
#sql #cleancode
https://t.iss.one/SoftwarePhilosophy/940

۵. چرا یادگیری از اشتباهات گذشته مانع اشتباهات در پروژه‌های بعدی نمی‌شوند؟ (Iran Agile)
#agile
https://t.iss.one/SoftwarePhilosophy/941

۶. آشنایی با کتابخانه DistrubtedLock در .NET و مسئله تغییرات همزمان داده
#dotnet #library #concurrency
https://t.iss.one/SoftwarePhilosophy/942

ـــــــــــ

@SoftwarePhilosophy

#پست_مجدد این پست تا به حال بیش از ۱۱۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد.

مقایسه کد دو اسمبلی ساخته کاری است که در هنگام بررسی نسخه‌های مختلف یک dll بسیار پیش می‌آید. با ابزارهایی مانند Reflector یا dotPeek می‌توان محتوای یک اسمبلی را مشاهده کرد ولی مقایسه دو نسخه مختلف یک اسمبلی با این ابزارها بسیار سخت است. ابزار JustAssembly یک ابزار رایگان و اوپن‌سورس است که اخیرا توسط تیم Telerik توسعه داده شده و به خوبی به برنامه نویسان این امکان را می‌دهد که نسخه‌های مختلف یک اسمبلی را با یکدیگر مقایسه کنند.

https://developer.telerik.com/topics/net/introducing-justassembly-lightweight-net-assembly-diff-tool/

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/Mezs30c7VfS


#مهران_داودی (https://ow.ly/GwIl309lFEm)

کانال تلگرام:
@SoftwarePhilosophy


___

#پست_مجدد این پست تا به حال بیش از ۴۶۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد.

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


https://mehrandvd.me/2015/10/26/spaces-shape-your-software-architecture/

#مهران_داودی
لینکداین:
https://ir.linkedin.com/in/mehrandvd


کانال تلگرام:
@SoftwarePhilosophy


___