refactoring ला default ठेवा. rewrite तेव्हाच न्याय्य असते जेव्हा सध्याची system स्वीकार्य खर्चात गरजा पूर्ण करण्यासाठी आणखी विकसित होऊ शकत नाही, आणि तुम्ही ते करत असताना मूल्य देत राहू शकता. बहुतेक "आम्हाला rewrite हवे" अंतःप्रेरणा खरे तर एक अव्यवस्थापित tech-debt समस्या असतात ज्या वाढीव refactoring कितीतरी कमी धोक्यात सोडवते.
मी त्याबद्दल कसा विचार करतो
- मूळ architecture अजूनही व्यवहार्य आहे का? data model, सीमा, आणि runtime नवीन गरजांपर्यंत ताणू शकत असतील, तर refactor करा. मूलभूत गृहीतके चुकीची असतील (चुकीचा storage प्रतिमान, scale करण्याचा मार्ग नाही, language/platform end-of-life), तर rewrite खरा उमेदवार बनतो.
- बदलाची वारंवारता काय आहे? क्वचित बदलणाऱ्या code ला सुंदर असण्याची गरज नाही. team रोज जिथे काम करते तिथे प्रयत्न केंद्रित करा.
- आम्हाला सध्याचे वर्तन समजते का? rewrite वर्षानुवर्षे साठलेले edge-case ज्ञान फेकून देतो. tests आणि spec नसेल, तर rewrite जुने bugs पुन्हा आणेल.
एक निर्णय चौकट
| संकेत | refactor कडे झुका | rewrite कडे झुका |
|---|---|---|
| Architecture गरजांना बसते | होय | नाही |
| Test/spec coverage | कमी किंवा जास्त | समानता पडताळण्याइतके पुरेसे |
| वाढीवपणे ship करू शकतो | होय | कठीण, big-bang |
| team ला code समजतो | होय | नाही, आणि मूळ लेखक गेले |
Trade-offs
- Refactor: कमी धोका, सतत delivery, पण खरोखर सडलेल्या पायावर हळू.
- Rewrite: स्वच्छ पाटी, पण तुम्ही feature-freeze कर भरता, dual-maintenance खर्च वाहता, आणि classic second-system अति-अभियांत्रिकीच्या सापळ्याचा धोका घेता.
- strangler-fig मधला मार्ग पसंत करा: जुन्यासोबत नवीन system उभी करा, वाढीवपणे traffic वळवा, जुने तुकड्या-तुकड्याने हटवा. ते refactor-पातळीच्या धोक्यासह rewrite चे फायदे देते.
धोके
- व्यावसायिक खर्चासाठी नव्हे तर सौंदर्य किंवा resume-चालित कारणांसाठी rewrite करणे.
- लपलेल्या वर्तनाला कमी लेखणे; नेहमी आधी tests सह सध्याचे वर्तन वैशिष्ट्यांकित करा.
- काहीही ship न करणारा अनेक-तिमाही big-bang rewrite — गती आणि विश्वास दोन्ही कोलमडतात.
हे का महत्त्वाचे आहे
refactor-विरुद्ध-rewrite हा निर्णय Tech Lead घेत असलेल्या सर्वात उच्च-प्रभावी निर्णयांपैकी एक आहे. तो rewrite कडे चुकीचा करा आणि तुम्ही वर्षभर delivery गोठवू शकता आणि तरीही अपयशी होऊ शकता; तो refactor कडे चुकीचा करा आणि तुम्ही हळूहळू velocity गमावता. तो अभिरुचीचा नव्हे तर खर्च-आणि-धोक्याचा निर्णय म्हणून मांडणे हेच senior विवेकाला पसंतीपासून वेगळे करते.