<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>نوشته های احسان سوری</title>
        <link>https://virgool.io/feed/@ehsansouri23</link>
        <description>دانشجوی کامپیوتر امیرکبیر و تهران. توسعه دهنده نرم افزار. گیتاریست :) ehsansouri.ir</description>
        <language>fa</language>
        <pubDate>2026-06-07 11:12:39</pubDate>
        <image>
            <url>https://files.virgool.io/upload/users/30666/avatar/kT0leT.png?height=120&amp;width=120</url>
            <title>احسان سوری</title>
            <link>https://virgool.io/@ehsansouri23</link>
        </image>

                    <item>
                <title>انواع مصاحبه</title>
                <link>https://virgool.io/@ehsansouri23/%D8%A7%D9%86%D9%88%D8%A7%D8%B9-%D9%85%D8%B5%D8%A7%D8%AD%D8%A8%D9%87-iglnh5jclis1</link>
                <description>من به عنوان مهندس نرم افزار چند شرکت و مجموعه برای مصاحبه رفتم. این نوشته تجربیات خودم و چند نفر دیگه هست از نحوه مصاحبه شرکت و مجموعه های مختلف. من نظر خودم رو هم راجع به هر کدوم از این ها گفتم. پس این نوشته خالی از بی طرفانه نیست :)بعضی از شرکت ها هستند که فرایند مصاحبه رو با فرایند رو کم کنی اشتباه گرفتن. وقتی ببینن داری سوالاتشون رو درست جواب میدی اینقدر سوال میپرسن و خستت میکنن که بالاخره یک سوال رو اشتباه جواب بدی. اون وقت فرد مصاحبه کننده یه پوزخند میزنه که بالاخره گیرت انداختم :/ بعضی از مجموعه ها هم هستند که تو جلسه مصاحبه بازجویی میکنن. پشت سر هم سوال میپرسن. سوال فنی و غیر فنی حتی سوالای زندگی شخصی. و اصلا اجازه نمیدن تو حرف دیگه ای پیش بکشی. معمولا فرد مصاحبه کننده هم خیلی بی روح هست و یه حالت پوکر فیس خاصی داره. بهتون توصیه میکنم اگر یکی از این دو حالت رو دیدید حتما از اون مجموعه سمی فرار کنید. اینها معمولا افراد رو به دید کارمند یا ربات میبینن که نباید هیچ اشتباهی توی کار بکنه. معمولا هم انتظاراتشون از آدم خیلی خیلی فضاییه!یک گروه دیگه اینطور هستند که قبل از هر چیز یک تسک یا پروژه تستی میدن داوطلب مصاحبه انجام بده. اینکار به خودی خود بد نیست. مخصوصا وقتی که شرکت از یه حدی بزرگتر باشه و داوطلب های اون موقعیت شغلی زیاد باشه. اونجا مشکل به وجود میاد که شما احساس کنی پروژه ای که برات تعریف کردند بیش از حد بزرگه یا اینکه حس کنی این پروژه یکی از چالش های حل نشده شرکت هست. من این رفتار رو غیر حرفه ای میدونم که چالش های باز رو بدن داوطلب مصاحبه جواب بده. حالا چه به شکل یک تسک چه توی جلسه مصاحبه فنی ازش بپرسن. رفتار حرفه تر اینه که چالش هایی که قبلا باهاش برخورد کردن و حلش کردند رو از داوطلب بپرسن.گروهی از شرکت ها هم هستند که حین جلسه فرد مصاحبه کننده خوش برخورده. وقتی سوال میپرسه اگر اشتباه جواب بدی با خونسردی میگه که جوابت اشتباه بود و جواب درست اینه. این مجموعه ها خیلی با فرهنگ هستند. برای نیروی انسانی ارزش قایل میشن و همکاری باهاشون میتونه باعث رشد آدم بشه.بعضی از شرکت ها هم هستند که معمولا طی مصاحبه سوالای فنی زیاد نمیپرسن. یا اگر هم بپرسن خیلی کلی و زیاد وارد جزییات نمیشن. معمولا جلسه مصاحبه این شکل میگذره که دوست دارن بدونن چه طور آدمی هستی. اهل مطالعه و تحقیق هستی. اهل کار تیمی هستی. فرضشون این هست که کسی که انسان خوبی باشه و شخصیت درستی داشته باشه موارد فنی رو میتونه یاد بگیره. ولی کسی که با ما اختلاف فاز داشته باشه اگر خدای برنامه نویسی هم باشه آبمون با هم توی جوب نمیره. اینجا باید بیشتر تحقیق کرد. یا شرکت یک مجموعه خیلی بزرگه که فرهنگ سازمانیش این طوره. یا یک استارتاپه که تازه میخواد کارش رو شروع کنه و چون محصولی نداره استک فنی هم نداره و خب وظیفه داوطلب این میشه که از صفر همه چیز رو بیاره بالا. به نظر من هر دوی این حالات خوبن. البته بسته به شخصیت خود فرد هم داره. معمولا این مجموعه ها افراد رو برای همکاری بلند مدت در نظر میگیرن.اگر شرکتی رفتید که برخورد مصاحبه کننده خوب نبود بیشتر تحقیق کنید. شاید فرهنگ سازمانی شرکت خوب باشه. با یک نفر نمیشه کل مجموعه رو قضاوت کرد. علاوه بر این من به شرکت راجع به برخورد بد مصاحبه کننده بازخورد میدم. که لااقل برای افراد بعد از من این پروسه اصلاح بشه. </description>
                <category>احسان سوری</category>
                <author>احسان سوری</author>
                <pubDate>Fri, 09 Apr 2021 18:54:28 +0430</pubDate>
            </item>
                    <item>
                <title>مهاجرت از اندروید</title>
                <link>https://virgool.io/@ehsansouri23/migrate-from-android-a4gdwhzqjl5r</link>
                <description>سلام. من احسانم. چند سالی سابقه توسعه اپلیکیشن ها و کتابخونه های اندروید ( نیتیو ) دارم. مدتیه تصمیم گرفتم این حوزه رو رها کنم و بک اند دولوپر بشم. در این پست مقایسه ای بین توسعه اندروید و بک اند انجام میدیمفرضیاتیه اندروید دولوپر باید با سرور ارتباط بهینه و درست داشته باشه. المان های گرافیکی صفحه ها رو همون طوری که ازش خواسته شده دقیق پیاده کنه. طوری که تو صفحه نمایش با سایز های مختلف خراب نشه. باید حواسش به مصرف باتری و پرفورمنس اپ باشه. امنیت اپ هم مهمه.....یه بک اند دولوپر باید حواسش باشه سیستمش سریع جواب بده. سیستمش امن باشه. همیشه بالا باشه. دیتابیس رو اصولی طراحی کنه. با سرویس های دیگه ارتباط درستی داشته باشه.....اما بعد از مقدمه میرسیم به دلایل منصادق باشیم. هدف نهایی اپلیکیشن در ۹۹٪ موارد نمایش دیتاهاییه که از سرور میگیره. ولی وظیفه سرور تولید و نگهداری دیتاهاست. ترجیح من اینه که در تولید و مدیریت دیتا نقش داشته باشم تا ارسال و دریافت اون هایک اپلیکیشن اندروید خیلی پیش‌نیاز ها لازم داره. مثلا من اگه امروز تصمیم بگیرم یه اپ جدید  بنویسم نمیتونم. یا اگر بتونم نتیجه مطلوبی حاصل نمیشه. من که خودم بی سلیقم! باید یکی UI UX برنامه رو طراحی کنه‌. یکی هم سمت سرور قضیه رو مدیریت کنه. ولی سمت سرور این دست و پا گیری ها رو نداره. شما میتونی خودت با ایده خودت یه سرور(در حد ساده برای ابتدای کار) بیاری بالا. که مصرف کننده نهایی می‌تونه ازش استفاده کنه. ولی رسوندن اپلیکیشن اندروید به دست مصرف کننده نهایی بیشتر زمان می‌بره.در اندروید (نیتیو) تقریبا همه چی مشخصه. شما باید از زبون جاوا یا کاتلین استفاده کنی. ولی برای بک اند دستت خیلی باز تره. بی نهایت زبون و فریم ورک هست که میتونی با توجه به نیازت ازشون استفاده کنی. من این آزادی عمل رو بیشتر میپسندم.در ادامه بالا تقریبا همه نیاز های یه اپ از طریق کامیونیتی گوگل تامین شده‌. مثلا برای امنیت برنامه گوگل سرویسی ارایه کرده. برای جلوگیری از مهندسی معکوس سرویسی داده. در ۹۹٪ موارد این سرویس های آماده کار رو راه می‌اندازند. مگر اینکه یه اپ خیلی خاص و enterprise باشه. ولی در سمت سرور مثلا برای امنیت سیستم باید خودت فرایند هایی رو تعریف کنی. یا بهتر بگم به همین راحتی نمیشه از ابزار های آماده استفاده کرد. نیاز به کمی تغییر و خلاقیت هست. این رو من بیشتر میپسندم. گوگل حتی برای نحوه کد نویسی هم ملاک هایی قرار داده. مثل پترن mvvm. ولی سمت سرور دست آدم خیلی باز تره. نمیگم خوبه یا بد. من آزادی عمل رو بیشتر ترجیح میدممن آدمی هستم که لاجیک و منطق رو بیشتر و بهتر درک میکنم تا ظاهر رو. و برام جذاب تره. برای همین صرف کردن وقت برای ایجاد یک صفحه اپ اندروید ( با XML ) یا کلنجار رفتن با المان های گرافیکی برای من خیلی سخته!</description>
                <category>احسان سوری</category>
                <author>احسان سوری</author>
                <pubDate>Sat, 04 Apr 2020 16:39:24 +0430</pubDate>
            </item>
                    <item>
                <title>چطور تست بنویسیم ؟</title>
                <link>https://virgool.io/coderlife/%DA%86%D8%B7%D9%88%D8%B1-%D8%AA%D8%B3%D8%AA-%D8%A8%D9%86%D9%88%DB%8C%D8%B3%DB%8C%D9%85-jvzpc9vqmjwg</link>
                <description>چندی پیش بر روی پروژه ای کار میکردم که برای اون نیاز بود تست بنویسم تا از درست کار کردن بخش های مختلف اون اطمینان حاصل کنیم. چیز هایی که نوشتم حاصل از تحقیق ها و تجربه شخصی ام از تست نوشتنه.فرض بر اینه که شما با برنامه نویسی و مفاهیم کلاس و متد و مشخصه های public و private آشنایی دارید.یکی از مهم ترین کار ها در توسعه نرم افزار تست نوشتنه. وقتی ما نرم افزاری رو تولید میکنیم باید مطمن باشیم که درست کار میکنه. برای اینکار میتونیم خودمون تک تک بخش های مختلف اون رو ببینیم و تست کنیم. یا اینکه یه مکانیزم اتوماتیک برای اینکار داشته باشیم. چون معمولا نرم افزار ها در طول زمان بزرگ میشن اینکه خودمون تک تک بخش های نرم افزار رو دستی تست کنیم غیر ممکن میشه. اگر برنامه نویسی نتونه برای کدش تست بنویسه اصلا نباید اسم برنامه نویس رو روش گذاشتاین جملع قطعا درسته! نوشتن تست یکی از مهارت های اصلی توسعه دهندگان حرفه ایه.نوشتن تست مزایای زیادی داره. شما وقتی تست مینویسید باید دقیقا ورودی و خروجی سیستمتون رو بدونید. همچنین باید انواع ورودی های احتمالی به سیستم رو هم در نظر بگیرید. همین باعث میشه که خودتون به درک بهتری از سیستم برسید و بعضا ممکنه تجدید نظری در سیستم و منطق و حتی بیزینستون کنین!همچنین تست نوشتن میتونه تا حدی کمکتون کنه تا یک معماری خوب برای برنامتون داشته باشید.نوشتن تست کمک زیادی به کسانی میکنه که میخواهند کد شما رو بخونن و با سیستم شما آشنا بشن. با یک نگاه به تست ها میشه فهمید که سیستم شما چه ورودی هایی رو قبول میکنه و چه چیزی رو به ما تحویل میده یا چه کاری رو برای ما انجام میده. به همین راحتی میشه با کلیت سیستم آشنا شد. انواع تست ها:تست در واقع یه برنامست که ما بهش میگیم ببین بخش های مختلف برنامم درست کار میکنه یا نه.به طور کلی تست هایی که ما برای نرم افزار مینویسیم به دو دسته Unit Test و Integration Test تقسیم میشن.Unit Test:این نوع تست ها وظیفه تست کردن بخش های مختلف برنامه را به صورت جداگانه برعهده دارد. مثلا فرض کنید میخواهیم ماشینی رو تست کنیم. Unit Test یعنی ما اجزای اون رو به تنهایی تست کنیم. مثلا ببینیم چرخش درست کار میکنه؟ فرمونش درست کار میکنه...وقتی داریم Unite Test انجام میدیم باید تاثیر قسمت های مختلف رو از بین ببریم. در مثال ماشین اگر بخواییم چرخ رو تست کنیم باید حواسمون باشه که فقط چرخ رو تست کنیم و مثلا عملکرد ترمز تاثیری نداشته باشه.Integration Test:وقتی دیدیم اجزای مختلف برنامه به تنهایی درست کار میکنند حالا نوبت به این میرسه که این اجزا رو در کنار هم تست کنیم. در مثال ماشین باید چرخ رو در حضور ترمز و فرمون تست کنیم. به این دلیل این نوع تست ها مهم اند چون ممکنه اجزای مختلف به تنهایی درست کار کنند اما در حضور همدیگه عملکرد مطلوبی نداشته باشن. مثلا فرض کنیم میخواییم رد شدن یک کامیون از داخل تونل رو تست کنیم. کامیون و تونل به تنهایی درست کار میکنند و وظیفشون رو انجام میدن. ولی کامیون نمیتونه از توی تونل رد شه!معمولا  Unit Test ها چون فقط با یک جز از برنامه کار دارند سریعتر اجرا میشوند. یک کد استاندارد باید حدود 80 درصد آن Unit Test شده باشد. به عبارت دیگر Unit Test Coverage باید 80 درصد باشد. در مقابل Integration Test ها چون با اجزای مختلف برنامه در ارتباط هستند کمی کند تر اجرا میشوند. هرم تستهرم تستهرم تست دقیقا به ما نشون میده که تعداد Unit Test ها معمولا بیشتر از Integration Test هاست. و هر چه به سمت بالای هرم برویم زمان اجرای تست ها بیشتر میشود.TDDیکی از روش های پرطرفدار برای توسعه نرم افزار توسعه تست محور هست. به این شکل که شما ابتدا تست هایی برای برنامه مینویسید. بعد باید کد برنامه رو تکمیل کنید که این تست ها پاس بشن. برای این روش باید تمامی حالت هایی که ورودی برنامه شما قبول میکنه رو لیست کنین و براش تست بنویسین. این روش شاید در ابتدای کار کمی خسته کننده به نظر برسه و کار رو کند کنه. ولی قطعا در بلند مدت این روش میتونه کمک بزرگی بکنه به اینکه نرم افزار ما خالی از اشتباه و باگ باشه و اینکه سرعت توسعه رو به شدت تسریع میکنه.چند نکته:وقتی میخواهید از متد ‌TDD استفاده کنید باید دقیقا ورودی و خروجی برنامتون معلوم باشه.باید نوع نگاهتون رو تغییر بدید. مثلا فرض کنید که یک کلاس داریم وظیفش انتگرال گرفتنه. یک متد داره که ما ورودی به اون میدیم و انتگرال رو حساب میکنه. ما ابتدا تابع محاسبه انتگرال رو مینویسیم ولی خالی. بعد  تست ها رو مینویسیم. مثلا انتگرال این عدد میشه این مقدار. بعد تابع محاسبه رو پیاده سازی میکنیم. ممکنه داخل این تابع از توابع private دیگه ای هم استفاده بشه. ولی مهم نیست.  عملکرد این متد برای ما مهمه. ممکنه بگید که شاید توابع private ای که داخل تابع اصلی استفاده شدن مشکل داشته باشن. جواب اینه که ما باید تمامی تست کیس های مختلف رو لیست کنیم و بنویسیم. اگر یکی از توابع درونی مشکلی داشته باشه قطعا یکی از تست کیس ها به مشکل میخوره. اگر تمامی تست کیس ها رو نوشتیم و همه شون مشکلی نداشتن اطمینان حاصل میکنیم که این کلاس داره وظیفش رو به درستی انجام میده.کلاس ها و توابع private رو نباید نیاز باشه تست کنیم. اگر نیاز شد که یک کلاس یا تابع private رو تست کنیم باید بدونیم که معماری نرم افزار ما احتمالا مشکلی داره و باید بیشتر بهش فکر کنیم. (اگر با روش TDD توسعه بدید که اصلا نیازی به تست متد و کلاس های private نمیشه.)وقتی Unit Test مینویسیم باید حواسمون باشه که فقط یک چیز رو تست کنیم. مثلا هنگام تست نباید با دیتابیس یا نتورک ارتباط داشته باشیم. بلکه باید این ها رو شبیه سازی یا mock کنیم.فراموش نکنیم که برای نوشتن تست خوب و البته نرم افزار خوب باید به اصول SOLID مسلط باشیم.</description>
                <category>احسان سوری</category>
                <author>احسان سوری</author>
                <pubDate>Tue, 31 Mar 2020 19:06:10 +0430</pubDate>
            </item>
                    <item>
                <title>0 یا 1</title>
                <link>https://virgool.io/@ehsansouri23/0-%DB%8C%D8%A7-1-nxpn9lwnvumi</link>
                <description>در چند سال اخیر شاهد این هستیم که خیل عظیمی از دانشجویان در دانشگاه به رشته کامپیوتر می‌روند و خیلی های دیگر هم از رشته فعلی خود به کامپیوتر تغییر رشته میدهند. واقعا چرا؟ چرا به کامپیوتر تغییر رشته میدهید؟در رشته خودم کار نیستبعضی ها به خاطر کار به کامپیوتر تغییر رشته میدهند. از حق نگذریم نسبت به بقیه رشته ها این رشته فعلا بازار کار خوبی داره . ولی نکته اینجاست. برای تغییر رشته باید معدل بالای ۱۷ داشت. پس کسانی که میان کامپیوتر آدمای درس خونی هستن. بعد که میان این اخلاقشون رو حفظ میکنن و همش به فکر اینن که معدلشون خوب شده. آخه عزیزان شما که به خاطر کار کردن اومدی. بچسب به کار دیگه . چرا همش به فکر معدلی. نمره رو تو رشته قبلیتم که میشد آورد.میخواهم استاد دانشگاه شوممن احترام زیادی برای (بعضی !) استاد های دانشگاه قائلم. کسی که هدفش استاد دانشگاه شدنه پس دیگه نگران بازار کار نباید باشه. مدرکش رو میگیره بعد میره هیئت علمی میشه بعد هر ماه حقوقش رو میگیره. اگه هدف اینه پس تو همه رشته ها میشه استاد شد. دیگه چرا تغییر رشته؟!میخواهم اپلای کنمحرف خیلی ها امروز این است. میخواهم اپلای کنم. میخواهم از ایران بروم. بروم جایی که قدرم را بدانند. در رفاه زندگی کنم. درسته که کشور ما صنعتش نسبت به کشور های پیشرفته اروپایی عقب تره، و خب مثلا برای کسی که عمران خونده شاید کار زیادی نباشه (که روی همین هم بحث دارم من)، ولی کشور های اروپایی که میخواهیم اپلای کنیم هم همین طوره؟ یعنی اگر در رشته خودمون اپلای کنیم بریم اون ور کار واسمون نیست؟! اینجا میریم داخل یه درخت تصمیم. یا در همون رشته ای که الان داریم میخونیم اپلای میکنیم و میریم دانشگاه خارجی درس میخونیم. که امکان پذیره. اونجا خارجه و برای هر رشته ای کار هست!یا اینکه بریم رشته کامپیوتر و از کامپیوتر اپلای کنیم. که باز هم امکان پذیره! پس اگر هدف اپلای کردنه که توی رشته ای که الان هستیم هم میتونیم اپلای کنیم و بریم خارج که یه زندگی مفرح داشته باشیم.میخوام یه کار بزرگ کنماگر کسی همت داشته باشه مطمئنا در زمینه های دیگه هم میتونه کار های بزرگ و تاثیر گذار انجام بده. درسته کامپیوتر در ایران خیلی تازه است و هنوز در این رشته چرخ اختراع نشده (کنایه از اینکه خیلی جای پیشرفت داریم!) ولی خب در سایر حوزه ها هم میشه پیشرفت کرد. لطفا کسی به دل نگیره چیزایی که نوشتم. صرفا یه دل نوشته بود برای اینکه بفهمم چرا خیلی ها دارن تغییر رشته میدن به رشته کامپیوتر. حتی کسانی که در رشته فعلیشون خیلی موفق هستن. لطفا لطفا لطفا تحت جو قرار نگیرید . هیجانی تصمیم نگیرید. مدرک گرا نباشید!  </description>
                <category>احسان سوری</category>
                <author>احسان سوری</author>
                <pubDate>Sun, 19 Jan 2020 23:01:49 +0330</pubDate>
            </item>
                    <item>
                <title>کاتلین یا جاوا؟</title>
                <link>https://virgool.io/coderlife/%DA%A9%D8%A7%D8%AA%D9%84%DB%8C%D9%86-%DB%8C%D8%A7-%D8%AC%D8%A7%D9%88%D8%A7-kth7avk7ezgg</link>
                <description>کاتلین برای اندرویدشاید به تازگی اسم کاتلین را زیاد شنیده باشید. اگر دقت کرده باشید کد های سمپل در سایت گوگل هم اول به زبان کالین هستند و بعد قابلیت تغییر به زبان جاوا دارند. ریپازیتوری هایی هم که به زبان کاتلین هستند به شدت در حال توسعه و بیشتر شدن هستند. میشود گفت که یادگیری کاتلین برای هم توسعه دهنده اندرویدی واجب است! به تازگی پروژه ای رو با کاتلین شروع کردم. تجربه خیلی خوبی بود. چرا به کاتلین مهاجرت کنیم؟قبل از شروع یادگیری زبان جدید بهتر است بدانیم چرا میخواهیم آنرا یاد بگیریم. باید آن را با سایر زبان ها و ابزار های موجود مقایسه کنیم و در صورتی که بهتر بود شروع به یادگیری و استفاده از آن کنیم.مقایسه کاتلین با جاواجاوا از دیرباز زبان برنامه نویسی برای سیستم عامل اندروید بوده است. الان هم خیلی از برنامه نویسان برای اندروید جاوا کد میزنند. خبر خوب این است که کاتلین با جاوا کاملا سازگار است.چون کاتلین هم روی jvm اجرا میشود. کد های کاتلین تبدیل به بایت کد هایی میشوند که jvm میتواند آنها را اجرا کند. میتوان در یک پروژه اندروید هم کد جاوا داشت هم کد کاتلین. حتی میشود از داخل کد کاتلین کد جاوا را صدا کرد و برعکس. این ویژگی به ما این امکان را میدهد که بتوانیم پروژه ای که در آن هستیم را تدریجی به زبان کاتلین ببریم.کاتلین در مقایسه با جاوا سینتکس راحت تری دارد. البته شاید در ابتدای کار کمی کار کردن با سینتکس کاتلین برایتان دشوار باشد ولی شک نکنید که در زمان کوتاهی متوجه خواهید شد که از جاوا خیلی ساده تر است. کاتلین نسبت به جاوا تعداد خط کد کمتری دارد. یعنی اگر بخواهید یک کار واحد را به زبان جاوا و کاتلین بنویسید کاتلین تعداد خط کد کمتری دارد.مقایسه تعداد خط کد جاوا و کاتلین به طور میانگینپرفورمنس و کارایی کاتلین نسبت به جاوا. میتوان گفت که کاتلین همان پرفورمنسی را دارد که جاوا دارد. چون کد های کاتلین هم دقیقا مانند جاوا بر روی jvm اجرا میشوند. برای اطلاعات بیشتر در این باره پیشنهاد میکنم این مقاله را بخوانید.یادگیری کاتلین بسیار ساده و استفاده از آن در اندروید بسیار ساده تر است! و خبر خوب این است که کسانی که جاوا بلدند میتوانند در مدت خیلی کوتاهی کاتلین را یاد بگیرند.برخی از ویژگی های کاتلینکاتلین به راحتی ما را از خطر null pointer exception حفظ میکند! کاتلین در مرحله کامپایل null pointer را بررسی میکند.در کاتلین دیگر متد getter و setter نداریم. با نام متغیر آنرا مقدار دهی میکنند. کاتلین یک زبان statically typed است. به این معنی که نوع متغیر ها(int, double, float) ثابت هستند و باید در زمان کامپایل معلوم باشند. دو شکل متغیر داریم. val متغیری که مقدارش ثابت است و قابل تغییر نیست و var متغیری که مقدارش قابل تغییر است.از ویژگی های جالب کاتلین میتوان به توابع افزوده یا extension function ها اشاره کرد. گاهی ما نیاز داریم عملکرد جدیدی را به یک کلاس اضافه کنیم. باید یک کلاس بسازیم که از کلاس مورد نظر ارث بری کند و بعد  ویژگی های خود را اضافه کنیم. اما توابع افزوده به این شکل اند که ما میتوانیم ویژگی خود را به کلاس اضافه کنیم بدون آنکه نیاز باشد کلاس جدیدی بسازیم.  مثلا میخواهیم متدی در کلاس ImageView باشد که آدرس عکس را بگیرد و آن را نمایش دهد. به این صورت عمل میکنیم: کاتلین کد زدن برای برخی از design pattern ها را برای ما ساده کرده است. مثلا برای ساخت یک کلاس singleton در جاوا اینطور عمل میکنیم در حالی که میتوانیم با کلید واژه object به راحتی یک کلاس singleton در کاتلین ایجاد کردکاتلین ویژگی های جالب و بسیار کاربردی دیگری دارد مثل sealed class و lambda و data class و  ... که پیشنهاد میکنم از اینجا دربارشان بیشتر مطالعه کنید.به کاتلین مهاجرت کنیم؟اگر پروژه جدیدی میخواهید شروع کنید و یا پروژه کوچکی دارید که کمتر از  ۳ ماه از توسعه ی آن میگذرد به کاتلین مهاجرت کنید. شک نکنید این کار بهتر است. یک فرصتی را تعیین کنید که کد های جاوا را به کاتلین تبدیل کنید. برای اینکار میتوانید از منوی کد گزینه Convert Java File to Kotlin File را انتخاب کنید. ولی بعضی اوقات نیاز است خودتان کد هایی که IDE تولید کرده را کمی تغییر دهید.(از تبدیل کردن کلاس های مدل خود شروع کنید)اگر پروژه تان کمی بزرگتر است و یا مدت زمان بیشتر از ۳ ماه از توسعه آن میگذرد باز هم به کاتلین مهاجرت کنید. اما به این شکل که ویژگی های جدیدی که پیاده میکنید را به زبان کاتلین بنویسید. سپس در یک فرصت مناسب بقیه کد های جاوا را هم به کاتلین تبدیل کنید. در ابتدای کار فقط کد ها را به کاتلین تبدیل کنید و سعی نکنید تغییر ساختار دهید تا از ویژگی های کاتلین استفاده کنید. پس از اینکه کل پروژه به کاتلین تغییر کرد میتوانید در صورت نیاز تغییری در ساختار پروژه دهید.اگر پروژه و تیم بزرگی دارید که بیشتر از ۶ ماه از توسعه آن میگذرد کمی کار سخت میشود. ابتدا کلاس های مدل خود را به کاتلین ببرید. بعد کلاس های تست را به کاتلین تبدیل کنید. با این کار همیشه مطمن خواهید بود که تغییر کدتان به کاتلین باگ یا نقصی در برنامه تان ایجاد نمیکند. اما همیشه یک نسخه جاوا از کدتان را داشته باشید. با وجود اینکه کاتلین زبان ایده آلی است ولی هنوز توسعه دهندگان ارشد جاوا در ایران بسیار بیشتر از توسعه دهندگان کاتلین هستند. ممکن است به همین راحتی یک برنامه نویس ارشد کاتلین را نتوانید پیدا کنید. برای اطلاعات بیشتر اینجا را مطالعه کنید.کاتلین به علت کاربرد خوبش مخصوصا در برنامه نویسی اندروید در این مدتی که نسخه stable آن عرضه شده طرفداران بسیاری پیدا کرده است. کاتلین را میتوان در سمت سرور و یا سمت کلاینت همراه با javascript  ویا حتی همراه با c استفاده کرد. که بعدا در باره آنها بیشتر خواهم نوشت.</description>
                <category>احسان سوری</category>
                <author>احسان سوری</author>
                <pubDate>Sun, 01 Dec 2019 16:54:58 +0330</pubDate>
            </item>
            </channel>
</rss>