احسان رضایی

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

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

زمانی که golang رو شروع کردم بلافاصله مشغول تحقیق و بررسی وب فریمورک هاش بودم. من قبلا مطلبی در مورد استفاده از فریمورک نوشتم و هنوز هم بر این عقیدم که مزیت های استفاده از فریمورک نسبت به عیب هایی که داره بیشتره. نکته جالب این بود که اغلب مخالف استفاده از فریمورک در go بودن و خب معمولا به جمله ی نیازی بهشون نداری بسنده میکردن.

برای تجربه بیشتر سراغ سه فریمورک gin، echo و روم به دیوار iris رفتم! یه نکته ی خیلی مهم وجود داشت. به نظرم این فریمورک ها به اندازه کافی کامل نیستن و هنگام توسعه زیاد اتفاق میوفته از پکیج های خارجی استفاده کنید. حقیقتا برای validator، router، middleware و error handling که میتونی پکیج هاشُ خودت توی پروژه ات به سادگی اضافه و استفاده کنی، نیازی به فریمورک نداری. در نتیجه تقریبا مزیتی نخواهد موند که از عیب هاش بیشتر باشه. اما پیشنهاد میکنم فریمورک هاشُ برای تجربه هم که شده امتحان کنید.

اجازه بدین قبل از شروع این موضوع آماریُ خدمتتون ارائه بدم.

در سال 2016 تخمین زده شد حدود 21 میلیون توسعه دهنده حرفه ای نرم افزار در سراسر دنیا فعالیت میکنن. با این حال:

-  75 درصد مدیران فناوری پیش بینی میکنن پروژه های نرم افزاری اونها شکست میخوره.

- در پروژه های موفق، کمتر از یک سوم اونها با بودجه و زمان مشخص شده به پایان میرسن.

سعی میکنم در مورد رایج ترین خطاها بنویسم. خوشحال میشم تجربه ی خودتون رو به اشتراک بذارین تا این موضوع رو کاملتر کنم. موارد زیر خطاهایی هست که من بهشون فکر میکنم:

1) داشتن شور، اشتیاق، امید و انگیزه. اما تخصص نه!

فرآیند تولید نرم افزار یک فرآیند پیچیده است، اینکه سرشار از شور، اشتیاق، امید و انگیزه هستین اما تخصص لازم برای مدیریت تیم نرم افزاریُ ندارین یعنی نباید درش دخالت کنید. اگر پروژه تون به میزان قابل توجهی بزرگ هست به پیدا کردن مدیر فکر کنید نه مدیریت. اجازه بدین باهاتون رو راست باشم. اگر برنامه نویسی کار کرده باشین، مخصوصا یک مقدار جزئی. شما بسیار خطرناک هستین! این مدل افراد معمولا علاوه بر دخالت در مدیریت پروژه، راه حل های فنی هم میدن! که خب در درجه اول آزار دهنده است و در درجه دوم به احتمال خیلی زیاد اشتباهه. و اگر افراد تیم قدرت نه گفتن رو نداشته باشن حتی اگر هم راه حل فنی و پیشنهادی رو اعمال نکنن باعث دخالت بیش از حد شما در پروژه خواهند شد. این در حالی است که در صورت عدم تخصص مدیریت فنی تنها باید نیاز خودتون رو به تیم ارجاع بدین نه چیز دیگه ای.

به مناسبت روز جهانی چپ دست ها البته با کمی تاخیر! باید بگم به عنوان یک چپ دست فکر نکم! نکته ی قابل توجه اینکه از پیام های داخل شبکه های اجتماعی متوجه شدم 10 درصد جامعه چپ دست نیستن و برعکس، راست دست ها در اقلیت به سر میبرن!

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

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

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

یادمه این موضوع چپ دست بودن رو به نیم کره های مغز هم ربط میدادن که توجه تون رو به این نقل قول جلب میکنم:

در مطالعه‌ای در سال ۲۰۱۳، تصاویر سه‌بعدی مغز هزار نفر مورد بررسی قرار گرفت و با استفاده از اسکنر MRI، میزان فعالیت هردو نیمکره اندازه‌گیری شد. نتایج نشان می‌داد که هر انسان، از هردو نیمکره مغزی خود بهره می‌برد و بخشی بر دیگری غالب نیست.

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

در انتها این روزُ به همه ی چپول ها تبریک میگم و آرزو میکنم با موفقیت هایی که تو زندگی به دست میارین خاص بشین نه این تفاوت.

به این نتیجه رسیدم توی برنامه نویسی دست رو هر چیزی بذاری(تکنولوژی، فریمورک و...) بازم پیدا میشن که بیان و یه عیبی روش بذارن :)

آیا واقعا جای عیب و ایراد گرفتن وجود داره؟ بله. حتما اینطور هست و اتفاقا کار آسونیه :)

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

