چه‌طور تو برنامه‌نویسی حرفه‌ای‌تر بشیم؟ (سری ۶)

در سری «برنامه‌نویسی حرفه‌ای‌تر»، در هر قسمت با تمرکز روی یک موضوع خاص، به مفاهیم مهم و کاربردی برنامه‌نویسی به صورت خلاصه و مفید می‌پردازم.
در این سری...

🔗 ساخت فانکشن abstract، در Enumها

🔗 قابلیت خفن کاتلین در مقداردهی به Enumها

🔗 چرا بهتره با Enum به شکل Exhaustive برخورد کنیم؟

🔗 چه زمانی و برای چی بهتره Enum بسازیم؟

🔗 کجا باید از Sealed Class استفاده کنیم و کاربردش چیه؟

🔗 تفاوت Sealed Class ها با Enum ها چیه؟ به چه دردی می‌خورن؟

🔗 یک ریفکتور مهم در استفاده از Enum ها

🔗 چند روش نوشتن when که باید بلد باشید

این ویدئوها رو در این Playlist یوتیوب هم می‌تونید ببینید و دنبال کنید.

دمتون گرم و خفن باشید،
@AdibCodes

حرفه‌ای شدن در برنامه‌نویسی، ریفکتور و دیباگینگ، با قابلیت‌های خفن IntelliJ، اندروید استودیو و دوستان

در سری «برنامه‌نویسی حرفه‌ای‌تر»، در هر قسمت با تمرکز روی یک موضوع خاص، به مفاهیم مهم و کاربردی برنامه‌نویسی به صورت خلاصه و مفید می‌پردازم.

در سری هفتم...

🔗 پرواز در IntelliJ و بقیه با قابلیت Postfix Completion

🔗 پرانتزگذاری حرفه‌ای در IntelliJ IDEA و اندروید استودیو و...

🔗 دیزاین پترن Factory Method رو یاد بگیریم

🔗 شورت‌کات حرفه‌ای برگشت به آخرین تغییر رو یاد بگیریم

🔗 ریفکتور سریع یک تکه کد به فایل جدید رو یاد بگیریم

🔗 دیباگ حرفه‌ای در IntelliJ و دوستان رو یاد بگیریم

🔗 ریفکتور بیرون کشیدن فانکشن از کد رو با IntelliJ و دوستان یاد بگیریم

🔗 ریفکتور فانکشن با پارامترهای زیاد در IntelliJ و دوستان رو یاد بگیریم

این ویدئوها رو در این Playlist یوتیوب هم می‌تونید ببینید و دنبال کنید.

دمتون گرم و خفن باشید،
@AdibCodes

🎬 آیا فرگمنت، بدترین لایبرری در اندروید بود؟

توی این ویدئو سراغ رده‌بندی لایبرری‌های معروف UI در دنیای اندروید رفتم — از روزهای اول تا امروز.
با هم بررسی می‌کنیم چرا ساخته شدن، چه تأثیری داشتن، و چطور مسیر ساخت UI رو تشکیل دادن.

از لایبرری‌های نوستالژیکی مثل Butterknife گرفته تا نسل‌های جدیدتر مثل کامپوز.

البته این وسط، نگاهی می‌کنم به یکی از بدترین تصمیمات گوگل در طراحی معماری اندروید 🙂

🎥 لینک تماشا:
https://youtube.com/watch?v=ThD8h_wBOrI


اگر از این ویدئو خوشتون اومد ممنون می‌شم به اشتراکش بگذراید که به دست بقیه هم برسه.

دمتون گرم،
@AdibCodes

🎬 رده‌بندی لایبرری‌های نتوورک در اندروید

توی این ویدئو که قسمت دوم از رده‌بندی لایبرری‌های اندروید هست رفتم سراغش لایبرری‌های نتوورک؛ شامل لایبرری‌های کلاینت نتوورک، مبدل‌های JSON و ابزارهایی که این فرآیند رو راحت می‌کنن.


از مواردی مثل AsyncTaskهای +!#$ که توسعه‌دهندگان اندروید رو بدبخت کردن گرفته تا زیباترین ساخته‌های بشر در اندروید، مثل OkHttp و رتروفیت.


🎥 لینک تماشا:
https://youtu.be/FeSe-By1_fA

اگر از این ویدئو هم خوشتون اومد ممنون می‌شم به اشتراکش بگذراید که به دست بقیه هم برسه.



دمتون گرم،
@AdibCodes

یادگیری فوت و فن‌های ادیتورهای IntelliJ، اندروید استودیو و ...

