معماری‌های نوین نرم‌افزار برای حل مسائلی به وجود آمده‌اند که قبلا وجود نداشتند. برای مثال شبکه‌های اجتماعی که در آن میلیون‌ها لایک و کامنت در ثانیه را هندل می‌کنند و همیشه با بیلیون‌ها رکورد سر و کار دارند مسائلی است که جدید هستند و با معماری و ابزارهای قبل قابل حل نیستند. دیتابیس‌های NoSql و PolyGlot ابزارهای جدیدی هستند که در معماری‌های جدید از آنها استفاده می‌شود. مقاله زیر از Dino Esposito معمار با سابقه نرم‌افزار، توضیح می‌دهد که چگونه با استفاده از Historical CRUD و Event Sourcing می‌توان راه‌حلی برای این گونه مسائل ارائه داد.

https://msdn.microsoft.com/en-us/magazine/mt703431

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

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


___

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

یکی از مهمترین بخش یک برنامه موبایل UI‌ آن است. یک برنامه موبایل هرچند دارای تحلیل و طراحی قوی و برنامه‌نویسی خوبی باشد بدون یک UI‌ خوب نمیتواند کاربر را جذب کند. ایجاد یک UI‌ قوی فقط با آگاهی از ویژگی‌هایی که سیستم عامل گوشی پشتیبانی میکند حاصل نمی‌شود. یک طراح خوب باید نقاط قوت و ضعف هر یک از تکنیک‌های استفاده شده در UI را بداند و در جای درست از آنها استفاده کند. مثلا دو روش برای Zoom کردن وجود دارد:
۱) Double-tap
۲) Pinch and Spread (با استفاده از دو انگشت و با دور یا نزدیک کردن دو انگشت به یکدیگر)
که هر کدام مزایا و معایب خود را دارند.

در پست زیر تکنیک‌های مختلف UI در برنامه‌های اندرویدی را بررسی کرده است.

https://unitid.nl/androidpatterns/

#افشین_علیزاده
لینکدین:
https://ir.linkedin.com/in/afshinalizadehbehjati

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



___

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

https://www.c-sharpcorner.com/article/is-json-overridden-xml/

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

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



___

یکی دیگر از موارد مهم در طراحی UI‌ برنامه‌های موبایل توجه به Landscape و یا Portrait بودن است. که هر کدام از این حالت‌ها ویژگی‌های خاص خود را دارند که طراح میتواند به خوبی از این ویژگی‌ها استفاده کند.
مثلا برنامه‌ای را در نظر بگیرد که برای بورس نوشته شده است. در حالت Portrait یک گرید نمایش داده میشود که شاخص بورس در هفته جاری را نشان میدهد. یک UI معمولی همین گرید را در حالت Landscape نمایش میدهد ولی یک UI خوب یک نمودار میله‌ای را نمایش میدهد.

در پست زیر Patternهای مختلفی را که برنامه‌های مختلف در نمایش Landscape استفاده کرده‌اند را بررسی کرده است.

https://www.smashingmagazine.com/2012/08/designing-device-orientation-portrait-landscape/

#افشین_علیزاده
لینکدین:
https://ir.linkedin.com/in/afshinalizadehbehjati

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



___

مفهوم Coupling:

یکی از اتفاقات بد که کم و بیش در هر پروژه ای به مرور پیش می آید، Coupling می باشد. جلوگیری از وقوع Coupling انرژی زیادی را از تیم توسعه خواهد گرفت و کار دشواری است. تیم ها و نفرات تازه کار از Coupling رنج می برند بدون آنکه از آن اطلاعی داشته باشند.
مفهوم Coupling به این معنا است که کلاس های مختلف، متد های مختلف، ماژول های مختلف تا چه میزان در هم تنیده و به هم وابسته اند. تنیدگی کد ها موجب می شود، تا هر تغییری در هر قسمتی، باعث بروز رفتارهای ناصحیح، از کار افتادگی و عدم کامپایل بخش هایی از برنامه شود که فکرش را هم نمی کنید.
وجود Coupling در نرم افزار ها موجب می شود تا هنگام تغییری در متد مربوط به کاربران، قسمتی از کد مربوط به انبارداری کامپایل نشود و یا قسمتی در سیستم سفارشات دچار خطای Run Time شود. 
به تعبیری وجود Coupling موجب می شود هر تغییری در سیستم موجب اثری به نام Ripple Effect و یا تغییرات موجی در نرم افزار شما شود. در نتیجه تغییر در سیستم های Coupled پر هزینه بوده و با عواقب غیرقابل پیشبینی رو به رو خواهد شد. همچنین گسترش این سیستم ها با دشواری مواجه خواهد بود.

