چند توصیه برای دوستان برنامه‌نویس جوان‌ترم!

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

بر خلاف مطلب‌های دیگه که توی ویرگول می‌نویسم از ابتدا، این مطلب‌ها ظرف چند ماه، توی یه کانال تلگرامی نوشته شده با آدرس زیر. اگر دوست داشتی اونجا هم می‌تونی منو دنبال کنی.

https://t.me/terminal_stuff

اما برسیم به توصیه‌ها:

توصیه‌ی اول: جای راحت

حتما سعی کنید برای برنامه‌نویسی جای نشستن‌تون مناسب و راحت باشه.

به چند تا دلیل:

• تعمیر «کمر» اصلا آسون نیست.
• قراره سال های زیادی تو این حالت بشینید و اگر یکم هم بد باشه تأثیرات زیادی داره.
• اگه جاتون ناراحت باشه احتمالا زودتر خسته می‌شید، بازدهیتون کم میشه و حواس‌پرتیتون بیشتر میشه. در واقع ممکنه تو یه حالت نامناسب بشه سریال دید ولی نمیشه برنامه نویسی کرد چون تمرکز بیشتری لازم داره. :)

شمایی که میگی نه من از هفته دیگه درست میشینم پشت میز، با شما هم هستم.

توصیه‌ی دوم: نشستن در حین کار با لپتاپ

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

برای بهبود وضعیت:

• حداقل کاری که می‌تونید بکنید اینه که یه موس و کیبورد بگیرید و وصل کنید بهش. لپتاپ هم جای بالاتری بذارید تا گردنتون هم اذیت نشه. با ۳۰۰-۴۰۰ هزارتومن می‌تونید یه موس و کیبورد نسبتا خوب بگیرید.
• اگر جای ثابتی هستید بهتره مانیتور هم داشته باشید. با حدود ۴ ملیون می‌تونید یه مانیتور IPS Full HD بگیرید. البته که عالی نیست ولی خب.

https://ergonomictoolbox.com/ergonomics/5-reasons-why-laptops-are-bad-for-your/

توصیه‌ی سوم:‌ ویرایشگر متنی شما

برای editorتون ارزش قائل باشید و بهش مسلط باشید.

چرا:

• ادیتور/IDE برای برنامه‌نویس‌ها مثل آچاره. اگر کسی از دور نگاه کنه و ببینه که خوب استفاده نمی‌کنیم فکر می‌کنه آدم باسوادی نیستیم.
• وقتی می‌خواید یه تغییری تو کد بدید و نتیجه رو ببینید بهتره که در کمترین زمان بتونید انجام بدید تا ایده‌اش نپریده و خلاصه feedback loop رو کوتاه تر میکنه.
• ابزارهایی که وجود دارن، برای هم‌صنف‌ها و همکارهای شما ساخته شده پس احتمال خیلی زیادی داره که شما هم بهش نیاز پیدا کنید. اگر بلد نباشید احتمالا مجبورید از یه راه سخت‌تر برید. مثلا refactor یا دیباگ ممکنه خیلی براتون ساده‌تر باشه. ممکنه هم از یه سری چیزا چون جالب نیستن تصمیم بگیرید استفاده نکنید مثل version control

چطوری:

• می‌تونید ویدیوی آموزشی ببینید. خیلیا تنظیم می‌کنن که کلیدهایی که می‌زنن رو تصویر نشون داده بشه، پس می‌تونید کامل یاد بگیرید.
• یکسری cheat sheet هم وجود داره که می‌تونید استفاده کنید.
• توی تنظیماتش بگردید و دستکاری کنید و سرچ کنید تا به بهترین شکل مناسب شما بشه.
• اگر کاری می‌خواید انجام بدید که سخته یا باید از ادیتور خارج بشید، سرچ کنید «انجام این کار در ادیتور فلان» و ببینید راهی هست یا نه. مثلا edit remote file in YOUR_EDITOR
• لیست پلاگین‌های به درد بخور رو تو اینترنت سرچ کنید و با احتیاط نصب کنید. همچنین می‌‌تونید ببینید دوستاتون از چه پلاگین‌هایی استفاده می‌کنن. شاید حتی تو گیتهاب/وبلاگشون گذاشته باشن.

