نوشته های سعید قاسمی

استاتیک تایپ و داینامیک تایپ در زبان های برنامه نویسی و بیشتر

سعید قاسمی — Sat, 21 Mar 2020 04:39:06 +0430

تو این مقاله میخوایم راجب چک کردن تایپ در زبان های برنامه نویسی صحبت کنیم. مثال هایی از زبان های برنامه نویسی میزنیم تایپ ضعیف و قوی رو بررسی مکینم و از مزایا و معایب ها میگیم.زمانی که راجب این موضوع جست و جو کردم به خصوص در استک اور فلو جواب ها کمی نامفهوم ، گیچ کننده و گاهی تناقض داشت و این شد که به جست و جو ادامه دادم و این شد که این مقاله رو نوشتم.قبل از این که وارد بحث بشیم نیاز که یک سری پیش نیاز ها و اصطلاح هارو بدونیم.تفاوت زبان های برنامه نویسی مفسری و کامپایلری هر دوی این گروه ها در واقع یک زبان برنامه نویسی سطح بالا را به یک زبان قابل فهم برای ماشین تبدیل می کنند با این تفاوت که در زبان های کامپایلری ابتدا یک بار کدها به صورت کامل ترجمه می شه و بعد برنامه برای اجرا از روی فایل کامپایل شده اجرا میشه. اما در زبان های مفسری کد ها به صورت خط به خط تفسیر و اجرا میشه.و اما مفاهیمی که باید بدونیم:سورس کد Source Code : کد اصلی ما که معمولا توسط انسان برای کامپیوتر ها نوشته میشهترجمه Translation : تبدیل کد های نوشته شده ما به چیزی که برای کامپیوتر ها قابل فهم باشهزمان اجرا Run-Time: مدت زمان اجرای دستورات برنامه - کد های ما - (اگر زبان ما کامپایلری بعد از کامپایل شدن اتفاق می افته)کامپایل شده Compiled: کد ترجمه شده قبل از run-timeاستاتیک تایپ Static Typingزبان های برنامه نویسی که استاتیک تایپ هستند ، چک کردن تایپ رو قبل از run-time انجام میدن یعنی زمانی که کامپایل شد.در این نوع زبان ها نیازه که قبل از این که یک متغیر رو استفاده کنیم اول تایپ (نوع) اون رو مشخص کنیم. زبان های برنامه نویسی که استاتیک تایپ هستند مثل C و C++ و GO و ... ./* C code */ static int num, sum; // explicit declaration num = 5; // now use the variables sum = 10; sum = sum + num; در قطعه کد بالا مثالی رو میبینید که در یک زبان استاتیک تایپ متغیر قبل از استفاده تعریف شده.استاتیک تایپ هاداینامیک تایپ Dynamic Typingدر زبان های برنامه نویسی داینامیک تایپ، متغیر در زمان اجرا مشخص می شه پس در زمان تعریف متغیر نیازی به تعریف نوع متغیر نیست . فقط کافیه متغیر رو تعریف و ازش استفاده کنیمزبان های برنامه نویسی مانند python و جاوااسکریپت و php از نوع داینامیک تایپ هستند./* Python code */ num = 10 // directly using the variableدر قطعه کد بالا ما مستقیم متغیر رو تعریف کردیم بدون این که قبلش بگیم نوع این متغیر قرار چی باشه. که این مشخصه زبان های داینامیک تایپ هست.استاتیک تایپ هادر واقع ما میتونیم بگیم معمولا زبان های برنامه نوسی کامپایلری استاتیک تایپ هستند و زبان های مفسری داینامیک تایپ . درسته که این دو تا مفهوم شبیه به هم هستند ولی دو مفهوم جدا هستند و نباید به جای هم استفاده بشن.استاتیک و داینامیک تایپ در مقابل تایپ قوی و تایپ ضعیف!استاتیک و داینامیک تایپ ها (Static and dynamic typing) و تایپ ضعیف و قوی (strong and weak typing) دو مفهوم و کانسپت جدا از همستند که بعضی موقع ها یکم گیج کننده میشه. این دو مفهوم جدا از هم باعث طبقه بندی زبان های برنامه نویسی میشه.تایپ قویدر زبان های تایپ قوی ، متغیرها لزوماً به یک نوع داده خاص محدود می شوند. پایتون و جاوا جز زبان های تایپ قوی حساب میشه. تمایز بین تایپ قوی و تایپ ضعیف ظریف تر است و بنابراین درک آن سخت تر از تفاوت بین تایپ استاتیک و تایپ پویا است./* Python code */ >>> foo = "x" >>> foo = foo + 2 Traceback (most recent call last): File "", line 1, in ? foo = foo + 2 TypeError: cannot concatenate 'str' and 'int' objects >>>در قطعه کد بالا foo از نوع string تعریف شده و در خط دوم سعی میکنه 2 رو به یه متغیر string اضافه کنه. و میبینیم که TypeError داده شده. در واقع به این معنیه که نمیشه یک متغیری که string تعریف شده رو با یک int جمع کنه. این همون چیزیه که زبان های تایپ قوی رو تعریف میکنه. متغیر ها به نوع داده خاصی محدود میشنتایپ ضعیفدر مقابل زبان های تایپ قوی ، زبان های تایپ ضعیف قرار دارند که متغیر ها یک تایپ خاصی ندارند و میتونند تایپشون تغییر کنه. دقت کنید این به این معنی نیست که متغیر ها تایپ ندارند بلکه تایپشون میتونه تغییر بکنه در واقع محدود به یک نوع تایپ نیستند. زبان های برنامه نویسی جاوااسکریپت ، پی اچ پی و C نمونه هایی از زبان های تایپ ضعیف هستند./* PHP code */ در قطعه کد بالا foo به صورت string تعریف شده و در خط بعدی به یک int جمع شده و خوب خطایی هم نداده که این مشخصه یک زبان تایپ ضعیفه.حالا که ما هر دو کانسپت داینامیک و استاتیک تایپ و تایپ ضعیف و قوی رو فهمیدیم پس میتونیم بگیم که python داینامیک تایپ و تایپ قویه و java استاتیک تایپ و تایپ قویه و php داینامیک تایپ و تایپ ضعیفه و C استاتیک تایپ و تایپ ضعیفهتفکیک زبان ها به نسبت تایپ های استاتیک - داینامیک و تایپ قوی -ضعیفحالا با همه این تفاسیر زبان های داینامیک تایپ بهتره یا استاتیک تایپ ؟هر دو نوع این زبان های برنامه نویسی طرفدارهایی داره و نمیشه قطعی گفت کودوم بهتر و کودوم بدتره. کسایی که از داینامیک تایپ های استفاده میکنن برای سادگی و صرفه جویی در زمان و این که نیاز که هر متغیر رو تایپش رو تعریف کنن و تعداد خط کد کمتری بنویسن خوشحال ترن. از طرف دیگه طرفداران تایپ استاتیک به این باورند که تعریف نوع متغیر یک نیاز برای یک زبان برنامه نویسه. پس طبق معمول این جنگ کودوم بهتره هیچ وقت برنده نخواهد داشت!ولی اگه از نظر پرفورمنس بخواهیم نگاه کنیم زبان های برنامه نویسی کامپایلری در زمان اجرا عملکرد بهتری دارند چون نیاز نیست در زمان اجرا تایپ ها چک بشه (چون قبلا در موقع کامپایل شدن چک شده) و خوب این عملکرد رو بهتر میکنه.امیدوارم از این مقاله استفاده کرده باشید و به دردتون خورده باشه ;)و خوشحال میشم نظرتون رو با من به اشتراک بزارید

