چیزهایی هست که نمی‌دانی؛ توصیه‌هایی به خودم وقتی یک برنامه‌نویس جوان بودم

گرگلی اُروس — وقتی به ده سال پیش خودم نگاه می‌کنم، یک سری چیزهایی هست که ای کاش زودتر شروع‌شان می‌کردم. عادت‌هایی که می‌توانست به من کمک کند تا سریع‌تر و متمرکز‌تر پیشرفت کنم. این‌ها توصیه‌هایی هستند که من به خودِ جوان‌ترم (که تازه اولین شغل حرفه‌ای‌اش را به عنوان توسعه‌هنده نرم‌افزار به دست‌آورده) می‌کنم.

۱. وقت بگذار و در سال ۲ کتاب درباره مهندسی نرم‌افزار بخوان

من هروقت که وقت گذاشتم و آهسته و پیوسته و درست‌ و حسابی یک کتاب پیشنهادی درباره مهندسی نرم‌افزار را خواندم، بهتر شدم. منظورم از مطالعه درست و حسابی؛ نوت برداشتن، بحث کردن با بقیه درباره قسمت‌های مختلف، کشیدن Doodle، امتحان کردن، مرور کردن و دوباره خواندن است.

ای کاش در چند سال اول کارم به عنوان توسعه‌دهنده چند کتاب مرتبط با نرم‌افزار می‌خواندم. من تازه از سال پنجم به بعد این کار را شروع کردم. کتاب‌هایی مثل C# in-depth و Clean Codes همه به من کمک کردند تا مهارت خودم را بالا ببرم. منظورم این نیست که من به شما یک سری کتاب خاص را معرفی کنم؛ بعضی از این‌ها اصلا تاریخ مصرف‌شان گذشته است. پیشنهاد من این است که خودتان به دنبال کتاب‌هایی بگردید که مفاهیم را عمیق‌تر از آن ‌چیزی که الان می‌دانید بگوید. این می‌تواند یک کتاب درباره یک تکنولوژیِ خاص یا درباره یک روش در مهندسی نرم‌افزار باشد.

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

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

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

بلندپرواز هم نباشید؛ هر شش ماه یک کتاب، هنوز هم فوق‌العاده است. یک کتاب را انتخاب کن و برایش وقت بگذار تا درست و حسابی مطالعه‌اش کنی. و وقتی که یکی دو کتاب خواندی، من کتاب How to Read a Book: The Classic Guide to Intelligent Reading را هم پیشنهاد می‌کنم؛ در ضمن روی این پیشنهادم خیلی هم جدی‌ام!

۲. زبانی که سرِ کار استفاده می‌کنی را عمیق یاد بگیر، تا تهِ ته!

من به عنوان یک کارِ پاره‌وقت، کدزنی را با PHP و کمی هم JavaScript شروع کردم. در دانشگاه هم C و ++C را یاد گرفته بودم که دوست‌شان نداشتم. برای اولین کار تمام وقتم سراغ #C رفتم. من کلی زبان را به صورت سطحی بلد بودم و در هیچ‌کدام‌شان استاد نبودم.

بعد از ۲ سال، از این که برای دیباگ‌کردن کد #C به توسعه‌دهنده‌های ارشد محتاج بودم کلافه شدم. یکی از توسعه‌دهنده‌ها که دیگر رفیق من برای دیباگ‌کردن کدها شده بود، جوری بود که انگار تمام ریزه‌کاری‌های #C را می‌داند. همین دوستم بود که به من کتاب C# in-depth را پیشنهاد کرد تا بخوانم، و من حسابی خواندمش! من تا تهِ این زبان را رفتم؛ حتی تا این که چگونه بازیافت حافظه (Garbage Collection) و Generics در پشت صحنه کار می‌کنند. من خودم را ساعت‌ها مجبور به خواندن می‌کردم تا مبحث‌های سختی مثل Covariance و Contravariance (مباحثی مربوط به Genericsها در برنامه‌نویسی شی‌گرا) را بفهمم.

