تکنیک‌های جذاب برای پیش از بارگذاری تصاویر

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

قبل از شروع صحبت، اجازه بدهید دو مفهوم زیر را برایتان تعریف کنم.
Placeholderها: همان عناصری هستند که تا زمان بارگذاری تصاویر، جای آن‌ها را برایشان نگه‌داشته و کاربرها را سرگرم می‌کنند.
و SVG: پسوند مربوط به تصاویر برداری (Vector) که به دلیل حجم کم و چند ویژگی دیگر، در وب جایگاه بسیار محبوبی پیدا کرده است.
قبل‌ترها از عکس‌های ثابت، رنگ‌ها و اینطور چیز‌ها به عنوان Placeholder استفاده می‌شد، ولی امروزه سرویس‌های مختلف حرکتی را آغاز کردند تا هرچقدر که می‌توانند Placeholder یک تصویر را به خود تصویر نزدیک کنند.
تلاش Google Image Search در این جهت، مرتبط بودن رنگ هر Placeholder به عکسی که بعدا در آن بارگذاری می‌شود، و تلاش Instagram، نمایش یک نسخه تار شده از عکس‌ها قبل از بارگذاری آن‌ها است.

امروز پیشنهاد جذاب و هوشمندانه یکی از برنامه‌نویسان Frontend شرکت Spotify را بررسی می‌کنیم. ایشان می‌گویند: مگر نه اینکه SVGها بسیار کم حجم هستند؟ پس چرا یک نسخه ساده شده بُرداری از تصاویر را قبل از بارگذاری‌شان نمایش ندهیم؟
هیجان‌انگیز است، نه؟
به نظر من که ایده بسیار جذابی‌ست. پیشنهاد می‌کنم جزئیات ایده ایشان را از زبان خودشان بخوانید:

https://medium.freecodecamp.org/using-svg-as-placeholders-more-image-loading-techniques-bed1b810ab2c

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

#معرفی #ایده #طراحی_رابط‌کاربری
@Dexign فلسفه دیزاین

___

🔴 7 روش برای مقابله با جلسات برنامه ریزی خسته کننده


1- با شکم خالی جلسه برگزار نکنید

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

2- قبل از جلسه برنامه ریزی، جلسه باید آماده شده باشد

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

3- انرژی محدود است پس اولویت بندی لازم است

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

4- تایم باکس باشیم

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

5- ما در طول اسپرینت هم در حال برنامه ریزی هستیم

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

6- Swarm کنید

شاید در طول اسپرینت نیاز به یک کار فکری باشد و این هم نیاز به خرد جمعی باشد، بهترین کار این است که یک جلسه با حضور همه یا بخشی از نفرات تیم برگزار شود، این جلسه نیز باید 1- تایم باکس باشد 2- فقط حول و حوش یک موضوع خاص باشد 3- زمانبدی شروع خوبی داشته باشد

7- جلسه نیاز به تسهیل گر دارد

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

https://goo.gl/Fz9Kb1

@iranagile

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

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

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

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

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

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

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

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

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

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

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

ـــــــــــ

@SoftwarePhilosophy

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

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

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

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


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

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


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


___

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

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


https://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 ها انجام می‌شوند.

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

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

https://ow.ly/3NGm30b5IjZ

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

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


___

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

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

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

https://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.iss.one/SoftwarePhilosophy/1129

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

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

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

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

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

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

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

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

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

https://t.iss.one/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 یکی از کارهایی است که انجام درست آن دقت پیش‌بینی زمان انجام پروژه را بالا می‌برد. ولی تخمین‌های درست و نزدیک به واقعیت کار ساده‌ای نیست و برای رسیدن به آن باید نظم خاصی داشت. اینکه چه افرادی در جلسه شرکت می‌کنند، چه سوالاتی می‌پرسند، چه توضیحاتی داده می‌شود، فرایند تخمین زدن و پوینت دادن چطور است، اینها همه از عوامل تاثیر گذار در یک تخمین خوب هستند.
پست زیر قدم‌هایی را برای رسیدن به یک تخمین موفق، معرفی و آنها را شرح داده‌است.

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

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

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

___

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

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

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

https://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