https://virgool.ir/feed/@dehqanیک برنامه نویس سادهfa2026-11-11 06:50:38https://files.virgool.ir/upload/users/46087/avatar/v6J1P6.jpghttps://virgool.ir/@dehqanhttps://virgool.ir/@dehqan/داکر-v1owzfwy0svtنسخه صوتی این مقاله را در پادکست کافه برنامه نویس گوش کنید: https://anchor.fm/codemy/episodes/ep-e5o52q/a-apc86h Castbox | Apple Podcasts | Google Podcasts | Shenotoما را در کافه برنامه نویس دنبال کنید:Twitter | Telegramاین روزها همه در مورد Docker و Kubernetes صحبت می کنند، می خواهیم در مورد این مفاهیم و این که چه امکاناتی بهمون میدن صحبت کنیم.برای اینکه بدونیم داکر چیه نیاز هست ابتدا در مورد گذشته دنیای آی تی صحبت کنیم تا بعدش به containerها برسیم تا بتونیم در مورد داکر صحبت کنیم. هدف از صحبت کردن در مورد گذشته آی تی اینه که به ما بفهمونه از کجا به کجا رسیدیم و مسیر پیشرفت چجوری بوده تا بتونیم داکر و دلایل ایجادش رو بهتر متوجه بشیم. به طور کلی تو دنیای آی تی، هر بیزینسی نیاز به یک اپلیکیشن داره. در واقع این اپلیکیشن ها هستند که بیزینس هارو میسازن. مهم نیست بیزینس شما در مورد چه موضوعی هست، بانک، فروشگاه، بلیط مسافرت و ... اپلیکیشن ها هسته این بیزینس ها هستن و به نحوی درهم آمیخته شده اند که عملا تفاوتی بین این دو وجود نداره. ممکنه خیلیا این جمله رو شنیده باشند که "بدون اپلیکیشن ها بیزینس ها هم معنی ندارند" و هر روز که میگذره به این جمله نزدیک و نزدیک تر میشیم.اکثر اپلیکیشن ها نیاز به سرور دارن. اوایل سال 2000 برای پابلیش کردن هر اپلیکیشن نیاز به خرید یک سرور بود. و منظور ما از سرور یه سخت افزار فیزیکی بزرگ و گرونه. حالتی رو فرض کنید که بیزینس شما نیاز به یک اپلیکیشن داره، برای این کار تیم آی تی باید یه سرور بخره، و تصمیمی که تو این حالت باید بگیره اینه که بهترین سرور ممکن رو در اختیار بیزینس قرار بده تا بتونه از پس نیازهای احتمالی بیزینس شما بر بیاد. دلیل این کار هم اینه که تا اون لحظه، کسی اطلاعی از مقدار منابعی که ممکنه اپ شما مصرف کنه نداره. اوایل سال 2000 هر اپلیکیشن نیاز به یک سرور مستقل داشتاین اتفاق برای هر اپلیکیشنی که بیزینس شما نیاز داره تکرار میشه و هزینه هنگفتی روی دست بیزینس میذاره، چه از لحاظ خرید سرور، چه از لحاظ نگهداری و تامین برق و چه ادمین هایی که قراره ازین سرورها پشتیبانی کنند. بعد از همه این اتفاق ها حالتی پیش میاد که بیزینس شما تعداد زیادی سرور گرون خریده که اکثر اون ها حتی از 10% منابعی هم که دارن استفاده نمی کنن. vmwareوظیفه اصلی vmware، تقسیم منابع یک سرور فیزیکی به چندین سرور مجازی استبا اومدن vmware این مشکلات حل شد. کاری که vmware انجام میده اینه که شما با خرید یک سرور و تقسیم منابع اون، میتونین چندین سرور مجازی داشته باشین که هر کدوم سیستم عامل خودشون رو دارن و منابع سیستم بین این سرورهای مجازی تقسیم میشه. مثلا اگر ما 4 تا اپلیکیشن داشته باشیم، با ساختن 4 سرور مجازی و اختصاص دادن منابع به هر کدوم مثل CPU، Memory و Hard Disk، خیالمون از بابت جدا کردن منابع سرور اصلی راحته، چون هر کدوم ازین سرور های مجازی فقط منابع خودشونو میشناسن. با این حساب هر کدوم از این سرورهای مجازی به عنوان یک سرور مستقل شناخته میشن و خبری از بقیه سرورها نخواهند داشت.مزیت این کار اینه که نیاز به خرید یک سرور به ازای هر اپ جدید نیست و میتونیم از سروهایی که داریم نهایت استفاده رو ببریم.کاری که vmware با دنیای آی تی کرد قابل چشم پوشی نیست ولی این تکنولوژی یه سری مشکلاتی هم داره.هر کدام از سرور های مجازی مستقل هستند و سیستم عامل مستقل خود را دارند.همون طور که قبلا هم گفتیم هر کدوم ازین سرور های مجازی مستقل هستند و سیستم عامل خودشون رو دارند. مشکل اول همین جا پیش میاد. حتی قبل ازینکه پابلیشی صورت بگیره مقداری از منابع سرور اصلی شما توسط سیستم عامل های سرورهای مجازی استفاده میشه و این اصلا خوب نیست.مشکل بعدی وقتی رخ میده که یکی ازین سرورهای مجازی از همه ظرفیتش استفاده نکنه و مقداری از منابعش بدون مصرف باقی بمونه. تو این حالت سرورهای مجازی خبری ازین اتفاق ندارن و عملا نمیتونن ازین منابع استفاده ای داشته باشن.ازونجایی که به ازای هر سرور مجازی، سیستم عامل خودمون رو داریم مشکلاتی از قبیل لایسنس هم وجود داره و البته با بالا رفتن تعداد این سیستم عامل ها هزینه پشتیبانی و حفظ امنیتشون هم بالا میره.Containerبرای حل مشکلات vmware، مفهومی به نام container ایجاد شد. ما میتونیم با استفاده از یک سیستم عامل و ایجاد container به ازای هر اپلیکیشن مشکل نصب چندین سیستم عامل رو برطرف کنیم.همچنین مشکل تخصیص بخشی از حافظه و سی پی یو و دیسک به هر اپلیکیشن حل میشه. در واقع containerها میتونند ظرفیت سرور رو با همدیگه به اشتراک بذارن.همچنین وجود یک سیستم عامل به جای چندین سیستم عامل، مدیریت و نگهداری سرور رو آسان تر میکنه.سوال مهمی که اینجا پیش میاد اینه که فرق بین مدل vmware و container چیه؟سمت راست: مدل container - سمت چپ: مدل vmwareدر مدل vmware، بالای سرور فیزیکی hyper visor نصب میشه که بالای اون تعدادی ماشین مجازی ساخته میشه که هر کدوم سیستم عامل خودشون رو دارن که توضیح دادیم تو این حالت چقدر منابع سیستم به هدر میره و چه مشکلات دیگه ای ممکنه پیش بیاد. در مدل container، بالای سرور فیزیکی، سیستم عامل نصب میشه و داخل سیستم عامل containerهامون ساخته میشن که توضیح دادیم چه مزیت هایی دارن. اینم بگم که فضایی که containerها میگیرن خیلی خیلی کمتر از ماشین های مجازیه و سرعت استارت و استاپ شدنشون به شکل باور نکردنیی سریعه، چون قرار نیست مثل ماشین مجازی سیستم عاملی بالا بیاد تا اپ بتونه کارشو انجام بده.آیا میشه گفت مهم ترین مزیت containerها اینه که مارو از شر ساختن ماشین های مجازی متعدد راحت می کنن؟نه، اتفاقی که میفته اینه که تو بیزینس های enterprise، کانتینرها و ماشین های مجازی در کنار هم وجود دارن، حالا ممکن هست یه سری بیزینس های ساده فقط با containerها کار کنن تا کارشون راحت تر جلو بره. اپلیکیشن های موسوم به Legacy، اپلیکیشن هایی هستند که همه ماژول های ما داخل یه پروژه هستند و اصطلاحا یه فایل binary برای پابلیش دارن. مشکلی که این حالت داره اینه که وقتی یک developer میخواد یه باگی رو رفع کنه، تغییراتش ممکنه روی کل پروژه تاثیر داشته باشه، یا حتی وقتی devOps میخواد این تغییرات رو پابلیش کنه، نیاز هست نسخه جدید رو با نسخه قدیم جایگزین کنه و این اتفاق باعث down شدن کل ماژول های ما میشه. تعریفی که اینجا وسط میاد Microserviceها هستن.پیاده سازی پروژه در قالب Microserviceدر مدل Microservice، با تبدیل کردن پروژه های بزرگ به چندین مینی اپ مشکلات قبلی رو نخواهیم داشت و کسی که میخواد بر فرض روی ماژول سرچ یه سری تغییرات جدید اعمال کنه، فقط روی همون ماژول کار می کنه و کارش تاثیری روی قسمت های دیگه نداره. همین اتفاق سمت devOps هم میفته، وقتی نسخه جدید ماژول سرچ با نسخه قدیمیش جایگزین میشه، این روال، کاری با بقیه ماژول ها نداره و اون ها همچنان up هستن و اعمال تغییرات جدید باعث از کار افتادن اون ها هنگام پابلیش نمیشه. کاری که container ها اینجا انجام میدن اینه که میتونن توی اسکیل کردن این مینی اپ ها به ما کمک کنن. مثلا اگر پروژه ما ماژول هایی مثل وب سایت، سرچ، سفارشات و ... داشته باشه، و بار خیلی زیادی روی ماژول وب سایت داشته باشیم با اضافه کردن containerهای مربوط به این ماژول می تونیم اسکیلمون رو به راحتی انجام بدیم. Dockerوقتی که از Docker صحبت میشه دو تا موضوع باید از هم تفکیک بشن. یکی شرکت داکر (Docker Inc) و اون یکی محصولش که اصطلاحا بهش میگیم Docker Technology.ازونجایی که containerها مثل سرورهای مجازی هستن ولی با این تفاوت که بسیار سریع تر عمل می کنند؛ کار داکر قرار دادن و اجرای اپلیکیشن ها داخل این containerهاست. داکر open source هست و روی گیت هاب کدش موجوده.نسخه open source داکر، که بهش Community Edition هم گفته میشه کاملا رایگانه. در کنار این نسخه، شرکت داکر نسخه ای به اسم Enterprise Edition هم داره که مثل همون نسخه قبلیه با این تفاوت که پولیه و یک سری امکانات برای مدیریت بهتر containerها بهمون میده و البته قرار داد پشتیبانی شرکت رو هم با خودش به همراه داره.در هر حال، نسخه Community و Enterprise کارشون اجرا و مدیریت اپلیکیشن ها داخل containerهاست.بحثی که اینجا پیش میاد برای مواقعی هست که شما میخواین containerهاتون رو به صورت بهینه اسکیل کنید. ینی اگه یه instance از یه container دارین که ماژول وب سایتتون رو اجرا می کنه، برای اینکه لود خیلی زیادی روش نباشه میایم یه instance از همون container دوباره ایجاد می کنیم تا load balancing رو بهتر بتونیم مدیریت کنیم. برای مدیریت بهتر اینکار دو تا ابزار وجود داره، Swarm و Kubernetes. جفتشون خوبن ولی بخاطر اینکه کوبر امکانات بهتری بهمون میده در مورد اون صحبت می کنیمKubernetesاز سال 1999 گوگل برای اینکه بتونه سرویس هایی مثل Search یا Gmail رو اسکیل کنه از containerها استفاده می کرده که تعداد این containerها خیلی زیاد بوده در حالی که اون موقه اصلا مفهومی به اسم Docker هم حتی وجود نداشته. برای مدیریت این containerها، گوگل سیستم هایی برای خودش ابداع کرد تا بتونه از پس اسکیل کردنشون بر بیاد. اولین سیستمی که برای مدیریت این containerها ساخت Borg بود. بعدش Omega ساخته شد؛ بعدش به دلایلی با استفاده از تجاربی که از Borg و Omega بدست آورده بودن تصمیمی گرفتن سیستم جدیدی رو خلق کنن. اینجا Kubernetes به وجود اومد. پس کوبر از دل گوگل بیرون اومده و البته open source هم هست.الان ممکنه از خودتون بپرسین فرق بین Docker و Kubernetes چیه؟داکر مسئول کار های low-level هست، مثلا start, stop یا حتی delete کردن containerها.اما کوبر مسئول یه سری کارای high-level مثل scheduling, scaling, healing یا updating کانتینرهای شماست. یعنی اگر اتفاقی برای یکی از containerها بیفته و باعث بشه که اپلیکیشن شما داخل اون container از کار بیفته، وظیفه کوبر اینه که مراقب این مسئله باشه و سریع این اتفاق رو تشخصی بده و یک container دیگه از اپ ما بسازه. یا حتی برای وقتی که یکی از containerهای ما زیر فشاره، باز کوبر این موضوع رو تشخصی میده و یک container برای ما ایجاد می کنه. یا اگر برای container ما آپدیتی وجود داشته باشه توسط مکانیزمی همه instanceهایی که ازون container وجود دارن توسط کوبر آپدیت میشن.برای فهم بهتر Kubernetes یک مثال ساده میزنم:یه ارکستر رو در نظر بگیرین، هر ارکستر از انواع مختلفی از الات موسیقی تشکیل شده؛ ویولون، گیتار، درام و خیلی چیزای دیگه که هر کدوم نوت های خودشونو دارن و البته نوع استفاده از اون سازها و کاری که انجام میدن متفاوته. شخصی که جلوی همه نوازنده ها وایمیسته و به رهبر ارکستر معروفه وظیفه هماهنگی همه این نوازنده ها و سازهاشون رو بر عهده داره. اینکه چه تعداد از یک ساز باید وجود داشته باشه یا هر کدوم از نوازنده ها کی باید شروع به نواختن کنن و کی باید تموم کنن.کاری که کوبر انجام میده دقیقا مثل رهبر ارکستر هست. در واقع کوبر با زیر نظر گرفتن containerها، برای ایجاد تغییراتی که منجر به اسکیل کردن پروژه میشه یه سری دستورات به داکر ارسال می کنه.اگر بخوام یه مثال فنی تر بزنم میشه Docker رو به یه low-level hyper visor مثل ESXi تشبیه کرد، و کوبر هم مثل vCenter هست که بالای همه این hyper visor ها میشینه.حالا اگه بخوایم یکم دقیق تر به مسئله نگاه کنیم، حالتی رو در نظر بگیرین که چندین تا سرور داریم که هر کدوم کوبر و داکر و کانتینر های خودشون رو دارن.کوبر به صورت اختصار به صورت K8s هم نوشته می شودبالای همه این سرورها، مغز اصلی کوبر قرار داره که از همه این سرورها و و ضعیت containerهاشون خبر داره و وقتی بهش میگیم ازین اپمون دو تا container می خوایم، خودش همه کارارو انجام میده و تشخیص میده که روی کدوم سرور باید این containerها اجرا بشن و همون طور که قبلا هم گفتیم مراقب لود روی اپ هامون هست که با زیاد کردن کانتینر ها اینکارو انجام میده.تو این مقاله تا اون جایی که تونستم، سعی کردم مفاهیم مروبط به Container, Docker و Kubernetes رو براتون توضیح بدم. امیدوارم با خوندن این مقاله راهتون رو پیدا کنین و مسیر پیشرفت براتون هموارتر بشه. اگر نظری یا سوالی دارین زیر همین پست پاسخگو هستم.علی دهقانعلی دهقانThu, 03 Oct 2019 23:20:03 +0330https://virgool.ir/@dehqan/داکر-به-زبان-خیلی-ساده-ye1p9ey1ycf2داکر (Docker) یه نرم افزار رایگانه که توسط شرکت Docker توسعه داده شده و در تاریخ 12 مارس 2013 به صورت رسمی عرضه شد.کار اصلی Docker چیه؟کار اصلی Docker ایجاد محیط های ایزوله و مستقل برای لانچ و دولوپ هست. به این محیط‌ها اصطلاحاً Container گفته میشه.با این قابلیت شما میتونین Containerهای خودتون رو روی هر دستگاهی اجرا کنین و اصلا نگران مشکلاتی از قبیل Dependency یا Compilation نباشین. تمام کاری که برای لانچ کردن اپلیکیشن خودتون نیاز دارین اینه که Containerتون رو ران کنین.آیا Docker یه ماشین مجازیه؟این سوال یکی از مهم ترین سوالاتیه که در مورد Docker پرسیده میشه و جوابش منفیه.ممکنه تو نگاه اول ماشین مجازی به نظر برسه ولی کارکردهاشون با هم فرق دارن. بر خلاف Docker، ماشین مجازی شامل یه سیستم عامل کامله و مثل یک کامپیوتر واقعی و مستقل عمل می‌کنه، ولی Docker فقط منابع دستگاه رو برای استفاده Containerها به اشتراک میذاره.تفاوت Virtual Machine با Dockerدلایل استفاده از Docker ؟داکر خیلی سریعه. بر خلاف ماشین مجازی اپلیکیشن‌های شما در عرض چند ثانیه میتونن STOP و START بشن.داکر قابلیت چند پلتفرمی داره، شما میتونین Containerهاتون رو روی هر سیستمی لانچ کنین.میتونین Containerهاتون رو با سرعت بیشتری نسبت به ماشین مجازی بسازین یا حذفشون کنین. دیگه نیازی نیست نگران Dependencyهاتون باشین. کافیه یه بار تنظیمات داکر رو انجام بدین تا دوباره نخواین اونارو جایی نصب کنین.خیلی راحت میتونین محیطی که اپلیکیشنتون رو توش اجرا می‌کنین تمیز و مرتب نگه دارین و هر زمانی که بخواین اونارو پاک کنین.و اینکه با داکر خیلی راحت تر می تونین پروژه هاتون رو گسترش بدین و اونارو روی سیستمای مختلف اجرا کنین.تو این مقاله سعی کردم خیلی مختصر و مفید Docker رو توضیح بدم.امیدوارم به جواب سوالاتتون رسیده باشین :)نسخه صوتی این مقاله رو در پادکست کافه برنامه نویس گوش کنید: https://anchor.fm/codemy/episodes/ep-e3q5o5/a-adj29a از طریق لینک های زیر هم میتونین این پادکست رو دنبال کنید:اپل پادکست | گوکل پادکست | کست باکسعلی دهقانعلی دهقانTue, 06 Aug 2019 16:48:50 +0430https://virgool.ir/@dehqan/5-عادت-قدرتمند-برنامه-نویسان-موفق-cwrbv5uaudliنسخه صوتی این مقاله را در قسمت چهارم پادکست کافه برنامه نویس گوش کنید: https://anchor.fm/codemy/episodes/ep-e4dp5a/a-ahhpr5 کست باکس | اپل پادکست | گوگل پادکستلری وال، سازنده زبان پرل، یه جمله معروف داره. اون میگه:توسعه دهندگان بزرگ دارای سه ویژگی اخلاقی هستند: تنبلن، صبرشون کمه و مغرورن. شاید این حرف براتون عجیب باشه. ولی دلایلی که آورده جالبن.تنبلن چون حال نوشتن کدای طولانی رو ندارن و با کمترین کد، تسک هاشون رو انجام میدن. از طرفی برای کداشون داکیومنت درست می کنن تا نیاز نباشه به سوالای زیادی پاسخ بدن.صبر کمشون باعث میشه تو حین نوشتن یه برنامه، پیش دستی بکنن و امکاناتی رو به اون اضافه کنن که مطمئن هستن جزو درخواست های بعدی کارفرما خواهد بود. و اعتماد به نفس بالایی دارند برای اینکه اونارو مجبور کنه کدای حرفه ای بنویسن تا بقیه نتونن ازش ایراد بگیرن.برنامه نویسای موفق لزوما جزو بهترین و بزرگترین برنامه نویسا نیستند.برنامه نویسی که تسک های روزانه اش رو درست و به موقع انجام میده خیلی مفیدتر از اون کسیه که با وجود نوشتن کدهای پیچیده، نمیتونه اونارو به موقع تحویل بده. به دلیل این که برای بیشتر کارفرماها حجم کار انجام شده مهمه تا اینکه لول کار بالا باشه ولی خیلیشون نصفه و نیمه رها شده باشن.موفقیتی که شما به دنبال اون هستید نشات گرفته از دیدی هست که شما نسبت به خودتون و دنیاتون دارین و اینکه عادات برخوردتون با چالش های زندگی به چه نحوی هست. به گفته محققان دانشگاه دوک دلیل 40% از موفقیت های ما برمیگرده به عادت هایی که تو زندگی داریم. در ادامه تعدادی از عادت های قدرتمند برای تبدیل شدن به یک برنامه نویس موفق رو بررسی می کنیم.حرفه ای باشیداستیو مارابولی محقق آمریکایی میگه:انجام کار درست و انجام کار سخت هر دوشون یه چیزن. و هردوی اون ها مستلزم حرفه ای گری هستن.حرفه ای بودن یه شمشیر دو لبس. از یه طرف باعث میشه که فرد به خودش افتخار کنه و از طرف دیگه مسئولیت پذیری و پاسخگویی رو با خودش به همراه میاره و هر دوی اینا نتیجه همدیگه هستن. شما نمیتونید افتخار ناشی از حرفه ای بودن رو با بی مسئولیتی به دست بیارید.تصور کنید شما یه سری تعییرات به اپتون دادین و اونو پابلیش کردین. یک مشکل جدی بابت کد شما پیش میاد و اپ برای یه روز از کار میفته و این اتفاق باعث میشه کارفرما متحمل هزینه زیادی بشه. تو این حالت شما فوقش میتونین تغییراتی که اضافه کردین رو به حالت قبل برگردونین اما خسارتی که زده شده قابل بازگشت نیست.وقتی همچین اتفاقی بیفته، یه برنامه نویس آماتور شونه هاش رو بالا میندازه و میگه "اتفاق پیش میاد" و شروع میکنه به نوشتن ماژول بعدی. اما یک شخص حرفه ای مسئولیت کارش رو برعهده میگیره و از اتفاقی که افتاده ابراز شرمندگی میکنه و این اطمینان رو میده که دیگه همچین اشتباهی تکرار نمیشه.همیشه به یاد داشته باشید که حرفه ای گری یعنی مسئولیت پذیر بودن. امکان نداره که همیشه حق با شما باشه و کارهاتون همونجوری پیش بره که انتظارشو دارین. اما نیاز هست که همیشه اشتباهاتی که انجام دادید رو بپذیرید و به دنبال جبران و تصحیحش باشید.یک اشتباه رو دوبار تکرار نکنیدآمیت کالانتری روانشناس و نویسنده هندی حرف قشنگی میزنه. اون میگه :اگر یک عذرخواهی با یک بهانه یا دلیل همراه شود، به این معنیه که اون شخص قراره دوباره مرتکب همین اشتباه بشه.بدیهیه که میخواهیم نرم افزارمون به درستی کار کنه. درواقع، بیشتر ما امروز برنامه نویس هستیم چون یه بار این کارو درست انجام دادیم و قصد تجربه مجدد اون حس خوشحالی و رضایتمندی رو داریم. اما ما تنها کسایی نیستیم که میخوایم نرم افزار کار کنه. مشتری و کارفرمای ما هم همینو میخوان. درواقع، اونا به ما پول میدند که نرم افزاریو بسازیم که طبق خواسته اونا کار کنه.تا اینجاش که خوبه. اما هیچ نرم افزاری بی عیب نیستد. هر کدوم یه اشکالاتی دارن.کلید اصلی ماجرا این نیست که یک کد بی عیب و نقص بنویسید. این اتفاق یه تصور خیالیه که هیچ وقتم محقق نمیشه. قبلا در این مورد صحبت شد که شما باید مسئولیت اشتباهاتتون رو بپذیرید.حالا نکته اینجاست که هیچ وقت یک اشتباه رو دوبار تکرار نکنید.همونطور که توی کارتون رشد می کنید، میزان خطاهای شما هم باید کاهش پیدا کنه و به صفر نزدیک بشه. این عدد هیچ وقت به صفر نمیرسه، اما این وظیفه شماست که تا اون جا که ممکنه کمترش کنید.هیچ چیز رو به شانس واگذار نکنیداگر چیزی اشتباه به نظر برسه، قطعا تو آینده شمارو با مشکل مواجه می کنه و هیچ شانسی هم نمیتونه مانع از اتفاق افتادنش بشه.چجوری میتونین مطمئن شین که کدتون بدون اشتباه کار میکنه؟ جوابش اینه که تستش کنید. حتی اگر مهلتتون تموم شده و فشار زیادی روتون هست که گوشه های کار رو بزنید و تمومش کنید، به هیچ وجه این کارو نکنید. از هر مدل تستی که بلدین استفاده کنین. تست هایی مثل Unit Testing, Integration Testing میتونه خیلی کمکتون کنه.اعتبار شما بستگی به این داره که، کدتون چقدر درست کار می کنه و فقط تست کردنه که میتونه احتمال درستی کد روبه 100% نزدیک کنه. مسئولیت کدتون با خودتونه، پس بهتره خط به خطش رو تست کنید.حالا اگه کدی که نوشتین "غیر قابل تست" باشه چی؟راه حلش اینه که کدتون رو برای تست کردن ساده کنید و بهترین روش برای این کار اینه که تست هارو قبل از نوشتن کد آماده کنین.همیشه کداتونو منعطف بنویسینفرض اصلی پروژه های نرم افزاری، اینه که به راحتی قابل تغییرن. اگه کدی که شما مینیویسین این قابلیتو نداره ینی یه جای کارو اشتباه رفتین.پروژه های زیادی دچار این مشکل میشن. تو این پروژه ها، برنامه نویسای زیادی میان و میرن و هرکدوم به این کد غیر منعطف چیزی رو اضافه می کنند و در نهایت یه هیولایی رو بوجود میارند که نه میشه دوباره نوشتش نه میشه براحتی نگهش داشت.کلید اصلی حل این چالش اینه که قسمت هایی از کد که باعث این عدم انعطاف شدن رو پیدا کنید. وقتی اون قسمت هارو پیدا کردین به جای اینکه به این آشفتگی چیز دیگه ای اضافه کنین، تلاش و زمانتون رو صرف دوباره نوشتن اون قسمت ها کنین. درسته ممکنه با این تغییرات جدید از ددلاینتون عقب بیفتین، ولی مطمئن باشین تلاش شما ارزششو داره و پشتیبانی اون قسمت خیلی راحت تر میشه.یه اصلی هست به اسم Merciless Refactoring، یا اصلاح بی رحمانه. به این معنی که زمانی نوشتن یه کد رو به پایان برسونین که مطمئنین ازین بهتر و تمیز تر نمیشد بنویسینش. سعی کنید همیشه این اصل رو رعایت کنید.و در نهایت همیشه در حال یادگیری باشیداشتیاق به یادگیری رو در خودتون پرورش بدید. اگر این کار رو بکنید، هیچ وقت رشدتون متوقف نمیشه.میخوام دوره CCIE رو بگذرونم، اما کارفرما حمایتم نمیکنه.میخوام React native یاد بگیرم. ولی نمیتونم یه زمان خالی توی برنامه شلوغم پیدا کنم.همه این ها بهانه هایی هستن برای طفره رفتن از یادگیری. رشد کاری شما شما مسئولیت خودتونه. این وظیفه کارفرمای شما نیست که از رشد و پیشرفت شما مطمئن بشه یا اینکه شما رو آموزش بده یا حتی براتون کتاب بخره.ساعات کاری هفتتون رو یه جوری تنظیم کنین، که علاوه بر تایم متعلق به کارفرماتون، یه ساعت هایی هم برای خودتون باقی بمونه که تو اون ساعت ها به آموزش و رشد خودتون بپردازین. میتونین از قاعده 20-40 استفاده کنید. ینی هفته کاری خودتون رو حداقل 60 ساعته در نظر بگیرین که 40 ساعت متعلق به کارفرما و 20 ساعت هم برای خودتونه. اگر از وقتتون آگاهانه استفاده کنید 20 ساعت، کار اضافه در هفته، اصلا سخت نیست. سعی کنین یادگیری و رشد جزئی از عادت و فرهنگ زندگی روزمرتون بشه.همیشه بیاد داشته باشید که دنیای نرم افزار همواره در حال تغییره و همه چیز در اون خیلی راحت میتونه تبدیل به یه دایناسور منقرض شده بشه. پس اگر میخواهید همیشه جلوتر از زمان خودتون باشید و با ارزش باقی بمونین، روی خودتون سرمایه گذاری کنید و همیشه در حال یادگیری باشید.همونطور که Seema Openers گفته:خود آموزی یه راه رشد ساده و در دسترس برای همس، اما فقط کسایی این کارو می کنن که نمیخوان زندگی کوچک و بی هدفی داشته باشند.آیا شما هم عادتی داشتین که باعث انجام بهتر کارهاتون شده باشه؟منبع: http://bit.ly/2X1uxioعلی دهقانعلی دهقانTue, 25 Jun 2019 21:01:41 +0430https://virgool.ir/@dehqan/چالش-های-رایج-برنامه-نویسی-jq9askqee4mwتو این چند سال با خیلیا کار کردم، دولوپرای فرانت اند، بک اند و فول استک هاخیلی از مشکلاتی که بهشون برخورد کردم شبیه هم بودن و حتی منم هر از گاهی قربانی این اشتباهات شدم. تو این مقاله سعی دارم این اشتباهات رایج رو با شما در میون بذارم.اگر به نون احتیاج دارین، نیاز نیست نونوایی بسازینتقریبا همه ما با این اشتباه مواجه شدیم. خیلی از برنامه نویسا برای تحویل یه پروژه ساده، درگیر پیاده سازی امکاناتی میشن که انگار قراره این پروژه میلیون ها کاربر داشته باشه و ویژگی های بهش اضافه می کنن که توی اون مقطع هیچ احتیاجی به اونا نیست. این اشتباه یه سری عواقب داره. پیچیدگی بیش از حد پروژه، طولانی تر شدن زمان پیاده سازی، عقب افتادن زمان تحویل پروژه و انجام تست های بیشتر از جمله اونان.به جای این کار سعی کنید به همون تسکی که دستتونه فکر کنید، نه این که این پروژه بعدها قراره به کجا برسه. وقتی که کاربرا شروع به استفاده از اپ شما کردن وقتشه که به فکر اضافه کردن ویژگی هایی باشید که باعث بهتر شدن اپتون میشه.ابزار مورد نیازتون رو پیدا کنید و به همونا بچسبینوقتی که میخواین شروع به پیاده سازی یه پروژه کنین، انتخاب مناسب ابزار خیلی نکته مهمیه. سعی کنین ابزاری رو انتخاب کنین که مطمئن و تست شده باشه و صرفا نیازی که دارین رو برطرف کنه. دقت کنین که پروژه شما قراره قابلیت هایی که ازش انتظار دارین رو برآورده کنه، پس از انتخاب ابزارایی که به دردتون نمیخوره پرهیز کنین. ممکنه حین انتخاب اونا با خودتون بگین تا وقتی که پروژم تموم بشه نسخه نهاییش ریلیز میشه پس فعلا کارمو با همینی که کامل کار نمی کنه ادامه بدم، یا بگین این ویژگیی که میخوام قطعا تا چند ماه دیگه بهش اضافه میشه. اگه این اتفاق افتاد بدونین که مسیر رو اشتباه میرین.برای انتخاب ابزار مناسب به چنتا نکته باید دقت کنین، بازه های آپدیت شدن، تعداد open issue ها و تعداد افرادی که روش کار می کنن ازین موارد هست. اصولا ابزاری که خیلی وقته کسی براش آپدیت نداده یا توسط یه نفر پیاده سازی میشه گزینه خوبی برای انتخاب نیستن.خیلی از زبونای برنامه نویسی راه های مشخصی برای قفل کردن نسخه ابزارها دارن و نسخه ای که احتمالا شما میخواین روش قفل بشه آخرین نسخه major اون هست. بعد ازین کار شاید ده ها نسخه جدیدتر ازون ابزار ریلیز بشه ولی وقتی کارتون با همون نسخه ای باهاش کار می کنین را میفته نیاز به آپدیت نیست. بنابراین وقتتون رو صرف آپدیت های بیخود نکنید و به جاش تمرکزتون رو روی پروژه بذارین.از ابزاهاتون بیشترین و بهترین استفاده رو ببریناگر از فریم ورک استفاده می کنین، قطعا راه هایی برای حل مشکلاتی که باهاشون مواجه میشین وجود داره. خیلی از راه حل هارو دیدم که میتونست خیلی راحت تر از طریق helper هایی که خود فریم ورک در اختیارمون قرار میده انجام بگیره. برای اینکه این راه حل هارو بهتر بشناسیم، قبل ازینکه شروع به انجام یه تسک کنین، حتما مشکلات احتمالی رو از documentation فریم ورک بررسی کنین. از اینکه وارد کدای فریم ورک بشین ترسی نداشته باشین. ممکنه اوایل فهمیدن اونا یه مقدار سخت باشه، ولی این کار نه تنها باعث کامل تر شدن درک شما از فریم ورک میشه بلکه با دیدن کدایی که توسط افراد باتجربه تر نوشته شده باعث افزایش مهارت شما میشه.نکته دیگه در مورد IDEییه که استفاده می کنین. مطمئن شید برای زبونی که باهاش برنامه نویسی می کنین بهترین IDE رو انتخاب کرده باشین. چون یاد گرفتن shortcutها و code snippetهاش میتونه تاثیر زیادی رو سرعت کدنویسیتون داشته باشه. حتی بهتره بعد از یه مدتی code snippetهای مخصوص به خودتون رو داشته باشین تا مواقعی که بهشون نیاز دارین به راحتی بتونین ازونا استفاده کنین.و از همه مهمتر اینه که debug کردن رو به خوبی یاد بگیرید. اینکه برای چک کردن مقدار یه متغییر اونو تو خروجی چاپ کنین یا با گذاشتن یه علامت مطمئن شین که کدتون وارد یه بلاک بخصوص میشه یا نه debug کردن نیست. اگر انجام اینکار باعث حل مشکل تو مدت کوتاهی میشه مشکل خاصی نداره ولی اگه قراره بیشتر از یه دقیقه طول بکشیه حتما از debugger استفاده کینن. با این کار میتونین مقادیر همه متغیرهاتون رو به راحتی بررسی کنین و مسیرهای احتمالیی که کدتون طی می کنه رو در نظر بگیرین.در صورتی کامنت بنویسین که حتما به دردبخور باشهکامنت به درد نخور چه کامنتیه؟ کامنتیه که هیچ اطلاعات اضافیی بهمون نمیده.مثلا اگر قرار باشه برای یه متد با اسم FetchExtractProcessData کامنت بذارین چی مینیویسین؟ اگر نوشته باشین این متد مسئول Fetch و Extract و Process کردن دیتاست، کامنت خوبی ننوشتین. چون نه تنها هیچ توضیحی نمیده حتی ممکنه بیشتر گیجمون کنه. از مثال های دیگه کامنت به دردنخور، کامنت هایی هستن که بعد از تغییر کد، آپدیت نشدن و باعث میشن اطلاعات درستی ندن. یا حتی کامنت هایی که مشکل گرامری دارن و اگه کسی اونارو بخونه هیچی ازشون نفهمه. پس یادتون باشه، اگر دارین کامنتی میذارین که بود و نبودش هیچ فرقی به حال بقیه نمی کنه بهتره اصلا ننویسینش.اگر همه کامنت هاتون پاک شه، کدتون هنوز قابل فهم هست؟ تو قسمت قبلی متدی رو مثال زدم که اسمش این بود: FetchExtractProcessDataاگر شما هم متدهاتون رو مثل این متد نامگذاری می کنین بدونین کدتون به هیچ وجه خوانا نیست. چون هیچ توضیحی در مورد علت اصلی وجود این متد و کارکرد نهاییش نمیده و صرفا چنتا فعله که پشت سر هم چیده شده. خیلی مهمه که متدها، کلاس ها و متغیرهاتون جوری نامگذاری بشن که هم بامفهوم باشن و هم کسی که اونارو میبینه با یک بار خوندنش اطلاعات خوبی نسبت بهش بدست بیاره. هیچ وقت از اختصار یا از کلمات پیچیده استفاده نکنین و به جاش سعی کنین به زبون ساده توضیحش بدین، ولی سعی کنید این اسامی از 4 یا 5 کلمه بیشتر نشن. حتما از Code Linter مخصوص به IDEتون برای مرتب و تمیز بودن کدهاتون استفاده کنین و قبل شروع کار با زبون جدید حتما الگوهای نوشتاری استاندارد مخصوص به زبونتون رو چک کنین.فرانت اند مهمتره یا بک اند؟این سوال همیشه بین برنامه نویسا بوده که کودوم سمته که کار مهمتر رو انجام میده. جواب من اینه که فرانت اند مهمتره. نیاز نیست وقتی یه پروژه رو شروع کردین نگران Caching, Performance یا Optimization بک اند باشین، چون قرار نیست از همون اول میلیون ها کاربر از اپتون استفاده کنن. خودتون به اپ هایی که هر روز باهاشون کار می کنین دقت کنین. دلیل اینکه باعث شده شما ازونا خوشتون بیاد چیه؟ این که از آخرین تکنولوژی استفاده می کنن؟ این که همه متدهاشون در بهینه ترین حالت ممکنه؟ مسلما این طور نیست. دلیلش اینه که نحوه ارائه محتوا به شکلیه که احساس خوبی بهتون میده و استفاده ازونا به هیچ وجه گیج کننده و خسته کننده نیست. البته معنی حرفم این نیست که بک اند مهم نیست. مطمئن باشید اگه فرانت به بهترین شکل خودش باشه ولی بک اند مشکل داشته باشه قطعا باعث شکست پروژه میشه.نکته ای که از همه مهم تره اینه که وقتتون رو صرف کارایی که فقط خودتون یا تعداد خیلی کمی از کاربرا ممکنه متوجهش بشن نکنین. به پروژه به عنوان یه محصول نگاه کنین، محصولی که قراره کاربرا رو جذب خودش کنه. پس از هدر دادن وقتتون روی کارایی که هیچ تاثیری توی ادامه مسیر پیشرفتتون ندارن پرهیز کنید.پیامایی که تو اپ نشون میدین برای کاربرای عادیه، نه دولوپراخیلی مهمه افرادی که قراره با اپتون کار کنن رو به خوبی بشناسین و تجربه کاربریتون، بر همین اساس طراحی بشه. جملاتی رو استفاده نکنین که فقط یه دولوپر میتونه اونارو بفهمه. جملاتی مثل "خطای سیستمی" یا "خطا در شبکه" یا حتی نشون دادن exceptionهای کدتون اصلا خوب نیستن و کاربراتون رو فراری میده. از جملات کامل، بامفهوم و ساده استفاده کنین. همین موضوع باعث میشه اونا در مقایل دیدن یه سری ازین خطاها حس بدی نگیرین و به کارشون تو اپ ادامه بدن. به عنوان مثال وقتی کاربر تو اپتون لاگین میکنه به جای نشون دادن "لاگین موفقیت آمیز" میتونین جمله ای رو نشون بدین که حس تعاملی بهتری به کاربر بده.خیلیا از خودشون میپرسن چجوری میشه برنامه نویس حرفه ای شد؟ این اتفاق نمی تونه یه شبه رخ بده. حرفه ای شدن تو انجام دادن تسک های روزانمون اتفاق میفته، تو نوع نگاهمون به حل مشکلاتی که اغلب مواقع با اونا موجه میشیم. سعی کنید وقتی یه تسکی رو انجام میدین به بهترین شکلش انجام بدین و صرفا انجام دادنش براتون مهم نباشه. برای درک بهتر این موضوع به پروژه هایی که تا حالا انجام دادین فک کنین. آیا انجام دادن اونا تو پیشرفت و رسیدن به نقطه فعلیتون تاثیر مثبت داشته؟ یا صرفا یه کار تکراری بوده مثل بقیه پروژه های قبلیتون؟ سعی کنید نکاتی که گفته شد رو حین انجام پروژه با خودتون مرور کنید تا کدزنی روز به روز براتون لذت بخش تر بشه.یادتون نره برنامه نویسی هیچ وقت نباید تکراری و عادی بشه.نسخه صوتی همین مقاله تو قسمت دوم پادکست کافه برنامه نویس وجود داره: https://anchor.fm/codemy/episodes/ep-e40a0a/a-aer03v از طریق لینک های زیر هم میتونین این پادکست رو دنبال کنید: اپل پادکستگوکل پادکستکست باکسعلی دهقانعلی دهقانSat, 15 Jun 2019 02:16:23 +0430