یاد گرفتن عمیق زبانی که با آن کار می‌کردم یکی از بهترین تصمیماتی بود که گرفتم. در اولین محل ‌کارم تصادفا و با کمک یک توسعه‌دهنده ارشد این اتفاق افتاد. با این حال این دانش برای من هم در کار و هم در مصاحبه‌های شغلی به یک نقطه قوت تبدیل شد. بعدها در مسیر کاری‌ام، از قصد عمقِ زبان‌ها و فریم‌ورک‌ها را هدف می‌گرفتم و به سمت‌شان حمله‌ور می‌شدم! در شرکت اسکایپ به عنوان توسعه‌دهنده #C استخدام شدم؛ اگر چه بعدا مجبور شدیم از #C به JavaScript و WinJS برویم. پس من سراغ JS رفتم و آن‌قدر عمیق یاد گرفتم که پس از مدتی آن‌ را به صورت یک دوره درس دادم.

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

۳. با بقیه‌ی توسعه‌دهنده‌ها بیشتر جفت شو!

حس می‌کنم این‌روزها تیم‌شدن و جفت‌شدن دیگر مد نیست. وقتی من شروع کردم، برنامه‌نویسی دونفره، توسعه آزمون‌محور (TDD) و برنامه‌نویسی چندنفره (mob programming) از فعالیت‌های محبوب بودند. بعضی از بزرگترین پیشرفت‌ها و موفقیت‌ها هم بعد از تیم‌شدن آدم‌ها با همدیگر اتفاق می‌افتاد.

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

یک خاطره جذاب دیگرم توسعه آزمون‌محور (TDD) با یک مهندس دیگر بود. ما کیبورد را دائما برای نوشتن کد تست و کد اصلی جا‌به‌جا می‌کردیم. ۲ روز تمام کار ما همین بود؛ اجرا کردن یک بخش دشوار از سیستم. واقعا سخت است تا توصیف کنم چقدر این کار برایم آموزنده بود. وقتی که در نیمه راه تعداد حالت‌های خاص (Edge Cases) را شمارش کردیم، به طور کامل رویکردمان را عوض کردیم. بعد از این ماجرا ارتباط خوبی با هم برقرار کردیم که تا ماه‌ها بعد هم ادامه پیدا کرد.

.

۴. یونیت‌تست بنویس و آن‌ها را هنگام CI اجرا کن.

توسعه‎‌دهنده‌های ارشد معمولا درباره‌ی اهمیت تست‌های واحد (Unit Test) حرف می‌زنند. اما این تاکیدها خیلی متناقض به‌ نظر می‌رسد. چرا ما باید زمان زیادی برای نوشتن تست‌های بی‌اهمیت تلف کنیم؟ آن موقع من در مورد یونیت‌تست‌ها این‌طور فکر می‌کردم!

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

خود من، به شخصه دوبار لذت این لحظه‌ها را چشیدم. اولین بار زمانی بود که به عنوان یک پروژه‌ی فرعی برای یک کازینوی آنلاین کوچک، یک موتور بک‌اند ساختم. API، کارِ مدیریت پول واقعی را بر عهده داشت و من به شدت از اشتباه کردن می‌ترسیدم؛ پس برای تمام قسمت‌های کدم یونیت‌تست نوشتم. تحویل پروژه با تاخیر انجام شد که البته بیشتر تقصیر این تست‌ها بود؛ چون خیلی زمان می‌گرفتند. ولی این کار، به نظر کار درستی بود. من پروژه را در پایان قرارداد به مشتری تحویل دادم. ۲ سال بعد، آن‌ها به من گفتند که چطور این تست‌ها، آن‌ها را چندین بار نجات داده بود و اگر این تست‌ها نبودند، باگ‌ها به تولیدات آن‌ها صدمات جدی می‌زد.

لحظه بعدیِ من در ساخت نسخه وب اسکایپ بود. ما از صفر، یک رقیب برای Google Hangouts روی سایت web.skype.com ساختیم. یک تیم قوی پشت کار بود و ما یونیت‌تست کامل و تست‌های ادغام سنگین داشتیم. ۳ ماه بعد از شروع پروژه، یکی از مهندس‌ها تصمیم گرفت که ما باید ساختار کل پروژه را بازنویسی (Refactor) کنیم. این بازنویسی به نظر خطرناک می‌آمد و همه‌ ما مخالف انجام آن بودیم.

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

۵. ریفکتور را به یک عادت تبدیل کن و در ابزار ریفکتور استاد شو

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

