پنج درس مهم از چهار سال کار به عنوان یک توسعه دهنده نرم‌افزار

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

جدول محتوا:

• هیچ وقت فرض نکنید
• مشکلات غیر فنی، سخت‌ترین مشکلات هستند
• اول فکر کرده، و سپس کد بنویسید
• چیزی که می‌سازید، از ابزاری که برای ساخت آن استفاده می‌کنید مهم‌تر است
• همه نقش‌ها اهمیت یکسانی دارند
• نتیجه گیری

هیچ وقت فرض نکنید

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

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

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

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

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

مشکلات غیر فنی، سخت‌ترین مشکلات هستند

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

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

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

اول فکر کرده، و سپس کد بنویسید

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

آشنا به نظر می‌رسد، نه؟ توسعه دهندگان شامل خود من، عاشق راه حل‌های خودکارسازی شده هستند.

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

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

چیزی که می‌سازید، از ابزاری که برای ساخت آن استفاده می‌کنید مهم‌تر است

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

منظور من را اشتباه برداشت نکنید، من هنوز هم عاشق آن‌ها هستم. اما پی بردم‌ام تا زمانی که ابزار مورد استفاده ما به عنوان توسعه دهندگان، ما را قادر می‌سازند تا کار را به اتمام برسانیم، مهم نیست که از چه ابزاری استفاده می‌کنیم. در توسعه‌دهی frontend، هر روز یک فریم‌وورک جدید منتشر می‌شود. با این که مهم است به عنوان یک توسعه دهنده با آن‌ها هم‌قدم بمانیم، اما نحوه کار یک چیز برای کاربران نهایی (افراد مهم) مهم نیست؛ فقط این که کار کند مهم است.

همه نقش‌ها اهمیت یکسانی دارند

من از پیش به اهمیت این که فرض نکنید هر غیر توسعه دهنده‌ای اشتباه می‌کند اشاره کرده‌ام. همچنین این که یاد گرفته‌ام هر عضوی که تیم شما را می‌سازد (تضمین کیفیت، مدیر پروژه، سهامداران دیگر و...)، به اندازه هر توسعه دهنده‌ای مهم است.

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

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

نتیجه گیری

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

منبع