Bir problemi həll edəndə yenisini yaratmamaq

Developer olaraq bəzən bir problemi çox tez həll etmək istəyirik.

• Exception çıxır — fix edirik.
• Performance zəifdir — cache əlavə edirik.
• Servislər bir-birinə çox bağlıdır — yeni servis ayırırıq.
• Database sorğusu çoxdur — başqa query yazırıq.

Problem həll olunur. Sonra başqa problem yaranır.

Fix həmişə həll deyil

Real layihələrdə bunu bir neçə dəfə görmüşəm. Bir problemi aradan qaldıran dəyişiklik başqa bir yerdə yeni davranış yarada bilir.

Məsələn, bir məlumatı cache-ə qoymaq database yükünü azalda bilər. Amma artıq həmin məlumatın nə vaxt yenilənəcəyini düşünmək lazımdır.

Bir servisi ayırmaq deployment-u rahatlaşdıra bilər. Amma indi network problemi də sənin probleminə çevrilir.

Bir validation əlavə etmək səhv məlumatın qarşısını ala bilər. Amma həmin qaydanın başqa giriş nöqtələrində də tətbiq olunması lazım gəlir.

Yəni texniki qərarın öz qiyməti var.

Mən indi əvvəlcə “niyə?” soruşuram

Bir dəyişiklik etməzdən əvvəl mümkün qədər problemi başa düşməyə çalışıram.

• Bu niyə baş verir?
• Problem hansı qatdadır?
• Bu dəyişiklik başqa nəyə təsir edə bilər?
• Daha sadə həll varmı?

Ən vacibi isə budur: mən problemi həqiqətən həll edirəm, yoxsa sadəcə simptomu gizlədirəm?

Bu sual çox vaxt daha çox kod yazmağın qarşısını alır.

Sadə həll çox vaxt daha yaxşıdır

Mənim üçün yaxşı backend kodu ən çox abstraction olan kod deyil.

Əgər problemi bir service-də aydın şəkildə həll etmək mümkündürsə, sırf arxitektura daha “professional” görünsün deyə əlavə layer yaratmağın mənası yoxdur.

Əgər database constraint problemi həll edirsə, həmin qaydanı yalnız Java kodunda saxlamaq məcburi deyil.

Əgər iki modul birlikdə dəyişirsə, onları süni şəkildə ayırmaq da həmişə düzgün qərar deyil.

Getdikcə başa düşürəm ki, engineering bəzən nə əlavə edəcəyini bilməkdən çox, nə əlavə etməməli olduğunu bilməkdir.