ToBecomeSoftwareEngineer

clean code, yes or no?? یکی از چالش هایی که کمابیش تو صنعت باهاش روبرو میشیم و از کمالگرایی نشئت میگیره، بحث over engineering هست. اصول کد نویسی تمیز هم یه چیز تجربیه که طی سالها تجربه مهندسای نرم افزار تو صنعت ایجاد شده. حالا یه جایی این کد نویسی تمیز میشه آنتی پترن یا بهتره بگم هشتاد درصد مواقع نیازی به رعایت کلین کد و این چیزا نیست. خیلی وقتا کلین کد فقط کد رو بسیار کثیف و پیچیده میکنه و عملا طی مدت زمانی توسعه کد رو غیر ممکن میکنه! پس سر این موضوع، دیزاین پترن ها، اصول معماری و ... وسواس به خرج ندید و اگر اونا رو پیاده نکردید هم عذاب وجدان نداشته باشید. اگر یه مدت دستتون تو کد باشه خواه نا خواه خودتون میدونید که چه موقع باید از اینا استفاده کنید و چه موقع خیر! اصولا تمیز کد زدن خیلی به این قوانین بستگی نداره و اگر زمانی حس کنید دارید زیاده روی میکنید بهتره که دست نگه دارید و کمتر فحش بخورید از جانب بقیه.

چرا CI/CD انقدر مهمه؟ سلام دوستان امیدوارم که حالتون خوب باشه بعد از مدتها سعی کردم که یه مطلب جدید بنویسم که البته قرار بود در مورد لایه های LSTM باشه اما اون بمونه برای بعد. شما وقتی در سازمانی به عنوان مهندس نرم افزار یا برنامه نویس استخدام میشین، روزانه تسک های زیادی رو طبیعتا انجام میدین حالا یا خود شما یا کل تیم که طبیعتا افراد زیادی درگیر میشن و مرتب یه سری فیچر ها اضافه میکنن، باگ ها رو فیکس میکنن و ادامه ماجرا.... حالا فرض کنید شما مسئول توسعه یه نرم افزار مثل بلوبانک،اسنپ یا بازارهای مالی هستید و اگر حتی یه دقیقه سیستم بیاد پایین کلی بدهی بالا میاد. و شما نمیتونید صبر کنید که سیستم بیاد بالا، یوزر سیستم رو تست کنه و باگ ها رو پیدا کنید. گذشته از اون این که یه نفر هی بخواد یه کار تکراری رو انجام بده مثل دپلوی، یا ران گرفتن تست ها و ... خواه نا خواه پرفرمنس کار به شدت میاد پایین.. حالا CI CD میاد که این مشکلات رو حل کنه. وقتی شما یه تیکه کد رو میزنین، این تیکه کد باید بره با کدبیس اصلی ادغام شه و اگر همه چی اوکی بود، در نهایت دیپلوی شه روی محیط پروداکشن. در حالت عادی دستی انجام دادن این کار دیگه منسوخ شده حتی در سازمان های کوچیک چون هزینه داره و خطای بسیار بالای انسان رو هم نمیشه نا دیده گرفت و نتیجه این کار رو ممکنه در یه سری نرم افزار ها دیده باشین که سیستم میاد بالا ولی پر از باگه. دلیل این کار اینه که سیستم ما در محیط دولپمنت و پروداکشن گاها رفتارهای متفاوتی رو از خودش نشون میده و این یه چیز کاملا بدیهیه. با ساخت pipeline CI/CD، ما میایم این مشکل رو برطرف میکنیم. یعنی یه سری کارای تکراری که از قضا کارهای فانی هم نیستن رو اتوماتیک میکنیم. تو این کار ما از ابزارهای زیادی میتونیم استفاده کنیم. یکی از ابزارهای کار راه بنداز github action هست.