* اگر کد شما دارای Coupling و وابستگی کمی باشد، به کد شما
Loosely Coupled گفته می شود، که نشان دهنده هنر مهندسی شما است.
* اگر کد شما دارای Coupling و وابستگی بالایی باشد، به کد شما Tightly Coupled گفته می شود.

یکی از مباحثی که همیشه در تشکیل تیم‌های نرم‌افزاری مطرح است، انتخاب زبان برنامه‌نویسی و یا تکنولوژی‌های مورد استفاده است. مقایسه محصولات موفق و نا موفق نشان می‌دهد هیچکدام از آنها صرفا با یک تکنولوژی و یا یک زبان خاص نوشته نشده‌اند. برای مثال سیستم‌های موفق زیادی وجود دارند که با Java و یا C# نوشته شده‌اند. همچنین سیستم‌های بی کیفیت زیادی نیز وجود دارد که با Java و یا C# نوشته شده‌اند. این حقیقت نشان می‌دهد دلیل موفقیت یا شکست سیستم‌ها نمی‌تواند زبان برنامه‌نویسی باشد. مقاله زیر توضیح می‌دهد که چطور طرز فکر برنامه‌نویس‌ها موفقیت و یا شکست یک سیستم را رقم می‌زند.

https://mehrandvd.me/2015/10/15/software-quality-comes-from-people-not-languages/

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


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

___

اگر در دنیای کامپیوتر و نرم‌افزار زندگی می‌کنید، حتما لینک‌ها و صفحه‌های زیادی در طول روز می‌بینید که دوست دارید بخوانید ولی فرصت مطالعه آن‌ها را ندارید. در پست زیر Scott Hanselman توضیح داده است که چگونه «بعدا بخوانید!» یا «Read it Later!». در این پست ابزارهایی معرفی شده‌است که بتوانید با آنها مطالب نخوانده خود را بهتر مدیریت کنید و بتوانید آن‌ها را به زمانی موکول کنید که فرصت دارید.

https://www.hanselman.com/blog/TwoMustHaveToolsForAMoreReadableWeb.aspx

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

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



___

مفهوم Polymorphism:

این مفهوم یکی از سه ویژگی اساسی برنامه نوسی شی گرا می باشد. کسی که برنامه نویسی شی گرا می داند با این مفاهیم اجین شده است و لاغیر!
1. فرض کنیم، کلاسی پایه به نام Shape داریم. این کلاس، متدی به نام Draw دارد که وظیفه کشیدن شکل بر روی صفحه را به عهده دارد.
2. کلاس های دلخواهی را از کلاس Shape به ارث می بریم. مثلا کلاس Circle (دایره)، کلاس Rectangle (مستطیل) و کلاس Square (مربع). طبیعتا هر کدام از این ها باید به نحو خاصی بر روی صفحه کشیده شوند و با هم متفاوتند. پس هر کدام از این ها، متد Draw را که از کلاس Shape به ارث برده اند، override می کنند و در این متد، کد مربوط به نحوه کشیدن شان را قرار می دهیم.
3. فرض کنیم کلاسی به نام Monitor داریم. این کلاس وظیفه دارد تا اشکال مختلف را بگیرد و بر روی صفحه نمایش دهد. 
آیا باید به ازای هر شکلی که داریم متد های جداگانه ای در کلاس Monitor تعریف کنیم؟ مثل متد های DrawCircle، DrawRectangle و DrawSquare؟ اگر تعداد اشکال به مرور زیاد شد باید هر بار کلاس Monitor هم تغییر بدهیم و کدهای مربوط به شکل جدید را اضافه کنیم؟ در این صورت اشکال و کلاس Monitor دچار Coupling شده اند!!!

4. راه حل: می توانیم در کلاس مانیتور فقط یک متد تعریف کنیم. نام این متد را Draw می گذاریم. ورودی این متد از جنس کلاس پایه Shape می باشد. در Draw فقط متد Shape.Draw را صدا خواهیم زد و اینجاست که Polymorphism وارد عمل می شود.

- شما یک مستطیل و یا دایره را به متد Monitor.Draw پاس می دهید. چون هر دو از جنس Shape هستن، مشکلی ایجاد نخواهد شد.
- هنگامی که در متد Monitor.Draw، متد Shape.Draw را صدا می زنیم، Polymorphism موجب می شود تا به طور خودکار CLR -مسئول اجرای کد- بداند که شی Shape در واقع از نوع دایره یا مستطیل می باشد و هوشمندانه متد مربوط و خاص به همان کلاس را اجرا می کند و نه کد مربوط به کلاس Shape را!

مفهوم Polymorphism موجب می شود که در هنگام اجرای کد (Run Time)، رفتار های متفاوتی از متد مربوط به کلاس Shape سربزند. این متد گاهی مربع می کشد و گاهی دایره. استفاده از این روش، یکی از راه های کاهش Coupling می باشد.

