Refleksi 1

Dalam mengimplementasikan fitur edit dan delete pada Spring Boot, saya telah menerapkan prinsip clean code seperti penggunaan nama variabel dan metode yang jelas, serta pemisahan logika bisnis ke dalam layer service. Selain itu, saya memastikan secure coding dengan validasi input di controller dan penggunaan repository hanya melalui service layer untuk mencegah akses langsung ke data.

Namun, ada beberapa perbaikan yang dapat dilakukan, seperti menambahkan exception handling yang lebih spesifik untuk menangani error saat produk tidak ditemukan.

Refleksi 2

1. Setelah menulis unit test, saya merasa lebih yakin bahwa fitur yang dikembangkan berjalan sesuai harapan. Namun, jumlah unit test dalam satu kelas sebaiknya disesuaikan dengan kompleksitas logika bisnisnya. Untuk memastikan cakupan pengujian yang cukup, saya memanfaatkan metrik code coverage. Meskipun code coverage mencapai 100%, bukan berarti kode bebas dari bug, karena masih ada kemungkinan kesalahan logika yang tidak terdeteksi oleh tes.

2. Saat membuat functional test suite baru, saya menyadari adanya duplikasi kode dari pengujian sebelumnya. Hal ini dapat mengurangi kualitas kode dan menyulitkan pemeliharaan. Untuk memperbaikinya, saya dapat mengabstraksi setup dan variabel yang sama ke dalam superclass atau menggunakan utility class agar kode lebih modular dan terorganisir.

Refleksi 3 (Modul 2)

1. Selama latihan ini, saya memperbaiki masalah kode yang terdeteksi oleh PMD, salah satunya adalah #File line problem. Masalah ini muncul karena ada baris kode yang melebihi panjang yang disarankan atau tidak sesuai dengan standar kualitas kode yang ditetapkan. Strategi yang saya gunakan untuk memperbaiki masalah ini adalah dengan melakukan refactoring, seperti memecah kode panjang menjadi beberapa baris yang lebih pendek, menghilangkan redundansi, serta memastikan kode lebih mudah dibaca dan dipahami.
2. Setelah melihat implementasi CI/CD workflows yang telah saya buat di GitHub, saya merasa bahwa implementasi ini telah memenuhi definisi Continuous Integration (CI) dan Continuous Deployment (CD). CI terpenuhi karena setiap perubahan kode yang dikirimkan ke repository secara otomatis diuji dan dianalisis dengan PMD, memastikan bahwa kode tetap bersih dan bebas dari kesalahan sebelum digabungkan ke branch utama. Selain itu, aspek Continuous Deployment (CD) juga sudah diimplementasikan dengan baik karena setelah kode diuji dan dianalisis, aplikasi secara otomatis dideploy ke PaaS yang dipilih, memastikan bahwa setiap perubahan yang valid dapat langsung diterapkan ke lingkungan produksi.
3. link deploy (https://theoretical-amara-asshdqi-9158eae2.koyeb.app/)

Refleksi 4 (Modul 3)

1. Dalam proyek ini, saya menerapkan dua prinsip SOLID utama. Pertama, Single Responsibility Principle (SRP) dengan memisahkan CarController dan ProductController menjadi kelas terpisah, sehingga setiap controller hanya memiliki satu tanggung jawab. Kedua, Dependency Inversion Principle (DIP) dengan mengganti injeksi field menggunakan @Autowired menjadi injeksi konstruktor di CarController, membuat controller bergantung pada abstraksi daripada implementasi konkret.
2. Penerapan SRP meningkatkan kemudahan pemeliharaan dan memperjelas struktur kode. Perubahan pada fitur mobil tidak akan mempengaruhi fitur produk karena keduanya sudah dipisahkan. Misalnya, penambahan metode baru untuk fitur mobil tidak akan mempengaruhi ProductController. Sementara itu, penerapan DIP melalui injeksi konstruktor meningkatkan kemampuan pengujian dan fleksibilitas, serta membuat ketergantungan menjadi eksplisit. Controller dapat bekerja dengan implementasi CarService apa pun tanpa perlu perubahan kode.
3. Tanpa penerapan SRP, kode menjadi rumit dan hubungan pewarisan yang tidak tepat (CarController "adalah" ProductController) menciptakan masalah logis dalam desain. Perubahan pada satu jenis entitas bisa tidak sengaja mempengaruhi yang lain. Tanpa DIP, terjadi pengikatan yang erat dengan implementasi spesifik, menyulitkan pengujian dan menyembunyikan ketergantungan. Pengujian unit menjadi lebih kompleks karena perlu menggunakan refleksi untuk menyuntikkan layanan palsu, berbeda dengan kesederhanaan injeksi konstruktor.