بعدا اما با یک مهندس در اسکایپ آشنا شدم که مدام بازنویسی‌های ریز و درشت انجام می‌داد. همه‌ی آن‌ها هم منطقی به نظر می‌رسیدند و کد هر دفعه بهتر می‌شد. تازه هیچ‌وقت هم چیزی خراب نمی‌شد. اما چطور چنین چیزی ممکن بود؟

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

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

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

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

ولی حالا که با تعداد زیادی مهندس نرم‌افزار تراز اول کار کرده‌ام و حتی بعضی از آن‌ها را رهبری کرده‌ام، می‌بینم که هیچ‌چیزی برای ترسیدن وجود ندارد. بهترین مهندسان نرم‌افزار یک تلفیق از دانش یادگرفتنی و تجربه‌‌های در میدانِ عمل‌اند. دانش را می‌توانی یاد بگیری؛ برای تجربه اما، باید به دنبالش بروی!

به دنبال فرصت‌هایی بگرد تا روی تکنولوژی‌ها و حوزه‌های متفاوت و پروژه‌های چالش‌برانگیز کار کنی. برای من حدود ۷ تا ۸ سال طول کشید تا به جایگاهی برسم که خودم را در سطح ارشد بدانم. همزمان بعضی‌ها با پیوستن به جاهای مستعدِ رشدِ بالا مثل Uber در عرض ۳ یا ۴ سال به این جایگاه می‌رسند. تفاوتش؟ آن‌ها روی پروژه‌های چالشی کار کردند، برای رسیدن در سطح دیگران تلاش کردند و حتی گاهی در میانه‌ی راه تیم‌شان را عوض کردند تا شروع جدیدی داشته باشند. آن‌ها داوطلب شدند تا بر روی پروژه‌های جدید کار کنند و تکنولوژی‌های جدید را به عنوان اولین نفر در تیم امتحان کنند. من هم نهایتا به چنین آدمی تبدیل شدم، ولی نه در طی همان سال‌های اول!

۷. هرچیزی که یاد گرفتی، یاد بده!

بهترین راه برای یادگرفتن چیزی، درس دادن آن است. من خیلی اتفاقی وارد این موضوع شدم. سال ۲۰۱۰، شروع به ارائه‌دادن روی .NET کردم. ارائه‌های من خوب نبودند ولی من چیزهای زیادی، آن‌ هم فقط هنگام آماده‌کردن مطالب آموختم.

این روزها، وقتی می‌خواهم چیزی را درست و حسابی یاد بگیرم، سعی می‌کنم تا یک سخنرانی درباره آن انجام دهم. من یک سال پس از پیوستن به Uber در ۲۰۱۷ پیشنهاد دادم تا یک ارائه با عنوان «اوبر چگونه از تغییرات بک‌اند در مقیاس بالا عبور کرد.» انجام دهم. خودم هم دقیق نفهمیدم چگونه این کار انجام شد! تا قبل از آن من بیشتر در کار توسعه‌ی موبایل و مدیریت تیم موبایل بودم. برای ارائه، هیچ چاره‌ای جز این که از سیر تا پیاز همه‌چیز را یاد بگیرم نداشتم. البته کلی از انجام این ‌کار لذت بردم. برای این ارائه، نزدیک به ۱۰۰ توسعه‌دهنده‌ ثبت‌نام کردند.

خیلی‌های دیگر هم به این روش ایمان کامل دارند، از جمله «شان وانگ» که یک چهره برجسته در این متد ملقب به #LearnInPublic است. داستان پیشرفت او از داستان من هم تحسین‌برانگیزتر است: از تغییر شغل پی‌در‌پی تا رسیدن به پست‌های ارشد در Netlify و AWS در تنها ۴ سال. بعد هم نوشتن یک کتاب درباره‌ی چیزهایی که یاد گرفته است. نکته‌ی جذاب درباره یاد دادن به دیگران این است که برایت حکم برد-برد دارد. نه تنها تو در هنگام تدریس چیزهای جدیدی یاد می‌گیری، بلکه به دیگران هم کمک می‌کنی و الهام‌بخش آن‌ها می‌شوی.

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

ترجمه از:

Advice to Myself When Starting Out as a Software Developer” by Gergely Orosz

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

نوشته چیزهایی هست که نمی‌دانی؛ توصیه‌هایی به خودم وقتی یک برنامه‌نویس جوان بودم اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی

دیدگاهتان را بنویسید