قسمت آخر (برای اینکه تو این مطلب از vim هم اسمی آورده باشم)

ابزارتون آگاهانه انتخاب کنید. قرار نیست چون همه از ابزارهای Jetbrains یا VS code استفاده می‌کنن شما هم استفاده کنید. البته که احتمالا کیفیت خوبی هم داره ولی تنها انتخاب نیست. حتی اگه از اونا استفاده می‌کنید می‌تونید شخصی‌سازی کنید.

ادیتورهای دیگه‌ای هم هستن که می‌تونید تا انتها شخصی‌سازیشون کنید و قابلیت‌های مورد نیاز رو به شکل مورد نیازتون بهشون اضافه کنید. Vim و neovim و emacs نمونه‌های مهم هستن. شخصی‌سازی به شما کمک می‌کنه به بهره‌وری بیشتری برسید. البته که باید دقت کنید خود شخصی‌سازی هم ازتون وقت می‌گیره.

کلیدواژه‌ی lsp هم مدنظر داشته باشید. به کمک این استاندارد (که ٰVS Code استانداردش کرد) ابزارهای auto complete مختلف (در واقع language server) تحت این پروتکل با ادیتور صحبت می‌کنن و می‌تونید از موتور اتوکامپلیتی که برای ادیتور شما نیست هم به راحتی استفاده کنید. چون همگی از یک پروتکل واحد پشتیبانی می‌کنن.

توصیه‌ی چهارم: ترویج علم

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

+ برای بقیه مفید باشید: خودتون چقدر از Stackoverflow استفاده کردید؟ چقدر فیلم های جادی رو دیدید؟ (به طول مثال) همین چنل رو چرا دنبال می‌کنید؟

+ برای آینده شغلیتون مفید باشید: اگر به دیگران چیزی یاد بدید، برای خودتون برند شخصی ساختید. یه جور نمونه کار می‌شه. براتون موقعیت‌های شغلی (نه فقط معلمی) هم میاره به زودی.

+ برای مشکلات بعدیتون مفید باشید: شاید به نظر بیاد احتمالش کمه ولی برای من که کم پیش نیومده که به یکی از مطالب قبلیم سر بزنم و مرور کنم. ما فراموشکاریم و اتفاقا چیزایی که یه زمانی خودتون نوشتیم بهترین چیز برای یادآوری اون موضوعه. چون به زبون خودمونه. به چشم جزوه نوشتن بهش نگاه کنید.

اما چه کارهایی می‌تونی بکنیم؟ اینا نظرات منه، قطعا میشه بهتر و کامل ترش کرد. استقبال می‌کنم.

• وبلاگ فارسی بنویسید. مخاطب وبلاگ فارسی معمولا کسیه که دوست داره شروع کنه ولی زبان انگلیسی بلد نیست که مطالب انگلیسی رو بخونه یا کلا با موضوع آشنا نیست که خودش سرچ کرده باشه.
• وبلاگ انگلیسی بنویسید. اگر زبانتون خوبه یا حتی معمولیه چرا که نه، اینطوری به آدمای بیشتری کمک کردید. اگر هرکس به زبان مادری خودش درس میداد چقدر علم ما کمتر بود؟
• فیلم ضبط کنید.
• منتور/معلم می‌تونید بشید.
• تو فروم‌های پرسش و پاسخ فعال باشید: اینجا خیلی باید دقت کرد. فروم منظورم جاییه که توش سوالات به درد بخور پرسیده می‌شه و جواب‌های به درد بخوری داده می‌شه و برای عموم قابل دسترسی و سرچه.

نمونه چیزایی که مناسب نیست:

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

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

به عنوان نکته آخر هم سعی کنید تو کمک به دیگران، همچنان برای وقت خودتون ارزش قائل باشید و کار تکراری نکنید. اگر جواب سوالی جایی هست، شما دوباره جواب ندید. اگر با سرچ می‌تونه به مطالب قابل قبولی برسه شما دوباره وقت نگذارید.

توصیه‌ی پنجم: مدام ایده بزنید

