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

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

اگر این کار این قدر سخت است، چرا ما اصلا نیازی به استاندارد کدنویسی داریم؟ یک دلیل برای قالب بندی یکسان کد این است که هیچ کس نمی‌تواند فقط با تغییر قالب کد به شیوه مخصوص خودش، آن کد را «تصاحب» کند. ما جلوی استفاده توسعه‌دهندگان از ضد الگوهای مشخص را می‌گیریم تا مانع از رخ دادن خطاهای معمول بشویم. در کل یک استاندارد کدنویسی کار کردن در پروژه را راحت‌تر می‌کند و سرعت توسعه را از ابتدا تا انتها حفظ می‌کند. این کار فقط وقتی نتیجه می‌دهد که همه بر روی آن استاندارد توافق کنند. اگر یک برنامه‌نویس از سه خط فاصله برای تو رفتگی کد استفاده کند و دیگری از چهار فاصله، هیچکدام از مزایای بالا محقق نمی‌شود.

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

• مطمئن شو که قالب‌بندی کد بخشی از فرایند ساخت (بیلد) است و با هر بار کامپایل کد اجرا می‌شود.
• از ابزارهای تحلیل کد ایستا برای مرور و پایش کد استفاده کن تا ضد الگوهای ناخواسته را شناسایی کند و هر زمان که به چنین موردی برخورد کرد، ساخت برنامه را متوقف کند.
• تنظیم کردن این ابزار را یاد بگیر تا بتوانی از آ‌ن‌ها برای جستجوی ضد الگوهای مخصوص پروژه استفاده کنی.
• فقط به اندازه‌گیری پوشش تست برنامه اکتفا نکن. پاسخ تست‌ها را هم به صورت خودکار بررسی کن. موکدا، اگر پوشش تست برنامه کم بود، ساخت را متوقف کن.

البته نمی‌توانی همه چیزهایی که برایت مهم است را خودکار کنی اما سعی برای هر چیزی که مهم می‌دانی این کارها را بکنی. یک متمم یا پیوست برای مستند استاندارد کدنویسی آماده کن مواردی را که نمی‌توانی به صورت خودکار علامت بزنی یا تصحیح کنی در آن بیاور. قبول کن که تو و همکارانت احتمالا با سرسختی آن‌ها را دنبال نخواهید کرد.

نکته نهایی این که استاندارد کدنویسی باید پویا و دینامیک باشد نه ایستا. همزمان با رشد پروژه، نیازهای آن هم تغییر می‌کند و چیزی که در ابتدای کار هوشمندانه به نظر می‌رسید ممکن است چند ماه بعد دیگر هوشمندانه نباشد.

Filip van Laenen