Python BackendHub – Telegram
Python BackendHub
7.51K subscribers
314 photos
46 videos
11 files
432 links
Learning python & Backend Engineering, with Mani!

Youtube: https://www.youtube.com/@GitOverHere
Github: https://github.com/ManiMozaffar
Linkedin: https://www.linkedin.com/in/manimozaffar

تبلیغات نداریم

Admin: @Mani_nikou
Download Telegram
Forwarded from Python BackendHub
اوایل که مصاحبه میرفتم همون اولین مصاحبه رد میشدم,
اما الان تقریبا هروقت مصاحبه میگیرم میرسم به coding challenge یا technical interview
تکنیک هایی که این مدت به کار بردم و جواب داده رو خواستم تو این پست بنویسم تا استفاده کنید:


اولین چیزی که مطرح میشه اینه که شما خودتونو معرفی کنید, تو این مرحله یک summary خلاصه از خودتون بگین و فعلا وارد جزییات نشین.

مهم ترین موضوع اینه که شما به اون شرکت علاقه نشون بدید. این موضوع به قدری مهمه که حتی اگه ممکنه کاندید بهتر از شما باشه ولی شما رو انتخاب کنند چون باعث میشه که فکر کنند شما متعهد تر هستین به اون شرکت تا اون فرد. این علاقه نشون دادن با سوال تخصصی تو اون فیلد میشه نشون داد. بهترین کار هم اینه که سایت شرکت رو دربیارین, اطلاعاتش رو بخونید و بعدش به chatgpt اون اطلاعات رو بدین و بهش بگین که چند تا سوال براتون طراحی کنه که هم یکم چالشی باشه و هم نشون بده که کاملا interested بودین.

اما کی باید این سوالات رو بپرسین؟ معمولا interviewer از شما میخواد که اول به حرفاش گوش بدین و معمولا یک introduction ای از شرکت خودشون و چالش هاش به شما میگه. بعد از شما میپرسه که آیا سوالی دارین یا نه, و بدترین جواب اینه که بگین نه ندارم. همینجاست که سوالاتی که حاضر کرده بودین, باید بپرسین و سعی کنید هم چند سوال راجب توضیحاتی که خودش داده اول بپرسین, حتی اگه کامل فهمیده بودین!


طرفی که باهاش مصاحبه میکنید رو بسنجید و سعی کنید که درجه صحبتتون بر اساس سطح technical اون آدم منطبق کنید. مثلا تو یک مصاحبه خود HR سابقه کد زنی داشت و من تونستم خیلی فنی تر حرف بزنم که تجربه خیلی خوبی برای جفتمون بود. اما اگه همینکارو با HR کنم که old fashion تره, قطعا یک red flag خواهد بود. سطح فنی اش رو از توضیحاتی که راجب شرکتشون میده میتونید ارزیابی کنید.

حالا نیمی از interview گذشته و فقط راجب شرکت حرف زده شده, احتمالا interview از شما بخواد که بک گراند بیشتری راجب خودتون بدین. حالا شما باید به نحوی مهارتتون رو بفروشید, مثلا به هر نحوی شده سعی کنید پروداکت هایی که تا امروز روش کار کردین به پروداکت این شرکت لینک کنید. حتی اگه دروغ بگین یا بزرگ نمایی کنید ایرادی نداره, فقط دروغ فنی نگین یا بزرگ نمایی از خودتون نکنید. مثلا ممکنه تو یک business domain ای اصلا کار نکرده باشین, مثل B2B. ولی اگه شب قبل حسابی راجبش بخونید میتونید ادعا کنید که اره فلان جای پروداکتمون B2B بود و من کمی درگیرش شدم. سعی کنید اگه تو این موارد دروغ میگین, خیلی خوب و متواضعانه دروغ بگین!

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


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


@ManiFoldsPython
👍14
راجب اصول تست نویسی, یک مقاله پیدا کردم, میخوندمش مفید و کلی بود
به عنوان یک software engineer حداقل باید با مفاهیم اشنا باشین که وقتی با کلمه های زیر خوردین فکر نکنید چیز خیلی عجیب و فضایی هستند. نمیگم بلدشون باشید ولی باید بدونید چی هستند. دونستن این موارد کمک میکنه بهتون که به عنوان یک SE بهتر کد بنویسید و بهتر تست بنویسید.

