برنامه‌نویس اندروید درست حسابی - قسمت اول
دوستی بهم پیام داد و عین پیامش این بود: «میشه لطفا بهم بگی که الان باید یه برنامه نویس درست و حسابی اندروید چیارو بلد باشه؟» اولین چیزی که یادم افتاد این نوشته از سجاد بود که به سوال مشابه پاسخ داده بود و خیلی خوب تجربیاتش رو نوشته بود. ولی سریع چند پله برگشتم عقب... برنامه‌نویس اندروید درست حسابی ینی: کسی که ۱. برنامه‌نویس باشه، ۲. اندروید بدونه ۳. درست حسابی باشه... دیدم نمیشه تو یه حرف، به هر ۳ تا بخش این برسیم... لازم بود یه سری چیزای پایه‌ای تر و اصولی تر هم تحلیل بشه، برای اینکه بقیه هم بتونن استفاده کنن، تو این نوشته سعی می‌کنم به هر ۳تاش بپردازم و نظر خودم رو بگم.
سلب ادعا: این نوشته صرفا تجربیات چندساله من به عنوان یک برنامه‌نویسه. سطح دانشم متوسطه و تازه اوایل راهم و ممکنه کامل نباشه. پس با ریسک خودتون بخونید و بهش عمل کنید و اگه نقدی چیزی داشتید حتما پایین بگید شاید به درد چند نفر خورد.
میگن برنامه‌ها از ۳ بخش الگوریتم‌ها، داده‌ها و مستندات تشکیل شدن. خیلی‌ها (از جمله من ۴-۵ سال پیش) فکر می‌کنن که صرف دونستن یه زبان برنامه‌نویسی و کارکردن با ۴تا کتابخونه، اونا رو برنامه‌نویس می‌کنه در صورتی که اینطوری نیست. یه زبان‌های برنامه‌نویسی و کتابخونه‌ها، واسه این طراحی میشن که مجبور نشیم چرخ رو دوباره اختراع کنیم. که به خودی خود خوبه، ولی مشکل وقتی پیش میاد که شما ندونید چرخه چجوری ساخته شده. خدا نکنه یه روزی اون ماشینی که شما سوارشید چرخش مشکل دار بشه، اونوقته که شما چون نمی‌دونید چرخ چطوری کار می‌کنه، مثل نتانیاهو می‌مونید تو گِل و نمی‌تونید مشکل رو حل کنید و سر از تورقوز‌آباد در میارید. (چه بدکرداری ای چرخ!) یه مشکل دیگه که به وجود میارد این وسط، اینه که چسبیدن به کتابخونه ها و زبون‌ها و در کل: ابزارها، باعث میشه ما همیشه یک لول از دانشمون ناقص باشه. این مقاله عالی از جوئل اسپولسکی قشنگ این قضیه رو توضیح میده. به زبون ساده، مثل درست کردن سوپ‌های آماده می‌مونه. طبق تجربه، کسایی که خودشون رو با فریمورک، لایبرری و امثالهم معرفی می‌کنن، مثل آشپزهایی می‌مونن که فقط سوپ آماده بلدن درست کنن، ینی پودر رو بریزن توی آب و... در حالی که یه آشپز معقول، می‌دونه که چجوری باید یه سوپ لذیذ درست کنه، چون قبلا مرغ پخته، جو پخته، هویج پخته (فهمیدین سوپ بلد نیستم؟).
توی برنامه‌نویسی هم همینه. به نظرم به جای اینکه کلی تایم بذارید و یه فریمورک یا ابزار رو یاد بگیرید، چیزای پایه‌ای تر و اصولی تر رو مسلط بشید. این چیزا معمولا توی دانشگاه یا آکادمی آموزش داده میشن (شاید به خاطر همینه اکثرا ازش فرار می‌کنن) و منابع خوبی هم براشون به صورت رایگان و آنلاین وجود داره. به نظرم تو قدم اول، یه برنامه‌نویس اینا رو باید بلد باشه:
۰. زبان انگلیسی: تو زبانشناسی یه اصطلاحی داریم به اسم lingua franca. ینی زبان مشترک. توی دنیای برنامه‌نویسی (و دنیای مدرن امروزی) انگلیسی، زبانیه که توسط همه صحبت میشه و فهمیده میشه و بسیاری از مستندات، محاورات، ارتباطات و آموزش‌ها به زبان انگلیسی هستن. پس یادگرفتنش به عنوان ابزار، ضروریه.
- یک زبان برنامه‌نویسی: توصیهٔ من جاواست. درسته که تو دنیای اندروید، کاتلین داره جون می‌گیره، اما به چند دلیل شروع کردن و یادگیری جاوا برای هر کسی که می‌خواد به دنیای اندروید وارد بشه ضروریه: ۱. بسیاری از لایبرری ها و کدهای موجود برای اندروید طی ۱۰-۱۲ سال اخیر به جاوا نوشته شدن و شما ممکنه برای پیدا کردن جواب سوالات، یا نگهداری کدهای legacy مجبور به دونستن جاوا باشید ۲. کاتلین روی jvm اجرا میشه و شما می‌تونید کدهای کاتلین رو به جاوا هم تحویل بگیرید (تجرید سوراخ) پس اگه جاوا بلد نباشید و یه ضرب برید سراغ کاتلین، شاید نتونید خوب زبون رو درکش کنید. نمی‌دونم شایدم بتونید... ۳. کاتلین درسته که تو اندروید داره جون می‌گیره، ولی بعیده که جاوا به این زودی از چرخه حذف بشه. چون مستقلا یه زبون خیلی بزرگه چه تو آکادمی چه تو صنعت و تو مقیاس‌های بزرگ و کوچیک داره ازش استفاده میشه و برنامه‌نویس زیاد داره. پس فکر اینکه یه روزی کاتلین جاوا رو توی اندروید حذف کنه رو نکنید. حتما یه روزی دنبال کاتلین برید، اما قبلش جاوا رو بلد بشین.
- سیستم‌عامل شبه-یونیکس (مثلا خانواده گنو/لینوکس): از برنامه‌نویس انتظار میره محیط اجرای برنامه‌ش رو بشناسه. هیچکس به راننده‌ای که تا حالا ماشین از نزدیک ندیده و ماشین رو درست نمی‌شناسه اجازه رانندگی نمی‌ده. توی دنیای کامپیوتر‌ها هم همین قانون رو داریم. شما اگه ندونید محیطی که قراره تو برنامه اجرا کنید، چطور حافظه رو مدیریت می‌کنه، چطور رشته‌های سی‌پی‌رو کنترل می‌کنه و چجوری به شما اجازه میده به بخش‌هایی دسترسی داشته باشید یا نه، ممکنه خیلی جاها به مشکل بخورید و حتی اگرم نخورید، تجرید سوراخ براتون مشکل ساز خواهد بود.
- ریاضیات گسسته، منطق و معماری کامپیوتر: اصطلاح «چارتا if و elseئه دیگه» رو بسیاری از برنامه‌نویسا باهاش آشنان. هیچوقت یادمون نره که علم کامپیوتر توسط ریاضی‌دان ها مطرح شد. در واقع اولین دانشمندای کامپیوتر، کسایی مثل خوارزمی و ابن هیثم بودن (کجایید آریایی ها؟). پس دونستن منطق ریاضی و بلد بودن اجزای کامپیوتر (منظورم هارد و سی‌پی‌یو نیست! منظورم ۱ و ۰ ها، بیس ریاضی و اصول اولیه مدارهای منطقیه)، کمک می‌کنه که شما یک لایه بیشتر تجرید سوراخ رو بپوشونید. همینطور یه پیش‌زمینه خیلی خوبی بهتون میده برای یادگیری بهتر موضوع بعدی:
- ساختمان داده و طراحی الگوریتم: این ۲ تا موضوع، معمولا ۶-۷ واحد درسی مقطع کارشناسی رشته‌های مرتبط با کامپیوتره. حرف این ۲ تا مبحث، اینه که شما به عنوان برنامه‌نویس و کسی که مساله رو حل می‌کنه، همیشه نمی‌تونی بهترین راه رو پیدا کنی. ینی اولین راهی که به ذهنت می‌رسه همیشه بهترینش نیست و حتما راه‌های بهتری براش وجود داره. تو این ۲ درس، اول اصول ساختمان داده آموزش داده میشه تا شما بتونید طبق موقعیت تصمیم بگیرید داده‌هاتون رو چجوری ذخیره و بازیابی کنید، تو درس الگوریتم هم به شما پیچیدگی زمانی رو معرفی می‌کنه و می‌گه انواع مسائل رو چجوری میشه با انواع مختلف الگوریتم‌های شناخته شده حل کرد و هرکدوم رو کجا استفاده کرد. این مورد برای خیلی از کسایی که برنامه‌نویس استخدام می‌کنن مهمه. به حدی که توی مصاحبه‌های تخصصی، حتما چندتا سوال از بحث ساختمان داده و الگوریتم داده میشه.
- طراحی شیءگرا و الگوهای طراحی: طراحی الگوریتم به زبان ساده میاد یه سری الگوریتم از پیش حل شده ارائه می‌کنه برای مساله‌های پیش رو، طراحی شی‌گرا و الگوهای طراحی هم مشابه همینن منتها تو مقیاس بزرگتر. به جای اینکه درگیر یک مساله خاص در فرایند نرم‌افزارمون باشیم، با استفاده از الگوهای طراحی میایم برای یه مساله‌ای که در طراحی نرم‌افزارمون به وجود میاد راه‌حل میدیم. الگوریتم‌ها مسائل رو حل می‌کنن و الگوهای طراحی میگن که الگوریتم‌ها چجوری در کنار هم قرار می‌گیرن. الگوهای طراحی خیلی جاها محاورات رو راحت تر می‌کنن. مثلا به جای اینکه به همکارتون که از مشکل مموری لیک شکایت می‌کنه، به فارسی سخت بخواید براش توضیح بدید، میگید از الگوی Singleton استفاده کن یا مثلا با DI اینجکتش کن به پروژه. اینطوری خیلی سریعتر و اصولی تر به حل کردن مسائلتون می‌رسید و درگیر محاورات اضافی نمی‌شید. یه کاربرد خیلی مهم دیگه توی الگوهای طراحی، وقتاییه که یه آدم جدید به پروژه اضافه میشه، یا مثلا وقتی شما می‌خواید کارتون رو ترک کنید و پروژه‌ها رو به جایگزینتون بسپرید، یا کسی باشید که کار رو از کسی تحویل می‌گیره. کافیه گفته بشه فلان‌جا و برای حل کردن فلان مشکل از پترن فکتوری یا ایکس استفاده کردم. کلی وقت صرفه جویی میشه و فهم پروژه بهتر میشه و پروسه توسعه نرم‌افزار خیلی سریعتر پیش میره.
- مهندسی نرم‌افزار: این اصطلاح به بکارگیری اصول مهندسی، در فرایند طراحی، توسعه، تست، پیاده سازی و مستندسازی نرم‌افزار اطلاق میشه. نرم‌افزار فقط نوشتن کد نیست. در واقع اگه بخوایم واقع‌بین باشیم، بخش زیادی از فرایند تولید یک نرم‌افزار، به کارهایی غیر از کدنویسی مربوط میشه. اینکه پروژه به چی میگن و مدیریت پروژه یعنی چی؟ اینکه یه نرم‌افزار چه مراحلی رو باید طی کنه تا تولید بشه، اسکرام چیه و مدل‌های مختلف توسعه نرم‌افزار چیا هستن؟ همینطور طراحی کلاس‌ها، اشیاء و روابط کلاس‌ها با همدیگه جزوی از مباحثی هستن که تو مهندسی نرم‌افزار در موردشون بحث میشه. همینطور در ادامه، کنترل نسخه و مدیریت عرضه نرم‌افزار باید یادگرفته بشه و دونستن اینکه نرم‌افزار بعد از اتمام توسعه کجا باید عرضه و اجرا بشه هم موضوع مهم دیگه‌ایه که هر برنامه‌نویسی باید اینو بدونه.
