وجود یک «لکه» یا 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



___

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

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


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

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


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


___

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

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

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

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

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

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

Managers jeopardize product quality by setting unreachable deadlines.

Workers kept under extreme time pressure will begin to sacrifice quality. They will push problems under the rug to be dealt with later or foisted off onto the product’s end user. They will deliver products that are unstable and not really complete. They will hate what they’re doing, but what other choice
do they have?

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


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

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



___

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

https://www.sitepoint.com/smooth-scrolling-vanilla-javanoscript/

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

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



___

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

https://www.sitepoint.com/implement-javas-equals-method-correctly/

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

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



___

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


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

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


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


___

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

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

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


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

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


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


___

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

http://uxmag.com/articles/design-like-a-human-in-the-age-of-algorithms

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

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



___

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

http://www.codeproject.com/Articles/462767/How-to-Think-Like-a-Functional-Programmer

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

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



___

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

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

http://jsnlog.com

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

https://uxmag.com/articles/the-best-enterprise-ux-is-the-one-you-never-see

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

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



___

چطور برنامه‌نویسی موازی را برای مادربزرگتان توضیح دهید!؟

برنامه نویسی موازی (Parallel Programming) و برنامه نویسی ناهمگام (Asynchronous Programming) مفاهیم نسبتا جدیدی در دنیای برنامه‌نویسی هستند که برای اغلب برنامه‌نویسان جدید است. همه در مورد آن شنیده‌انم ولی اغلب واضح نیست که دقیقا چیست و چرا سخت است. یک مفهوم پایه برای درک این مفاهیم پایه Thread یا نخ است. نخ‌ها مفاهیمی هستند که وظیفه انجام کارها روی CPU را دارند. در دنیای ما انسان‌ها کسانی هستند که کار انجام می‌دهند. مقاله زیر مفهوم «نخ» را به «انسان» شبیه دیده‌است و سعی کرده‌است مفاهیم پیچیده دنیای برنامه‌نویسی را با مفاهیم ساده‌ دنیای ما انسان‌ها توضیح دهد.

http://mehrandvd.me/2016/04/18/parallel-programming-grandmother/


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

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



___

مفهوم Dependency Injection یکی از مواردی است که در طراحی ASP.NET Core وجود دارد. مقاله زیر علاوه بر اینکه مروری بر این مفهوم مهم دارد، نحوه پیاده‌سازی و استفاده از آن را در ASP.Net Core توضیح می‌دهد. همچنین در این مقاله به منظور آموزش این مفهوم، یک مثال به صورت قدم به قدم پیاده‌سازی شده‌است.

http://www.c-sharpcorner.com/article/dependency-injection-in-Asp-Net-core/

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

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



___

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

http://mehrandvd.me/2016/03/28/linq-the-bad-parts/

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

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



___

مفهوم delegate در زبان C# چه مشکلی را حل می‌کند؟ این مفهوم مشابه همان مفهوم Function Pointer یا اشاره‌گر به تابع در زبان‌هایی مانند C++ است. در حقیقت delegate ها می‌توانند یک تابع را در دل خود نگه‌ دارند و به صورت امن به آن اشاره کنند. شما اجازه دارید آنها را با هر تابعی که با امضای تعریف شده‌ در آنها تطابق دارد مقدار دهی کنید.
لینک زیر این مفهوم را با مثال توضیح می‌دهد.

http://www.c-sharpcorner.com/blogs/what-problem-does-delegates-solve-in-c-sharp

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

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



___

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

https://goo.gl/RY3veo

محمد مهدی نظری

لینکدین
https://ir.linkedin.com/in/mohammad-mahdi-nazari-90097b58

توییتر
https://twitter.com/ShamehdiN
کانال تلگرام:
@SoftwarePhilosophy


___

در این مقاله شما متوجه می شوید که چگونه SQL Server In-Memory OLTP بدن استفاده از Lock و Latch تراکنشها را در یک زمان و بر روی یک سطر از داده انجام می دهد. http://fard-solutions.com/sql-server-memory-multi-version-concurrency-control/