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

محصولی مانند 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 فلسفه دیزاین

____

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

۱. ضد الگوی «کد مرده» یا Dead Code چیست؟

https://t.me/SoftwarePhilosophy/1140

۲. قدم‌های مناسب برای رسیدن به تخمین موفق در پروژه

https://t.me/SoftwarePhilosophy/1142

۳. آشنایی با کانبان و نحوه کار بورد کانبان در پروژه‌های نرم‌افزاری

https://t.me/SoftwarePhilosophy/1144

۴. استفاده از JSON در SQL Server 2016 (SQL Server)

https://t.me/SoftwarePhilosophy/1145

۵. آشنایی با برنامه نویسی Blockchain و معرفی کتاب

https://t.me/SoftwarePhilosophy/1146

۶. راهنمای جیبی برای «خلق کردن» (فلسفه دیزاین)

https://t.me/SoftwarePhilosophy/1147

ـــــــــــ

@SoftwarePhilosophy

🔻 عنوان: مالک محصول بزرگ در مقابل مالک محصول کوچک

🔸 امروزه تقریبا در تمامی شرکت ­های نرم افزاری ایران و جهان از رویکردی چابک برای مدیریت محصولات و یا پروژه ­های نرم­ افزاری استفاده می ­شود. در تمامی این سازمان ­ها، افرادی با عنوان مالک محصول اسکرام و یا مدیر محصول چابک در حال توسعه محصولات نرم ­افزاری و دیجیتال هستند.

🆔 @agileproduct

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

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

👇👇👇👇
https://goo.gl/rXss2J

🆔 @agileproduct

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

قورباغه را دوباره اختراع نکنید!

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


http://mehrandvd.me/2016/03/09/reinventing-the-frog/

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


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


___

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

الگوی Async Retry Pattern یکی از الگوهایی است که در برنامه‌نویسی برنامه‌های نسل جدید بسیار مهم است. بسیاری دستگاه‌ها و بسترهای جدید شبکه مطمئنی ندارند. برای مثال اینترنت روی گوشی ممکن است بسته به موقعیت قطع و وصل شود و یا کیفیت پایینی داشته باشد. در این بسترها عملیات باید در صورت ناموفق بودن چند بار تکرار شوند و یا اصلاحا retry شود. ابزارهایی که برای retry طراحی شده‌اند این امکان را می‌دهند تا بتوان یک کار را با چند بار retry کردن انجام داد. برای مثال:
var maxRetryAttempts = 3;
var pauseBetweenFailures = TimeSpan.FromSeconds(2);

RetryHelper.RetryOnException(
maxRetryAttempts,
pauseBetweenFailures,
() => {
httpClient.Delete("https://example.com/api/products/1");
}
);

کد بالا برای شرایط کدهای همگام مناسب است ولی اگر بخواهید این کد را به صورت async اجرا کنید و از httpClient.DeleteAsync() استفاده کنید کد مناسبی نیست.

مقاله زیر ضمن تشریح این الگو، توضیح داده‌است که چطور می‌توان با استفاده از async/await الگوی retry pattern را پیاده‌سازی کرد.

https://alastaircrabtree.com/implementing-the-retry-pattern-for-async-tasks-in-c/

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

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

___

معرفی کتاب‌های بی‌ربط به دیزاین

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

آقای Daniel Burka، یکی از همکاران Google Ventures، در توییتی از دیزاینرها خواسته بود که بهترین کتاب دیزاینی که مربوط به دیزاین نیست را معرفی کنند. ایشان جواب‌های دریافتی‌شان را در قالب مقاله‌ای با ما به اشتراک گذاشته‌اند.

کتاب‌های این مجموعه را از دست ندهید.

https://medium.com/@dburka/the-best-design-books-that-arent-explicitly-about-design-74fc96ce115e

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

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

__