- Testing Strategy
- Test policy
- Test scenario & Test case
- Software requirements, and requirements review
- Types of automated testing (A/B, smoke, unit, integration, e2e, exploratory, stress, load, perfomance, regression, cross-device, crowss-browser, acceptance, black box, Operational acceptance, conctract acceptance)
- Types of manual testing (exploratory testing, ad hoc testing)
- Software quality indicators
- Test Metrics


لینک مقاله:
https://www.altexsoft.com/blog/engineering/software-testing-qa-best-practices/


@ManiFoldsPython
👍12
یک تمرین میذارم که انجام بدیم, بعدش ویدیو میگیرم و خودم دقیقا همینکارو میکنم, از اون تمرین هاست که ظاهرش به شدت راحته ولی باطن به شدت سخت.

وقتی شما تو یک شرکت خوب کار کنید اولین چیزی که باهاش مواجه میشین strict code review هست.
یکی کدتون رو به حدی review میکنه که مجبور میشین ۴-۵ بار تغییرش بدید تا کد مرج شه.
خیلیم ربطی به level برنامه نویسی نداره هر انسانی موقع نوشتن کد قطعا یک سری خطایی میکنه که هدف code review کم کردن اون احتمال اون خطاست.

پی نوشت:‌عکس نشون میده چرا code review و pair programming میتونه مفید باشه
@ManiFoldsPython
👍4
اولین کد, مدل دیتابیس
ایرادات این کد رو پیدا کنید و کامنت کنید 👀

با sqlalchemy نوشته شده...
این مدل قراره فایل های آپلود شده رو تو دیتابیس مسیرشو ذخیره کنه و بگه از چه source ای اومدن (مثلا سورس فایل آپلود شده چی بوده) و کی آپلودش کرده

@ManiFoldsPython
دومین تیکه کد
داره یک سری فایل میگیره
و ذخیرش میکنه تو سیستم
کانتنت تایپشونو چک میکنه

و ارور raise میکنه اگه مشکلی داشت

مشکل این کد؟ (حداقل ۱۰-۱۵ تا مشکل داره این تیکه کد)

@ManiFoldsPython
👍1
تیکه اخر کد
قسمت روتر

@ManiFoldsPython
Media is too big
VIEW IN TELEGRAM
تو این ویدیو پرداختم به نحوه code review و clean code
یک کد FastAPI که خوب نبود و نیاز به ریفکتور اساسی داشت رو باهم ریفکتور کردیم و توضیح دادم دقیقا چرا ریفکتور کردم و چرا نسخه ریفکتور شده بهتره

خود کد رو از این ریپو میتونید ببینید
https://github.com/ManiMozaffar/dirty-code

نکته:‌ آخر ویدیو یادم رفت که database model رو داخل دیتابیس add کنم. داخل کد کمی تغییر دادم که این موضوع رعایت شده.


™️ @DjangoIR

© @DjangoEx |
© @ManiFoldsPython
11👍4
Python BackendHub
پستا سمت چه تایپیکی بیشتر باشه بنظرتون؟
من سعی کردم وزن پست های کانال رو طبق این نظر سنجی قرار بدم
بیشتر مشکل رو متدولوژی و اصول توسعه نرم افزار و تست نویسی بود..
سعی کردم به صورت مقاله یا پست طور توضیح بدم این موارد رو, ولی اینکه بخوام تو یک ویدیو توضیح بدم شاید کمی سخت تر باشه. چون این موارد تو پروژه واقعی منطقی ترن تا یک پروژه سمپلی که میزنیم..

بنظرتون, چطور میتونم محتوا تولید کنم تو این زمینه؟ مخصوصا تست نویسی🤔اگه ایده ای دارید خوشحال میشم کامنت کنید

پ.ن: سری ویدیو ریفکتور و code review رو ادامه میدم سعی میکنم ویدیو های بعدی کوتاه تر شه که بتونیم نحوه نوشتن کد maintainable رو باهم تمرین کنیم.

@ManiFoldsPython
👍113
Python BackendHub
تو این ویدیو پرداختم به نحوه code review و clean code یک کد FastAPI که خوب نبود و نیاز به ریفکتور اساسی داشت رو باهم ریفکتور کردیم و توضیح دادم دقیقا چرا ریفکتور کردم و چرا نسخه ریفکتور شده بهتره خود کد رو از این ریپو میتونید ببینید https://github.com/Ma…
یک نکته ای داخل این ویدیو بود که نتونستم توی ویدیو بگم چون خیلی طولانی میشد و ربط مستقیم به تایتل ویدیو هم نداشت.. به عنوان یک برنامه نویس باید بفهمید چیکار دارین میکنید.