وقتی که ما پایپلاین رو میسازیم، یه سری تسک ها پشت سر هم ران میشن. اصلی ترینشون این سه تا هستن: 1.build 2.test 3.deploy حالا فرض ما اینه که یه پروژه به زبان پایتون بالا میاریم ( چون شما ماشین لرنینگ دوست دارید فرض کنید که یه API پردازش تصویر هست😁) این پروژه رو ما قصد داریم که با داکر بالا بیاریمش. طبیعتا وقتی که یه کامیت انجام میشه قدم اول اینه که ما پروژه رو بیلد کنیم ببینیم چی میگه. با داکر بیلد میکنیم و کلی چیز ممکنه که بخوایم لحاظ کنیم موقع بیلد، اولینش ورژن پایتونه. بعد از این که پروژه بیلد شد نوبت میرسه به تست که آقا این مدل ما تحت فشاره تو پروداکشن. معلوم نیست که چی به خوردش میدن حالا اگر یه چیز بد رو به خوردش بدن مسموم میشه و میره تو کما. دوستان این بخش تست خیلی خیلی خیلی خیلی مهمه و استرس اصلی روی همین بخشه. باید کلی سناریو بچینید و سیستم رو تست کنید و تست ها موقع کامیت به شکل اتوماتیک اجرا شن. مرحله سوم اگر که اوضاع بر وفق مراد بود و کم و کسری اتفاق نیفتاد به شکل خود کار روی سرور ریموت میره و میشینه البته گاهی اوقات ممکنه ما بخوایم ایمیج داکر رو بذاریم روی داکر هاب. در کل فرایند توسعه این اتفاق به شکل مکرر رخ میده و هر جا ایرادی وجود داشت توسط برنامه نویس بر طرف میشه. این بود یه معرفی کلی از CI/CD و وضعیت پایپلاین شما بسته به پروژه و سازمان میتونه خیلی متفاوت تر باشه و کارهای بسیار بیشتری رو ساپورت کنه

موضوع بعدی درباره لایه های LSTM هست

MLOps for research همونطور که میدونید رویکرد MLOps به تبدیل الگوریتم های ماشین لرنینگ به نرم افزار های مقیاس پذیر میپردازه. یه سوالی که پیش میاد اینه که به عنوان یه محقق نیازه MLOps بلد باشیم یا خیر؟ بله، به عنوان یه محقق شما باید به برخی از مفاهیم MLOps تسلط داشته باشید در واقع شاید تفاوت شما با یه مهندس یادگیری ماشین در بحث دیپلوی باشه و لاغیر. وقتی صحبت از ریسرچ میشه و مقاله ای میخواد عملی شه، با دیتای زیادی سر و کار داریم پس نیازه مباحث مربوط به MLOps رو بدونیم چون صرفا دیتای ما با تکنیک های معمولی نمیتونه پردازش شه پس باید یه زیرساخت قدرتمند هم ساخته شه طبیعتا.

و اما این کلیپ به نظر من این حرف که باید همه فول استک باشن اشتباه محضه و تریک جدید برای بیگاری گرفتن از نیروهاست👎👎 رو یه زمینه تمرکز کنید ولی از بقیه زمینه ها هم بدونید.

تا چه حد با حرفای ایشون موافقین؟

حقیقت... تلخ یا شیرین؟! ۱.پیج های اینستاگرامی درباره برنامه نویسی در بیشتر مواقع چرت و پرت میگن. پس بهشون گوش نکنید. ۲. هوش مصنوعی هیچوقت جای برنامه نویس رو نمیگیره فقط شیوه و نوع کار برنامه نویس رو تغییر میده. ۳. لزوما نیاز نیست برای یاد گرفتن پول پرداخت کنید. اکثر آموزش ها در یوتیوب به شکل رایگان قرار داره. ۴. به عنوان شخصی که در حوزه نرم افزار کار میکنه باید دائم در حال یادگیری باشید. اگر حس کردید مدت زیادیه چیز جدیدی یاد نگرفتید این یعنی شما منسوخ شدید و میذارنتون تو موزه :) ۵. دربرار تغییر مثبت مقاوم نباشید. چون دائما در حال تغییر هستید و خودتون خبر ندارید. ۶. گرفتن مدرک از کورسرا برای اکثر دوره ها فایده آنچنانی برای استخدام نداره پس الکی جوش نزنید. ۷. هر کسی گفت شما در مدت ۶ ماه برنامه نویس میشید رو در جا بلاک کنید. اون شخص کلاهبرداره. ۸. به عنوان برنامه نویس با افراد احمق زیادی روبرو میشید. تنها راه مقابله بلاک کردن هست و دیگر هیچ... سعی نکنید با بحث منطقی قانعشون کنید. ۹. اون چرت و پرتایی که باب شده درباره برنامه نویس ها ( سبک زندگی ناسالم، فست فود، سیگار و قهوه و ...) همه از دم بیخوده. شما به عنوان برنامه نویس هیچ فرد خاصی نیستید که خودتون رو خاص بدونید و لازم به ذکره که شاخ غول رو هم نشکستید :) مثل قشر معمولی جامعه زندگی میکنید و هیچ ادا اطوار خاصی هم ندارید. پس انقدر جوگیر نباشید. ۱۰. دست بالای دست زیاده. سعی کنید به جای یادگرفتن چیزایی که همه میدونن، چیزاییو یاد بگیرید که کمتر کسی میدونه.