Mühendis Gibi Yap

Bir Yazılım Mühendisinin işi problemleri çözmektir. Her şey bu aktiviteye indirgenebilir. Bu nedenle, sorunları çözmek için sağlam bir metodolojiye sahip olmak önemlidir. Sonuçta biz mühendisiz ve sorunları çözmek için eğitildik. Bunu bir mühendis gibi yapmalıyız.

Gereksinimleri anlayın

İlk adım, gereksinimleri anlamaktır . Bir problemi çözmek için, problemin tam olarak ne olduğunu anlamalısınız. 2-3 haftalık bir çalışma sürecek bir özellik, ve bu yapılmazsa karşınıza çıkacak “ Ah, şu da var… ”, “Ah, bunu düşünmedik!”, “Belki şu şekilde daha iyi olur … ”. gibi şeyler.
Bir problemi çözmeye başladığınızda, başlangıç ​​noktasını , nihai hedefi ve aradaki engelleri anladığınızdan emin olun . Olası en kötü şey, aslında bekleneni yapmayan bir çözüm üretmektir.
Son bir not olarak, unutmayın ki siz yalnızca sorunun nasıl çözüleceğine karar verirsiniz . Yeni özelliğin gereksinimlerini, onları mümkün olan en iyi şekilde ifade etmeniz ve sorunları çözmek sizin işinizdir. Mühendis olmayan biri size sorunu nasıl çözeceğinizi söylemeye çalışırsa, suratına yumruk atın.

Boyutunu anlayın

Saniyede 100.000 istek hizmet vermenin, dakikada 100 istek hizmet etmekten biraz farklı olduğu konusunda hepimiz hemfikiriz. Sorunu çözme yaklaşımı farklıdır. Bu nedenle, “girdinin boyutunun” ne olduğunu veya başka bir deyişle sorunun ne kadar büyük olduğunu anlamak önemlidir . Aksi takdirde iki senaryo vardır. En iyi durum,% 10 oranında kullanılan bir sistemi tasarlamak ve uygulamak için 6 ay harcamanızdır. En kötü durum,% 180 oranında kullanılan bir sistemi tasarlamak için 1 ay harcamanızdır. En iyi durum zaman / kaynak israfıysa, kendinizi en kötü durumda bulmak istemezsiniz. Bu durumdan kaçınmak için doğru soruları sormalıyız.

• Sistemin kaç talebi karşılaması gerekir?
• Beklenen yanıt süresi nedir?
• Kaç kaynağımız var?
• Son tarihler ne olacak?
  Doğru sorular bağlama bağlıdır, ancak hedef bir ve yalnızca bir tanesidir: sorunun boyutunu anlamak .

Devlerin omuzlarında durun …

Sana bir sır vereceğim. Başka birinin sorununuzu çözme şansı yüksektir. Hem de çok yüksek . Tek yapmanız gereken, kullanım durumunuzla eşleşen bir problem için bir çözüm olup olmadığını bulmak için literatürde bir araştırma yapmaktır. İyi bilinen sorunlara ev yapımı çözümlerden kaçının, bunlar yalnızca başka sorunları beraberinde getirir. “Hazırda Bekletme”, “Kafka” gibi birçok şirket var çünkü:

• “Farklı bir kullanım örneğimiz var” (görmek istiyorum)
• “X teknolojisinin performansı bizim için yeterli değil” (gerçekten?)
• “Daha iyisini yapabiliriz” (bu en komik olanı mı?)
  Sonuç: Gereksinimlerinizi ve sorunun boyutunu öğrendikten sonra, literatürde bir araştırma yapın. Tekerleği yeniden icat etmenin bir anlamı yok .

… Ama dev olmadığını unutma

Mevcut çözümlerin üzerine inşa etmek sorun değil, ancak aşırılıktan kaçının. Google olmadığınızı unutmayın . Dışarıdaki harika teknolojiler okyanusunda, en ünlü / yenilikçi / kullanılmayan her zaman sizin için en iyisidir. Günde 5 mesaj işlemek için bir Kafka kümesi dağıtmak muhtemelen iyi bir fikir değildir. İşi minimum karmaşıklıkla yapacak teknolojiyi seçin . Bu karar size uzun vadede ödeme yapacak.

Büyükanne Odaklı Geliştirme

Çözümünüzü büyükanneniz tarafından anlaşılır hale getirmeye çalışarak uygulayın. Süslü ve süper karmaşık uygulamalardan kaçının. Onları basit ve anlaşılır bir şey lehine bir kenara koyun . Bu, kodu daha sürdürülebilir hale getirecektir. Optimizasyonu gerekli oldukları ana bırakın.
Daha resmi olarak, uygulamanız En Az Güç Kuralına uygun olmalıdır . Orijinal kural, programlama dilinin seçimiyle ilgilidir. Bu bağlamda şu şekilde okuyabiliriz:

“Mevcut çözümler arasından sorununuzu çözebilecek en az güçlü olanı seçin.”

Fonksiyonel programlamayı kullanmaya başladığımda bu kuralı öğrendim. Eşsiz bir şıklıkla çözümler uygulamanıza olanak sağlar. Ancak bu tür çözümler bazen çok karmaşıktır. Ben biraz daha az zarif ve verimli ama çok daha anlaşılır ve sürdürülebilir bir uygulamayı tercih ederim. Kodunuzu okuyan tek kişi siz olmayacaksınız .

Sonuç

Biz mühendisiz, işimiz problemleri ne şekilde görünürlerse görünsün çözmektir. Doğru çözümü sunmak için mühendislik becerilerimizi uygulamalı ve problemi pragmatik olarak analiz etmeliyiz . İstenilen sonucu elde etmek için bir çözüm olmadığını unutmamalıyız. Az çaba ve birlikte az karmaşıklık ile gerekeni yapmalıyız. Umarım bu hikayede anlattığım metodoloji böyle bir başarıya doğru bir adım atmanıza yardımcı olur.

Görüşürüz.

Kaynak: Luca Florio – Do it like an engineer