در این مقاله من خلاصه ای از موارد مهم رو از فصل اول کتاب مهندسی نرم افزار گوگل نوشته ام ، امیدوارم که براتون مفید باشه
مهندس نرم افزار کیست؟ اين عنوان فصل اول كتاب مهندسی نرم افزار در گوگل هست و نویسندگان اشاره ميكنن به تفاوت های یک مهندس نرم افزار و یک برنامه نويس، كه شامل سه فرق اساسی در این دو نقش ميباشد:
نويسندگان كتاب تعریف یک مهندس نرم افزار رو اينچنین تعريف ميكنن، مهندس نرم افزار همان برنامه نويس هست منتهی تركيب شده با زمان و با مسئولیت های بیشتر و اشاره كرده كه برنامه نویسی يك بخش خیلی مهمی از توسعه نرم افزار هست و اشاره میکنه به نوع تسک های یک برنامه نويس و مهندس نرم افزار، که برنامه نويس فقط کارش نوشتن کد هست ولی مهندس نرم افزار وظیفه اش توسعه ، ويرايش و نگهداری اون کد هست .
و در ادامه با يك سوال مهم به سراغ تشريح كردن اون سه فرق یک سوال رو میپرسه و اون سوال اين است
انتظار شما از طول عمر كدي كه شما نوشتين چقدر است؟
و در جواب اين سوال اشاره ميكنه به عامل های زیادی از جمله dependencies های مختلف كه باعث تغيير در نرم افزار ميشن و در نتيجه به كلمه ديگه اشاره ميكنه به اسم تشخيص كه تشخيص دادن چقدر مهم است و تمایز اصلی یک برنامه نویس و يك مهندس نرم افزار هست.
این توانایی تشخیص دادن تفاوت اصلی هست كه به اسم پایداری (sustainability) شناخته ميشه و توضيح ميده كه برنامه شما زماني پايدار است كه در طول عمری كه شما برای نرم افزارتان پيش بينی كردين قادر باشين كه به تغييرات مهمي كه مياد سمت نرم افزار شما ، واكنش نشون بدين چه تغييرات بیزینسی و چه تغييرات تكنيكال و تاكيد مي كنه ما فقط دنبال توانايی هستيم و ممكنه كه شما توانایی پاسخ به تغییرات را داشته باشين ولی به دلايل ديگه مثل نداشتن اولويت يا نداشتن ارزش تغییرات جدید رو اعمال نكنين. ولی اگه اين امكان رو نداشته باشين كه واكنش نشون بدين به تغييرات شما در موقعیت خطرناکی هستين كه دست به دعا برمیدارین كه خدا كنه اين تغيير نياز جدی نشه. ولی به یک قانون اشاره میکنه شاید در کوتاه مدت نياز سراغتون نیاد ولی در بلند مدت حتما سراغتون میاد .
و در ادامه به تاثير تغييرات يك برنامه نويس و يك مهندس نرم افزار اشاره ميكنه كه تسك هاي يك برنامه نويس معمولا شخصی هست ولی تسك هاي يك مهندس نرم افزار روي يك تيم اثر ميزاره، و اشاره ميكنه به اين كه توسعه تيمي اين روزها يك مشكل جديد هست ولي ميتونه به شما توانايي توليد يك سيستم ارزشمند میده برخلاف برنامه هايی كه به صورت فردی نوشته شده اند.
سازمان دادن يك تيم ، عملكرد يك نرم افزار و تركيب پروژه ها از پيچيدگي هاي يك مهندس نرم افزار ميباشد. و اين مشکلات ميتونن رو مقياس دادن (scale) نرم افزار تاثير بزارن . همچنين اشاره كرده به اين كه مقياس پذيري ميتونه مشکلات ديگري هم داشته باشه از جنس ارتباط ، ارتباط بين انسان ها و بحث بين اونها.
در نهایت به این اشاره میکنه که مهمترین هدف یک مهندس نرم افزار هدفش پایداری و مدیریت هزینه های scale برای یک سازمان هست.
زمان و تغییرات
وقتي بحث تغييرات ميشه نويسنده به دو نوع نرم افزار اشاره ميكنه کدهایی با عمر كوتاه و کدهایی كه هيچ پاياني ندارند و هميشه نياز به تغييرات دارن و از دلايلی صحبت ميكنه كه باعث سخت تغيير دادن نرم افزار در اينده ميشن يا كاملا جلو تغيير رو ميگيره .
دلايلي از جمله اشنا نبودن برنامه نويس با تسکی كه داره انجام ميده یا تخمين اشتباه در اندازه زمان تغييراتی كه نرم افزار نياز داره و اينها باعث ميشه كه جلوی تغییرات رو بگیره و شركت ها از يك جايی به بعد قيد توسعه محصول قديمی رو بزنن و تصمیم بگیرن که ديگه اپديتش نکنن و يك كد جديد رو بنویسن.
و در ادامه نويسنده اشاره ميكنه به دو نوع كد ، کدی كه فقط كار ميكنه در مقابل کدی كه قابل توسعه هست كه به يك قانون شبيه ميكنه به نام Hyrum
و اين قانون به اين اشاره ميكنه به بحث تغيير و حفظ نرم افزار در طول زمان و اشاره ميكنه كه اين هميشه کد های غیر قابل توسعه به وجود مياد و ما نميتونيم كه جلوش رو بگيريم که پیش نیاد بلكه فقط ميتونيم كه روندش رو کاهش بديم .
مقياس پذيری
ابتدای این بخش نویسنده دوباره مبحث پایداری رو بررسی میکنه و همچنین توانایی انجام تغییرات رو و اشاره میکنه که Codebase سازمان شما زمانی پایدار هست که قادر به انجام تغییرات در آن باشین بدون هیچ خطر خاصی و اگر ما این مسله توانایی رو پنهان کنیم به صورت خطی و در طول زمان هزینه به سیستم اضافه میکنیم و امکان مقیاس پذیری را از نرم افزار رو میگیریم.
و در ادامه به این مورد اشاره میکنن هزینه های توسعه فقط محدود به توسعه نیروهای انسانی نیست و خود توسعه خود جریان کاری(Workflow) شما هم مهمه، همانطور که خود نرم افزار نیاز به توسعه منابع داره مثل حافظه و پهنای باند نوع شکل توسعه نرم افزار و درگیری نیرو های انسانی با این شکل توسعه هم باید قابل توسعه باشن. مثلا اگه برای تست یکی از بخش های نرم افزار منابع بیشتری مصرف کنین و این به ازای هر نفر این منابع بیشتر مصرف میشه شما در حالت ناپایداری هستین و باید این روند رو بهبود بدین.
و در نهایت بعد از توسعه انسانی و جریان کاری ، مهمترین دارایی یک سازمان که همون Codebase اصلی هست هم باید قابل توسعه باشد .و چیزهای مختلفی میتونه جلوی این توسعه رو بگیره مثل رشد در چیزهای مختلفی در طول زمان مانند افزایش زمان بیلد نرم افزار یا افزایش لاگ های مربوط به سیستم کنترل نسخه و ممکن هست که اینها باعث بشن که مسیر توسعه خیلی راحت نباشه و باید مراقب باشیم که دچار مشکل قورباغه اپ پز شده نشویم.
و در ادامه نویسنده سیاست های مقایس پذیری رو به دو قسمت تقسیم کرده سیاست های که قابل توسعه نیستن و سیاست هایی که قابل توسعه هستن به خوبی. و این دو قسمت رو میشه در سازمان های خود پیدا کرد و دسته بندیشون کرد.
سبك سنگين كردن هنگام گرفتن تصميمات در زمان توسعه
گرفتن تصمیمات درست زمانی اتفاق میفته که ما به صورت کامل بدونیم چه چیزی رو میخواهیم توسعه بدهیم و یا کامل در جریان عمر نرم افزاری که روش کار میکنیم باشیم و میدونیم که چه جوری سیستم رو مقیاس بدیم و فیچر های جدید رو اضافه کنیم توسط مهندسان بیشتر این جمله ای هست که نویسنده درباره این تاپیک شروع کرده است.
وقتی بحث تصمیمات میشه نویسنده یک مثال خوب میزنه که تو مهندس نرم افزار هم مثل زندگی ما تصمیمات درست اتفاقای خوبی هم برامون رقم میزنه ولی خب اشاره میکنه که شاید همیشه هم خوب نشه ولی دلیلی نمیشه که شما از جملاتی مثل اینکه "به خاطر اینکه من گفته بودم" استفاده کنین و در گوگل از این جمله خیلی خوششون نمیاد و اشاره میکنه که تو تیم های مختلف یک نفر هست که باید بتونه برای هر موضوعی و یا هر تاپیکی راه های متنوع و مشخصی را پیشنهاد بده و هدف اینست که همه با این نظرات موافق باشن و مهم تصمیم جمعی هست نه فردی و این رو هم باید در نظر گرفت که همیشه تصمیم اشتباه پیش میاد و یکی از معیارهای تصمیم گیری بین ایده ها هزینه ها هست که به دو قسمت تبدیل میشه هزینه های کلی و هزینه های مهندسی.
و یک مثال خیلی جالب میزنن که منظور از هزینه چی هست ؟ منظور صرفا هزینه نرم افزاری نیست و هزینه تقسیم میشه به موارد مختلف مثل هزینه های مالی ُکه منظور پول هست ، یا هزینه منابع که منظورشون Cpu time هست ، هزینه های نیروی انسانی و میزان کارامد بودنشون و یا هزینه های تاثیر بر روی جامعه هم مهم هست این ها فقط نمونه هایی از هزینه ها هستن.
و به یک مورد جالب اشاره میکنن که اینکه همیشه شما پول تو حسابتون باشه و بتونین همه هزینه ها رو پرداخت کنین الزاما ارزش آفرینی نمیکنه و یکی دیگه از هزینه ها و ارزش های یک سازمان نیروهای یک سازمان هستن و نیروها هم باید احساس این رو کنن که ماژول خوبی رو توسعه میدن و در سیستم استفاده میشه و میتونن که ارزش آفرین باشن درون یک سازمان و اگه این مورد نباشه مشکلاتی که تا الان راجبش حرف زدیم پیش میاد و اگه یک نیرویی خوشحال باشه به راحتی میشه بر مشکلات غلبه کرد.
و در ادامه نویسنده اشاره میکنه به پارامتر های مختلف که جلوی هدر رفتن انرژی رو میگیرن از جمله فراهم کردن ساده ترین چیزها برای برگزاری جلسات مثل ماژیک که در همه کمدها ماژیک در انواع رنگ های مختلف وجود دارن که لحظه ای کمبود به وجود نیاد و از فکر خارج نشن.
نتیجه گیری
وقتی که صحبت از تفاوت برنامه نویس و یک مهندس نرم افزار میشه با دونستن موارد بالا که بهشون اشاره کردیم نتیجه این نیست که مهندسی نرم افزار از یک برنامه نویس برتر هست یا نه بحث نوع پروژه و اهمیت پروژه هست شاید ما تصمیم بگیریم و یک پروژه رو صرف ۳ روز توسط برنامه نویس توسعه بدهیم و بعد هم نیازی به توسعه اش پیدا نکنیم و حتی نیازی به بررسی موارد مختلف نباشه و بیشتر این تمایز به خاطر مدیریت و بهبود نرم افزار در طول زمان هست و اینکه نرم افزار قابل توسعه و قابل نگهداری بین یک تیم باشد و مهندس نرم افزار چنین وظیفه ای را دارد.