https://msdn.microsoft.com/en-us/library/ms173152.aspx

در مورد WebApi مطالب زیادی وجود دارد. ولی پست زیر با جزئیات خیلی زیادی کل چرخه پیغام‌های HTTP را در WebApi Pipeline به طور کاملا عملی بررسی کرده‌است. خواندن این مقاله می‌تواند خیلی به درک مفهوم Pipeline در این معماری‌ها کمک کند. نکته خوب این مقاله این است که در آن OWIN که یک معماری بسیار عالی برای استفاده و پیاده سازی WebApi است توضیح داده شده‌است. معماری OWIN کمک می‌کند بتوانید WebApi را مستقل از جایی که قرار است در آن Host شود طراحی کنید و برای مثال بتوانید آن را حتی در یک برنامه Console Application استفاده کنید.

https://www.c-sharpcorner.com/article/webapi-pipeline-revealed-a-true-practical-approach/

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

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



___

مهندسی معکوس و یا Decompile کردن کدهای دات نت:
در پلتفرم دات نت، فارغ از زبانی (سی شارپ، F# و ویژوال بیسیک و ....) که برای برنامه نویسی استفاده می کنیم، کد های ما پس از کامپایل شدن تبدیل به یک زبان میانی به نام IL و یا Intermediate Language می شوند. به علت اینکه تمامی کد ها در نهایت به یک "زبان واحدِ میانی" تبدیل می شوند، می توانیم در هر زبانی که هستیم که از کتابخانه هایی که توسط زبان های دیگر توسعه پیدا کرده اند استفاده کنیم.
در هنگام اجرا، زبان IL به زبان ماشین کامپایل می شود و همین جا یکی از دلایل کندی نرم افزار های توسعه داده شده با دات نت در قیاس با زبان های C و یا C++ می باشد. چرا که باید زمانی را صرف کامپایل کد ها به زبان ماشین نماییم.
زبان IL، اگر چه شبیه به زبان Assembly است ولی به پیچیدگی و گنگی آن نیست. در کد های IL اطلاعات بسیار زیادی در مورد کد اصلی ما نگهداشته می شود. به همین خاطر روند مهندسی معکوس کد ها از زبان IL به زبان اصلی بسیار ساده صورت خواهد پذیرفت. یعنی می توانیم با داشتن یک dll یا فایل exe کد های اصلی را بدست بیاوریم. ابزارهای بسیار متنوعی برای این منظور وجود دارند.

برگرداندن کد ها به جز استفاده های غیر قانونی، برای یادگیری و فهمیدن رفتار کتابخانه های دیگران بسیار مفید می باشند. 
ابزار های:
1. https://ilspy.net
2. https://www.jetbrains.com/decompiler

ویژگی float در CSS یکی از ویژگی‌هایی است که نکات ریز خیلی زیادی دارد. به همین دلیل استفاده از آن معمولا در ابتدا خیلی ساده به نظر می‌رسد، ولی بعد از اینکه مدل صفحه پیچیده‌تر شد و تعداد زیادی از دستورات شروع به تاثیرگذاری روی یکدیگر کردند دیگر مدیریت آن آسان نیست. پست زیر که به زبان فارسی هم هست توضیحات خیلی خوبی در مورد توصیف عملکرد این ویژگی داده‌است که برای تمام کسانی که با CSS کار می‌کنند مفید است.

https://css-tricks.ir/css_reference/float/

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

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



___

به نظر می‌رسد که تکنولوژی آنقدرها هم که به نظر می‌رسد به موفقیت پروژه‌ها کمک نمی‌کند! برای مثال در کتاب «Peopleware: Productive Projects and Teams» عامل مهمتری را برای موفقیت یک پروژه معرفی کرده‌است: «اعتماد افراد به یکدیگر». در تیمی که افراد به یکدیگر اعتماد نداشته باشند ریسک خیلی بالایی متوجه پروژه می‌شود و آینده آن به شدت در خطر خواهد بود.

Better technology seemed unlikely to be much help. If a group of people who had to work together didn’t trust each other.

از کتاب
Peopleware: Productive Projects and Teams
نوشته:
Tom DeMarco & Timothy Lister


#افشین_علیزاده
لینکدین:
https://ir.linkedin.com/in/afshinalizadehbehjati

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



___

مایکروسافت قریب به یک سال است که یک CSS Framework به نام Office UI Fabric را به صورت متن باز توسعه داده است. با استفاده از این فریم ورک می توانید وب اپلیکشن هایی با شکل و شمایل Office و یا ویندوز 10 طراحی کنید.
https://dev.office.com/fabric

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


https://mehrandvd.me/2015/07/16/goalkeepers-vs-leaders-2/

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


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


___

موقعیت‌های زیر را در نظر بگیرید:
۱) راننده‌ای که اگر به موقع به فرودگاه نرسد، پرواز را از دست می‌دهد.
۲) عابر پیاده‌ای که عجله دارد.
۳) خانم خانه‌داری که مهمان‌ها یک ساعت زودتر آمده‌اند و گرسنه هستند.
احتمالا هر یک از ما حالت مشابهی را تجربه کردیم که در آن یک محدودیت زمانی وجود دارد و ناخواسته قوانینی را که رعایت می‌کردیم، دیگر رعایت نمی‌کنیم.
۱) به احتمال زیاد دیگر به تابلو ورود ممنوع و یا حق تقدیم توجهی نمی‌کند .
۲) به چراغ قرمز توجه نمی‌کند و از پل عابر پیاده نیز استفاده نمی‌کند .
۳) از کیفیت غذا کاسته شده است.
برنامه‌نویس نیز از این قاعده مستثنی نیست. اگر تحت فشار زمان‌بندی پروژه باشد سریع‌تر کار میکند ولی به خاطر اینکه سر وقت بتواند پروژه را تحویل دهد قوانینی را نادیده می‌گیرد و در نتیجه از کیفیت کد کاسته می‌شود.

