Overreacted

Memperbaiki Seperti Tidak Dilihat Orang Lain

15 Februari 2019 • ☕️ 1 min read

Beberapa dari utang teknis adalah pemandangan yang biasa

Struktur data yang tidak memadai mungkin akan menyebabkan Kode yang berbelit-belit. Disaat kebutuhan terus berganti, Kode mungkin memiliki beberapa jejak dari pendekatan sebelumnya. Terkadang Kode ditulis terlalu berburu-buru atau ceroboh.

Jenis dari utang teknis ini mudah untuk didiskusikan karena itu sangat terlihat karena jelas sekali hal tersebut adalah bugs yang terlihat, masalah performa, dan sulit untuk kalau ingin menambah fitur.

Selain itu juga ada lagi, ada jenis utang teknis yang lebih berbahaya dan tersembunyi.

Mungkin rangkaian tes sedikit lambat, bukan lambat dengan arti lelet - tetapi hanya cukup melihat bugs dari kode tersebut dan mengesampingkan kode tersebut. Mungkin anda tidak percaya dengan development script tersebut dan anda lompat dari rilis ekstra tersebut. Barangkali lapisan abstraksi tersebut membuat hal terlalu rumit dan susah untuk mencari penyebab dari penurunan performa yang Anda akhirnya menyisipkan sebuah TODO di kode anda. Kadang beberapa unit test terkadang terlalu kaku dan anda akhirnya memikirkan sebuah ide yang dapat membangkitkan semangat anda sampai anda dapat fitur yang direncanakan sebelumnya.

Dari semua hal ini adalah melanggar kesepakatan, hal tersebut mungkin seperti gangguan atau distraksi, hal tersebut terasa sia-sia untuk dikomplain, lagi pula hal tersebut sangat penting, anda tidak mungkin melakukan hal tersebut terlepas dari perselisihan bukan?

Dan pada akhirnya hal ini tidak diselesaikan, Hal tersebut sepertinya tidak penting. Perselisihan mebunuh hal tesebut. Beberapa dari eksplorasi hal ini tidak ada konsekuensi, Beberapa mungkin dapat membuat mengubah proyek anda.

Anda tidak pernah tahu. Hal ini mengapa anda harus secara aktif mengurangi perselisihan. Seperti takdir proyek anda yang bergantung pada hal ini karena memang hal itu adalah fakta.

Memperbaiki seperti tidak dilihat orang lain.