نظر شخصیم اینه که این مهم ترین اصل برنامه نویسیه. هر کدی که شما مینویسید باید بفهمید که دلیلش چی بوده؟ چرا اینکارو کردین؟ نکته ای که من متوجه شدم اینه که خیلی از دوستان واقعا دلایلی برای کاری که میکنند ندارن... . یعنی یک reasoning ای همیشه داشته باشید حتی به غلط. چون بالاخره هممون اشتباه میکنیم دیگه.. ولی باید بدونیم داشتیم چیکار میکردیم!

مثال میگم, کسی که کتاب two scopes django رو خونده باشه اونجا نویسنده میگه که تو جنگو تمام assert ها رد میشن موقعی که دیباگ رو false میذارین. دلیلش چیه؟ دلیلش اینه که شما وقتی پایتون رو آپتیمایز ران میکنید (و خود پایتونم از حالت دیباگ خارج میشه که با داندر دیباگ میتونید ببینید) یکی از کار هایی که میکنه تمام assertion هارو ایگنور میکنه. پس شما وقتی two scopes رو دارید میخونید باید بعد اون جمله ای که نوشته یک چرا بذارید و گوگلش کنید. چرا اینکارو میکردن؟‌ قطعا یک دلیلی دارن دیگه... جنگو core دولوپر ها که الکی کدی وارد جنگو نمیکنن... عمق اطلاعاتتون هم در همین راستا زیاد میشه.

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

مثال دیگه وقتی شما مینویسی router.post باید بدونید داره چه اتفاقی میفته. اینکه میاین validation حجم باینری فایل input رو توی خود روتر مینویسید یعنی عمق سواد HTTP نداشتین.
مثال دیگه اینکه داریم کد رو decouple میکنیم که reusable شه باید بدونید چرا داریم اینکارو میکنیم. برنامه نویسی جغرافی نیست. من دیدم بعضیا میگن چون فلان کتاب یا فلان شخص گفته, دنبال راه حل اونا نباشید تو مرحله اول شما باید صورت سوال رو درک کنید تا بعد بتونید راه حل اونا رو درک کنید.

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

@ManiFoldsPython
👍16🔥4
Python BackendHub
وقتی میگفتم این هفته فقط باید تست بنویسم و ‍code review تست بکنم شوخی نمیکردم :)) کانتربیوت امروز گیتهابمه پی نوشت: اون ۴ تا review ای که کردم هم unit test بوده رو یک ریپو دیگه @ManiFoldsPython
بعضیا پرسیدن من چطوری مثلا تست نویسی رو یاد گرفتم, مثلا چه کتاب خاصی خوندم یا چه دوره ای دیدم..

بنظره من کلا اشتباهه که شما ۱ کتاب بخونی و بعد بگی اوکی من یاد گرفتم. چون اون کتابو یک انسان نوشته, و ذهنیت اون انسان پشت اون کتاب بوده. برای همین من شخصا ترجیح میدم تو همچین چیزایی برای اینکه ذهنم bias نشه به جاش ۳۰-۴۰ تا article بخونم که کار همون یک کتاب رو میکنه برای من ولی از دید ۳۰-۴۰ نفره مختلف..

امروز ۲ تا آرتیکل خوندم براتون میذارم اینجا راجب تست نویسیه

اولیش راجب اینه که always assert the failing test first توی یونیت تستاتون. خیلی وقتا assertion ای که میذارین شما برای حل یک چیزی (مثلا میگین فلان چیز خرابه)‌اشتباهه. در صورتی که assertion شما اشتباهه و دلیل باگ اون چیزی که شما فکر میکردی نیست و طبق همین assertion جلو میرین و کد رو تغییر میدین. تغییراتی که دادین کلا وقتتون رو هدر دادین و حالا احتمالا باگ جدید هم درست کردید. پس به جای سرو کله زدن با یک باگ باید با ۲ باگ سرو کله بزنید. برای همین تو اولین قدم سعی کنید تستی بنویسید که اون خطا رو reproduce میکنه تو مینیمال ترین حالت ممکن. (دقیقا ‍unit ای که fail میشه باید براش تست بنویسید). اینطوری خیلیی راحت دیباگش میکنید و یک چهارم وقتتون گرفته میشه.
اینجا خیلی کامل توضیح داده
https://canro91.github.io/2021/02/05/FailingTest/

نکته دوم راجب confidence بود تو تست نویسی. تستی که مینویسیم واقعا چقدر اطمینان میده به ما که محصولمون کار میکنه؟ چقدر ارزش داره؟ این مقاله راجب همینه
https://meeshkan.com/blog/defining-confidence-in-software-testing/

