۵ قانون مرتبط به Clean Code برگرفته از کتاب Uncle Bob

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

چگونه کدی بنویسیم که تغییر دادنش دردسرساز نشود؟

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

ما معمولاً عجله داریم: Deadline داریم، Feature جدید داریم، تحویل داریم. در چنین شرایطی، سرعت اولویت پیدا می‌کند و نظم و تمیزی کد عقب می‌افتد. در کتاب Clean Code اشاره شده، کیفیت تصادفی نیست. نظم باید ساخته شود، تقویت شود، نگه‌داری شود و جالب اینجاست که این نظم فقط مخصوص نرم‌افزار نیست؛ دهه‌ها قبل در کارخانه‌های ژاپنی سیستم نظافتی با عنوان 5S معرفی شد تا محیط کار را ساماندهی کند. بعدها دیده شد که این اصول فقط برای کارخانه نیست؛ می‌توان آنها را در مدیریت، آموزش، حتی زندگی روزمره به کار برد و حالا نوبت برنامه‌نویسی است.

در این مقاله می‌خواهیم 5S را از فضای صنعتی خارج کنیم و ببینیم چطور دقیقاً می‌توان آن را روی Clean Code پیاده کرد. بعد از خواندن این مطلب، نه‌تنها کد تمیز را بهتر می‌فهمید، بلکه الگوی جدیدی برای نگاه کردن به پروژه‌هایتان پیدا می‌کنید.

با آموزش مهندسی نرم‌افزار در نیک‌ آموز، 5S و Clean Code را در پروژه‌ها و کدهای عملی اجرا کنید.

1. Seiri –  حذف اضافات (Sort)

   «فقط آنچه لازم است را نگه دار.»

اولین S از 5S با یک حقیقت ساده شروع می‌شود: چیزهای اضافی نه‌تنها فضا را شلوغ می‌کنند، بلکه ذهن را هم قفل می‌کنند. در کدنویسی، این “اضافات” چه هستند؟

• متغیرهایی که یک روز استفاده شدند و بعد رها شدند.
• متدهای قدیمی.
• کلاس‌هایی که هیچ‌وقت پاک نشدند.
• بخش‌هایی از کد که شاید برای “روز مبادا” گذاشته شده‌اند.
• Commentهای تاریخ گذشته.
• TODOهایی که هیچ‌وقت قرار نیست انجام شوند.

حذف این موارد فقط یک کار سطحی نیست. تحقیقات در روانشناسی شناختی ثابت کرده: شلوغی محیط کاری، شلوغی ذهن را زیاد می‌کند. این موضوع در کدنویسی هم صادق است. وقتی فایل‌هایتان پر از بخش‌های بلااستفاده باشد، ناخواسته یک “بار ذهنی” اضافی به خودتان تحمیل می‌کنید. هر بار که کد را می‌خوانید، مغزتان باید تصمیم بگیرد:

• این لازم است؟
• این کار می‌کند؟
• این چرا اینجاست؟
• این را باید اصلاح کنم یا نه؟ و این تصمیم‌های کوچک، انرژی زیادی را از شما می‌گیرند.

چرا حذف اضافات مهم‌تر از اضافه کردن امکانات است؟ بیشتر ما ناخودآگاه ترجیح می‌دهیم چیز جدید اضافه کنیم تا اینکه چیزی را پاک کنیم اما تا زمانی که فضای کار تمیز نشده باشد، هر افزونهٔ جدید خودش یک خطر است. در Clean Code هم آمده: اول تمیز کن، بعد بساز. ساختن روی کد شلوغ مثل چیدن کتاب روی میز خاکی‌ست. شاید چند روز اول مشکلی نداشته باشد، اما بعد از مدتی میز را نمی‌توانید ببینید.
پرسش کلیدی Seiri: آیا این بخش از کد واقعاً ضروری است؟ اگر نه، حذفش کنید. تمیزی کد از همین‌جا شروع می‌شود.

نمونه:

public class EngineService
{
private int _testCounter; // ? برای چی مونده؟
private string backupTempName = "test"; // سال‌هاست استفاده نمیشه
public void StartEngine() 
{ 
    // TODO: باید یک سیستم جدید برای استارت ساخته شود 

    Console.WriteLine("Engine Started"); 
}   
private void OldMethodNotUsed() { } // متد قدیمی اما حذف نشده 
}