در سری قبل - قسمت هفتم از
«برنامه‌نویسی حرفه‌ای‌تر»- سراغ فوت و فن‌های IDE رفتم و با توجه به استقبال‌تون از این موضوع، این ویدئو‌های کوتاه رو ادامه دادم. در سری هشتم...

🔗 دیباگ حرفه‌ای با Evaluate Expression

🔗 ریفکتور ساختن اتوماتیک پارامترها در فانکشن

🔗 ریفکتور خفن Change Signature

🔗 سرچ حرفه‌ای

🔗 سرچ حرفه‌ای و سریع کلاس‌ها، فیلد‌ها و فانکشن‌ها

🔗 ادیت و جابه‌جایی حرفه‌ای کد

🔗 سلکت سریع کد

🔗 قابلیت فوق‌العاده Scratch Files و نحوه استفاده ازش

🔗 کار کردن با چند زبان در یک فایل با قابلیت Inject Language

🔗 قابلیت پراستفاده Clipboard History

این ویدئوها رو در این Playlist یوتیوب هم می‌تونید ببینید و دنبال کنید.

دمتون گرم و خفن باشید،
@AdibCodes

🎬 رده‌بندی لایبرری‌های Dependency Injection در اندروید

توی این ویدئو که قسمت سوم از رده‌بندی لایبرری‌های اندروید هست می‌رم سراغ دی‌آی‌ها؛ از تاریخچه‌شون گرفته تا چه نکات مثبت و منفی‌ای دارن.

از لایبرری‌های قدیمی مثل Guice شروع می‌کنیم، نگاهی به تکامل Dagger می‌اندازیم و در انتها می‌رسیم به Koin و Hilt.


🎥 لینک تماشا:
https://www.youtube.com/watch?v=XVUBSd5KbUY


دمتون گرم،
@AdibCodes

چه‌طور تو برنامه‌نویسی حرفه‌ای‌تر بشیم؟

در سری «برنامه‌نویسی حرفه‌ای‌تر»، در هر قسمت با تمرکز روی یک موضوع خاص، به مفاهیم مهم و کاربردی برنامه‌نویسی به صورت خلاصه و مفید می‌پردازم.
در سری نهم...

🔗 دیف گرفتن حرفه‌ای و سریع در IntelliJ

🔗 ریفکتور Extract Constant در IntelliJ

🔗 شورت‌کات حرفه‌ای Surround With

🔗 آرامش موقع کد زدن؟ قابلیت Distraction-free Mode در IntelliJ

🔗 یک پلاگین عالی در IntelliJ برای یادگیری شورت‌کات‌ها

🔗 قابلیت حرفه‌ای IntelliJ برای مشاهده بایت‌کد کاتلین و تبدیل به جاوا

این ویدئوها رو در این Playlist یوتیوب هم می‌تونید ببینید و دنبال کنید.

دمتون گرم و خفن باشید،
@AdibCodes

کاتلین ورژن 2.3.0 منتشر شد

در این نسخه:
- بهبودهای جدید در زبان و پایدار شدن برخی قابلیت‌ها

- پشتیبانی از Java 25 در JVM
- بهبودهای Kotlin/Native، Kotlin/Wasm و Kotlin/JS

- سازگاری با Gradle 9.0
- به‌روزرسانی‌هایی در کتابخانه استاندارد

بیشتر بخوانید:
https://blog.jetbrains.com/kotlin/2025/12/kotlin-2-3-0-released/

@AdibCodes

🔥 قابلیت Explicit Backing Fields در کاتلین ۲.۳

یکی از مهم‌ترین تغییرات نسخه‌ی جدید کاتلین که در پست قبلی معرفی شد، قابلیت Explicit backing fields هست که در این پست بهش می‌پردازم.

یکی از نکات کاتلین‌ (و بسیاری از زبان‌ها) این بود که افراد وقتی یک فیلدی رو تعریف می‌کردن،‌ فرض کنید یک MutableList، و می‌خواستن افرادی که خارج از این کلاس به این فیلد دسترسی پیدا می‌کنن، اون رو به شکل Mutable نبینن و صرفاً یک List رو ببین که بتونن بخوننش.
اغلباً کاری که انجام می‌شد، تعریف یک فیلد private با تایپ اصلی و یک فیلد public با تایپ کمتر‌تغییرپذیر بود. در واقع یک «backing field» به شکل دستی نوشته می‌شد.

به طور مثال:

private val _names = MutableList<String>()
val names: List<String> get() = _names

این موضوع مختص لیست‌ها نیست و در انواع کلاس‌هایی که چندین پیاده‌سازی دارند (مثل Flow‌ و SharedFlow) هم وجود داشت و چنین Duplicationهایی رو به وجود می‌آورد؛ علاوه بر نیاز به نامگذاری‌های متفاوت برای این فیلد‌ها.

