آیا کسی هست که دور از چشم مادر دزدکی از آشپزخانه خوراکی برنداشته باشد؟ یا با جمع دوستان تا دیر وقت بیرون نمانده باشد؟ یا وقتی در پارک مشغول قدم زدن بوده برای کوتاه کردن مسیر از روی چمن راه نرفته باشد؟
آیا برنامه نویسی هست که حتی یک بار یکی از بهترین شیوه ها در برنامه نویسی که مانند قوانین حکاکی شده بر روی سنگ می باشند را نقض نکرده و فقط طبق همین شیوه ها پیش رفته باشد؟ با اطمینان می توان گفت که خیلی از برنامه نویسان این کار را قبلا انجام داده اند. اما شاید دلیل اینکه کد آنها از حالت معمول بهتر بوده این باشد که برخی از این قوانین را زیر پا گذاشته اند. حداقل این مساله باعث می شده که زیر سوال نروند یا کارشان را از دست ندهند یا شاید هم دستگاه در زمان اجرای برنامه آنها، منفجر نشود.
البته زیر پا گذاشتن قوانین هیچ وقت بدون ریسک نیست. اگر شما یک جراح مغز باشید واقعا باید از قوانین و اصول پیروی کنید اما وقتی در حال توسعه یک نرم افزار هستید چه حالتی می تواند ریسک را به حد نهایت برساند؟ برای نمونه وقتی توسعه نرم افزار برای یک پهپاد جنگی، مدیریت شبکه برق، تجهیزات پزشکی یا فضاپیما انجام می شود، توسعه دهنده باید با آرامش بیشتر و سرعت کمتر برنامه نویسی را انجام داده و به قوانین عمل کند. اما آن دسته از برنامه نویسانی که کارهای پرمخاطره ای ندارند که بیشتر ما هم همینطور هستیم، بهتر است که هر از گاهی قوانین خود برای توسعه را بازنگری کنند.
وقتی مشکلی برای حل کردن دارید که یافتن جواب آن با گوگل فقط 5 ثانیه طول می کشد، مزاحم همکار خود نمی شوید که این مشکل را در 10 دقیقه برای شما حل کند و اگر جواب در استک اورفلو هست از آن استفاده می کنید. طرفداران کدنویسی خالص مدعی هستند که نباید هیچ کدی را کپی کنید چون ممکن است که ندانید کد کپی شده چگونه کار می کند و این سخن بی راهی نیست.
اما در هر صورت شما در زمان یافتن یک راه حل، حتما جستجو می کنید. معمولا به راهنمای توابع یا اشیاء استفاده شده در راه حل نگاهی می اندازید. همچنین احتمالا نیاز هست که نام برخی از متغیرهای استفاده شده در راه حل را متناسب سازی کرده و جای مناسب برای قرار دادن تکه کد در برنامه اصلی را مشخص کنید. این کارها بدون داشتن حداقل درک از کد کپی شده امکان پذیر نیست.
نکته دیگری که برنامه نویسان خالص گرا به آن تاکید دارند این است که در کدهای کپی شده ممکن است از کاراکترهای غیرقابل مشاهده مانند تب و بک اسپیس استفاده شده باشد که در صفحه نمایش آن را مشاهده نمی کنید و می تواند در خروجی برنامه شما موثر باشد. استدلال این افراد این است که اگر می خواهید کد را کپی کنید حداقل خودتان تایپ آن را انجام دهید تا به طور ناخواسته کاراکترهای غیر قابل چاپی را وارد کد خود نکنید و باعث خرابکاری در پروژه نشوید. این نصیحت خوبی است اما موردی است که خیلی روی نمی دهد و حل کردن آن کار پیچیده ای نیست.
این نکته از پیروان مکتب متن باز که کپی کردن کل سورس کد یک پروژه متن باز به پروژه های اختصاصی بد است، کاملا صحیح است. نه تنها این کار غیر اخلاقی است همچنین باعث می شود تا کد پروژه اختصاصی دچار حفره های امنیتی شود چون احتمالا کد متن باز استفاده شده به طور مداوم تغییرات امنیتی را دریافت نخواهد کرد.
متاسفانه همیشه برنامه نویسانی وجود خواهند داشت که از کدهای متن باز سوء استفاده می کنند اما این افراد هزینه بالایی برای آن پرداخت می کنند. برای مثال می توان به پروژه Log4j اشاره کرد. این برنامه یک پروژه متن باز است که گزارشی از اطلاعات را برای مدیران سیستم ایجاد می کند. در اواخر سال 2021 اخباری مبنی بر حمله هکری به دلیل وجود یک حفره امنیتی به سرورهای شرکت های کلودفلیر، ماین کرفت، توییتر و بسیاری دیگر منتشر شد که به دلیل استفاده از برنامه Log4j به روز نشده در برنامه های این شرکت ها بوده است.
البته هیچ کس نمی خواهد که چنین اتفاقات بدی برایش پیش بیاید پس می توانید کدهای متن باز را کپی کنید اما این کار را به صورت اخلاقی انجام داده و در نهایت اگر می توانید کدهای خود را نیز متن باز کنید.
حفظ مالکیت همیشگی کد احمقانه است
قبلا جملاتی شبیه به این بیان می شد که کد شما مثل بچه شماست. شما آن را ساخته اید پس مسئول هر کاری که کد انجام می دهد هم هستید تا روزی که بمیرید. این جملات دروغی بیش نیستند. البته درست است که نمی توان فقط کد خود را به همکاران تحویل داد و هر وقت کسی سوالی در مورد آن داشت اظهار بی اطلاعاتی کرد. پس از تحویل کد همیشه سوالاتی پیش خواهد آمد حتی اگر بهترین مستندات هم برای پروژه ها تهیه شده باشد. بنابراین پس از تحویل کد در هفته یا ماه های اولیه در دسترس افرادی که کدها را تحویل می گیرند باشید.
همانطور که گفته شد برنامه نویس باید کد خود را در نهایت تحویل دهد. گاهی اوقات پای مسائل زندگی به میانه کار کشیده می شود. خانواده نیاز به توجه شما دارد یا همزمان تعداد زیادی پروژه دارید که باید به همه آنها رسیدگی کنید. در این حالت تعداد زیادی کار وجود خواهد داشت که فرصت انجام آنها پایان یافته و اینجاست که مشخص می شود فرسودگی شغلی برای یک برنامه نویس، واقعی است.
اگر یک برنامه نویس با تجربه هم چندین پروژه همزمان در دست داشته باشد که همه آنها نیاز به پشتیبانی داشته باشند، پذیرش پروژه جدید هر چقدر هم که جالب باشد، برای او خیلی دشوار خواهد بود. خوب البته این مساله اصلا خوب نیست چون جلوی رشد را می گیرد. معمولا مهم ترین چیزی که یک توسعه دهنده می خواهد این است که بیشتر یاد بگیرد و رشد کند. پس باید به نوعی کارها را پس از مدتی واگذار کند تا فرصت بیشتری برای رشد پیدا کند.
در کنار همه اینها توسعه برنامه و پشتیبانی آن یک فرایند رایگان نیست. امروزه افراد شغل خود در بازه های زمانی کوتاه تری تغییر می دهند. وقتی فردی از شرکتی جابجا می شود نمی توان از او انتظار داشت که در موقعیت جدید به شرکت قبلی هم پاسخگو باشد. در این حالت وظیفه تیم است که کد پروژه را به روز نگه دارد. تیم ها هم باید به این نکته توجه داشته باشند که در دام واگذاری بخش های مختلف به افراد مختلف نیفتند. این مساله در ابتدا جذاب به نظر می رسد اما در نهایت سیلوهایی از افراد ایجاد می کند که ارتباطی با هم ندارند و این مساله اصلا خوب نیست.
طبیعی است که توسعه دهنده، کدهایی که خودش نوشته را می شناسد و بهتر می فهمد اما اگر هر کس فقط مسئول کدهای خودش باشد، هیچ شخص دیگری آن قسمت کد را نگاه هم نمی کند مگر اینکه مجبور شود. در این حالت برنامه نویسان بازخوردهای مهم و ایده های جدید در مورد کدهای خود را از دست می دهند. احساس مالکیت یک حس مسئولیت و وظیفه به برنامه نویس می دهد تا برای حذف مشکلات برنامه و حفره های امنیتی تلاش کند. اما همیشه باید این مسئولیت به صورت اشتراکی بوده و افراد متعددی وظیفه نگهداری و پشتیبانی یک پروژه را با هم به عهده داشته باشند.
تست به شدت کار را کند می کند و متخصصین هم این را قبول دارند
در سال 2008 زمانی که سایت استک اورفلو راه اندازی شد، مسیر مشخصی برای ساخت یک سایت پرسش و پاسخ در ابعاد بسیار بزرگ وجود نداشت. امروزه انجام چنین پروژه هایی شبیه پروژه های موجود در دوره های آموزشی پروژه محور است. قبلا بدون سرویس های ابری، سیستم های توسعه بدون کد و سیستم های مدیریت بانک اطلاعاتی ویژوال، توسعه چنین سامانه ای با این ابعاد کار مشکلی بود.
سایت استک اورفلو بالاتر از همه ویژگی ها، می خواست که سایتی کاربردی برای کاربران باشد پس آنها سعی کردند که سرعت اجرا در اولویت اول آنها باشد و تست کردن را در پایان لیست اولویت های خود قرار دادند. یعنی سایت استک اورفلو که خودش محلی برای استادان برنامه نویسی است، همه چیز را تست نمی کرد. اصلا آنها در ابتدای کار هیچ چیزی را تست نمی کردند.
امروزه نه تنها تست اجباری است بلکه بهترین شیوه ها برای خود تست هم تعریف شده اند. این شیوه ها خود نیز به تعداد زیادی شیوه های دیگر تقسیم می شوند که نشان می دهد چقدر این مساله برای برخی از افراد اهمیت دارد. خوب پس اصل داستان در این مطلب چیست؟ آیا نباید مطمئن شویم که کد ما کار می کند؟ چرا. اما تست کردن زمان می برد و همیشه زمان به اندازه کافی در اختیار نداریم.
اجرای تست زمانی زیادی می برد مثلا برای تست یک صفحه بلاگ تا حد نهایت تحمل سرور ممکن است تا 20 دقیقه یا بیشتر نیاز به صرف زمان باشد در حالی نمایش یک صفحه بلاگ مساله ساده ای است. تست کردن در هر مرحله از توسعه نیز زمان برنامه نویس را می گیرد. هر وقت توسعه دهنده ویژگی جدیدی را به برنامه اضافه می کند باید تست هایی که مخصوص آن ویژگی ساخته است را به پروژه اضافه کرده و آن ها در در بخش مرتبط در مجموعه ابزارهای تست قرار دهد.
با گذشت زمان این هزینه ها نیز افزایش می یابد. برای حل این مساله دو راه وجود دارد: اول اینکه یک مجموعه کامل تست داشته باشید اما فقط مهم ترین چیزها در زمان توسعه جدید، مورد تست قرار می گیرد. حالت دوم اینکه فقط ضروری ترین تست ها را در مرحله اول پیاده سازی کنید. این حالت به نظر خیلی پایدار نیست اما می توانید با استوارسازی ساختاری پروژه نیاز به تست ها را کاهش دهید. اگر نیازی به نمونه مشابه دارید باز می توانید به استک اورفلو نگاه کنید. این سایت همیشه دوست شماست.
نتیجه نهایی: بهترین شیوه ها مانع سرعت
در این مطلب هدف این نیست که شما را متقاعد کنیم تا قوانین را کنار بیندازید و مانند یک دیوانه کدنویسی کنید. هدف این است که شما را متقاعد کنیم تا حداقل قوانین و بهترین شیوه ها را کلمه به کلمه دنبال نکنید. اگر کدی را از استک اورفلو یا هر سایت دیگری کپی کنید، تا زمانی که درکی درستی از کد کپی شده داشته باشید و بتوانید تغییرات لازم را انجام دهید، مشکلی ایجاد نمی شود.
اگر یک کد متن باز را به صورت کامل در پروژه انحصاری که متن باز نیست به کار ببرید، قوانین را زیر پا گذاشته اید و دچار مشکل می شوید. همچنین اگر کدهای کپی شده را به روز نکنید ممکن است حفره های امنیتی توسط هکرها جهت نفوذ مورد استفاده قرار گرفته و مشکلات امنیتی برای شما ایجاد کند.
مالکیت کد خصوصا مالکیت فردی کد کار اشتباهی است. سعی کنید که هر پروژه را به چندین نفر بسپارید. یاد بگیرید که کد خود را رها کرده و آن را تحویل دیگران بدهید. ذهن و تقویم کاری خود را آزاد کرده و اجازه بدهید تا چیزهای جدید وارد آنها شود.
کد خود را تا حد مرگ تست نکنید. مسائلی را تست کنید که احتمال بیشتری برای بروز خطا دارند یا احتمال می دهید که هکرها از مسیر آنها می توانند نفوذ کنند. تست را زمانی که ضرورت دارد حتما انجام دهید و اجازه بدهید تا ساختار برنامه مسائل دیگر را پوشش دهد.
همه این موارد در نهایت پیشنهاد این نیست که شما در روش توسعه خود 180 درجه تغییر جهت بدهید. به جای آن باید گاهی اوقات از رعایت کلمه به کلمه بهترین شیوه ها خودداری کنید. از طرفی سرپیچی از قوانین گاهی اوقات جذاب است مثل برداشتن بدون اجازه خوراکی، وقت گذرانی بیش از حد با دوستان یا کدنویسی به روش های غیر معمول.
با پیروی از قوانین و بهترین شیوه ها چیزهای خوبی خواهید ساخت. با پیروی از قوانینی که در موقعیت مورد نظر ما معقول هستند و دور انداختن بقیه موارد، محصولات عالی خواهید ساخت.