از کد شلوغ تا کد تمیز؛ مسیر یادگیری آموزش برنامه‌نویسی با نیک آموز

۲. Seiton – نظم و جای درست (Set in Order)

«هر چیز در جای خودش.»

وقتی وارد یک کارگاه منظم می‌شوید، هر ابزار دقیقاً در جای خودش است؛ چکش، پیچ‌گوشتی، آچار …؛ همه‌چیز جایی است که انتظار دارید. حالا وارد پروژه‌ی خودتان شوید: آیا کلاس‌ها، متدها، فایل‌ها، فولدرها و Namespaceها دقیقاً همان‌جایی هستند که باید باشند؟ یا هرچیز هرجا پیدا می‌شود؟ Seiton می‌گوید: فقط درست کار کردن کافی نیست؛ کد باید در جای صحیح قرار داشته باشد.

مثال‌ها:

• متدی که ۳۰۰ خط است و بین ۱۰ کار مختلف جابه‌جا می‌شود.
• کلاس‌هایی که همه‌چیزدان هستند و کارهای متفاوت انجام می‌دهند.
• نام‌هایی که مفهوم واقعی را منتقل نمی‌کنند.
• فایل‌هایی که مسئولیتشان مبهم است.
• پروژه‌هایی که ساختار پوشه‌هایشان هیچ نظم درونی ندارد.

وقتی کد در جای مناسب نباشد، مغز مجبور است دائماً جست‌وجو کند. این فرایند کوچک ذهن را خسته می‌کند و سرعت توسعه را ۲ تا ۵ برابر پایین می‌آورد.

Seiton یعنی:

• هر کلاس، مسئولیت مشخص داشته باشد.
• نام‌گذاری دقیق باشد.
• ساختار فولدرها معنادار باشد.
• کدهای مرتبط کنار هم باشند.
• قوانین چیدمان در پروژه ثابت باشند.

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

نمونه نامناسب:

Project/
├── Helpers/
│ └── OrderProcessing.cs ← چرا اینجاست؟
├── Controllers/
│ └── UserHelper.cs ← این کنترلر نیست که!
├── Services/
│ └── SmsApi.cs
├── Utils/
│ └── OrderController.cs ← اشتباه واضح

نمونه مناسب:

Project/
├── Orders/
│ ├── OrderController.cs
│ ├── OrderService.cs
│ └── OrderRepository.cs
├── Users/
│ ├── UserController.cs
│ └── UserService.cs
└── Shared/
└── SmsApi.cs

۳. Seiso – پاکیزگی و شفافیت (Shine)

«هر روز، هر فایل را تمیز نگه دار.»

Seiso مرحله‌ای است که معمولاً فکر می‌کنیم بی‌اهمیت است. اما دقیقاً همانجایی است که پروژه‌های بزرگ پیروز یا شکست می‌خورند.

تصور کنید:

• TODOهای قدیمی.
• Logهایی که کسی به آنها توجه نمی‌کند.
• کامنت‌هایی که معنایی ندارند.
• کدهای Debug رهاشده.
• نسخه‌های تکراری از یک بخش.
• متغیرهای استفاده‌نشده.

همه این‌ها مثل گرد و غبار روی میز کار هستند. میز هنوز کار می‌کند، اما دل‌نشین نیست. در برنامه‌نویسی هم فایل هنوز اجرا می‌شود، اما حس خوبی نمی‌دهد. Seiso می‌گوید: هر بار که فایل را باز می‌کنید، باید بهتر از قبل آن را تحویل بدهید. این نه یک قانون سختگیرانه، بلکه یک فرهنگ است.

پاکیزگی یعنی چه؟

• فایل‌های شفاف.
• کد قابل خواندن.
• حداقل ابهام.
• حذف تکرار.
• کاهش نویز.
• نوشته شدن توضیحات زمانی که ضروری است.
• حذف کامنت‌های بی‌مصرف.
• نوشتن کدی که آینده را در نظر بگیرد.

وقتی فردا فایل را باز می‌کنید و از خودتان تشکر می‌کنید، یعنی Seiso را درست انجام داده‌اید. چرا پاکیزگی انگیزه ایجاد می‌کند؟ چون:

• کد تمیز اعتماد می‌دهد.
• تغییرش آسان است.
• مغز درگیر نمی‌شود.
• محیط کاری حرفه‌ای‌تر می‌شود.
• تیم با خیال راحت روی آن توسعه می‌دهد.

کد تمیز مثل اتاق مرتب است. وقتی واردش می‌شوید، حس می‌کنید توانایی انجام هر کاری را دارید.

نمونه کثیف:

public class CarService
{
// ********** old variables don't remove **********
private int tmp;
private string _xCarName;
private DateTime dt1;
// todo fix this later 
// todo maybe delete? not sure 
public void Register(string name, int km, string phone) 
{ 
    Console.WriteLine("ok");  // debug 
    var x1 = km + 20;  // ???? 
    // گرفتن اطلاعات مشتری 
    Console.WriteLine("ثبت شد " + name + km + phone); // string بهم چسبیده! 
    // ********** old function ********** 
    OldMethodxxxx(); 
}   
private void OldMethodxxxx() 
{ 
    Console.WriteLine("old..."); 
    // maybe use? maybe not? 
} 
}

نمونه تمیز:

public class CarService
{
public void RegisterService(string ownerName, int currentKilometers, string phoneNumber)
{
var message = BuildConfirmationMessage(ownerName, currentKilometers, phoneNumber);
notificationService.SendSms(phoneNumber, message);
}
private string BuildConfirmationMessage(string ownerName, int km, string phone) 
{ 
    return $"سرویس خودروی شما با موفقیت ثبت شد.\n" + 
           $"مالک: {ownerName}\n" + 
           $"کارکرد فعلی: {km}\n" + 
           $"شماره تماس: {phone}"; 
} 
}

۴. Seiketsu – استانداردسازی (Standardize)

«از هرج و مرج جلوگیری کن. یک زبان مشترک داشته باشید.»
در هر تیمی اگر استاندارد نباشد، هرکس زبان خودش را حرف می‌زند.

• یکی PascalCase دوست دارد.
• یکی camelCase.
• یکی اسم‌های کوتاه می‌گذارد.
• یکی اسم‌های طولانی.
• یکی پوشه‌بندی عجیب دارد.
• یکی همه‌چیز را در یک فایل می‌گذارد.

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

• نام‌گذاری‌ها
• قوانین معماری
• ساختار پوشه‌ها
• الگوهای طراحی
• روش نوشتن تست
• شیوه‌ی مدیریت Exception 
• طریقه‌ی لاگ‌برداری
• Style Guide مربوط به زبان

وقتی همه یک زبان مشترک داشته باشند:

• خواندن کد ساده‌تر است.
• یادگیری پروژه برای اعضای جدید سریع‌تر است.
• خطاها کمتر می‌شود.
• توسعه هماهنگ‌تر می‌شود.
• معماری پایدار می‌ماند.

استاندارد محصول توافق و فرهنگ تیم است، نه یک دستور سخت‌گیرانه.

نمونه بدون استاندارد:

public void SendSMS() { } // PascalCase
public void send_email() { } // snake_case
public void SENDPush() { } // چرا همه حرف بزرگ؟!

نمونه با استاندارد:

public void SendSms() { }
public void SendEmail() { }
public void SendPushNotification() { } 

 کد تمیز را عملی یاد بگیرید، با آموزش برنامه‌نویسی رایگان در نیک‌ آموز

۵. Shitsuke – انضباط (Sustain)

«سخت‌ترین بخش: پایبندی.»

اگر تمام مراحل قبلی خوب انجام شود اما Shitsuke رعایت نشود، همه‌چیز دوباره ویران خواهد شد.
 Shitsuke یعنی:

• حتی روزهای شلوغ.
• حتی وقتی Deadline نزدیک است.
• حتی وقتی Feature جدید عجله دارد.
• حتی وقتی می‌توانید میان‌بر بزنید؛ باز هم استاندارد و تمیزی کد را رها نکنید.

بخش بزرگی از کیفیت، “دانش” نیست؛ عادت و انضباط است، دانستن کافی نیست؛ باید انجام شود، بارها و بارها تکرار شود تا تبدیل به فرهنگ شود. چرا Shitsuke سخت‌ترین مرحله است؟
چون:

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

انضباط یعنی چه؟

