Yes, Anda tidak salah membaca judul atau mendengar. Saya yakin ketika Anda membuat project secara pribadi ataupun untuk orang lain, client, dan team internal pasti mengalami keterlambatan. Selama menjadi software engineer, saya masih mencari tau alasan mengapa pembuatan software menjadi terlambat. Oh mungkin karena teamnya kurang kompeten, Oh munkin timelinenya kurang panjang, Oh mungkin permintaan yang berubah-rubah di tengah jalan, Oh mungkin standarisasinya yang kurang baik di terapkan, Oh mungkin dari awal permintaannya kurang jelas, dan masih banyak lagi... Sebab musabab diatas hanyalah sedikit dari banyak sebab yang sering saya dengar atau bahkan yang saya ikut terjun didalamnnya. Tapi apakah pembuatan software ngak bisa ontime? jawabannya Bisa, ujar seorang software engineer yang di anggap senior, dan di kenyataannya tidak sesimple kalimat Bisa. Kalimat Bisa sering saya dapatkan ketika client yang minta dan software engineer yang jawab atau jik...
Factory Method: Problem -> Solution -> Results 🚀 Alright, let's dive into this pattern. The Problem 🤔 Imagine you're building an app, maybe a game where players can choose different types of characters (like Warriors, Mages, Archers). At first, you might just create them directly wherever you need them, like: // Somewhere in your game logic... Character player1 = new Warrior(); Character player2 = new Mage(); This works fine for a small game. But what happens when you add tons of character types? Or maybe the way you create characters gets super complex, needing specific stats or items? Your main code gets cluttered with all this character creation logic. Even worse, if you decide to change how a Warrior is created (maybe they need a specific starting weapon now), you have to hunt down every single place you created a Warrior and change it. Major headache! 😩 It makes your code rigid and hard to update. You're basically locked into the specific classes you...