معماری های صحیح برنامه نویسی

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

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

یکی از ساده ترین مصداق های این موضوع انتخاب بین Entity Framework، ADO.NET و Dapper می باشد. همه ما می دانیم که قطعا Entity Framework از دیگر روش ها کارایی پایین تری خواهد داشت، حتی با به کار بستن ترفند های خاصِ خودش. پس انتخاب Entity Framework چه مزیتی خواهد داشت؟

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

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

https://www.exceptionnotfound.net/dapper-vs-entity-framework-vs-ado-net-performance-benchmarking/

این نوشته بر گرفته از کانال تلگرامی است

http://zangin.ir

http://tablokar.ir

لاگ ها - یکپارچه سازی

لاگ ها - یکپارچه سازی

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

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

1. قابلیت جستجوهای پیشرفته، گزارش سازی و کوئری زدن بر روی آن ها وجود ندارد.
2. در برنامه های پر ترافیک ثبت لاگ بر روی فایل ترافیک I/O زیادی را به سیستم تحمیل می کند.
3. اگر سامانه متشکل از چند سیستم جدا از هم باشد، لاگ های پراکنده ای خواهیم داشت که هر کدام در یک محل جدا و غیریکپارچه قرار گرفته اند.
4. برای خواندن لاگ ها نیاز به دسترسی به مستقیم به سرور خواهید داشت.

برای حل مشکل یکپارچگی لاگ ها، خیلی از سیستم های پرترافیک از پلتفرمی به نام ELK استفاده می کنند. اما برای سیستم های کوچک تر و یا تیم هایی که در عین کیفیت از پیچیدگی فراری هستند، می توان از ابزار فوق العاده و البته رایگان SEQ استفاده کرد. این ابزار به شما امکان می دهد تا لاگ ها را از همه سیستم های تان یکجا جمع کنید، بدون نیاز به دسترسی مستقیم به سرور و با مرورگرتان لاگ ها را در یک پنل زیبا و کاربردی مشاهده کنید و با زبانی شبیه به SQL در میان لاگ ها جستجو کرده و گزارش و نمودار بسازید و از داشبورد به نسبت خوب و کاربردی بهره مند شوید. البته برای اینکه بتوانید در لاگ ها جستجوهای پیشرفته داشته باشید، باید لاگ های تان ساختارمند باشند. در قسمت بعدی راجع به لاگ های ساختارمند صحبت خواهیم کرد.

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

* ابزار SEQ توسط توسعه دهنده کتابخانه پرقدرت Autofac و Serilog توسعه داده شده است.

* دانلود ابزار SEQ
https://getseq.net/Download

*توضیحاتی در مورد SEQ
https://blog.getseq.net/hello-seq-4-0-dashboards-alerts-more-improvements/

https://blog.getseq.net/seq-4-2-rtm/

* پلتفرم ELK - پرقدرت ولی به نسبت پیچیده از حیث راه اندازی و نگهداری
https://www.elastic.co/webinars/introduction-elk-stack

@irandotnet

این نوشته بر گرفته از کانال تلگرامی است

http://zangin.ir

http://tablokar.ir

یادگیری مفاهیم پایه یا تکنولوژی های جدید

یادگیری مفاهیم پایه یا تکنولوژی های جدید

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

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

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

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

* اسکات هنسلمن https://www.hanselman.com/blog/YouGotThisYouKnowTheFundamentalsYouAreALearnerPlusTheImpostersHandbook.aspx

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

* مَتیو جونز : همه کدها دورریختی اند

https://exceptionnotfound.net/all-code-is-disposable-just-like-it-should-be/

* مَتیو جونز : من از 9 تا 5 کار می کنم | شما هم می توانید

https://exceptionnotfound.net/i-am-a-9-to-5-developer-and-so-can-you/

* مطلبی در مورد سندروم Imposter و اینکه تحقیقات نشان می دهد برنامه نویسانی که مدام کار می کنند، دچار مشکلات روحی متعددتر و بازدهی پایین تری هستند. عاشق برنامه نویسی بودن به معنی هفته 100 ساعت کار کردن نیست.

http://www.businessinsider.com/syndromes-drive-coders-crazy-2014-3

@irandotnet

این نوشته بر گرفته از کانال تلگرامی است

http://zangin.ir

http://tablokar.ir

درون کمپانی های نرم افزاری چه می گذرد؟

درون کمپانی های نرم افزاری چه می گذرد؟

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

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

در زیر فهرست بلاگ های کمپانی های مهم است که من از آن ها مطلع هستم. اگر شما از بلاگ های کمپانی های دیگر، مخصوصا ایرانی مثل کافه بازار، آپارات، ویرگول، طرفداری و .... مطلع هستید، من رو در جریان بگذارید تا این فهرست به روزرسانی شود.

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

* بلاگ تست گوگل
https://testing.googleblog.com/

* بلاگ فنی نت فلیکس | شامل مطالب خوبی پیرامون مایکروسرویس ها، استریمینگ و ماشین لرنینگ
https://medium.com/netflix-techblog

* بلاگ فنی یوتیوب
https://youtube-eng.googleblog.com/2016/05/

* بلاگ فنی گیت هاب
https://github.com/blog

* بلاگ فنی Stackoverflow | دارای مطالبی خواندنی حتی برای خواننده متوسط
https://stackoverflow.blog/engineering/

* تجربیات مایکروسافت در حرکت به سمت توسعه های سریع تر، با کیفیت تر و مقاوم تر
https://www.visualstudio.com/learn/monolith-cloud-service/

* بلاگ فنی مایکروسافت DevOps
https://blogs.msdn.microsoft.com/devops/

* بلاگ فنی فیس بوک
https://research.fb.com/blog/

(این فهرست به روز خواهد شد)

@irandotnet

این نوشته بر گرفته از کانال تلگرامی است

http://zangin.ir

http://tablokar.ir

نکته ای در رابطه با استفاده بهینه از HttpClient

نکته ای در رابطه با استفاده بهینه از HttpClient

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

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

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

کلاس HttpClient از اساس Thread-safe طراحی شده است. یعنی می توان با داشتن یک نمونه از آن، همزمان در thread های مختلف - درخواست های مختلف کاربران در یک وب اپلیکیشن - از همان یک نمونه استفاده کرد و کار هیچ Thread ایی بر دیگری اثر نخواهد گذاشت.

* تجربه تلخ از عدم استفاده صحیح از HttpClient
https://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/

* توصیه رسمی مایکروسافت بر ساخت یک نمونه از HttpClient و استفاده از آن در باقی نقاط برنامه:
https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclient?view=netframework-4.7

* توضیحی دقیق در مورد thread-safety کلاس HttpClient
http://www.michaeltaylorp3.net/httpclient-is-it-really-thread-safe/

@irandotnet

این نوشته بر گرفته از کانال تلگرامی است

http://zangin.ir

http://tablokar.ir