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

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

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


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

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


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


___

برای APIها و نرم افزارهایی که کاربران زیادی دارند Load Test امری حیاتی بشمار می‌آید. ابزارهای open source زیادی برای اینکار وجود دارند که Gatling یکی از آن ابزارها ست . Gatling ابزاری قدرتمند در زمینه Load test است که از پروتکل HTTP پشتیبانی می کند. با Gatling تنها با استفاده از تعداد اندکی دستگاه می‌توانید صدها هزار درخواست در ثانیه را روی Web application خود شبیه سازی کنید و گزارش و تحلیل‌هایی با پارامترهای دقیق بدست بیاورید. از نکات جذاب Gatling امکان تعریف سناریو تست کارایی به همان صورتی که در سایر فریمورک‌های تست اتوماتیک فراهم شده، می‌باشد. بدین ترتیب می توان این تست را هم در فرایند تست خودکار گنجاند.
توضیحات بیشتر در لینک های زیر:

https://dzone.com/articles/api-load-testing-with-gatling

https://gatling.io/performancetesting /

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

https://ow.ly/obSH30firlJ

#شراره_لطفی (https://ow.ly/xvC530dx8xL)

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


___

🐘 استوری پوینت همان ساعت نیست

در پروژه های نرم افزاری روش های تخمین زدن متفاوتی وجود دارد؛ ساده‌ترین روش این است از نفری که میخواهد کار را انجام بدهد بپرسید “این چند ساعت طول می کشد؟” و او بر اساس تجربه قبلی یک ساعتی را اعلام می کند.  اما اکثر تیم های چابک از واحدی به نام استوری پوینت استفاده می کنند. تیم های جدید یا نفرات جدیدی که برای اولین بار سراغ این روش تخمین زدن می‌آیند دقیقا سعی می‌کنند ساعت را به پوینت ربط دهند یعنی هر پوینت معادل هشت ساعت.

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

وقتی به یک کاری می گوییم سه پوینت، سه پوینت به تنهایی هیچ معنی ندارد، سه پوینت نسبت به چه چیز؟ در نسبیت شما همیشه باید یک پایه داشته باشید. مثلا اگر فرض کنیم یک صفحه Add/Edit ساده 8 پوینت است. پس سری بعد  قرار باشد  یک صفحه Add/Edit  داشته باشیم که کمی نیز قوانین کسب‌کار در آن دخیل است، احتمالا پوینت 13 است.

🔴 چرا ساعت همان پوینت نیست؟

شاید یک صفحه Add/Edit برای من هشت ساعت طول بکشد، پس باید پوینت بشود 1 اما برای همکارم که کمی کند تر است، این کار دو روز طول می کشد پس این پوینت باید بشود 2. حالا فرض کنید این دونفر چگونه می خواهند در مورد اینکار با هم از روش پوینت استفاده کنند؟ اما اگر کل تیم، فرای اینکه چه کسی می خواهد این کار را انجام بدهد در نظر بگیرند که هر  Add/Edit مثلا 8 پوینت است، پس همه تعریف مشترکی از پوینت خواهند داشت.

اما در غیر اینصورت بهتر است از لفظ پوینت استفاده نکنید.

🔴 آیا ما مجبور هستیم از پوینت استفاده کنیم؟

اصولا نه. اصلا نیازی به استفاده از این روش نیست. اکثر تیم ها در ایران به اسم از پوینت استفاده می کنند ولی همان سیستم ساعتی است.

بهترین حالت چه چیز است؟

بهترین حالت این است که شما User Story ها را از روش پوینت استفاده کنید، بدلیل اینکه همه تیم بر روی این کار تعامل داشته باشند. اما وقتی این User Story به چندین تسک شکست، آنها باید ساعتی تخمین زده شوند. چرا؟ چون قرار است تسک را یک نفر خاص انجام بدهد و آن نفر بر اساس مهارت ها و تجربیات قبلی آن کار را تخمین می زند.

@iranagile

🌐 https://goo.gl/7fQaxs

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

۱. ابزار اوپن سورس JustAssembly برای مقایسه نسخه‌های مختلف یک اسمبلی

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

۲. مفهوم فضا و تاثیر آن بر مشتری

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

۳. قدرت‌های Sketch و After Effects به کمک هم می‌آیند (دیزاین)

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

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

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

۵. آشنایی با Gatling ابزاری قدرتمند برای Load test

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

۶. استوری پوینت همان ساعت نیست (Iran Agile)

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

ـــــــــــ

@SoftwarePhilosophy

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