موضوع دقیقا اینجا مشخص میشه. ممکن هست انتخاب یک شخص برای من نوعی و یا شخص دیگه ای سم باشه!

عمدتا 4 دلیل اصلی برای این موضوع وجود داره.

اول. بزرگ جلوه دادن خودشون!

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

دوم. سلیقه...

شاید بتونم با مورد اولی ها کنار بیام اما دومی نه. اینکه سلیقه ی خودت رو درست بدونی و بقیه رو غلط فاجعه است... یادمه یه مطلب در مورد استاندارد کدنویسی داخل یه فریمورک رو مطالعه میکردم که اولش به این جمله برخوردم:

هیچ قانون سختگیرانه ای برای شما وجود نداره...

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

سوم. جبهه گرفتن.

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

چهارم. اطلاعات کهنه.

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

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

اما اگر به اون 4 دسته از توسعه دهندگان بالا برخوردین هدفونتون رو بذارید گوشتون و با هر چیزی که خوشحالتون میکنه کار کنید. از افرادی که این مسائل ساده رو درک نمیکنن نمیشه توقع ساکت شدن داشت.

حتما چنین کدی رو قبلا دیدین:

    public function index() : JsonResponse
    {
        $cars = Car::with('facilities', 'type', 'color', 'rentalDetail')->all();
        return response()->json($cars, 200);
    }

هوم... . مورد بدی توش دیده نمیشه. یک سرویس ساده که لیست خودرو ها رو میده. اما منطق/logic توی کنترلر نوشته شده. هر چند به عقیده من آوردن منطق در کنترلر برای app های کوچک مشکلی به وجود نمیاره اما با رشد نرم افزار بیشتر و بیشتر نیاز به یک ساختار منسجم و متمرکز رو حس میکنید.

به عنوان یک روش جایگزین و بهتر میشه از الگوی طراحی مخزن یا بهتر هست بگیم Repository Design Pattern استفاده کرد. مثل همیشه ساده بگم، در این روش مسئولیت ارتباط و استخراج داده ها رو از روی دوش مدل برمیداریم و اون رو در کلاس های Repository پیاده میکنیم، داخل کنترلر هم فقط متد هاشون رو صدا میزنیم.

    public function index() : JsonResponse
    {
        $cars = $this->carRepository->get();
        return response()->json($cars, 200);
    }

این روش مزیت های زیادی داره از جمله:

- ایجاد ساختاری منسجم و متمرکز
- حذف کد های تکراری
- توسعه و نگهداری آسانتر
- کاهش خطا و خطایابی سریعتر
- از بین بردن وابستگی های بین مدل و کنترلر
- کد تمیز و واضحتر

خب به نظرم توضیحات تا همین اندازه کافی هست و بهتره بریم سراغ یک نمونه ساده از پیاده سازی این روش تا مزایایی که بهمون میده رو بیشتر درک کنید.

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

در درجه اول اگر به موردی علاقه دارین امتیاز ویژه ای براش در نظر بگیرید چون خیلی توی موفقیت شما موثر خواهد بود.

میرسیم به بازار کار. دغدغه مهمیه. بازار خودتون رو انتخاب کنید. نیازمندی های داخل کشور با خارج از اون کمی متفاوته. فرض رو بر داخل میگیریم. آگهی های استخدام داخل رو با توجه به علاقه و شرایطی که دارین بررسی کنید.
مثلا اگر محل زندگی شما جوری هست که مجبور به دورکاری هستید، آگهی های استخدام دورکاری رو چک کنید. نیازمندی هاشون، حقوق و دستمزد و... به انتخاب شما کمک میکنه.
فرض کنید بین یادگیری Angular و React گیر کردیم. الان که مشغول نوشتن این مطلب هستم توی یکی از سایت های کاریابی Angular صد و ده تا و React دویست و پنجاه آگهی استخدام داره.
توی مرحله بعد میریم سراغ میزان حقوق دستمزد هر کدومشون و...
همین سرچ کوچیک نشون میده امروز React Developer شانس بیشتری برای استخدام داره.
این کارو توی بازه ها و سایت های مختلف باید انجام داد(هفتگی یا ماهانه). چون گرفتن آمار در یک روز و یک منبع ممکنه شما رو به اشتباه بندازه.
حالا بعد از کلی سبک و سنگین کردن میتونید مشورت بگیرید. اینجا دیگه متوجه تعصب طرف مقابلتون خواهید شد.

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

آلن پرلیس میگه: احمق ها پیچیدگی رو نادیده میگیرن، عملگرایان ازش رنج میبرن و نوابغ حذفش میکنن.

