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

۱. استاندارد طراحی URL از لحاظ UX

https://t.me/SoftwarePhilosophy/1120

۲. امنیت در سیستم‌های large scale با راهکار تیم امنیت بهسازان بانک ملت

https://t.me/SoftwarePhilosophy/1122

۳. مقایسه عملکرد فریم‌ورک‌های مشهور Mapper از لحظا سرعت و عملکرد

https://t.me/SoftwarePhilosophy/1124

۴. تکنیک‌های جذاب برای پیش از بارگذاری تصاویر (فلسفه دیزاین)

https://t.me/SoftwarePhilosophy/1125

۵. هفت روش برای مقابله با جلسات برنامه ریزی خسته کننده (Iran Agile)

https://t.me/SoftwarePhilosophy/1126

ـــــــــــ

@SoftwarePhilosophy

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

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

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

لینک زیر توضیح می‌دهد که چگونه یک معماری بد باعث «رشد افزونگی کد» در نرم‌افزار می‌شود.


http://mehrandvd.me/2016/02/28/growing-redundancy-an-architectural-disease/

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


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


___

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

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


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

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


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


___

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

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

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

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

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

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

http://ow.ly/3NGm30b5IjZ

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

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


___

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

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

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

http://mehrandvd.me/2016/10/02/touch-point-real-percepction-product/

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

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

___

فُــرم‌ها را بهتر دیزاین کنیم

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

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

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

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

https://uxplanet.org/3-best-form-design-practices-for-your-design-process-383510b31613

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

#بررسی #نمونه_موفق #طراحی_فرم
@Dexign فلسفه دیزاین

___

⭕ با باگ‌ها چه کنیم؟

“هشتاد و پنج تا باگ از واحد تست گزارش شده، لیستش را ایمیل کردم برای همه. باگ‌های هرکس به تفکیک مشخص شده. تا شنبه ظهر باید همه باگ‌ها رفع شده باشد!”

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

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

آیا این وضعیت برای شما هم آشنا است؟

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

ببینیم در خصوص چنین رویدادی چه رویکردهایی قابل اتخاذ است:

همینه که هست!

بسیاری از افراد اعم از مدیر یا برنامه نویس، هستند که این شرایط را طبیعی می‌دانند : “باگ جزیی از نرم افزار است و از آن راه گریزی نیست”. “از ما بزرگترها، مایکروسافت و گوگل هم نرم‌افزارهای‌شان باگ دارد. ما که جای خود داریم!” . “گروه تست، کارش همین است که باگ‌های کار ما را پیدا کند”.

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

فرصتی برای بهبود

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

خوشبختانه قبل از ما خیلی‌ها دنبال پاسخ این پرسش‌ها رفته‌اند و راهکارهایی نیز ارائه کرده‌اند:

✅ استفاده از روال‌های تست اتوماتیک و استقرار CI و CD  – Continuous Delivery : این کار مستلزم ایجاد Unit Test های مناسب است که به صورت روزانه یا به ازای هر Commit کد اجرا شده و اشکالات و خطاها را به توسعه دهنده اطلاع دهند. شما را نمی‌دانم اما برای من پیش آمده که وقتی کدی را تغییر داده ام در جای دیگری از برنامه که در مخیله‌ام نمی‌گنجید منجر به خطا شده. وجود Unit Test بسیار به این موضوع کمک میکند. اگر هم که با رویکرد TDDانجام شود که چه بهتر. چون تست هایی که نوشتن آنها به بعد موکول می‌شود، ممکن است مشمول فراموشی، سهل انگاری یا کمبود وقت شوند و هرگز نوشته نشوند.

✅توجه بیشتر به تست و همکاری تسترها در زمان توسعه نرم افزار

✅بررسی باگ‌ها و شناسایی دلایل رخداد آن. مثلا پاسخ به سوالاتی از این دست: اکثریت باگ ها مربوط به کدام بخش از برنامه است و آیا نمی‌شود با تقویت Unit Testها ، تغییر معماری یا راهکارهای دیگر، باگ‌های مربوط به آن را کاهش داد؟

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

✅ رفاکتورینگ: کدهای تمیز، خوانا ، متدهای کم حجم و به دور از کدهای Duplicate منطقا احتمال باگ کمتری دارند.

✅ پرهیز از اضافه کاری: خود اضافه کاری و کد زدن در شرایط خستگی، فشار و استرس نیز در بروز کدهای بی‌کیفیت‌تر و باگ‌های بیشتر بی‌تاثیر نیست.

https://goo.gl/tCXLN6

@iranagile

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

