Setelah melakukan review saya, saya merasa saya sudah melaksanakan hal-hal yang dipelajari di kelas.
Menurut saya, saya sudah menulis kode dengan menggunakan prinsip-prinsip clean code. Namun demikian, ada beberapa prinsip yang belum saya lakukan.
See More
Prinsip-prinsip clean code yang saya sudah terapkan adalah:
- Meaningful names
- Functions
- Objects and Data Structures
Menurut pendapat saya, fungsi yang telah saya buat ini memiliki ukuran yang cukup ideal. Fungsi yang telah saya buat dibuat dengan prinsip Single Responsibility, di mana setiap fungsi hanya melakukan satu tugas spesifik. Hal ini membantu dalam mempertahankan readibility dan code maintainability. Selain itu, saya telah memberikan nama yang deskriptif untuk fungsi yang telah saya buat. Nama yang deskriptif ini memudahkan pemahaman tentang apa yang sebenarnya dilakukan oleh fungsi tersebut tanpa harus membaca detail implementasinya. Fungsi ini juga dirancang sedemikian rupa sehingga tidak memiliki side effect bagi program secara keseluruhan. Hal tersebut berarti bahwa fungsi ini tidak mengubah status atau kondisi dari bagian lain dari program. Hal ini sangat penting dalam pemrograman fungsional dan membantu dalam meminimalkan bug dan kesalahan. Fungsi ini melakukan operasi create, edit, dan delete. Hal menarik yang telah saya buat adalah bahwa ketiga operasi ini dilakukan dalam class yang sama, yang berarti bahwa mereka mungkin berinteraksi dengan data yang sama dan oleh karena itu harus ditangani dengan hati-hati.
Menurut saya, saya telah menerapkan prinsip Object and Data Structures dalam kode yang telah saya tulis. Saya telah membuat abstraksi dalam bentuk interface. Abstraksi ini memungkinkan kita untuk menyembunyikan detail implementasi yang kompleks dan hanya mengekspos metode dan properti yang diperlukan. Ini membantu dalam mempertahankan modularitas dan fleksibilitas kode. Selanjutnya, saya menggunakan atribut yang disimpan secara private dalam class yang ada. Untuk mengakses atau memodifikasi atribut private ini, saya menggunakan metode setter dan getter. Metode setter dan getter ini bertindak sebagai antarmuka untuk atribut private, memungkinkan kita untuk mengontrol bagaimana atribut ini diakses dan dimodifikasi.
Berikut adalah prinsip clean code yang belum saya terapkan.
- Comments
- Error Handling
Sampai sekarang, saya belum menuliskan komentar apapun pada kode saya. Hal ini karena saya rasa kode saya sudah cukup concise. Menurut saya, karena kode saya belum panjang dan masih sangat mudah dilakukan tracing dan karena saya menggunakan nama yang jelas, comments tidak perlu dilakukan. Jika kedepannya comments perlu dilakukan karena kompleksitas kode bertambah, saya akan menambahkannya. Selain itu, error handling belum saya lakukan. Hal ini karena menurut saya error handling belum diperlukan. Hal ini dikarenakan kode saya pada bagian create, edit, dan delete seharusnya tidak memunculkan error. Walaupun di bagian findById dan update kemungkinan terjadi error karena mengembalikan null, tetapi karena kita mengirimkan id yang pasti ada, seharusnya method findById dan update tidak akan pernah mengembalikan null. Jika ada kemungkinan bahwa kedua fungsi tersebut mengembalikan null, saya mungkin akan mencoba throw, try, dan catch.
Setelah membuat beberapa unit tests untuk kode saya, ada beberapa hal yang saya temui dan rasakan.
See More
Saya merasa cukup yakin dengan code saya. Saya telah mengetesnya sebagai user maupun sebagai programmer yang iseng. Saya mencoba untuk memasukkan quantity yang negatif maupun yang tidak bersifat integer. Karena program saya belum meng-handle kasus tersebut, maka saya juga sekalian mengurusnya ketika mengurus unit test. Saya mengurusnya dengan cara throw exception di dalam program agar program benar-benar jelas mengalami masalah apa.
Menurut saya, tidak ada angka yang pasti untuk jumlah unit test pada sebuah class. Walaupun demikian, menurut saya ada baiknya jika jumlah unit test dan fungsi yang ada pada di sebuah kelas mirip jumlahnya, ataupun unit test-nya dibuat lebih banyak. Hal ini untuk memastikan program yang telah dibuat sudah robust. Dengan memastikan program yang telah dibuat adalah program yang robust, kita bisa lebih percaya dengan program kita. Hal ini oleh karena program kita sebenarnya "diawasi" dengan unit test yang telah kita buat, yang harapannya jika ada perubahan di masa mendatang, perubahan yang kita buat tidak merusak program yang ada.
Jika sebuah kode punya 100% code coverage menurut saya bug bisa saja tetap terjadi. Walaupun demikian, kemungkinannya kecil karena unit test sudah mengecek banyak aspek dari kode. Intinya adalah tidak ada jaminan bahwa kode yang telah dibuat tidak memiliki bug atau error. Hal ini dikarenakan code coverage bukanlah sebuah adalah pennjamin bahwa kode yang telah dibuat bebas dari bug atau error. Melainkan, code coverage yang luas adalah penjamin bahwa kita sudah mencoba semaksimal mungkin untuk memastikan code kita sudah kita coba untuk buat sedemikian rupa sehingga tidak ada bug atau error yang dilewatkan.
Jika saya diminta untuk mengecek jumlah item pada product list, saya rasa membuat kelas baru adalah hal yang redundant untuk dilakukan. Menurut saya, kita bisa langsung membuat seperti yang saya buat, yaitu menekan tombol submit dan mengecek berapa item yang telah ada di tabel. Menurut saya dengan membuatnya seperti itu, kode akan tetap bersih dan mudah untuk di-trace karena tidak ada terlalu banyak hal yang perlu diuji. Dengan demikian, saya rasa mudah untuk kita kembali ke sebuah proyek dan mulai mengerjakannya. Menurut saya, semakin mudah untuk sebuah program menarik kita untuk mengerjakannya artinya kode tersebut sudah semakin baik dibuat karena sudah menarik kita untuk mengerjakannya.
Terakhir, saya ingin mengoreksi kode saya tentang membuat unit test jika kita memaksa suatu atribut pada product untuk bernilai null. Saya mendesain program saya sedemikian rupa sehingga program saya melemparkan sebuah exception.
Setelah membuat beberapa unit tests tambahan untuk kode saya agar code coverage saya 100% ada beberapa hal yang saya temui dan rasakan.
See More
Berpindah dari kode pada src dan test bukanlah hal yang mudah. Hal ini dikarenakan kita harus bisa melakukan multitasking. Saya adalah seseorang yang tidak cukup hebat dalam melakukan hal tersebut, jadi saya bukanlah seorang expert dalam melakukan unit test. Selain itu, karena kita sedang bekerja dengan kesepakatan yang kita buat sendiri (misalnya null jika tidak ditemukan) kita perlu mengingat itu ketika kita bekerja. Hal ini kadang menyulitkan kita untuk bekerja. Oleh karena itu, saya rasa mempelajari penulisan kode yang terstandarisasi merupakan hal yang sangat penting. Hal ini agar setidaknya, setiap programmer yang bekerja setidaknnya memiliki standar ketika bekerja.
Menurut saya, CI/CD merupakan hal yang sangat penting untuk diimplementasikan para kode yang telah kita buat. Menurut saya, dengan membuat CI/CD, kedua hal ini bisa dilakukan secara otomatis setiap kita mengupload file kita. Menurut saya, CI yang telah saya buat sudah benar. Tetapi jika boleh menambahkan komentar personal saya, menurut saya menarik bahwa kita melakukan CI pada semua branch dan pull request. Apakah hal ini bisa menjadi hal yang berbahaya bagi kode kita di masa yang akan mendatang? Kemudian mengenai CD, dengan menggunakan koyeb saya mendapatkan error Too Many Requests. Menurut saya, hal ini adalah karena keterbatasan dari Docker yang adalah sebuah container yang free, oleh karena itu saya dibatasi penggunaannya.calc
Minggu ini saya mempelajari tentang SOLID principles. Prinsip ini sangat penting untuk dipelajari karena akan berpengaruh terhadap aspek scalability dari kode yang kita buat.
See More
Ada 5 jenis prinsip dalam SOLID principles. Pertama ada SRP (Single Responsibility Principle). SRP berarti setiap kelas dipisahkan menurut apa yang dilakukannya. Hal ini adalah agar setiap class memiliki hanya satu hal saja yang dikerjakan. Hal ini sangat penting supaya 1 kelas tidak melakukan 2 hal yang berbeda agar kita mudah untuk mendeteksi jika ada sebuah masalah yang terjadi. Pada kasus kode saya, saya memisahkan CarController dengan ProductController supaya terjadi pemisahan antara tugas yang ada. Hal ini agar Car tidak tercampur dengan Product.
Selain itu saya juga melakukan konsep OCP, yaitu konsep Open-Closed Principle. Prinsip ini adalah prinsip yang kita gunakan agar ada bagian kode yang mudah untuk dilakukan ekstensi, tetapi tetap tertutup sehingga tidak mudah dimodifikasi. Hal ini adalah untuk mencegah terjadinya error. Pada kode saya, saya membuat sebuah class interface. Hal ini adalah agar saya memiliki panduan untuk method-method apa saja yang perlu saya buat dan method-method tersebut mudah untuk dilakukan ekstensi tetapi tidak mudah untuk dimodifikasi karena harus ada kelas interface yang perlu diubah juga. Hal ini diharapkan membuat saya lebih mindful terhadap perubahan yang saya buat terhadap method saya.
Terakhir, saya mengimplementasikan DIP, yaitu Dependency Inversion Principle. Disini, saya melakukan abstraksi supaya modul yang high level tidak bergantung kepada yang low level. Contoh penerapannya bisa dilihat dari CarController yang menggunakan service dari CarService dan bukan CarServiceImpl. Hal ini supaya saya menggunakan service dari sebuah interface. Dengan menggunakan interface, kita sudah menerapkan penggunaan abstraksi yang telah kita buat pada Controller.
Prinsip-prinsip diatas telah membantu saya agar kode yang saya buat lebih fool proof. Hal ini agar kode mudah dipahami (dapat dipahami dengan waktu yang cepat) dan kode yang saya buat aksesibel untuk programmer pada segala jenis keahlian. Hal ini kemudian harapannya dapat meningkatkan perkembangan kode yang saya buat agar bisa dikembangkan oleh programmer lain. Selain kolaborasi, kode yang kita buat ini akan lebih mudah dikelola dan hal ini membuat scalability dari program kita yang baik.
Pada kode saya, ISP (Interface Segregation Principle) diterapkan dengan cara memisahkan kelas kelas yang ada berdasarkan fungsinya. Pemisahan ini dilakukan agar kita modularitas program meningkat. Hal ini supaya kita bisa memisahkan masalah-masalah yang mungkin timbul di masa depan, jadi kita memisahkan program kita ke modul-modul yang dapat membendung masalahnya pada sebuah kelas saja, bukan pada kelas-kelas lain.
Jika tidak menerapkan SOLID, kode yang dibuat bisa saja sulit untuk dimengerti orang lain. Hal ini tentu menghambat perkembangan kode yang telah dibuat dan kode yang kita buat malah menjadi redundant dan tidak akan digunakan kembali. Padahal harapannnya adalah kode yang kita buat akan tetap dipakai untuk kemudian hari. Tetapi karena sulit dimengerti dan sulit untuk dikembangkan, kode-kode yang ada malah perlu waktu untuk ditulis kembali agar menjadi sebuah kode yang mudah dipahami. Hal ini tentunya memakan sumber daya yang seharusnya bisa digunakan untuk hal-hal lain yang lebih penting.