People under time pressure don’t work better—they just work
faster.

از کتاب:
Peopleware: Productive Projects and Teams (Tom DeMarco & Timothy Lister)

#افشین_علیزاده
لینکدین:
https://ir.linkedin.com/in/afshinalizadehbehjati

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



___

وجود یک «لکه» یا Blob در کد برنامه شما یک نمونه ضد الگوی برنامه نویسی (Anti Pattern) محسوب می‌شود. یکی از علائمی که نشان می‌دهد برنامه شما لکه دارد، زمانی است که از این جمله استفاده می‌کنید: «این قسمت از کد، قلب سیستم است»
وقتی از این جمله استفاده می‌کنید، یعنی قسمتی از کد شما وجود دارد که در آن حجم زیادی از منطق برنامه شما نوشته شده‌است و شکسته نشده‌است. لکه‌ها تمایل به بزرگ شدن دارند،‌ یعنی خیلی وقت‌ها برای نوشتن یک کد جدید، احساس‌ می‌کنید باید آن را به «قلب سیستم» اضافه کنید. خیلی وقت‌ها علت این مشکل معماری بد و یا حتی «نبود معماری» است.

لینک زیر بیشتر در مورد این Anti Pattern توضیح داده است.

https://sourcemaking.com/antipatterns/the-blob

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


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


___

جملات زیر غالبا به مقدار زیاد شنیده می‌شوند:
• من صبح زود و قبل از اینکه کسی دیگری در شرکت باشد خیلی بهتر کار می‌کنم.
• در یک روز تعطیل می‌توانم به اندازه ۲ یا ۳ روز کاری،‌ کار انجام بدهم.
جملاتی از قبیل جملات بالا نشانه این هستند که محیط کاری مناسبی وجود ندارد. و مدیران با اتخاذ تصمیمات مناسب می‌توانند آرامش را به محیط کار برگردانند. ولی متاسفانه هیچ کس کاری انجام نمی‌دهد.

Staying late or arriving early or staying home to work in peace is a damning indictment of the office environment.
The amazing thing is not that it’s so often impossible to work in the workplace; the amazing thing is that everyone
knows it and nobody ever does anything about it.

از کتاب:
Peopleware: Productive Projects and Teams (Tom DeMarco & Timothy Lister)

#افشین_علیزاده
لینکدین:
https://ir.linkedin.com/in/afshinalizadehbehjati

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



___

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

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


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

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


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


___

با ما در ارتباط باشید!

تا امروز فیدبک‌های خیلی خوبی از شما دوستان گرفتیم. بر اساس فیدبک‌های شما تصمیم گرفتیم که پست‌های این کانال را در سه دسته بندی پست کنیم:
۱) مطالب مهندسی و معماری نرم‌افزار و مدیریت تیم‌های نرم‌افزاری
۲) مطالب مربوط به آخرین تکنولوژی‌ها
۳) مطالب مربوط به تکنولوژی‌های مرسوم که در شرکت‌ها استفاده می‌شود.

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

لطفا اگر نظر، پیشنهاد، انتقاد و یا هرگونه فیدبکی نسبت به این کانال دارید، در توئیتر بنویسید. مطمئن باشید ما آنها را می‌خوانیم. (در توئیتر https://twitter.com/mehrandvd را منشن کنید و از هشتگ #SoftwarePhilosophy استفاده کنید)