refactoring ला default ठेवा. rewrite तेव्हाच न्याय्य असते जेव्हा सध्याची system स्वीकार्य खर्चात गरजा पूर्ण करण्यासाठी आणखी विकसित होऊ शकत नाही, आणि तुम्ही ते करत असताना मूल्य देत राहू शकता. बहुतेक "आम्हाला rewrite हवे" अंतःप्रेरणा खरे तर एक अव्यवस्थापित tech-debt समस्या असतात ज्या वाढीव refactoring कितीतरी कमी धोक्यात सोडवते.
| संकेत | refactor कडे झुका | rewrite कडे झुका |
|---|---|---|
| Architecture गरजांना बसते | होय | नाही |
| Test/spec coverage | कमी किंवा जास्त | समानता पडताळण्याइतके पुरेसे |
| वाढीवपणे ship करू शकतो | होय | कठीण, big-bang |
| team ला code समजतो | होय | नाही, आणि मूळ लेखक गेले |
refactor-विरुद्ध-rewrite हा निर्णय Tech Lead घेत असलेल्या सर्वात उच्च-प्रभावी निर्णयांपैकी एक आहे. तो rewrite कडे चुकीचा करा आणि तुम्ही वर्षभर delivery गोठवू शकता आणि तरीही अपयशी होऊ शकता; तो refactor कडे चुकीचा करा आणि तुम्ही हळूहळू velocity गमावता. तो अभिरुचीचा नव्हे तर खर्च-आणि-धोक्याचा निर्णय म्हणून मांडणे हेच senior विवेकाला पसंतीपासून वेगळे करते.
सविस्तर उत्तरांसह IT मुलाखत प्रश्नांचे ग्रंथालय — Junior पासून Senior पर्यंत.
देणगी द्या