شاید سالها پیش چنین مطلبی رو نوشتم. اما دوست داشتم دوباره هم بنویسم. حقیقتا، این بحث، بحثیه که هیچوقت قدیمی نمی‌شه و راستش رو بخواید، حتی میتونه بروز بشه. به همین خاطر تصمیم گرفتم اینجا، این تجربه رو منتقل کنم. شاید دو سال دیگه یه مطلب دیگه با همین مضمون اینجا بنویسم.
حالا چرا اینجا؟ در حال حاضر، ابزارهایی مثل ویرگول و مدیوم و dev.to و … اومدند که انتقال تجربه رو هم آسون کردند. اما راستش انتقال تجربه در وبلاگی که سالهای سال اصلی‌ترین محل انتقال تجربه و دانش من بوده، نوشتن مطالبی مثل این، که از جوانب مختلفی اهمیت بالایی دارند اون هم در جای دیگر؛ نوعی خیانت به اینجاست!
خب، هندی‌بازی بسه 😀 بریم سر اصل مطلب.
حقیقتا نوشتن برنامه در دنیای امروز، مثل قدیم برای «حل مسائل ریاضی» نیست. گرچه ما در هر حال، داریم یه مساله‌ای رو به شکل مدلهای متعدد ریاضی درمیاریم که فهمشون رو آسون کنیم؛ اما صرفا ریاضی‌کاری نمی‌کنیم. پس نیازه که اول از همه یه سری مهارت خاص رو در خودمون تقویت کنیم.
تقویت مهارت‌های نرم
شاید مهارت‌های نرم یا Soft Skills ، به صورت مستقیم در نوشتن برنامه مهم نباشند. اما از اونجایی که آداب معاشرت، این که چطور صحبت فنی درستی داشته باشیم، بررسی شرایط روانی خودمون و مشتری و …؛ برای کسایی که میخوان از طریق برنامه‌نویسی و توسعه نرم‌افزار ارتزاق کنند مهم باشه.
بعضی مهارت‌های نرم که در کار برنامه‌نویسی (بعنوان یک شغل) مهمن :
- آداب معاشرت: راستش این رو من نباید توضیح بدم دیگه :D. و خب آداب معاشرت حتی در فرهنگ‌های مختلف میتونه شکلای مختلفی داشته باشه. پس به نظر میاد لازمه که علاوه بر بلد بودن آداب معاشرت در فرهنگ حاکم بر منطقه خودمون، آداب معاشرت حاکم بر سایر مناطق هم یاد بگیریم. یکی از دلایلش هم شاید این که ممکنه روزی کار ریموت بهمون بخوره.
- اخلاق کاری: اخلاق کاری، یه سری چارچوب ویژه خودش رو میتونه داشته باشه. اما خب هرشخصی میتونه چیزی بهش اضافه کنه یا تعریف مشخص‌تری ازش ارائه کنه. به نظرم لازمه که بعنوان برنامه‌نویس، اخلاق کاری خودمون رو هم شفاف مشخص کنیم.
- روحیه کار تیمی: گفتن نداره، برنامه‌های بزرگ رو معمولا یک نفر نمی‌نویسه. اگر یک نفر هم بنویسه یحتمل بعدها به تیم محول کنه ادامه توسعه‌ش رو. پس لازمه که روحیه کار تیمی رو هم در خودمون تقویت کنیم.
اینا چیزایی بودن که در زمینه Soft Skill یا همون «مهارت نرم» به نظرم رسیدن. البته فقط اینا هم نیستند. اما بهتره اینها رو تا حد خوبی، تقویت کنیم.
یادگیری زبان انگلیسی
زبان انگلیسی، مدتهای زیادی (شاید از زمانی که امریکایی‌ها در دنیا اسم و رسم دار شدند؛ به طور دقیق از بعد جنگ دوم جهانی) میشه که شده زبان بین المللی. ارتباطات مختلف، تولید محتوا و حتی تولید علم به این زبان انجام میشه.
گرچه شخصا خوشحال میشم اگر جایی مستندات فارسی ببینم، اما ناچاریم برای بهتر شدنمون در دنیای برنامه‌نویسی، زبان انگلیسی رو هم به خوبی یاد بگیریم. در بخش قبلی، به کار ریموت اشاره کردم. لازم به ذکره که شما لازم دارید برای انجام مصاحبه و ارتباط گرفتن با خارجی‌ها، زبان انگلیسی بلد باشید (با این فرض که تو شرایطشون نگن زبان خودشون هم باید بدونید. مثلا شرکت ترکیه‌ای، ممکنه از شما بخواد تُرکی هم بلد باشید.) که در اون صورت، اگر حال و حوصله کافی دارید، میتونید یک زبان جدید هم شروع کنید.
این دو موردی که در بالا اشاره کردم، خیلی با عنوان مطلب خوانایی نداشتند. راستش بهتره که بریم سراغ این که «چطور یک برنامه بنویسیم؟». حقیقتا این سوال، سوال خوبی نیست. به قول دوستی «سوالیه که مثل زلزله‌ست». البته اینطورام نیست، اما حقیقتش سوال خوب، سوالیه که هدف سوال‌کننده درش مشخص باشه.
پس بیایم اینطوری نگاه کنیم. شما شخصی هستید که شنیده برنامه‌نویس‌ها خوب پول درمیارن. یا شنیده که اگر مهارت برنامه‌نویسی هم داشته باشه، احتمالا بتونه آینده شغلی خودش رو بیش از حال؛ تضمین کنه. خب، این سوال که «چطور برنامه نویس بشم؟» یا «چطور برنامه بنویسم؟» و … مطمئنا تو ذهن شما می‌پیچه.
من بعنوان یک برنامه‌نویس، این سوال رو اصلاح می‌کنم به این شکل :
چطور یک برنامه تجاری بنویسم و آینده شغلی خودم رو تضمین کنم؟
الان این سوال از نظر من یک سوال خوبه. من میدونم شما چند هدف دارید :
- برنامه نویسی
- برنامه نویسی با هدف یک برنامه تجاری
- تضمین آینده شغلی
- (احتمالا) درآمد بالا
خب، حالا میایم سراغ این که شما دقیقا نیاز دارید چه مراحلی رو طی کنید. اینها تجربه شخصی من هستند و ممکنه کامل نباشند. پس لطفا بعد از خوندن این مقاله، خودتون هم دنبال منبع باشید 🙂
شناخت نیاز بازار
«نیاز بازار» چیزیه که احتمالا تو کار زیاد بشنویم. اما بیاید عمیق‌تر بهش فکر کنید. نیاز بازار دقیقا چیه؟ بازار از دو بخش عرضه‌کننده و تقاضاکننده تشکیل شده. تقاضاکننده یا مشتری؛ یک انسانه. یک شهروند مثل من و شما. پس شاید اولین و بهترین «نیاز بازار» نیازی باشه که من در حال حاضر دارم. منطقی‌تر بگم که اون چیزی که نیاز منه، مطمئنا نیاز تعداد زیادی آدم دیگه هم هست. این یعنی اگر این نیاز منحصر به شما بود، ممکن بود اصلا راه حل‌های احتمالی به سرتون نزنه.
بعنوان یک تجربه، میتونم بگم وقتایی که با دوستانم صحبتی کردم تازه فهمیدم چه نیازهایی بوده که داشتم، میدونستم دارم ولی راه حل درستی نداشتم. اما صحبت‌ها باعث شده به راه حل برسم و نیازهای دیگران هم رفع کنم حتی. پس این موضوع رو جدی بگیرید.
طراحی راه‌حل
اول مقاله اشاره کردم که برنامه‌نویسی علیرغم این که در دنیای امروز حل یه سری مساله ریاضی نیست، اما ما همچنان به مدل‌سازی‌های ریاضیاتی برای طراحی یک برنامه خوب نیاز داریم. در واقع بعد از این که نیازهای بازار رو بسنجیم، نیاز داریم که تا حد امکان اونها رو ساده کنیم و از راه‌حل‌های ذهنیمون، مدل ریاضی بسازیم.
ساخت این مدلهای ریاضی؛ نتیجه‌ش میشه الگوریتم‌های ما. نتیجه‌ش میشه دیتابیس‌های ما. پس یعنی بعد شناخت بازار، نیاز داریم تا حد زیادی ریاضی‌کاری کنیم و ببینیم که چی به چیه. تا برسیم به یه ساختاری که بتونه به برنامه تبدیل بشه.
چیدن پلن
این مرحله، خودش حتی شامل واحد‌های درسی میشه. نمی‌دونم عبارت «مهندسی نرم‌افزار» به گوش شما خورده یا نه؛ اما مهندسی نرم‌افزار، حرفش دقیقا همینه. یعنی شما وقتی یه چیزی داری و میخوای پیاده‌ش کنی، نیاز به پلن چیدن داری.
خب، فکر کنم اگر بخوام همینطوری توضیح بدم خیلی خیلی پیچیده و مصنوع میشه. بیایم موردی بررسی کنیم که یه پلن خوب چطوریه. در واقع چیزی که در ذیل این مطلب میاد؛ پلنیه که خودم برای یه پروژه چیدم (البته با کمی دخل و تصرف 🙂 )
- معرفی اجمالی پروژه
- بررسی پروژه های مشابه
- طرح مساله
- طرح راه حل
- طرح ساختارهای داده‌ای
- طرح ساختارهای الگوریتمی
- طرح روش پیاده‌سازی
- زبان، فرمورک و …
- مدت زمان احتمالی پیاده سازی
- امکاناتی که در فازهای مختلف نیاز داریم
- پکیج‌ها و ابزارهای کمکی
- توسعه‌پذیر کردن طرح پیاده شده
- آماده‌سازی برای ارائه
با چیدن چنین پلنی، شما میتونید به خوبی روند توسعه رو پیش ببرید. ابزارهایی مثل ترلو و تسکولو و … هم هستند که بهتون کمک کنن در انجام دادن این مراحل.
پیاده‌سازی
فکر کنم اینجا دیگه میرسیم به خود خود خود برنامه‌نویسی. راستش این همه توضیح دادم که به اینجا برسیم. برای پیاده سازی، چی نیاز داریم؟
- یه خط اینترنت
- یه هدفون
- یه پلی‌لیست از موزیک مورد نیاز برای برنامه‌نویسی (دیگه این بستگی به سلیقه‌تون داره 😉 )
- مقدار خوبی ماده قندی و قهوه
اما آیا اینا کافین؟ خیر. اینها خوبن. در واقع با اینترنت شما به دنیای بی‌کران مستندات و اطلاعات متصل هستید. با استفاده از هدفونتون به پلی‌لیست گوش میدید و خب احتمالا وقتی خسته می‌شید یه فنجون قهوه داغ خیلی می‌چسبه. یا مثلا وقتی قندتون میفته، یه شیرینی میخورید.
اما برای پیاده سازی، ما ذهنیت نیاز داریم. راستش ذهنیت ما باید اینطوری باشه :
- شناخت ابزار مناسب: ابزارهای زیادی همیشه دم دست ما هستند. اما این به خودمون برمی‌گرده که از کدوم استفاده کنیم برای انجام کارمون. نمی‌دونم شما دیدید یا نه. اما با چاقو میوه خوری هم میشه پیچ‌های ریز رو باز کرد. حالا سوال اینه، آیا کار منطقیه؟ نه! آچارهای ریز هستند که به طرفة‌العینی، پیچ رو برای ما باز میکنن. پس مهمه که ابزارها رو بررسی کنید و بهترین رو انتخاب کنید.
- استفاده از ابزارهای کنترل سورس: خب، کنترل سورس، به شکل خوب و عجیبی؛ به تسریع روند توسعه کمک می‌کنه. اما مهم‌ترین بخشش که کمتر کسی بهش توجه می‌کنه اینه که این ابزارها، روند توسعه ما رو قابل ردگیری می‌کنند. یعنی چی؟ یعنی میشه فهمید سه روز پیش دقیقا چه حرکتی زدیم و آیا حرکتی که امروز می‌زنیم، درسته؟ و از این چیزا 🙂
- تجدید نظر، هرجا که لازم بود : خب این آخرین مورد این لیسته. راستش دوست دارم با یه مثال جمعش کنم! کرنل لینوکس یه برنامه خیلی بزرگه که قریب به سی‌ساله داره توسعه داده میشه. توسعه اولیه این برنامه تا سال ۲۰۱۲ ادامه داشت. تقریبا بیست سال روی یک مدل پافشاری شده بود. اما می‌دونید اتفاق بد چی بود؟ این که در سال ۲۰۱۵ توسعه‌دهنده‌ها فهمیدن که یکم دیگه بگذره عملا هیچ غلطی نمی‌تونن بکنن (اگر با چنین لحنی می‌گم به این خاطره که دقیقا به همین وضعیت دچار شده بودند) و خب تصمیم گرفتن تو کل کرنل، تجدید نظر کلی کنن. این یعنی چی؟ یعنی نترسید و هرجا که دیدید دارید گند میزنید، حتی شده برگردید و از اول کار رو انجام بدید، این کار رو بکنید.
این هم موارد مورد نیاز برای پیاده سازی. خب یه نصیحت ریزی می‌کنم و بعدش هم کلا مطلب رو می‌بندم 🙂
بلندپروازی نکنید 🙂
رویاپرداز و بلندپرواز بودن خوبه. جف بزوس و بیل گیتس و ایلان ماسک و …، یه بخش بزرگی از موفقیتشون رو مدیون همین بلندپروازیشون هستند. اما بگذریم، بیش از اندازه بلندپرواز بودن هم گاهی کار دست آدم میده.
پس بهتره که «خیلی» بلندپرواز نباشید و حد معقولی هدفگذاری کنید برای پروژه‌ها. اینطوری پروژه‌ها هم به موقع انجام میشن و صدالبته، کیفیت لازم رو خواهند داشت.
حرف آخر
حرف آخری ندارم، راستش مطلب اونقدر طولانیه که اگر تا اینجا اومدید، دمتون گرم! من سعی کردم هرچی که این اواخر برای خودم پیش اومد و با رعایتش کیفیت کارم بالاتر رفت رو بنویسم. فقط الان بعنوان حرف آخر، میتونم بگم که لطفا اگر تجربه مشابهی دارید، در بخش کامنت‌های همین پست بنویسید.
آزاد و شاد باشید.
