Go में लीगेसी कोड का रीफैक्टरिंग: चरण-दर-चरण मार्गदर्शिका

Go में लीगेसी कोड का रीफैक्टरिंग: चरण-दर-चरण मार्गदर्शिका

Go में लीगेसी कोड के साथ काम करना डेवलपर के जीवन का एक अपरिहार्य हिस्सा है। अक्सर ऐसा कोड जल्दबाजी में, बिना परीक्षणों के, ग्लोबल वेरिएबल्स और मोनोलिथिक फंक्शन्स के साथ लिखा जाता है। हालाँकि, Go में लीगेसी कोड का रीफैक्टरिंग केवल फिर से लिखना नहीं है, बल्कि एक रणनीतिक प्रक्रिया है जिसमें सावधानी और व्यवस्थित दृष्टिकोण की आवश्यकता होती है। इस लेख में, हम चर्चा करेंगे कि उत्पाद को तोड़े बिना मौजूदा कोड को सुरक्षित और प्रभावी ढंग से कैसे सुधारें।

Go में लीगेसी कोड का रीफैक्टरिंग कठिन क्यों है?

Go में लीगेसी कोड में अक्सर विशिष्ट समस्याएँ होती हैं:

• ग्लोबल वेरिएबल्स — परीक्षण और समानांतर निष्पादन को जटिल बनाते हैं।
• मोनोलिथिक फंक्शन्स — सैकड़ों पंक्तियों लंबे फंक्शन जो सब कुछ एक साथ करते हैं।
• इंटरफेस का अभाव — विशिष्ट कार्यान्वयन के लिए कठोर बंधन।
• कोई परीक्षण नहीं — परीक्षणों के बिना रीफैक्टरिंग बारूदी सुरंग पर चलने जैसा है।

लेकिन Go कोड को धीरे-धीरे सुधारने के लिए शक्तिशाली उपकरण प्रदान करता है। मुख्य बात यह है कि छोटे-छोटे कदम उठाएँ, प्रत्येक चरण पर सिस्टम की कार्यक्षमता बनाए रखें।

चरण 1: तैयारी और परीक्षण

कोड बदलने से पहले, एक "सुरक्षा जाल" — परीक्षण बनाना आवश्यक है। भले ही कोड का परीक्षण नहीं किया गया हो, आप विशेषता परीक्षण (characterization tests) लिख सकते हैं। वे सिस्टम के वर्तमान व्यवहार को रिकॉर्ड करते हैं, ताकि आप सुनिश्चित कर सकें कि रीफैक्टरिंग के बाद कुछ भी नहीं टूटा है।

package main

import "testing"

func TestCalculateTotal(t *testing.T) {    // मान लीजिए हमारे पास एक लीगेसी फंक्शन CalculateTotal है    result := CalculateTotal(100, 20)    expected := 120.0

    if result != expected {        t.Errorf("CalculateTotal(100, 20) = %f; want %f", result, expected)    }}

परीक्षण चलाएँ और सुनिश्चित करें कि वे पास होते हैं। अब आपके पास सुरक्षित बदलावों के लिए एक आधार है।

चरण 2: इंटरफेस को अलग करना

Go में लीगेसी कोड की मुख्य समस्याओं में से एक घटकों के बीच कठोर संबंध है। समाधान — इंटरफेस को अलग करना है। यह परीक्षण करते समय वास्तविक निर्भरताओं को मॉक से बदलने की अनुमति देता है, साथ ही भविष्य में कार्यान्वयन को बदलना आसान बनाता है।

एक उदाहरण पर विचार करें। मान लीजिए, हमारे पास एक फंक्शन है जो सीधे डेटाबेस में डेटा सहेजता है:

package main

import "database/sql"

type User struct {    ID   int    Name string}

func SaveUser(db *sql.DB, user User) error {    _, err := db.Exec("INSERT INTO users (name) VALUES ($1)", user.Name)    return err}

समस्या: हम वास्तविक डेटाबेस के बिना इस फंक्शन का परीक्षण नहीं कर सकते। समाधान — एक इंटरफेस को अलग करना:

package main

// UserStorage उपयोगकर्ताओं को संग्रहीत करने के लिए अनुबंध को परिभाषित करता हैtype UserStorage interface {    Save(user User) error}

type UserSaver struct {    storage UserStorage}

func NewUserSaver(storage UserStorage) *UserSaver {    return &UserSaver{storage: storage}}

func (s *UserSaver) SaveUser(user User) error {    return s.storage.Save(user)}

अब हम परीक्षण के लिए एक मॉक बना सकते हैं:

package main

import "testing"

type mockStorage struct{}

func (m *mockStorage) Save(user User) error {    return nil // हमेशा सफल}

func TestUserSaver_SaveUser(t *testing.T) {    saver := NewUserSaver(&mockStorage{})    err := saver.SaveUser(User{ID: 1, Name: "Alice"})    if err != nil {        t.Errorf("unexpected error: %v", err)    }}

चरण 3: डिपेंडेंसी इंजेक्शन

इंटरफेस को अलग करने के बाद, अगला कदम डिपेंडेंसी इंजेक्शन (Dependency Injection, DI) है। फंक्शन के अंदर निर्भरताएँ बनाने (जैसे, DB कनेक्शन खोलना) के बजाय, हम उन्हें बाहर से पास करते हैं।

एक विशिष्ट लीगेसी कोड पर विचार करें:

package