امنیت یکی از دغدغه‌های مهم نرم‌افزارهای large scale است. این دغدغه نه تنها به خود نرم‌افزار بر می‌گردد، بلکه بیشتر به تیم‌هایی برمی‌گردد که در حال توسعه این سیستم‌ها هستند. اینکه تیم برنامه‌نویسی بتواند یک ویژگی امنیتی مانند لاگین را بنویسد بسیار تفاوت دارد با اینکه بتواند یک کد را امن بنویسد. «توانایی کد نویسی امن» یک مهارت است که مخصوصا برنامه‌نویسان سیستم‌های large scale مانند سیستم‌های بانکی یا ERP باید از آن برخوردار باشند.
یکی از مهمترین تعارضات تیم‌های برنامه‌نویس با دپارتمان‌های امنیت، این طرز تفکر است که امنیت «یک تست نهایی» است که باید در انتها انجام شود. این رویکرد اشتباه غالبا باعث می‌شود ریسک‌های امنیتی زیادی متوجه سازمان شود. در تیم‌های حرفه‌ای امنیت یک کار روزانه است که همه هر روز در حال انجام آن هستند.
اخیرا دپارتمان امنیت «بهسازان» در بانک ملت پروژه جالبی را به نام «مسابقه CTF» یا Capture The Flag را اجرا کرده‌است. طی این رویداد با برگزاری یک سری مسابقات جذاب برنامه‌نویسی امنیتی، به طور ناخودآگاه دانش امنیتی تمام افراد سازمان، مخصوصا برنامه نویسان بالا رفته‌است. نکته جالبه پلتفرم بهسازان این بود که آن را طوری طراحی کرده‌اند که می‌توانند در اختیار سایر سازمان‌ها نیز قرار دهند تا متناسب با بیزنس خود آن را پیکربندی کنند و موجب آموزش این مهارت‌ها به سازمان خود شوند.

https://mehrandvd.me/2017/05/23/capture-flag-secure-software/

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

https://ow.ly/p03w30cbHdO

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

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


___

طراحی دکمه‌ها در گذر زمان

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

در مقاله امروز، آقای Wojciech Dobry نتیجه بررسی را که روی تغییرات طراحی ۸ ساله دکمه‌ها داشته‌اند، ارائه می‌دهند.
این تحقیق روی پلتفرم Dribbble اتفاق افتاده است.

پیشنهاد میکنم این سیرِ زمانی جالب را همین حالا روی این مقاله بررسی کنید:

https://www.toptal.com/designers/ui/button-design-dribbble-timeline

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

#دکمه #تاریخچه #روند
@Dexign دیزاین

___

یکی از معماری‌های نوین نرم افزاری که این روزها طرفداران زیادی را به خود جلب نموده است، معماری Microservices می‌باشد. این معماری با پیاده سازی سرویس‌های متعدد و غیروابسته، پیاده‌سازی تغییرات در نرم افزار را ساده‌تر می نمایند. در این معماری Microservice ها به دو شکل متداول با هم ارتباط دارند، یکی از طریق REST و دیگری از طریق Messaging. پیاده سازی بصورت Messaging از بهم تنیدگی کدها می‌کاهد و وابستگی بین سرویس‌ها را به حداقل می‌رساند. برای این نوع پیاده سازی در .NET می توان از کتابخانه MassTransit استفاده نمود. MassTransit یک Service Bus می‌باشد که از تکنولوژی‌های RabbitMQ و Azure ServiceBus در پشت صحنه بهره می‌برد و کمک می‌کند تا بتوان راحت‌تر معماری Microservice را بطور صحیح پیاده سازی نمود.


https://masstransit-project.com/

https://github.com/MassTransit/MassTransit



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

https://ow.ly/p03w30cbHdO

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

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


___

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

استفاده از LINQ در PowerShell در موقعیت‌هایی که به Performance بالا نیاز است می‌تواند بسیار کارا باشد. در ابتدا به نظر عجیب می‌رسد که چطور می‌توان از LINQ در PowerShell استفاده کرد و یا اصولا چرا باید این کار را کرد. در مقاله جذاب زیر به هر دو این سوال‌ها پاسخ داده شده‌‌است. در این مقاله ابتدا به طور خلاصه مفاهیم LINQ شرح داده‌شده‌اند. سپس کاربرد هر کدام از متدهای LINQ با ذکر مثال در اسکریپت‌های PowerShell آموزش داده شده‌است.

https://www.simple-talk.com/dotnet/net-framework/high-performance-powershell-linq/

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

https://ow.ly/bgOq30cm0iu


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

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


___

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

مقایسه تکنولوژی‌های React Native و Xamarin Forms برای پروژه‌های Cross Platform یکی از بحث‌های داغ این روز‌های برنامه‌نویسان موبایل است. مقاله زیر این دو فریم‌ورک را از ابعاد مختلف مقایسه کرده و نظر خود را در هر مورد شرح داده. نکته جالب این مقاله این است که قبل از توضیح کامل، در یک پاراگراف که آن را Short Version یا نسخه کوتاه نام‌گذاری کرده خیلی خلاصه نتیجه را توضیح داده‌است.
به نظر این برنامه‌نویس، اگر برنامه نویس JavaScript هستید React Native را انتخاب خواهید کرد، اگر برنامه‌نویس C# باشید Xamarin Forms را انتخاب خواهید کرد. اگر به هر دو مسلط باشید (که معمولا کم پیش می‌آید) برای پروژه‌های واقعی و بیزنسی Xamarin Forms را انتخاب می‌کنید و React Native را برای پروژه‌های شخصی انتخاب خواهید کرد.