کاتلینِ جدید راهکارش برای این موضوع ساده‌ست و توسطش می‌تونین این backing fieldها رو به صراحت تعریف کنید و براشون پشت و رویی متفاوت داشته باشید.

val names: StateFlow<String>
    field = MutableStateFlow("")

خوبی این قابلیت اینه که شما لازم نیست نام‌گذاری متفاوتی برای این فیلد‌ها داشته باشید و خوانایی بالاتری هم داره.
این موضوع بسیار شبیه به تفاوت visibility در getter و setterهای فیلد‌هاست، اما با این تفاوت که این تغییر رو در تایپ فیلدها اعمال می‌کنه.

زبان‌های بسیار کمی هستن که چنین قابلیتی رو پشتیبانی می‌کنن، و کاتلین هم به دسته‌ی اون‌ها پیوست.
این قابلیت در حال حاضر در حالت آزمایشی هست و نیازه توسط یک آرگومان کامپایر (که در پست بالا هست) فعالش کنید.

موفق باشید،
@AdibCodes

با هم Regex رو اصولی یاد بگیریم 💡

رجکس یک ابزار فوق‌العاده برای جستجو و پردازش متن‌هاست. در کنار باطنی قدرتمند،‌ ظاهرش به نظر حفظی و شاید در نگاه اول سخت باشه و در این سری «برنامه‌نویسی حرفه‌ای‌تر»، با هر ویدئوی کوتاه به یادگیری یک مفهوم مهم و کاربردی رجکس می‌پردازم، که با زبانی ساده یادش بگیریم، الگوهای مختلف باهاش بسازیم و هروقت الگویی ازش رو دیدیم، بتونیم بفهمیم دقیقاً چه‌کاری انجام می‌ده.

🔗 چه‌طور regex رو اصولی یاد بگیریم؟

🔗 کاراکتر نقطه (.) در regex

🔗 کاراکتر کلیدی * در regex

🔗 پیدا کردن اعداد با regex

🔗 چه طور به سادگی «کلمات» رو با regex پیدا کنیم

🔗 کاراکتر علامت سوال تو regex چیکار می‌کنه؟

🔗 چه‌طور در regex دنبال کلمات بگردیم

🔗 چه‌طور در regex بشماریم؟

🔗 چه‌طور در regex به راحتی موارد رو OR کنیم؟

🔗 چه‌طور با رجکس از «جای» چیزها مطمئن بشیم؟

🔗 فرار کردن از کارهای دیفالت در regex

🔗 چه طور نذاریم regex حریص باشه؟

🔗 تمرین regex: ایمیل‌ها رو در بیاریم!

این ویدئوها رو در این Playlist رجکس من در یوتیوب هم می‌تونید ببینید و دنبال کنید.

دمتون گرم و خفن باشید،
@AdibCodes

ادیب (هنوز) کدز؟ 🤔

بله! به نظر می‌رسه با اینکه چند ماه از آخرین ویدئوهام می‌گذره و در این مدت خبری نبود، هنوز کامل توسط ای‌آی جایگزین نشدم! 😅
--
سلام دوستان. امیدوارم تو این چند ماهی که نبودم، حال دلتون خوب بوده باشه و سلامت باشید.

همون‌طور که می‌دونید تو این مدت خبرها و مشغله‌های زیادی در ایران برای همه‌مون وجود داشت (و دارن). از یک طرف جنگ، چالش‌ها و قطعی/کندی اینترنت، و از طرف دیگه تغییر اولویت‌های شخصی برای من باعث شد این چند ماه کمتر بتونم روی ساختن ویدئوها و همچنین مطالب این کانال وقت بذارم.

اما خبر خوب اینکه من همچنان قصد دارم روی ارائه محتوا به زبان فارسی در زمینه برنامه‌نویسی زمان بگذارم، چون هنوز فکر می‌کنم فضای خالی زیادی برای این موضوع وجود داره. به همین خاطر از این به بعد سعی می‌کنم اول فعالیتم رو توی همین کانال تلگرام بیشتر کنم، و بعد از یه مدت ویدئوها رو هم از سر بگیرم! ✌️

چیزهای زیادی هست که در موردشون حرف بزنیم؛ از استفاده مناسب از ای‌آی، Harnessها و ابزارهاش برای خفن‌تر شدن در برنامه‌نویسی، تا سیستم‌دیزاین، آماده‌شدن برای مصاحبه‌ها، و البته مطالب همیشگی‌مون: کاتلین، جاوا، معماری و نکات ریز و درشت برنامه‌نویسی.


دم همه‌تون گرم که این مدت همراه بودید ❤️
@AdibCodes