کامپوننت های خنگ و کامپوننت های باهوش در ری اکت؟!

سعید قاسمی — Mon, 12 Aug 2019 14:36:21 +0430

چند وقت پیش در مصاحبه شرکتی به این مفهوم بر خوردم Dumb Components and Smart Components و برق از چشام پرید اوووو شت لعنتی این چیه دیگه! و بعد از ریختن پَرهام چند روز بعد با سرچ فهمیدم که چه مفهوم ساده ای بوده و بلد بودم! مفهومی که کسی که تازه ری اکت رو هم شروع میکنه بلده ولی به خاطر این که این مفهوم رو با این اسم نمیدونستم فک کردم بلد نیستم!پس حتی اگه آورده این پست براتون این باشه که بدونید این کانسپت رو با این نام هم میگن شاید براتون کافی باشه تا اگه جایی شنیدید برق از چشماتون نپره!Samrt & Dumb Componentsاین کانسپت یکی از بسیار اصولی است که باید در ری اکت بدونید و رعایتش کنید.اسم دیگه Dumb Component and Smart Component (کامپوننت های خنگ و کامپوننت های باهوش :)) ) Presentational Component and Container Component هم هست یا Stateful Component StateLess Component هم میگن.کامپوننت های خنگ (Dumb Component (Presentational Componentاین کامپوننت ها اغلب برای نمایش دیتا توی DOM استفاده میشن. و هیچ لاجیک فانکشن و استیت داخلی ندارند.از این رو بهشون کامپوننت های خنگ گفته میشه هر چی رو که بهشون پاس بدی همون رو نمایش میده و بیشتر یک UI Component هستند در نتیجه اغلب این کامپوننت ها بیشتر reusable خواهند بود.const header = (props) => { return (

{props.title}

) }کامپوننت های باهوش (Smart Component / Stateful Component (Container Componentدر طرف دیگه کامپوننت های باهوش رو داریم این کامپوننت ها اغلب state داخلی دارند و در این کامپوننت ها هست که باید نگران چگونگی کار کردن اپمون باشیم.این کامپوننت های دیتا ، فانکشن یا پراپسی که دریافت میکنن رو با پردازشی که روشون انجام میدن دیتا رو نمایش یا به کامپوننت باهوش یا خنگ دیگه پاس میدن.با توجه به تفاسیر پس باید این کامپوننت ها Class Component باشن یا اگه از Function Component استفاده میشه از hook استفاده بشه که بتونه state و لایف سایکل هارو در این کامپوننت ها داشته باشیم.class Page extends Component { constructor(props) { super(props); this.state = { firstTimeLoading: true, } } render() { return ( {this.state.firstTimeLoading &&

} {this.state.firstTimeLoading ||

} ); } }نتیجه گیری و مثالاستفاده از این کانسپت (دیزاین پترن) بهتون کمک میکنه تا لاجیک و UI خودتون رو از هم جدا کنید و ساختاری بهتری رو برای اپتون داشته باشید.برای مثال شما فکر کنید که باتنی توی اپتون دارید و قرار در بعضی از صفحات به ازای کلیک روی این باتن api کال بشه حالا راه کار چیه؟! میتونید هر باتن رو جدا در نظر بگیرید و ساختار خودشو داشته باشه که اینطوری باید به ازای هر باتن در صفحه کد جدا بنویسید!ولی راه حل درست اینه که باتن رو به عنوان یک کامپوننت باهوش در نظر بگیریم که به ازای هر بار کلیک اکشنی به پرنتش پاس بده و api کالمون تو پرنتش رخ بده نه توی خود کامپوننت باتن! با این کار کامپوننت باتن رو reusable کردیم و همه جای اپمون میتونیم ازش استفاده کنیم.

(DX (Developer Experience چیست و چرا مهم است؟

سعید قاسمی — Thu, 11 Jul 2019 17:56:13 +0430

تو این مطلب می خوام درباره (DX (Developer Experience (معادل فارسی پیدا نکردم بیاین از همین DX استفاده کنیم) صحبت کنم. و میخوام راجع به مباحث زیر توضیح بدم:وقتی میگیم DX از چی حرف میزنیم؟چرا DX مهمه؟چطور DX بهتری داشته باشیم؟تاثیر DX روی کیفیت و سرعت توسعه محصولمزایا و هزینه های DX برای سازمان چی میتونه باشه؟آیا به یک DX Designer نیاز خواهیم داشت؟DX (Developer Experience) چیست؟وقتی میگیم DX از چی حرف میزنیم؟این روزها بازار X ها خیلی داغه از (UX (User Experience گرفته تا (CX (Customer Experience و (EX (Employee Experience و امروز راجع به یه X دیگه صحبت کنیم به اسم : DX (Developer Experience) این DX همون تجربه کاربری یا UX است برای وقتی که کاربر محصول، کدهای اوپن سورس، API ، پروژه، پلاگین و ... ما یک برنامه‌نویس باشه. در واقع DX کمک می‌کنه برنامه‌نویس‌ها زندگی راحت‌تری داشته باشند و موقع کار با کدها از کارشون لذت ببرند. چرا DX مهمه؟به همون دلیل که UX مهمه! وقتی کاربران از محصول ما راضی باشن و چیزی رو که اونا میخواستن رو بهشون دادیم به هدفی که میخواستیم رسیدیم و خیلی خوشحالیم. ولی دولوپر ها چی؟ خوشحال بودنشون چه قدر مهمه؟ این که از کارشون لذت ببرن چه قدر میتونه روی خروجیشون تاثیر بزاره؟ و این خروجی چه قدر روی کیفیت محصول و اهداف بیزینس تاثیر میزاره؟ احتمالا شما هم مثل من به این نتیجه رسیدید که دولوپر خوشحال تاثیر مستقیم روی کیفیت محصول و اهداف بیزینس داره.هر چند ما اغلب دوس داریم صحبت نکنیم و توی کد ها غرق باشیم (به قول دوستی دولوپرها آدمای darkی هستن) و شاید واسه همین باشه که آخرین X برای ما دولوپرهاست. شاید وقتش باشه از خودمون دفاع بکنیم و از مشکلاتمون صحبت کنیم تا این فلسفه DX رو جا بندازیم. ولی نکته جالب این قضیه اینه که ما دولوپرها باید خودمون DX رو برای خودمون بهتر کنیم و مطالبه گرش باشیم...چطور DX بهتری داشته باشیم؟یک نکته ای که باید بهش توجه کنیم اینه که DX ربطی به EX نداره و حوزه کاری DX تماما بر میگرده به کیفیت کدنویسی! و این کد باید چطور باشه و چه پیشنیاز های باید داشته باشه که ما به یک DX خوب برسیم در حالی که EX مربوط میشه فضای کاری و اقدامات منابع انسانی و ... .و اما موارد مهمی که باعث DX خوب میشه:1- مستنداتاحتمالا برای همه ما دولوپرها پیش اومده که وارد پروژه شدیم که کد های به شدت پیچیده و کثیف داره! و شما گفتید "oh! shit"و بعد، از رفتن به اون شرکت یا گرفتن پروژه پشیمون شده باشید.مستندات نویسی یکی از مهم ترین اصول DX هست! همیشه برای پروژه تون مستندات بنویسید نه فقط تکنولوژی های استفاده شده بلکه ماژول ها و نحوه استفاده از اون ها و حتی اگه از یک ماژول استفاده کردید و به مشکل خوردید و عوضش کردید این رو هم تو مستنداتتون بنویس و از علت تغییرش بنویسید تا اگه نفر بعدی خواست استفاده کنه متوجه باشه.ثبات و پایبندی به مستندات خیلی مهمه! اگه چند نفرید و دارید یک مستندات رو مینویسید حواستون باشه با یک اصول و ساختار نوشته شده باشه و حتما در طول پروژه بهش پایبند باشید از تغییر تو پروژه تون انجام دادین چیزی کم و زیاد کردین حتما مستنداتتون رو آپدیت کنید.نحوه مستندات نویسی و ساختارش خیلی مهمه، اگه مستندات پکیج های خارجی رو دیده باشید با یک "Getting Started" شروع شدن و بعدش درباره نحوه نصب و نیازمندی هاش نوشتن و بعد وارد جزئیات شدن. متاسفانه ما تو کشورمون خیلی به مستندات نویسی پروژه هامون اعتقاد نداریم و وقتی که نیروی جدید قرار به تیممون اضافه بشه کلی باید تلاش کنه تا متوجه ساختار پروژه باشه! و وای اگه متوجه نشده و واسه خودش ساختار جدید تعریف کنه که اون پروژه یک اسپاگتی کدی بیش نیست!2- یادداشت های امکانات جدید و تغییر در کد قبلی Release Notes and Changelogsوقتی پروژمون آپدیت میشه حواسمون باشه لیست Release Notes ها رو شفاف بنویسم چه چیزهایی جدید اضافه شده چه چیزهایی فیکس و چه چیزهایی تغییر کده تا دولوپرهایی که میخوان آپدیت کنن متوجه تغییرات باشن.3- رعایت استانداردها و اصطلاحاتوقتی داریم از یک زبان برنامه نویسی یا یک فریم ورک و لایبرری استفاده میکنیم سعی کنیم اصول و استاندارد هایی که توی کامیونیتیش شکل گرفته رو رعایت کنیم تا دولوپر های سریع تر بتونن باهاش ارتباط برقرار کنند.4- ابزاهایگاهی توسعه یک نرم افزار بستگی به نوع نرم افزار و ورژن های مختلف اون داره مطمئن بشیم که این هارو توی مستنداتمون نوشته باشیم5- توضیح درباره متدهاوقتی متدی نوشته میشه حالت های مختلفش رو تو مستنداتتمون بیاریم مثلا چه زمانی true میشه چه زمانی false میشه چه اتفاقی بیوفته null برمیگردونه ، پارامترهای ورودی چیه و ...6- متدهای حذف شده و Deprecated شدهاگه شما میخواید متدهایی رو تغییر بدید بهتره این کارو آروم انجام بدید و به دولوپرها اجازه بدید خودشون رو وفق بدن. تا حد امکان از حذف متد ها خودداری کنید و فقط Deprecations کنید و پیشنهاد بدید از متدهای جدید استفاده کنند7- تعیین Namespaceاگر دارید به صورت تیمی کار میکنید Namespaces خیلی میتونه مهم باشه و باعث یک دست شدن ساختار پروژه ها و سریع تر کار کردن دولوپر ها باشه8- نوشتن Read Meسعی کنید حتما برای پروژتون Read Me داشته باشید. و به طور خلاصه توضیحات و نحوه نصب و مثال ها و راهنمایی هارو بنویسید.9- دستورالعمل Code of Conduct مشخص کردن دستورالعمل یا اصطلاحا Code of Conduct برای پروژه های اپن سورسی و تیمی خیلی مهمه و باعث یک دست شدن و تمیز شدن کد ها میشه به طوری که کدی که هم تیمی شما می نویسه با کد شما فرقی نمیکنه و سریع میتونید کد رو ریویو کنید.اینا مواردی مهم و تاثیر گذاری روی DX بود که قطعا موارد بسیاری دیگه هم هست که اگه رعایت بشه بسیار زندگی با دولوپر هارو راحت تر میکنه و برای جا انداختن همچین فرهنگی باید از خودمون شروع کنیم سعی کنیم این موارد رو رعایت کنیم. فک نمیکنیم اگه به شرکتی برید که این موارد رو رعایت کرده باشن کار خیلی براتون جذاب خواهد بود؟تاثیر DX روی کیفیت و سرعت توسعه محصولرعایت نکات DX و بهبودش میتونه روی کیفیت کدهامون تاثیر بزاره و تکنیکال دبت رو بسیار کاهش بده و دیگه خبری از اسپاگتی کد نیست و تماما کلین کد نوشته میشه و این باعث میشه سرعت دولوپ محصول به مراتب بالاتر بره و اگه نیروی جدیدی به تیممون اضافه میشه سریع میتونه team-up بشهمزایا و هزینه های DX برای سازمان چی میتونه باشه؟قطعا DX برای سازمان ها و شرکت ها بسیار مفیده چرا که فیچرها سریع تر اضافه میشه ، سازمان متکی به فرد نمیشه که با رفتنش تمام دانش رو با خودش ببره و تمام دانش رو به صورت مستندات وجود داره ، تمام نیرو های یه واحد میتونه روی تمام پروژه کار کنه و این طوری نیست که هر نیرو فقط کد خودش رو دولوپ و دیباگ کنه! و ... .ولی هر چیز خوبی یه هزینه ای داره! سازمان باید هزینه زمانی بهبود DX رو بده و دید بلند مدت داشته باشه دولوپر باید زمان لازم رو برای نوشتن مستندات ، بروز نگه داشتن و پایبند بودن به مستندات و اصول تعریف شده رو داشته باشه. ولی امان از تسک های فورس ...!!!آیا به یک DX Designer نیاز خواهیم داشت؟همونطور که گفتم دولوپرها زیاد به صحبت کردن و توضیح دادن علاقه ای ندارد و مستندات نویسی هم از این قائده مستثنی نیست و بیشتر دوس دارن تو دنیای کد نویسی خودشون باشن. شاید همین امر باعث بشه در آینده منتظر یک پوزیشن جدید DX Designer باشیم! کسی که بتونه مستندات پروژه رو بنویسه ، بروز نگه داره و بهش پایبند باشه و همینطور استفاده از نرم افزارها رو از لحاظ DX بررسی کنه ، درباره پکیج ها و ماژول ها و پروژه های اوپن سورس و انتخابشون نظر بده و سعی کنه ساختار و اصول کد نویسی رو در سازمان حذف کنه.امیدوارم این مقاله به دردتون خورده باشه و تجربه کدنویسیتون رو بهبود بده و زندگی رو براتون لذت بخش تر بکنه!اگه نظری داشتید خوشحال میشم باهام در میون بزارید ;)