در فرایند تولید نرم افزار دو نوع پیچیدگی وجود دارد. پیچیدگی ذاتی (essential complexity) به نوعی از پیچیدگی گفته می شود که در ذات برنامه است و از مساله ای که حل می شود نشعت می گیرد. مثلا اگر قرار است برنامه شما سه مساله خاص را حل کند، این سه مساله از پیچیدگی های ذاتی برنامه هستند. نوع دیگر پیچیدگی نوع تصادفی است (accidental complexity) که به پیچیدگی هایی گفته می شود که مهندسان تولید کرده و در ذات مساله قرار ندارند. مثلا پیچیدگی استفاده از زبان های سطح پایین مثل assembly، ویرایش یک فایل با format بسیار پیچیده و یا طول کشیدن فرایند تست از پیچیدگی های تصادفی هستند.
این مطلب در مقاله بسیار مشهور no silver bullet فرد بروکس مورد بررسی قرار می گیرد. بروکس مطرح می کند که پیچیدگی های ذاتی برنامه ها تا حد زیادی حل شده اند و برای پیشرفت های شدید در هر ده برابر بهتر شدن، باید چندین متد مختلف و با قدرت زیاد تولید شوند.
مساله ای که من در این جا قصد مطرح کردنش را دارم مطالب درون مقاله نیست، بلکه می خواهم در باره اهمیت این موضوع صحبت کنم که ما به عنوان برنامه نویس بتوانیم پیچیدگی های تصادفی را تشخیص دهیم و در مواقع لازم ابزار های مناسب برای رفع این پیچیدگی ها را تولید کنیم. اگر پیچیدگی های تصادفی جلوی پیشرفت کار را بگیرند، ما در رقابت از کسانی که این پیچیدگی ها را برای خود حل کرده اند عقب خواهیم ماند و همچنین تولید نرم افزار برایمان کند خواهد شد. استفاده از ابزار های نوشته شده خاص برای پروژه، نوشتن تست، Continuous integration ، استفاده از زبان های مناسب و framework ها مناسب برای مساله ای که آن را حل می کنیم و بسیاری موارد دیگر از این دسته ملاحظات هستند.
برنامه نویس های مختلفی را دیدم که از ابزار های اشتباه و روش هایی برای انجام کاری استفاده می کنند و آن وقت به علت اشتباه خود مساله را پیچیده می یابند. برنامه نویسی دیدم که چون با زبان جاوا کد می زد و کامپایل کردن یک پکیج برایش سخت شده بود. به این دلیل تصور می کرد که برنامه نویس بسیار خوبی است و کارهای پیچیده ای انجام داده است. همچنین برنامه نویسی دیگر را در جایی دیدم که به جای انجام یک کار تکراری به شکل خودکار با یک ابزار آن را دستی انجام می داد و ایراد می گرفت که او نباید این کار را انجام دهد. به خاطر می آورم که در گذشته خودم کارهای مختلفی را از روش سخت انجام داده ام و به همین دلیل پروسه انجام کار برایم سخت به نظر آمده بوده است. مثلا یک بار به جای visualize کردن یک سری داده برای درک بهتر با نوشتن آن در فایل به شکل آرایه ای دو بعدی از اعداد سعی می کردم آن را debug کنم که یافتن مشکلی ساده را برایم سخت کرد. و یا همین چند روز پیش به علت انتخاب کردن config اشتباه در visual studio هنگام کار با پروژه ، حدود یک ساعت تمام log های visual studio را برای یافتن اشکالی که اصلا وجود نداشت طلف کردم. اگر کدی نوشته بودم که پروژه ام انتخاب config اشتباه را به من گزارش دهد، امکان وجود این خطا اصلا وجود نداشت.
به همین دلیل یادگیری کار با سیستم های build محیطی که با آن کار می کنید و editor های مربوطه مثل Unity و visual studio برای هر برنامه نویس جدی لازم است. من خود چندان با ساخت extension برای visual studio آشنا نیستم. اندکی اطلاعات دارم ولی هرگز چیز جدی با آن نساخته ام. قصد دارم به زودی ضعف خود را در این زمینه جبران کنم. خوشبختانه در Unity تجربه نسبتا زیادی در ساخت اسکریپت های editor دارم و بارها برای کارهای مختلف در پروژه های مختلف ابزار های، ویرایش داده، ساخت build و ... ساخته ام. این کار به کم شدن اشتباهات و از بین بردن پیچیدگی های تصادفی کمک می کند.