https://shellmonger.com/2017/05/25/which-is-better-react-native-or-xamarin-forms/


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

https://ow.ly/9ZTM30cuKFN


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

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


___

🔴 روش استوری مپینگ در عمل

همیشه وقتی در مورد اسکرام صحبت می‌کنیم، اولین فرض ما این است که تیم یک بک‌لاگ محصول دارد. ولی در مورد اینکه این بک‌لاگ از کجا آمده است و چگونه تولید میشود زیاد صحبت نشده است. یکی از بهترین روشهای ایجاد بک‌لاگ اولیه محصول Story Mapping است.

بک‌لاگ یک بعدی یا چند بعدی؟

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

بک‌لاگ فلت چندین ایراد اساسی دارد:

1. حس یک لیست بی پایان از کارها که هیچ وقت تمام نمی شود (لیست بابانوئل)
2. نداشتن یک تصویر کلی از کل پروژه یا محصول
3. از دست دادن دید Iterative – Incremental
4. اولویت بندی بک‌لاگ فلت در عمل خیلی سخت است

https://goo.gl/iUryqU

@iranagile

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

۱. امنیت در سیستم‌های large scale با راهکار تیم امنیت بهسازان بانک ملت
#security #ctf
https://t.iss.one/SoftwarePhilosophy/955

۲. طراحی دکمه‌ها در گذر زمان (دیزاین)
#design #ux
https://t.iss.one/SoftwarePhilosophy/956

۳. آشنایی با Service Bus، MassTransit در معماری Microservices
#architecture #microservice
https://t.iss.one/SoftwarePhilosophy/957

۴. استفاده از LINQ در PowerShell
#powershell #linq
https://t.iss.one/SoftwarePhilosophy/959

۵. مقایسه تکنولوژی‌های React Native و Xamarin Forms برای پروژه‌های Cross Platform
#crossplatform #ReactNative #Xamarin
https://t.iss.one/SoftwarePhilosophy/961

۶. روش استوری مپینگ در عمل (Iran Agile)
#agile
https://t.iss.one/SoftwarePhilosophy/962

ـــــــــــ

@SoftwarePhilosophy

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

https://eventstore.org/docs/introduction/4.0.0/

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

https://ow.ly/7rNP30fxL3o

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

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


___

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

مدیریت خطا یا Exception Handling صحیح یکی از نکات مهم در کدهای با کیفیت است. در یک کد با کیفیت باید به خطاها فکر کرد و برای آنها در هنگام توسعه تصمیم گرفت. اینکه کجا یک exception را catch کنید و کجا به آن اجازه دهید به لایه‌های بالاتر رود، اینکه چگونه exception‌ ها را در هم wrap کنید و موارد بسیار دیگر مستقیما روی کیفیت کد شما تاثیر می‌گذارد.
مقاله زیر در مورد نحوه انجام این کار در Large .NET Projects را شرح داده‌است و مطالعه آن می‌تواند کمک زیادی به بالا رفتن کد برنامه نویسان کند.

https://www.dotnetcurry.com/patterns-practices/1364/error-handling-dotnet-projects

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

https://ow.ly/SWJZ30cAalk


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

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


___

اگر دوستانی دارید که نه تنها برنامه نویس هستند، بلکه اعتقاد دارید «مهندس نرم‌افزار» هم هستند، آنها را به کانال @SoftwarePhilosophy دعوت کنید.
این پیغام را برای آنها Forward کنید.

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

مفهوم box model در css یکی مهمترین مفاهیمی است که برنامه‌نویسان را قادر می‌سازد چینش‌های مختلف مورد نیاز را پیاده‌سازی کنند. همیشه تنظیم مقدار position با absolute یا relative یا مقادیر دیگر، و یا تنظیم مقدار display با inline یا block برای رسیدن به چینش مورد نظر دردسر دارد، در صورتیکه ندانید آنها چطور کار می‌کنند. چون نمی‌دانیم این دو متغییر ساده چطور کار می‌کنند معمولا شروع به تنظیم شانسی این مقادیر می‌کنیم تا به چینش مناسب برسیم، اگر برسیم!!
مطلب زیر، مستندی بسیار دقیق در مورد نحوه کار box model در css است و مطالعه آن به تمام کسانی که با css کار می‌کنند پیشنهاد می‌شود. این مستند در واقع استانداردی است که توسط کنسرسیوم وب تنظیم شده و تمام مرورگر‌ها موظفند طوری کار کنند که مطابق با این استاندارد باشد.

https://www.w3.org/TR/CSS2/visuren.html

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

https://ow.ly/VgEs30cHTKm

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

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


___

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