@ManiFoldsPython
👍7
داشتم یک سر به لیست سابسکرایبم میزدم که تلسکو رو دیدم :))
اولین توتوریال پایتونیم رو با تلسکو دیدم واقعا یکی از بهترین معلم هایی که دیدم. تو هر ویدیوش ۱۰ بار خطا میکرد و بعد دیباگش میکرد.

@ManiFoldsPython
10😁6👍4
صبح obs ریختم که ریکورد های بعدیو با obs بکنم

نتیجش این شد که رفتم تو میتینگ daily standup و تبدیل شدم به mr invisible 😎

۲۰ دقیقست دارم بالا پایینش میکنم ولی درست نمیشه :))‌ کسی راهکاری داره براش؟

پ.ن:‌اپو بستم ... درست نمیشه
@ManiFoldsPython
🤣16
این پست راجب SDLC هست, یک مقاله عالی راجب Gherkin
لینک

What is Gherkin Language?
Gherkin is a business readable language which helps you to describe business behavior without going into details of implementation. It is a domain specific language for defining tests in Cucumber format for specifications. It uses plain language to describe use cases and allows users to remove logic details from behavior tests.

Gherkin Syntax
Gherkin is line-oriented language just like YAML and Python. Each line called step and starts with keyword and end of the terminals with a stop. Tab or space are used for the indentation. In this noscript, a comment can be added anywhere you want, but it should start with a # sign

توصیه میکنم اولین کاری که باید انجام بدید موقع ساخت یک Software اینه که یک فرد غیر فنی بیاد و با Gherkin Syntax دقیقا داکیومنت کنه چی میخواد از تیم سافتور. یادگیریش یک روز هم زمان نمیبره. صرفا یک language هست برای توصیف محصول. اون موقع دیگه تیم دولوپر انرژی خیلی کمتری میذاره رو فهم بیزنس و خیلی راحت تر متوجه میشه و دیزاینی که میشه هم دقیقا متناسب با همون بیزنس و فیچر ها خواهد بود.

@ManiFoldsPython
👍4🤯3
کیفیت کد خوب با این metric ها سنجیده میشه:
Reusability
Readability
Testability
Flexibility
Mature Tests

کتاب x و روش y همه راه حل برای حل این مشکلاتن. کدی که این ۵ مورد توش رعایت شده اصلا مهم نیست که OOP بوده یا نه. مهم نیست SOLID بوده یا نه. مهم نیست TDD بوده یا نه.
خلاصه TDD اینه که به شما داره میگه کدتون باید Testability بالایی داشته باشه و overengineer نکنید و اول <فکر>‌کنید بعد <دیزاین>‌کنید و بعد کد بزنید (برای اینکه اول تست بنویسید دقیقا باید این مسیر طی شه) ولی آیا تنها روش رسیدن به اینا TDD هست؟ قطعا نه. یک راه حل خوبه. برای یک سواله خوب که معایب خودشو هم داره. پس همیشه به جای دنبال کردن کورکورانه یک methodology فکر کنید ببینید چی داره به شما میده و چی از شما میگیره

@ManiFoldsPython
👍7
https://www.youtube.com/watch?v=udrvnKiQHsA

ویدیو دوم هم آپلود شد. همون ویدیو لایو بود که ظبط کردیم. خوشبختانه فیچر chapter ساختن هم باز شد برام تو یوتیوب

سورس کد دوره لایو چلنج
https://github.com/ManiMozaffar/fast-student

لینک توضیحات خود تمرین و چیزایی که تو تسک خواسته شده بود ازتون
- توضیح لایو کد چنلج

@ManiFoldsPython
7👍1
امروز پلی لیست بعدی رو شروع میکنم
سعی میکنم ۲ ویدیو ضبط کنم

ویدیو اول: DI و DIP
ویدیو دوم:‌ یونیت تست و ماک گرفتن


دوستان برای پلی لیست ریفکتورینگ اگه کدی چیزی دارید که در حد ۲۰۰ خط نوشته شده خیلی ممنون میشم باهام به اشتراک بگذاریدش که بتونم ریفکتورش کنم و ظبطش کنم که اون پلی لیست هم ادامه داشته باشه. سه چهار ریپو کد نیاز دارم. اگه داشتین کامنت کنید تو همین پست که من اضافش کنم به لیستم

@ManiFoldsPython
👍8🔥64