احسان رضایی

یک توسعه دهنده

یک پیشنهاد هنگام جستجوی شغل جدید

سلام،
ساعت 10 شب 30 آبان 1401. حال هممون خوب نیست...
بعد از کلی وقت اومدم توی لینکدین تا وضعیت شغلیم رو open to work بزنم. متوجه شدم خیلیا مثل من به علت اوضاع بد موجود شغلشون رو از دست دادن. حس کردم وقت نوشتن تجربیاتم در این زمینه است. من فقر رو با پوست و خون و استخونم درک کردم، اگر ازم بپرسین بزرگترین ترست چیه میگم بی پولی. لازم دونستم بگم توی این شرایط بهتره چکار کرد و توصیه ای براتون دارم.
اینجا قرار نیست توضیح بدم چطور رزومه بهتری بنویسید یا چطور مصاحبه کنید، از یه مقدار عقب ترش میگم و خوشحال میشم این مطلب به دردتون بخوره.

ادامه...

چپ دست ها آدمای خاصی هستن یا چی؟

left hand


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

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

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

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

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

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

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

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

این جماعت توسعه دهنده ی خرده گیر

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

تم روشن یا تیره؟ کدام برای چشم مفیدتر هست؟

شاید صرفا مربوط به فضای برنامه نویسی نباشه، در کل به دنبال این بودم که یک صفحه ی روشن با نوشته های تیره برای چشم مفیدتر هست یا نوشته های روشن با صفحه ای تیره؟ در ابتدا فرض رو بر این میگیریم که نور به اندازه کافی در اتاق وجود داره. از دهه 1980 تا الان مطالعات زیادی در این مورد انجام شده و هنوز هم به پایان نرسیده! یکی از اونها که مربوط به همون دهه اول هست میگه مطالعات به ما نشان دادند که متون تیره در یک صفحه/پس زمینه روشن بهتر از حالت دوم یعنی نوشته های روشن با صفحه ی تیره است. به عنوان مثال اونها متوجه شدن که شرکت کننده ها در این آزمایش 26 درصد دقیقتر متون رو مطالعه میکنن اگر نوشته ها تیره و صفحه روشن باشه.

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

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

چرا از framework استفاده میکنم؟

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

موضوع بعدی کار کوچک و کار بزرگ هست و به نظرم درسته که برای انجام یک کار کوچک نباید از یک فریمورک بزرگ استفاده کرد. این موضوع اصلا ربطی به استفاده یا عدم استفاده از فریمورک نداره. 

دلیل بعدی استفاده از ابزار ها و پکیج های مورد علاقه است. تا حدودی میشه فریمورک رو کاستوم کرد.

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

- آیا از نظر فنی اینقدر کامل و بی عیب و نقص هستین که در این کار اشتباه نکرده باشید؟

- امنیت چطور؟ آیا امنیت رو به خوبی تضمین میکنید؟

- مستندات کاملی برای اون نوشتین و امکان این وجود داره که نفر جدیدی بدون درد و خونریزی وارد تیم بشه؟

- و سوال اخر، آیا مطمئن هستید به پرفورمنسی که دنبالش بودین رسیدین و بهتر از پرفورمنس سایر فریمورک هاست؟!

‏احساس تعلق خاطر به محل کار

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

‏اما خوشبختانه من موندم. رئیس شرکت می‌گفت متاسفیم اما مجبوریم. اون موقع من فهمیدم چقدر کودکانه فکر می‌کردم. همیشه موضوع منفعت هست. تاسف اون هیچ ارزشی برای کسایی که اخراج شدن نداشت. اون از روز اول هم برای کسی دلسوزی نمی‌کرد. برای اون چیزی که مهمه بازدهی بیشتر نیروهاش بود و هست.

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

ادامه...

داستان اول شخص بودن یک توسعه دهنده

یه دوستی میگفت در همین لحظه که داری به موضوعی فکر میکنی به طور میانگین حدود 16 نفر دیگه هم مثل تو دارن هم زمان به این موضوع فکر میکنن!

به نظرم توی برنامه نویسی اول شخص بودن یعنی ادعا. اینکه بگیم اولین نفری بودیم که این کارُ انجام دادیم یا مثلا تنها کسی بودم که انجامش دادم و...

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

دانشگاه یا موز!

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

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

ادامه...

کتاب‌ها

کتاب الگوهای طراحی به بیان ساده(design patterns / دیزاین پترن)

در مهندسی نرم افزار، design patterns(الگوهای طراحی) راه حل‌های قابل استفاده برای مشکلاتی هستند که معمولاً در طراحی نرم‌افزار اتفاق می افتند.

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

کتاب refactoring / ریفکتورینگ

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

در کتاب Refactoring اثر Martin Fowler نوشته شده: refactoring تکنیک مرتب/منظم سازی برای تجدید ساختار کد موجود است. تغییر ساختار داخلی کد بدون تغییر رفتار خارجی آن.

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