یه عبارتی به کار می‌برن به اسم «ماهیچه‌ی خلاقیت»، تعبیرش هم اینه که هرچی بیش‌تر از خلاقیتتون استفاده کنید مثل یه ماهیچه قوی‌تر میشه. برای برنامه‌نویسی هم به این ماهیچه نیاز داریم که بتونیم مسائل رو حل کنیم. البته منظورم این نیست که باید خودمون ایده بزنیم که یه درخت باینری رو برعکس کنیم، برای همین کارهای روتین هم نیاز به ایده داریم.

حالا چطوری ایده بزنیم و تمرین خلاقیت کنیم؟

• برای مسائل زندگی که حل نشده راه حل بدید، بعدا اگر حل شدن با راه حل خودتون مقایسه کنید و ایده بگیرید.

مثلا دارن دوربین زیر نمایشگر می‌سازن، فکر کنید که چطوری چنین چیزی ممکنه؟ یا چرا ممکن نیست؟

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

مثلا صفجه نمایش لمسی می‌سازن، بهش فکر کنید چطوری ساخته شده؟ بعد برید سرچ کنید که واقعا چطوری ساخته شده.

یا مثلا یه برنامه هست که مصرف جوهر پرینتر رو کم می‌کنه، اول فکر کنید چطوری کار می‌کنه بعد برید سرچ کنید.

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

مثلا موتور هواپیما ایده‌ کارکردش چطوریه؟ آیا میشه تو ماشین لباسشویی هم استفاده بشه؟ تو ابمیوه گیری چی؟ اگه بخواد بشه چطوری میشه؟ اگه قطعا نمیشه چرا قطعا نمیشه؟

• ایده‌هاتون رو هرچند احمقانه با دیگران به اشتراک بگذارید. خیلی اوقات ایده‌های خوب از پردازش یه ایده بد توسط یه آدم دیگه به وجود میاد. اینطوری خودتون هم یاد می‌گیرید ایده هاتون رو بهتر کنید.

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

این دو تا مطلب هم جالب بودن. مثلا ایده‌ی ۶ کلاه رو مطرح کرده بود یکیش.

توصیه‌ی ششم: خوب تعامل کنید

این قبوله که عمده‌ی کار برنامه‌نویس‌ها پشت کامپیوتره اما یه قسمت مهمش هم اینه که بدونیم پشت کامپیوتر چیکار باید بکنیم. و معمولا این دونستنه از تعامل با آدم‌های دیگه به دست میاد. حالا چه مدیر پروژه یا کارفرما یا مشتری یا ...

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

یه سری از این موارد توی کتاب «کدنویس تمیز» هست.

توصیه‌ی هفتم: به‌روش‌ها

پیگیر best practice ها باشید ولی آگاهانه بشکنیدشون.

به‌روش‌ها یا همون best practice ها کارهایی هستند که خوبه انجام بدیم و احتمالا اگه انجام ندیم داریم اشتباه میکنیم. پس می‌تونن به یه برنامه نویس تازه کار کمک کنن تا اصطلاحا idiomatic کد بزنه.

مثال ساده ش می‌تونه این باشه که اگه یه دستور یه بار قراره اجرا بشه لازم نیست ببریمش توی یه do while که شرطش falseئه.

اما آگاهانه شکستن به این معنیه که اگه یه مدت با این کار کردید و خبره شدید اگرچه «کلا اون رو اجرا می‌کنید» اما اگه جایی دقیقا می‌دونید دارید چیکار می‌کنید اشکالی هم نداره شکستنش. مثلا همین مثال بالا یه کاربرد معتبر داره و استفاده هم میشه.

یا مثلا گوتو رو تاکید دارن استفاده نکنیم اما برنامه‌نویس های خیلی خفن سی (مثلا کد sudo یا kernel یا ...)‌ رو می‌نویسن از گوتو استفاده می‌کنن. اما اونا حواسشون هست و به‌جا دارن اون قاعده رو می‌شکنن.

میشه گفت اگه یه پترن عجیب ببینیم دو حالت داره. یا طرف خیلی حرفه‌ایه و می‌دونه داره چیکار میکنه یا خیلی تازه کاره و نمی‌دونه داره چیکار می‌کنه.

توصیه‌ی هشتم: کد خوب بخوانید

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

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

توصیه‌ی نهم: دانش نامرتبط داشته باشید

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

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