توسعه دهندگان خوب چگونه با کدهای بد کار می کنند؟
برنامه نویسی
فرض این که یک برنامه نویس هرگز حتی یک خط کدی هم ننوشته باشد که اشتباه و به درد نخور باشد فرض محالی نیست، با این وجود احتمال آن بسیار کم است. واقعیت این است که وجود باگ های امنیتی، اجزای تجربه ی کاربری غیر منطبق و نامیزان، و بسیاری اشتباهات دیگر در کارهای هر توسعه دهنده ای وجود دارد. این به آن معنا نیست که چنین فردی یک توسعه دهنده ی بد است. فقط می توان گفت که احتمال خطا برای هر انسانی وجود دارد. در عین حال، این چالش های کاری توسعه دهندگان را هدایت می کند تا بدترین اشتباهات را در کدها و زیرساخت های اساسی خود بیابند و برای رفع آن ها طرح ریزی کنند. با چند مثال می بینیم که آن ها چه طور این کار را انجام می دهند.
ایجاد چالش برای سیستم
چند سال پیش Netflix -شرکت آمریکایی ارائه دهنده ی خدمات آنلاین رسانه ای- مجموعه ای از ابزارهای مدیریت نرم افزار مبتنی بر رایانش ابری را که برای آزمون میزان قابلیت ارتجاع و بهبود پذیری سرویس های وب آمازون استفاده می شوند، با نام Chaos Monkey به صورت متن باز منتشر کرد.
وظیفه ی این نرم افزار این است که برای جلوگیری از وقوع شرایط بحرانی حاد در سیستم از قبل چنین شرایطی را در مقیاس کوچک تر شبیه سازی کند، به این صورت که به صورت دوره ای یک یا تعداد بیش تری از ماشین های مجازی را خاموش می کند و آن ها را از ادامه ی فعالیت باز می دارند. کار Chaos Monkey بر اساس این فرض است که بهترین راه جلوگیری از یک فاجعه ی بزرگ این است که قبلاً آن را در اندازه های کوچک تر تجربه کرده باشید، تا دست کم در زمان رو به رو شدن با مشکلی پیش بینی نشده آمادگی ذهنی برای مقابله با آن را داشته باشید.
احتمال خرابی در هر سیستمی وجود دارد و با شبیه سازی به روش های غیر قابل پیش بینی Netflix ارتجاع پذیری و قابلیت بهبود را در ساختار خود اعمال می کند. در واقع به جای اینکه شرایط را همیشه خوب در نظر بگیرد، فرض را بر این بگذارید که بالاخره روزی هم ممکن است سیستم های شما با مشکل رو به رو شوند.
سنجش کدها به بهترین شکل
Jeff Atwood توسعه دهنده ی نرم افزاری در یکی از پست های وبلاگ معروف خود Coding Horror در مورد روش هایی برای بهبود کدها به موردی مشابه بحث قبل اشاره می کند و پیشنهاد می دهد تا “بدترین بلاها را بر سر کد خود بیاورید.” او می نویسد: “من باور دارم یک نقطه ی عطف کلیدی در زندگی کاری هر برنامه نویس خبره ای زمانی است که متوجه می شود خودش بدترین دشمن خود است، و تنها راهی که می توان از آن برای کم کردن فشار این موضوع استفاده کرد پذیرفتن آن است. مثل بدترین دشمن خودتان رفتار کنید. تجربه ی کاربری خود را به چالش بکشید. کدهای خود را درهم بشکنید. بدترین بلاها را بر سر کد خود بیاورید.”
در عمل این کار به معنای آن است که “برنامه نویسان نیاز به یک آگاهی کاری خوب از حداقل اشتباهات رایج، یعنی موارد مکرری که برنامه نویسان متوسط معمولاً در آن ها دچار خطا می شوند دارند، تا بتوانند با آن خطاها مقابله کنند.” این حرف به معنای آن است که شما به عنوان خالق یک برنامه باید بهترین آزمونگر آن باشید و با دست کاری کدهای آن، تمام نقص ها و خطاهای موجود و ریشه ی آن ها را بیابید و اصلاح کنید.
Andre Medeiros مهندس واسط کاربری نیز این نکته را می افزاید که “همان طور که توسعه دهندگان به طور روز افزون باگ های موجود در کدهای خود را می گیرند و آن را عاری از نقص می سازند، ما هم باید با اشکال زدایی چنین کاری انجام دهیم. برای آن که از ایجاد باگ جلوگیری کنید کدها را طوری بنویسید که از دید هر برنامه نویسی ساده و روان باشند. برای درست کردن باگ ها کدهای خود را بفهمید. برای آن که کدهای خود را به طور دقیق بفهمید فرضیات خود را فهرست کرده و اعتبار آن ها را بسنجید و اثبات کنید، در صورت لزوم ابزارهای خطاگیری و اشکال زدایی ایجاد کنید.”
ایجاد بی ثباتی در کدها
البته یکی از بزرگترین مشکلات توسعه دهندگان با کدهایشان این است که مقدار زیادی از کدهای دیگر را به ارث می برند و از چیزهایی که دیگران نوشته اند استفاده می کنند. به این موضوع به چشم نیاز به فضای بیش تر در منزلتان نگاه کنید، بنابراین تصمیم می گیرید که یک طبقه ی دیگر بسازید. اما خانه ی شما از ابتدا با یک طرح معماری مناسب ساخته نشده است، و شما حقیقتاً نمی دانید که طرح ساختمان چیست و مثلاً کدام دیوارها حمال هستند. شما بهترین حدس خود را می زنید، یک طبقه را بالا می برید و . . . امیدوارید که به نتیجه ی دلخواه خود برسید. و سپس باز هم این کار را برای طبقات بعدی انجام می دهید. این شیوه ای است که بسیاری از سیستم های نرم افزاری که بخش های حیاتی سازمان را کنترل می کنند، بر اساس آن اداره می شوند. این رویکرد برای مدتی جواب می دهد، اما هر لایه ی جدید قابلیت آسیب پذیری بیش تری را اضافه می
کند، چنین شیوه ای در کدنویسی سیستم را به سمت بی ثباتی میل می دهد و امکان تخریب آن را بالا می برد، و مثل این است که آسمان خراش های لغزان را در یک محل زلزله خیز بنا کنید.
آن طور که مشهود است تا زمانی که همه ی کدنویسان مقید به پرداخت بدهی فنی -Technical debt- خود نباشند یعنی به جای آن که کدهای خود را تمیز و با دقت و حوصله بنویسند به دنبال انجام یک کار سریع و درهم باشند، کار چندانی نمی توان برای بهبود این شرایط انجام داد. با این حال شاید تمایل به دستکاری کدها نشان دهد که تا چه اندازه پرداخت بدهی های فنی می تواند حیاتی باشد.
How Good Developers Deal With Bad Code
