21 puan yazan xguru 2020-09-21 | 8 yorum | WhatsApp'ta paylaş

"25 milyon satırlık Oracle Database 12.2 kodu."

HN'de sorulan bir soruya eski bir Oracle çalışanının verdiği yanıt

"Hayal bile edilemeyecek bir dehşet. Mevcut 1000 testi geçmeden tek satır kod yazmak bile mümkün değil.

Elle not alıp çözmeden anlaşılamayan gizemli makrolar var; bu makroların gerçekte ne yaptığını anlamak bir ila iki gün sürüyor.

Bazen kodun farklı durumlarda nasıl çalışacağını öngörebilmek için 20 farklı flag'in değerlerini ve etkilerini anlamanız gerekiyor.

Bazen bu sayı 100'ü bile geçiyor. Abartı değil.

Bu ürünün hâlâ hayatta kalıp çalışmasının tek nedeni, kelimenin tam anlamıyla milyonlarca test olması."

Oracle DB geliştiricisinin hayatı

  1. Yeni bir bug üzerinde çalışmaya başla

  2. Bu bug'a neden olan ve gizemli biçimlerde birbiriyle etkileşen 20 farklı flag'i anlamak için 2 hafta harca

  3. Yeni özel senaryoyu ele almak için bir flag daha ekle. Bu flag'i kontrol etmek için birkaç satır kod yaz, ardından problemli durumu çözmek ve bug'ı önlemek için birkaç satır daha ekle

  4. Kod değişikliğini 100~200 makineden oluşan test farm'ına gönder. Ardından yeni Oracle DB build'i alınır ve milyonlarca test dağıtık biçimde çalıştırılır

  5. Eve git. Ertesi gün gel ve başka bir işe başla. Testlerin tamamlanması 20~30 saat sürer

  6. Eve git. Ertesi gün gel ve test sonuçlarına bak. İyi bir günde yaklaşık 100 test fail olur. Kötü bir günde yaklaşık 1000 test fail olur. Bu testlerden birkaçını seçip varsayımlarında neyin yanlış olduğunu anlamaya çalış. Muhtemelen bug'ın özünü kavramak için dikkate alman gereken 10 kadar flag daha vardır

  7. Bu sorunu çözmek için birkaç flag daha ekle. Değişikliği tekrar test farm'ına gönder. Yine 20~30 saat bekle

  8. 2 hafta boyunca bu flag kombinasyonlarının düzgün çalışması için düzeltmeler yap ve aynı döngüyü tekrarla

  9. Nihayet 'güzel bir gün'de hiçbir test fail etmez

  10. Yaptığın değişiklik için yüzlerce ek test yaz ki şansı yaver gitmeyen bir sonraki geliştirici bu düzeltmeyi bozamazsın

  11. Son testler için tekrar gönder. Sonra review için gönder. Review yine 2 haftadan 2 aya kadar sürebileceği için başka bir bug'a geçip çalışmaya başla

  12. 2 hafta ile 2 ay sonra, her şey bittiğinde kod main branch'e merge edilir

Oracle programcısının bug düzeltme hayatı böyle. Abartı değil.

Yeni bir özellik geliştirmenin nasıl bir dehşet olduğunu artık siz düşünün.

Küçük bir özelliğin geliştirilmesi 6 ay ile 1 yıl, bazen 2 yıl bile sürebilir. (Örneğin Active Directory kimlik doğrulaması gibi yeni bir kimlik doğrulama yöntemi eklemek.)

Bu ürünün çalışıyor olması bir mucize.

Artık Oracle'da çalışmıyorum ve bir daha da Oracle'da çalışmayacağım.

8 yorum

 
neocoin 2020-09-28

Şimdiye kadar gördüğünüz en büyük Bad Code neydi?

Test döngüsü şöyle:

  1. Kod yaz

  2. Test yaz

  3. Kodu refactor et, sonra 1'e dön

Ama 1 ve 2 çok zaman aldığı için, sonuçta 3. adımın sürekli atlanması ortaya çıkıyor.

 
kunggom 2020-09-21

Bu vesileyle Martin Fowler’ın konuşmasına yeniden bakalım. Görünüşe göre Oracle Database’in “iç kalite”si (Internal Quality) pek iyi değil.

https://tr.news.hada.io/topic?id=2752

 
kbumsik 2020-09-21

Oracle açısından bakınca bir şekilde doğal görünüyor; hatta bu yazılıma bakıp “gerçekten enterprise içinmiş...” diye düşünecek kadar güven veriyor.

Ama o yazıdaki gibi bir yerde çalışmak istemezdim.

 
exitmusic 2020-09-21

Bence tam tersine, test odaklı geliştirme kültürü yüzünden geliştirme süreci bozulmuş olabilir diye düşünüyorum.

Nasıl olursa olsun yeter ki testlerden geçsin anlayışıyla geliştirme yapılıyor... Muhtemelen böyle bir ortamda refactoring yapmayı hayal bile edemezsiniz.

 
sduck4 2020-09-22

Sorun testten çok, bir özelliği düzeltmek/eklemek için 20~100 bayrağı hesaba katmayı gerektiren tasarımsal problem daha büyük değil mi?

DBMS'nin karmaşıklığı yüzünden bunun kaçınılmaz olduğunu düşünsem de.

 
kunggom 2020-09-21

Test de sonuçta geliştiricinin yazdığı koddur. Aklıma gelmişken testlerle ilgili bir yazı paylaşmıştım.

https://tr.news.hada.io/topic?id=2883

 
ffdd270 2020-09-21

Proje o kadar kötü durumda değilse, testler arayüzü baştan aşağı değiştirseniz bile eskisiyle aynı kaldığını sürekli garanti edebildiği için, aksine refactoring konusunda insana cesaret verebilir diye düşünüyorum. Ben de bu aralar yaptığım emülatörde parametreleri BYTE değerlerinden Enum değerlerine dönüştürme işi yaptım. Derleme başarılı oldu ama testler başarısızdı; testler olmasaydı ne yapardım diye düşününce bir kez ciddi ciddi irkildiğim olmuştu.

Kod tabanı o kadar büyükse, refactoring yapmayı düşünseniz bile fazla devasa olduğu için vazgeçiliyor, üstüne bir de kod eklenmeye devam ediyor... Muhtemelen böyle bir sonsuz döngüye düşmüş olabilirler diye temkinli bir tahminde bulunuyorum.

 
xguru 2020-09-21

O kişinin zorlanmış olmasını ben de anlayabiliyorum,

ama paradoksal biçimde, "testlerin ne kadar önemli olduğunu" düşündüren bir yazı olduğu için çevirdim.

Bu yanıtın asıl soru gönderisine toplam 578 yanıt gelmişti.

Ask HN: Şimdiye kadar çalışırken gördüğünüz en büyük kötü kod miktarı neydi?

https://news.ycombinator.com/item?id=18442637

Sadece 1. seviye yanıtlar bile eğlenceli. İnsanların yaşadığı şeylerin her yerde aynı olduğunu düşündürüyor..