⚠️ آیا rtk واقعاً مصرف توکن رو ۹۰٪ کاهش می‌ده؟ (جواب کوتاه: نه خیر، حتی زیاد هم می‌کنه!)

تیم جت‌برینز در قسمت دوم تحقیقاتش برای ابزار‌های ای‌آی (دفعه قبل روی caveman این کار رو انجام دادن) سراغ rtk (راست توکن کیلر!) رفته؛ ابزاری که ادعا می‌کنه با فشرده‌سازی خروجی دستورات، مصرف توکن ایجنت‌ها رو تا ۹۰٪ کم می‌کنه.

نتیجه‌ی تستشون برعکس چیزی که ادعا شده بود دراومد. میزان مصرف توکن‌ها کم که نشد هیچ، در بعضی جاها حدود ۷٪ حتی بیشتر هم شد.

▫️ عکس اول: چقدر توکن «بیشتر» مصرف شد! (همه باید کمتر می‌بودن). عکس دوم: این هزینه اضافی داره کجا می‌ره. عکس سوم: با اینکه هر درخواست در rtk کوچیک‌تره، «تعداد» درخواست‌ها در استفاده ازش نسبت به حالت عادی بیشتره.

▫️ کلاً فقط حدود ۳۳٪ از دستورات Bash قابل‌فشرده‌سازی‌ان، این یعنی سقف واقعی صرفه‌جویی از اول هم حدود ۳٪ بود، نه ۹۰٪

▫️ در reasoning effort پایین، rtk نه‌تنها صرفه‌جویی نکرده، بلکه هزینه رو ۷.۶٪ هم بیشتر کرده

▫️ در effort بالا این هزینه‌ی اضافه از بین می‌ره، ولی صرفه‌جویی هم از اون‌ور صفره


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

(و البته، کلاً بهتره حواستون به این مدل ابزارهای «فوق‌العاده» باشه. علاوه بر اعداد و ارقام نادرست، در گذشته هم زیاد بهمون اثبات شده که بعضی‌هاشون در ادامه کارهای بدتری هم می‌کنن!)

خود مقاله رو اینجا می‌تونید کامل بخونید:
🔗 https://blog.jetbrains.com/ai/2026/07/rtk-claude-code-token-savings/

⛔️ای‌آی ممنوع، خودتون کدش رو بنویسید!

جیک وارتون (معروف‌ترین و قدیمی‌ترین فرد حوزه‌ی اندروید) در این پست اعلام کرد که در پروژه‌های Lysine شامل رتروفیت، OkHttp و ... استفاده از هوش مصنوعی در تولید کد و حتی ساختن پول ریکوئست و کامنت‌ها رو برنمی‌تابن!

اگه قراره از LLMها برای تحقیق، آنالیز و یا آزمایش استفاده کنید، ما نمی‌تونیم جلوتون رو بگیریم. اما برای مشارکت در پروژه لازمه که «خود» شما کدش رو نوشته باشید و صحبت‌های ما هم با «خود» شما باشه.

تنها جایی که استفاده از ای‌آی رو پذیرفته می‌دونن، در تحقیق برای ساخت پروژه و همچنین کمک در ترجمه‌ی توضیحات پروژه‌ها هست.

باید دید واکنش‌ها به این پست چیه.
اگر خاطرتون باشه چند ماه پیش زبان برنامه‌نویسی Zig در اینجا اعلام کرد که استفاده از ای‌آی رو در هیچ قسمتی از ساخت این زبون قبول نمی‌کنن، حتی برای spelling و گرامر (!) و واکنش‌ها به این تصمیم گسترده بود.

از طرفی دیگه Linus Torvalds خالق لینوکس چندی پیش در یک ایمیل اعلام کرد که «لینوکس یکی از اون پروژه‌های ضد ای‌آی نیست و نخواهد بود» و ای‌آی رو یه ابزار خوب برای توسعه‌دهندگان (مشابه ابزارهای دیگه) دونست.

@AdibCodes

خودم رویکرد Linus رو بیشتر می‌پسندم و فکر می‌کنم ای‌آی یک ابزار خیلی خوب برای توسعه‌ست و نمی‌شه کمکش در توسعه برنامه‌نویسی رو انکار کرد.
البته خط فکری پروژه‌های مثل زیگ رو هم درک می‌کنم، اما خودمنظرم اینه که نه قدغن کردنش مناسبه، چرا که مشابه ابزارهای دیگه استفاده ازش برای رسیدن به خروجی مناسب یادگیری و هنر می‌خواد، نه ترجیح می‌دم که استفاده بیش از حدش رو در حلقوم افراد تبلیغ و یا اجبار کنم. (با نگاهی چپ‌چپ به مایکروسافت! 😐)