جایگزینی اصول مهندسی نرم‌افزار با ابداعات و روش‌های نادرست و رنج حاصله

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

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

به عنوان مثال آنها مثل من و مدیران من نگران تغییرات در نرم‌افزار نیستند. چون از چیزی به اسم unit test استفاده کرده و این unit testها را هم به نحوی به ابزار buildی مثل TeamCity یا TFS معرفی کرده‌اند. هر وقت که check-inی در سورس کنترل برنامه اتفاق بیفتد، نتیجه تغییر حاصله در تمام unit testها بررسی شده و درست بودن یا نبودن تغییر بلافاصله مشخص می‌شود. حال من برنامه‌نویس ایرانی از همه جا بی‌خبر هم می‌خواهم مثل اونها در برنامه‌ام تغییر ایجاد کنم بدون داشتن این همه ترس. اما نمی‌توانم. چون آن‌ها ساختار و روش‌شان را برای استفاده از unit test آماده کرده‌اند. مثلاً بدنه متودها را کوچک نگه داشته‌اند، اصل Separation of Concern را رعایت کرده‌اند، در صورت لزوم از Mocking استفاده کرده‌اند و غیره و غیره. از این دست مثال‌ها زیاد می‌توان پیدا کرد.

این روزها این رنج را بیش از بیش احساس می‌کنم. اما نمی‌دانم با آن چه کنم. آیا چاره کار Freelance شدن است؟ آیا چاره کار عوض کردن شغل است؟ آیا چاره کار همکاری با پروژه‌های Open Source و در نیاوردن پول است؟ آیا چاره کار مهاجرت است؟ آیا چاره کار تاسیس شرکت شخصی و قبول همه مصائب شرکت‌داری است و پروژه گرفتن است؟ آیا …؟