توی حرفه ما یه کدنویسی احمقانه هم منجر به پیچیدگی میشه. کنار اومدن با پیچیدگی، کاری که عملگرایان انجام میدن ادامه دادن و بزرگتر کردن پیچیدگیه.
پیچیده شدن نرم افزار دلایل زیادی داره. حتی ممکنه برگرده به قبل از برنامه نویسی. منظورم مراحل تحلیل، طراحی و... هست. گاهی نرم افزار با بزرگ شدن پیچیده هم میشه. پس همراه با توسعه همیشه باید کدهای قدیمی، اضافی و بلااستفاده رو حذف کنیم. وابستگی ها رو به حداقل برسونیم، از روش های من دراودی پرهیز کنیم و ... . در نتیجه به نظرم استفاده از design patterns، SOLID، رعایت اصول و سبک کد نویسی، فریمورک ها و موارد مشابه هم میتونه در این زمینه به شما کمک کنه.

گاهی داخل app نیاز به یک فیلد با مقادیر مشخصی داریم. مثل status در جدول payments که میتونه paid یا unpaid باشه. از اونجایی که در پروژه های مختلف این فیلد رو به روش های متفاوتی پیاده میکردن تصمیم گرفتم در موردش کمی بنویسم. به طور کلی سه دیتا تایپ برای این قبیل فیلد ها انتخاب میشن که در موردشون توضیح میدم.

- string/varchar: ساده ترین رویکرد انتخاب دیتا تایپ string هست. وضوح خوبی هم داره. چون هنگام توسعه با یک نگاه به سطر مورد نظرتون متوجه وضعیتش میشید. حتی میتونید توی فرانت دقیقا این رشته رو چاپ کنید(ولی نه توی app های چند زبانه). اما بسته به طول رشته طبیعتا فضایی برای ذخیره سازی در نظر گرفته میشه. هر چند موضوع فضا خیلی وقته به حاشیه رفته و کمتر کسی نگران پر شدن هارد سرورشه، اما اگر سطرهای زیادی داشته باشید هنگام پیمایش اطلاعات، کندی رو حس خواهید کرد. مورد بعدی تغییرات هست. فرض کنید پس از مدتی متوجه غلط املایی در یکی از آیتم ها میشید، تمام سطر ها باید update بشن.

- enum: چیزی که ازش به شدت متنفرم! من دوست ندارم منطق و فرآیند برنامه رو توی دیتابیس ببرم. چرا که مثلا هنگام تغییرات و یا کم و زیاد شدن آیتم ها مجبورم جدول رو هم بروز کنم.

- tinyint: یک رویکرد مناسب برای بهبود سرعت query ها و ملایم در هنگام تغییرات یا افزودن گزینه های بیشتر. نیازی نیست به طور مستقیم با اعداد کار کنید، میتویند از جدول میانی یا ثابت ها بهره برد. من به طور پیشفرض از ثابت ها برای آیتم های کم و جدول در مواقعی که گزینه های زیادی یاا اطلاعات اضافی مثل توضیحات و... داریم استفاده میکنم.

انتخاب هر یک از این روش ها بستگی به شرایط و app شما داره. میتونید string رو برای پروژه های کوچک و اطلاعات کم استفاده کنید. enum توی پروژه هایی که به شما ارث رسیده(یک پروژه قدیمی که مشغول توسعه نسخه جدیدش هستید) و فرآیند ها و منطق برنامه از قبل مشخص هست هزینه تغییرات پایینی داره. tinyint هم زمانی که در یک پروژه بزرگ یا مواقعی که تغییرات زیادی هنگام توسعه اتفاق میوفته کارآمد هست.

برای deploy روش های زیادی وجود داره که اغلب وارد پیچیدگی هایی میشن. من تصمیم دارم کوتاه و ساده در موردش بنویسم و از تنظیمات جانبی اون صرف نظر میکنم.

در مرحله اول به یک http server نیاز داریم. من خودم مخالف استفاده از فریمورک های golang هستم ولی الان دم دسته و مثال رو با gin انجام میدم. شما هر طور خواستین بنویسید.

package main

import (
	"github.com/gin-gonic/gin"
	"net/http"
)

func main()  {
	router := gin.Default()
	router.GET("/", func(context *gin.Context) {
		context.JSON(http.StatusOK, gin.H{
			"status": "OK",
		})
	})

	router.Run(":8080")
}

به Dockerfile نیاز داریم. پیشفرض به پورت 8080 گوش میده و app رو اجرا میکنه(پورت http server هم روی 8080 ست شده).

FROM golang:1.13
ENV APP_NAME app
ENV PORT 8080
WORKDIR /go/src/app

CMD ./${APP_NAME}
EXPOSE ${PORT}

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

مثال زیر اسنادی رو که فیلد user شون با k شروع و با y تموم بشه رو match میکنه.

GET /_search
{
    "query": {
        "regexp": {
            "user": {
                "value": "k.*y"
            }
        }
    }
}