۱. چگونه یک معماری بد باعث «رشد افزونگی کد» در نرم‌افزار می‌شود

https://t.me/SoftwarePhilosophy/1129

۲. مفهوم فضا و تاثیر آن در معماری نرم‌افزار

https://t.me/SoftwarePhilosophy/1131

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

https://t.me/SoftwarePhilosophy/1133

۴. مفهوم Touch Point و نقش آن در تعریف محصولات نرم‌افزاری

https://t.me/SoftwarePhilosophy/1135

۵. فُــرم‌ها را بهتر دیزاین کنیم (فلسفه دیزاین)

https://t.me/SoftwarePhilosophy/1136

۶. با باگ‌ها چه کنیم؟ (Iran Agile)

https://t.me/SoftwarePhilosophy/1137

ـــــــــــ

@SoftwarePhilosophy


ـــــــــ

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

ضد الگوی «کد مرده» یا Dead Code، یک Anti Pattern رایج در شرکت‌هایی است که مدت نسبتا زیادی سیستم تولید می‌کنند. اگر شما این جمله‌ها را می‌شنوید احتمالا شما هم دچار این ضد الگو شده‌اید:
- این کد رو دو نفر قبلا نوشند که سه سال پیش رفتند و پارسال یه نفر دیگه تلاش کرد یاد بگیره و مستند بنویسه براش و اون هم رفته. البته فک نکنم الان اصلا از این کد استفاده بشه، ولی محض احتیاط بهتره پاک نشه!
این نوع کدها غالبا پیچیدگی سیستم را به شدت بالا می‌برند و تغییرات آتی سیستم را بسیار سخت می‌کنند.
بسیاری از این کدها به این علت به وجود می‌آیند که در زمان تولید کدهای در حد R&D وارد کد عملیاتی شده و به مدیریت آن در آینده فکر نشده.


https://sourcemaking.com/antipatterns/lava-flow

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


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


___

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

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

http://www.agilebuddha.com/agile/agile-estimation-8-steps-to-successful-story-point-estimation/

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

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

___

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

یکی از تکنیک‌هایی که در مدیریت پروژه‌های نرم‌افزاری برای مدیریت کارها استفاده می‌شود استفاده از مفهوم «کانبان» است. این روش که شرکت تویوتا از آن در سیستم تولید just-in-time خود استفاده می‌کند برای پروژه‌های نرم‌افزاری نیز سازگار شده‌است.
یکی از اهداف کانبان، شناسایی گلوگاه‌های کاری است تا بتوان به فرایندی بهینه‌تر برای تولید نرم‌افزار رسید.

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

http://kanbanblog.com/explained/

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

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

___

سلام وعرض ادب خدمت دوستان عزیز
شب بر شما خوش باشه انشالله
یکی از قابلیتهای اضافه شده در SQL Server 2016 استفاده از JSON هست.
در این مقاله که لینکش رو قرار میدهم به شما نشان میدهد که چطور و به سادگی میتوانید با استفاده از این قابلیت توسعه Rest API رو خیلی راحتتر انجام بدین.

امیدوارم از این مقاله لذت ببرید

ارادتمند شما
حمیدرضا صادقیان
https://blogs.msdn.microsoft.com/sqlserverstorageengine/2018/01/29/simplify-rest-api-development-modern-single-page-apps-sql-server/?utm_source=dlvr.it&utm_medium=linkedin

ID: @Hamidreza_Sadeghian
SQL Server Channel : @SQL_Server
SQL Server Group : https://telegram.me/joinchat/BTQQtzy50j80lW2DM90Wtw

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

کتاب زیر با عنوان Blockchain Programming in C# که در GitBook قرار دارد به طور کامل این مفهوم را شرح داده و استفاده از آن را در زبان C# پیاده‌سازی کرده است.

https://programmingblockchain.gitbooks.io/programmingblockchain/content/introduction/why_blockchain_programming_and_not_bitcoin_program.html

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

http://ow.ly/XWSp30i6XTE

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

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


___

راهنمای جیبی برای «خلق کردن»

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

مقاله امروز بطور کامل به بررسی خلاق بودن می‌پردازد و نتیجه‌ای است از مطالعه نوشته‌های Mihaly Csikszentmihalyi (روانشناس) و Betty Edwards (مدرس هنر) در قالب روشی به نام ISIIVE. هر حرف از این نام معرف یکی از مراحل این روند است و مثل بسیاری روش‌های دیگر، با پرسیدن «سوال دُرست» شروع می‌شود.

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

https://uxplanet.org/pocket-creativity-d1868400ff1b

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

#معرفی #تکنیک #خلاقیت
@Dexign فلسفه دیزاین

____