ডিফল্ট হলো refactoring। একটি rewrite কেবল তখনই ন্যায্য যখন বিদ্যমান সিস্টেম একটি গ্রহণযোগ্য খরচে আর প্রয়োজন মেটাতে বিবর্তিত হতে পারে না, এবং আপনি তা করার সময়ও মূল্য ডেলিভার করতে থাকতে পারেন। অধিকাংশ "আমাদের rewrite দরকার" প্রবৃত্তি আসলে একটি অব্যবস্থাপিত tech-debt সমস্যা যা ক্রমবর্ধমান refactoring অনেক কম ঝুঁকিতে সমাধান করে।
| সংকেত | refactor-এর দিকে ঝুঁকুন | rewrite-এর দিকে ঝুঁকুন |
|---|---|---|
| Architecture প্রয়োজনে খাপ খায় | হ্যাঁ | না |
| Test/spec coverage | কম বা বেশি | সমতা যাচাইয়ের জন্য যথেষ্ট বেশি |
| ক্রমবর্ধমানভাবে ship করা যায় | হ্যাঁ | কঠিন, big-bang |
| দল কোড বোঝে | হ্যাঁ | না, এবং মূল লেখকরা চলে গেছে |
refactor-বনাম-rewrite সিদ্ধান্ত একজন Tech Lead-এর নেওয়া সর্বোচ্চ-প্রভাবশালী সিদ্ধান্তের একটি। rewrite-এর দিকে ভুল করুন এবং আপনি delivery এক বছরের জন্য জমিয়ে দিয়েও ব্যর্থ হতে পারেন; refactor-এর দিকে ভুল করুন এবং আপনি ধীরে ধীরে velocity হারান। এটিকে রুচির সিদ্ধান্ত নয়, খরচ-ও-ঝুঁকির সিদ্ধান্ত হিসেবে উপস্থাপন করাই senior বিচারবুদ্ধিকে পছন্দ থেকে আলাদা করে।