در محل کار، مدیر بخش مهندسی از من خواست که دانش خود را بیشتر با بقیه اعضای تیم به اشتراک بگذارم. البته ما بررسی کد را با هم انجام می‌دهیم و روش‌های دیگری نیز برای گسترش دانش در تیم خود داریم. همچنین جلسات فنی برگزار می‌کنیم که در مورد چگونگی حل مشکلات موجود صحبت می‌کنیم. این فرصت خوبی است برای به اشتراک گذاری دانش تخصصی که می‌تواند به صورت مشاوره یا راهنمایی در مورد تکنیکی برای پیاده سازی چیزی باشد، اما خوب است که نوع دیگری از جلسات را برای حفظ انگیزه، فعال بودن و آنالیز تیم انجام دهید. من به چندین موضوع فکر کردم تا بتوانم در مورد آنها صحبت کنم که شامل موارد فنی از این قبیل بودند: DevOps، سیستم‌های توزیع شده، برنامه نویسی فانکشنال و موارد هیجان انگیز دیگر. اما بعد فهمیدم که تیم از نظر فنی بسیار خوب است و همه اعضا برنامه نویسان بسیار توانمندی هستند. ببینید من از واژه برنامه نویس استفاده کردم، اما این چیزی است که ما هستیم؟ قطعا نه. عنوان شغلی می‌گوید مهندس نرم افزار ،اما این همه کاری است که ما انجام می‌دهیم؟ نوشتن کد؟ فکر نمی‌کنم اینطور باشد. من شروع به نوشتن افکارم کردم و آنها را در قالب این مقاله قرار دادم. با فكر كردن در مورد آن، بسیاری از ما متوجه پیچیدگی مهندسی نرم افزار نیستیم و وظایف آن را به حداقل می‌رسانیم. خود من علاوه بر نوشتن كد، كتاب هم می‌نویسم یا ویژگی‌های جدیدی را حفظ و پیاده‌سازی می‌كنم، اما کل داستان بسیار پیچیده‌تر از این است.
تفاوت برنامه نویس، توسعه دهنده و مهندس
سوء تفاهم نشود. نقش‌های زیادی وجود دارد و ما در موارد مختلف این عناوین را به خود نسبت می‌دهیم: مهندس نرم افزار ، توسعه دهنده نرم افزار ، برنامه نویس و برنامه نویس کامپیوتر. توجه داشته باشید که این کلمات با هم تفاوت دارند و هر کدام معنی خود را دارد. من معتقدم که باید موارد را به درستی نام‌گذاری کنیم و نقش‌ها را به شیوه‌ای بهتر و با انتظارات متفاوت از هم جدا کنیم.
برنامه نویس
برنامه نویس کسی است که کد را می‌نویسد و همین. یک برنامه نویس بیش از حد به معماری نرم افزار یا طراحی اهمیت نمی‌دهد. او مشخصات کامل آنچه را که برای پیاده سازی لازم دارد به دست می‌آورد، کد را می‌نویسد و آن را تحویل می‌دهد. همچنین در مورد نحوه استقرار، محل اجرا یا نحوه استفاده از آن تفکر زیادی نمی‌کند.
توسعه دهنده
یک توسعه دهنده نرم افزار بیشتر به طراحی و معماری اهمیت می‌دهد و علاقه زیادی به محل استقرار، نحوه اجرا یا طرز استفاده از آن ندارد.
من نمی‌گویم همه برنامه نویسان یا توسعه دهندگان اینگونه هستند، فقط می‌گویم این موارد باید دغدغه آن نقش‌ها باشد. اگر خود را یک برنامه نویس یا توسعه دهنده می‌دانید و فراتر از آن پیش می‌روید، بسیار عالی است. تمام هدف این مقاله به اشتراک گذاشتن دیدگاه‌ها و تعاریف در مورد نقش مهندس نرم افزار است.
مهندس نرم افزار
یک مهندس نرم افزار دقیقا مانند یک برنامه نویس و توسعه دهنده، به نرم افزار اهمیت می‌دهد. همچنین کد می‌نویسد و مطمئن می‌شود که مطابق انتظار کار می‌کند. به علاوه نگران طراحی، معماری و اجرای بهترین متدها از هر جنبه در مورد نرم افزار نیز هست.
- ساختار: ما به عنوان یک مهندس نرم افزار، نگران ساختن یک نرم افزار خوب هستیم. نه تنها در مورد خود نرم افزار بلکه در مورد بلوک‌های ساخته شده، انتخاب یا ساختن صحیح و اجرای سطوح مناسب در تلاشیم تا تعمیر و نگهداری آسان‌تر باشد.
- عملکرد: به عنوان یک مهندس نرم افزار، می‌دانیم که لازم نیست همیشه چیز جدیدی بسازیم. فقط می‌توانیم نرم افزار موجود را اجرا کنیم و روی آن کار کنیم، نظارت کنیم، مدیریت کنیم و مطمئن شویم که به درستی کار می‌کند تا هر کاربر بتواند اهداف خود را با آن محقق کند. همچنین می‌دانیم که نرم افزاری که می‌سازیم باید توسط کسی (بعضی اوقات خود ما) اداره شود، بنابراین برای مدیریت راه‌هایی برای ارتباط و تعامل با آن بسازیم.
- مستندسازی: این یک نکته است که معمولا فراموش می‌شود. ما موارد مختلفی از کتابچه‌های راهنما و انواع دیگر اسناد را می‌خوانیم و آنها را تفسیر می‌کنیم تا از نرم افزار شخص ثالث استفاده کنیم، اما برای اینکه دیگران از نرم افزار ما استفاده کنند یا اینکه آن را بفهمند و طرز صحیح استفاده از آن را بدانند، باید مستنداتی را اضافه کنیم.
ما در مورد نرم افزار اطلاعات داریم
در نظر داشته باشید که باید در مورد آن چیزهای زیادی بدانیم، نه تنها برای نوشتن آن بلکه برای استفاده موثر هنگام ساختن آن.
همچنین باید مطمئن شویم که این کار به خوبی انجام می‌شود. بنابراین نگران معماری، طراحی و تصمیم گیری صحیح از ابتدا هستیم که شامل انتخاب پشته مناسب، ساخت انتزاع‌های مناسب و استفاده از بهترین شیوه‌هایی که می‌شناسیم، می‌شوند.
به علاوه برنامه‌ای که می‌سازیم باید قابل استفاده باشد. بنابراین نگران مواردی مانند CICD، نظارت و نحوه ورود به سیستم هستیم. سعی کنیم آن را به گونه‌ای بسازیم که عیب یابی و یافتن مشکلات در هنگام تولید آسان باشد و همچنین راه‌هایی برای تعامل با آن برای جمع آوری اطلاعات یا گزارش‌ها از طریق خط فرمان را نیز در صورت لزوم در نظر بگیریم.
ضمن اینکه تمامی این راهکارها باید جواب دهد. بنابراین نگران تست و تأیید هستیم تا رفتار سیستم‌هایی که ایجاد می‌کنیم قابل پیش بینی، تأثیرگذار و بدون اشکال باشد. به این صورت که برای مجموعه‌ای از ورودی‌ها، خروجی چیزی باشد که انتظار داریم.
ما نه تنها می‌دانیم که چگونه نرم افزار را بسازیم، بلکه در مورد بسیاری از چیزهای پیرامون آن نیز اطلاعات کافی داریم.
- می‌دانیم که باید اجرا شود: بنابراین در مورد زیرساخت‌ها و سیستم‌عامل‌ها اطلاعات داریم، اما ادمین سیستم نیستیم.
- می‌دانیم که با نرم افزارهای دیگر در ارتباط است: بنابراین در مورد پروتکل‌های شبکه و ارتباطات و همچنین سیستم‌های توزیع شده اطلاعات داریم، اما ما مهندس شبکه نیستیم.
- می‌دانیم که باید داده‌ها را در جایی ذخیره کند: بنابراین در مورد پایگاه داده و مدل سازی داده‌ها اطلاعات داریم و باید این کار را به طور موثر انجام دهیم و بدانیم که در صورت لزوم چگونه عملکرد را تنظیم کنیم، اما مدیر سیستم نیستیم.
- می‌دانیم که عملکرد آن باید به روشی خاص باشد: بنابراین نگران تست در چندین سطح و از انواع مختلف هستیم مانند عملکرد، تست واحد، یکپارچه سازی، تست رابط کاربری و تجربه کاربری و تست API. اما مهندس QA نیستیم.
ما بخشی از یک تیم هستیم
همه آنچه که قبلا ذکر کردم بسیار دشوار و پیچیده است. به علاوه باید با انسان‌های دیگر نیز کار کنیم، ما عضوی از تیمی هستیم که معمولا افرادی از زمینه‌ها و تخصص‌های گوناگون هستند مثل مدیر (گاهی اوقات غیر فنی) یا مدیر پروژه، یک مدیر مهندسی، برخی از مهندسان فرانت-اند، متخصصان کیفیت و موارد دیگر. ما باید از طرق مختلف با یکدیگر ارتباط برقرار کنیم و همه در پیشرفت پروژه با هم سهیم شویم.
- جلسات: ما باید در جلسات شرکت کنیم تا در مورد کار انجام شده مختصات فنی را توضیح دهیم و اگر کسی در مورد چیزی که ما می‌دانیم به کمک نیاز دارد، مشکلش را برطرف کنیم.
- مستندات: این به شکل‌های مختلفی مانند مشخصات فنی و مستندات API وجود دارد. همه این موارد در پایان روز ارتباطی است که باید به طور مداوم جریان داشته باشد، فقط به این دلیل که ما تصمیم می‌گیریم آن را به صورت متن مورد نظرمان ذخیره کنیم تا هر وقت کسی نیاز به استفاده از API یا چگونگی پیاده سازی چیزی و روند تفکر پشت آن داشته باشد، مجبور نباشیم دوباره آن را تکرار کنیم.
- بازبینی کد: این مورد خوبی است، زمانی است که به افراد کمک می‌کنیم تا کارشان را به شکل بهتری انجام دهند، همچنین وقتی که برای بهبود کار خود کمک می‌گیریم و از دیگران می‌آموزیم. این مورد نیز فرم دیگری از ارتباط است.
ارتباطات همه چیز است
تنها چیزی که دوست دارم در این مقاله به آن اهمیت دهید این موضوع است. مهارت‌های سخت برای نقش مهندسی نرم افزار بسیار مهم هستند. ما باید در مورد نحوه نوشتن کدی که عملکرد بهتری دارد فکر کنیم. اما اگر نتوانیم با دیگران کار کنیم و نحوه تعامل با آنها را بلد نباشیم، هیچ یک از اینها مفید نخواهد بود. برای کار با دیگران، ارتباط همه چیز است.
- تصور نکنید افرادی که می‌خواهید با آنها صحبت کنید، همان زمینه و تخصص شما را داشته باشند. همیشه با به اشتراک گذاشتن اطلاعات مورد نیاز برای درک مشکل موجود یا راه حل ارائه شده خود شروع کنید.
- مخاطبان خود را بشناسید. هنگام برقراری ارتباط تنظیم لحن و زبان بسیار مهم است.
- همیشه سوال کنید. شما هرگز نمی‌دانید که دیگران چه زمینه‌ای دارند و تنها راه برای فهمیدن آن پرسیدن است. وقتی چیزی واضح نیست یا خود را در تصور چیزی می‌بینید، وقت آن است که باید بپرسید. فقط برای اطمینان از اینکه همه در یک سطح هستند و درک یکسانی دارند می‌توانید یک سوال بپرسید، زیرا چیزی که ممکن است زاید به نظر برسد را نمی‌دانید.
وقتی فهمیدید که همه چیز را نمی‌دانید، متوجه خواهید شد که بقیه افراد نیز همه چیز را نمی‌دانند، پس مجبور نیستید هر چیزی را بدانید. هرکسی در حیطه تخصصی خود می‌داند و راجع به برخی از مواردی که در معرض آن قرار گرفته یا مطالعه کرده اطلاع دارد و برخی دیگر را نادیده می‌گیرد. بنابراین فراموش نکنید که همه ما فقط با گفتگو با یکدیگر، برقراری ارتباط و به اشتراک گذاشتن دانش خود قدرتمندتر می‌شویم.
دیدگاه و پرسش
در حال دریافت نظرات از سرور، لطفا منتظر بمانید
در حال دریافت نظرات از سرور، لطفا منتظر بمانید