• همیشه Refactor کردن.
• به تعویق نینداختن تمیزکاری ضروری.
• پذیرش بازخورد.
• پایبندی به استانداردها.
• مستندسازی اصول پروژه.
• آموزش اعضای جدید تیم.
• بازبینی منظم ساختار پروژه.

Shitsuke یک فرآیند پایان‌ناپذیر است. کد خوب یک مقصد نیست؛ یک مسیر است.

نمونه بدون انضباط:

// فقط برای امروز اینجوری نوشتم، بعداً درستش میکنم
public void Process() => Console.WriteLine("OK");

نمونه با انضباط

public void ProcessOrder()
{
orderProcessor.Execute();
}

سخن پایانی:

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

• Seiri به شما یاد می‌دهد اضافات را حذف کنید.
• Seiton می‌گوید هرچیز باید در جای درست باشد.
• Seiso روی تمیزی و شفافیت تأکید می‌کند.
• Seiketsu استاندارد و زبان مشترک می‌سازد.
• Shitsuke فرهنگ پایبندی و انضباط ایجاد می‌کند.

   این پنج اصل با هم یک سیستم می‌سازند؛ سیستمی که کمک می‌کند کدی بنویسید:

• قابل خواندن
• قابل نگه‌داری
• قابل تغییر
• قابل توسعه
• و مهم‌تر از همه، قابل اعتماد

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

سوالات متداول

۱.وقتی می‌گوییم Seiri یعنی حذف و سامان‌دهی، این اصل چه کمکی به ذهن می‌کند؟
Seiri یعنی «جدا کردن ضروری از غیرضروری».

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

۲.چرا برای اجرای Seiton (نظم‌دهی) لازم است ابتدا یک نقشه ذهنی دقیق داشته باشیم؟
Seiton یعنی «هر چیز در جای خودش.»

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

۳.در Seiso چرا می‌گوییم اگر ذهن به تمیزکاری روزانه عادت نداشته باشد، دوباره همه‌چیز به‌هم می‌ریزد؟
Seiso  یعنی «پاک‌سازی و مراقبت مستمر.»

اگر ذهن فقط یک‌بار تمیزکاری کند اما عادت نداشته باشد، محیط (یا کار یا اهداف) دوباره به‌هم می‌ریزد. راز Seiso این است: تمیزی نتیجهٔ عمل تکرارشونده است، نه تلاش مقطعی. ذهنی که نظافت روزانه ندارد، اطلاعات موقت، کارهای نیمه‌تمام و حواس‌پرتی‌ها را دوباره انباشته می‌کند.

۴.چرا تا وقتی استانداردها در ذهن درونی نشوند، Seiketsu پایدار نمی‌ماند؟
Seiketsu یعنی «استانداردسازی و یکپارچه‌سازی.»

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

۵.در Shitsuke چرا نظم بیرونی بدون نظم ذهنی ماندگار نیست؟
Shitsuke یعنی «انضباط شخصی و پایبندی دائمی.»

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

۶.چگونه یک ذهن خلوت باعث می‌شود چرخه 5S مؤثر باشد؟

5S یک سیستم مکانیکی نیست؛ یک سیستم شناختی است. ذهن پاک و خلوت باعث می‌شود:

• تصمیم‌گیری سریع‌تر شود.
• تشخیص مهم و غیرمهم راحت‌تر شود.
• نظم قابل‌حفظ باشد.
• استانداردها پایدار بمانند.

برعکس، ذهن شلوغ قادر به Seiri ,Seiton یا Seiso نیست. ذهن شلوغ کل چرخه را مختل می‌کند چون نمی‌تواند روی هیچ مرحله‌ای تمرکز کند.

۷.چرا اجرای 5S بدون تغییر ذهنیت افراد همیشه به شکست منجر می‌شود؟

چون 5S یک «سیستم ذهنی» است، نه فقط مجموعه‌ای از ابزارها. اگر ذهنیت افراد تغییر نکند:

• Seiri سطحی می‌شود.
• Seiton شکل نمی‌گیرد.
• Seiso ادامه پیدا نمی‌کند.
• Seiketsu پایدار نمی‌ماند.
• Shitsuke تبدیل به اجبار می‌شود.

حتی اگر ابزار، دستورالعمل، آموزش و استاندارد کامل باشد، تا زمانی که ذهن آماده نباشد، 5S عملی نمی‌شود.