Büyüme Projelerinde Geliştiricinin Zihniyeti

Yeni başlayan veya büyüyen bir projede geliştirici olduğunuzda, birçok teknolojiye hakim olmak ve karmaşık, yüksek yüklü hizmetlerin nasıl oluşturulacağını bilmek yeterli değildir. Kariyerim boyunca birçok büyüyen projede yer aldım ve sıfırdan iki startup kurdum. Bu yazımda gelişim aşamasında nelere odaklanmam gerektiği ve mükemmeliyetçiliğin neden en iyi fikirleri bile bozduğuna dair deneyimlerimi paylaşacağım.

Araçlar Bir Araçtır, Bir Son Değil

Her geliştirici için bir projeyi tek başına başlatmak ciddi bir zorluktur. Her şeyi mükemmel yapmanız gerektiğini hissetmeniz çok doğal. Mükemmeliyetçilik arzusunun çoğu zaman meslektaşlarımın beni fazladan bir 'baskı' nedeniyle ya da bir kalıp ya da araç kullanmadığım için yargılayacağı korkusunun bir yansıması olduğunu fark etmem biraz zaman aldı; ve işte şöyle: üretim sunucusu çökecek, müşteriler şikayet edecek, kovulacağım ve dünyanın sonu gelecek.

Herhangi bir araç, kalıp veya programlama dili yalnızca bir araçtır , amaç değil. Daha sık sorun: Buna neden şimdi ihtiyacım var? Ne sağlayacak? Hangi metrikleri iyileştirecek? Örneğin: neden şimdi bir linter yapılandıralım? CI/CD'yi neden şimdi özelleştirmelisiniz? Günde 10 kez dağıtım yapıyorsanız muhtemelen buna ihtiyacınız olacaktır. Bir sürümü haftada veya ayda bir dağıtırsanız büyük olasılıkla bunu yapmazsınız. CI/CD özelleştirmesi çok zaman alacak ancak geliştirmeyi hızlandırmayacak veya projeye ve müşterilere değer getirmeyecekse şimdi uygulanmalı mı?

Bir evcil hayvan projesinde yeni bir şey denemek mantıklıdır: deponun ve kodun yapısını sonsuz bir şekilde geliştirmek, kalıplarla denemeler yapmak vb. Bu durumda uyguladığımız araçlar amaçtır . Bir üretim projesinin temel amacı müşterilere değer sunmaktır. Müşteriler, tek tırnaklar ve tek tırnaklar yerine çift tırnak kullandığımızı ve sabit kod olmadığını asla bilemeyecekler.

Yeniden düzenleme yalnızca geliştirme hızını ve performansını artıracağı, hataları azaltacağı veya birikmiş yığının engelini kaldıracağı durumlarda gereklidir.

Kaliteye olan bağlılık, mükemmeliyetçilik arzunuzu değil, ürünün hedeflerini takip etmelidir. Bu nedenle şunu hatırlamak önemlidir: Büyüyen bir projedeki geliştirici asla mükemmeliyetçi değildir.

İş Değeri Önce Gelir

Büyüyen bir projedeki geliştirici için iş değerini anlamak çok önemlidir. Yalnızca hazır spesifikasyonlara göre kodlayan sıradan bir geliştirici olmaya alıştığınızda, ilk başta zorlayıcı olabilir.

Ürün yeni doğduğunda, kullanıcılara sağladığı değer henüz kanıtlanmamıştır ancak kanıtlanması gereken değer paydaşların zihninde mevcuttur. Bu aşamada kod tabanına gereksiz mantık yükleme hatasına düşebilirsiniz. Örneğin bir sipariş işleyici yazmanız gerekiyor. Henüz tek bir tür olmasına rağmen, veritabanındaki siparişleri içeren bir tablo ve sipariş türlerini içeren ikinci bir tablo oluşturursunuz.

Diyelim ki bunu yapıyorsunuz çünkü paydaş bir gün bu mantığın gerekli olabileceği konusunda ısrar ediyor. Gerçekte buna hiçbir zaman ihtiyaç duyulmayabilir. Şu anda hiçbir değeri yoksa gereksiz varlıklar yaratmayın ve daha da önemlisi, iş zamanınızı ve paranızı buna harcamayın.

Makul bir soru sorulabilir: "Bir paydaşla tartışacak mıyım?" Bazen öyle yapacaksın. Paydaşlar detaylı analiz bekliyor. Büyüyen projelerin özellikleri çoğunlukla kaynak eksikliğidir, bu nedenle geliştiricilerin analitik becerilere sahip olması gerekir. Ürünün yaşayabilirliği kelimenin tam anlamıyla buna bağlı olduğundan, ürünün özelliklerinin değerini sürekli olarak doğrulamanız gerekir.

Kendinizi zayıf bir şekilde dağıtırsanız, işletmenin kaynakları tükenecek ve depoyu arşivleyeceksiniz.

Pek çok soru sorun: "Bu özelliği neden şimdi uyguluyoruz? Bu sorunu şimdi çözelim mi? Bu sorun mevcut mu?" Yukarıda teknolojilerle ilgili olarak anlatılanlarla tamamen aynıdır. Doğru soruları sorabilmek profesyonelliğinizi ortaya çıkarır. Zamanınızı ve iş kaynaklarınızı yalnızca müşterilerinize gerçekten değer katacak şeylere harcamanız gerekir.

Hackathon'lar, iş değerinin anlaşılmasının sonucu nasıl etkilediğini gösteren harika bir örnektir. Sınırlı bir süre içinde, açıkça tanımlanmış bir soruna ideal olmayan ancak uygulanabilir bir çözüm sunulmalıdır. Geliştiriciler projeden ilham aldıklarında ve bunu neden yaptıklarını net bir şekilde anladıklarında 2 günde bile iyi sonuç ortaya çıkıyor.

Plan Risklere Bağlıdır

Bir strateji oyunu hayal edin: Bir oduncunuz ve bir aceminiz var. Amaç bir savaşçı yaratmaktır. İlk olarak oduncunun odun toplaması ve acemi askeri eğitim alabileceği kışla inşa etmesi gerekir. Odun toplamak için oduncunun haritanın keşfedilmemiş bir kısmından ormana ulaşması gerekiyor. Haritaya bakılırsa ormana bir oyun gününde ulaşılabiliyor, odun kesimi yaklaşık yarım gün sürüyor, kışlanın inşası ise bir hafta sürüyor. Yani yaklaşık on gün sonra kışlalar ortaya çıkacak.

Oduncunun ormana ulaşması neredeyse bir gün sürüyor ama nehir aniden yolu kapatıyor. Hedef değişir: Diğer tarafa geçmek için bir baraj, köprü ya da tekne inşa etmeliyiz ya da belki başka bir yerde orman aramak daha iyidir. Erken değerlendirme stratejide bozulmaya yol açar. Gözcü önce haritanın keşfedilmemiş bir bölümünü araştırmış olsaydı bu risk önlenebilirdi.

Deneyimli bir geliştirici, paydaş için açık olmayan risklerin farkındadır: üçüncü taraf hizmetleriyle entegrasyonlar, kod tabanını genişletmenin karmaşıklığı vb. Riskleri değerlendirip uyarmak sizin sorumluluğunuzdadır. Çoğu zaman paydaşlar bu risklerin farkında değildir ancak onlar için önemli olan değerlendirmeyi etkilerler.

Örnek bir görev: hizmetinizi bir ödeme hizmetiyle entegre etmek. Öncelikle ödeme hizmetini kurun, erişim sağlayın ve işlerin nerede ters gidebileceğini araştırın. Entegrasyondan önce nasıl entegre edileceğini anlayın. İki veya üç haftalık geliştirme sürecinden sonra özelliğin zamanında tamamlanamayacağını veya ödeme hizmetinin şartları değiştirmesi veya gerekli özellik için desteğin devre dışı bırakılması nedeniyle entegrasyonun başarısız olduğunu öğrenmek yerine araştırmaya bir gün harcamak daha iyidir. .

Riskleri çözdükten sonra işi planlamanız ve görev için bir zaman tahmini sağlamanız gerekir. Kullandığım çerçeve bu:

• Senaryolar yazın veya bunları ekranda görselleştirin: örneğin kullanıcı bir düğmeye tıklar ve belge indirilir. Anladığınız yaklaşımları seçin.

• Daha teknik bir bakış açısıyla senaryonun nasıl çalışabileceğini analiz edin. Ne kadar çok seçenek o kadar iyi. Seçenekleri değerlendiriyorum ve sorunu en hızlı şekilde çözebilecek, riskleri en aza indirilmiş, potansiyel olarak ölçeklenebilir bir çözüm seçiyorum.

• Senaryoları kodlanması gereken mantıksal parçalara ayırın.

• Her parçayı gün cinsinden tahmin edin ve ardından 1,11 katsayısıyla çarpın. Bu benim kişisel büyü katsayım, yani 11 Ekim'deki doğum günüm. Bu elbette bir şaka (ya da değil). Benim tavsiyem, projenin kapsamına bağlı olarak tahmine birkaç gün, hatta hafta daha eklemektir. Risklerin çoğunu mümkün olduğu kadar öngörmeye çalışırken bazıları öngörülememektedir. Başarısız olmaktansa işleri erken bitirmek en iyisidir.

  
  

  Daha büyük bir tahmin vermekten korkmayın: Bir paydaş "Bunu daha hızlı yapamaz mısın?" diye sorduğunda. Sadece "Hayır" cevabını vermeyin, nedenini gerekçelendirin. Riskleri anlatın, senaryoları gösterin ve örnekler verin. Paydaşın, sorunu rastgele değerlendirmediğinizi, analiz ettiğinizi anlaması gerekir.

Önemli husus: ruh haliniz de bir risktir. Tatillerinizi planlayın ve motivasyonunuzu korumak ve tükenmemek için zihinsel sağlığınıza dikkat edin: bu sizin sorumluluğunuzdur.

MVP bir uzay aracı değil

"MVP nasıl oluşturulur?" tüm kariyerim boyunca beni rahatsız etti. Kulağa basit geliyor - Minimum uygulanabilir ürün.

Vikipedi tanımı:

Minimum uygulanabilir ürün (MVP), bir ürünün, gelecekteki ürün geliştirme için geri bildirim sağlayabilecek ilk müşteriler tarafından kullanılabilecek yeterli özelliklere sahip bir versiyonudur.

Bir MVP oluşturmanız gerektiğinde, bazen bunun daha çok gülünç derecede büyük miktarda zaman alan bir uzay aracı inşa etmeye benzediğini sık sık gözlemledim. MVP aşamasındaki ana hedef, müşteriden hızlı geri bildirim almak ve bu geri bildirime dayanarak paydaşla 'düz mi gideceğiz' yoksa 'sağa mı döneceğiz' konusunda anlaşmaya varmaktır. Geri bildirim toplamanın en iyi yolu ölçümlerdir. Onlar olmadan da başarılı olmaları harika, ama başaramasalar bile en azından nedenini bileceksiniz.

Size ilk MVP'mi anlatacağım. Pek çok araç ve çerçeve buldum: UML, Tasarım Desenleri, Yol Haritası, Hikaye Noktaları, Sistem Gereksinimi Belirtimi, ADR, UI testleri vb . Bunların hepsini kullanmaya karar verdim çünkü bu çerçeveler büyük şirketlerde kullanılıyor ve bunları konferanslarda, konferanslarda ve YouTube'da duydum.

Hizmetin amacı test çalıştırmalarıyla ilgili verileri depolamaktı. Bir yıl boyunca bir yol haritası hazırladım, UML'de detaylı bir mimari çizdim, arka uç için bir çerçeve seçmek için uzun zaman harcadım, Sentry'de test ve loglamalar için bir sistem kurdum ve beklenen 10 yerine birçok kullanıcının yükünü hesapladım. -15. Mükemmel bir proje yapmak istedim.

İlk versiyonun tamamlanması 6 ay sürdü. Tüm lansmanlara, grafiklere bakabilir, raporları indirebiliyordunuz ancak veri toplamada bir sorun vardı. Haftada iki veya üç kez bozuk bir rapor çıkıyordu, bu da hizmetin kullanılmasını imkansız hale getiriyordu ama ben inatla planı takip ettim.

Sonraki birkaç yıl içinde birçok farklı projem oldu ve girişimimi başlatmaya çalıştım. Pazarlama, satış ve müşteri sıkıntısını öğrendim. Bu deneyim zihniyetimi değiştirdi ve bu makalede paylaştığım yaklaşımları geliştirmemi sağladı. Pratikte nasıl çalıştıklarını göstermek için yakın zamanda yapılan bir görevi anlatacağım.

Yavaşlığından dolayı kullanıcıları rahatsız eden API yöntemini hızlandırmam gerekiyordu. Plan, dahili hizmetler ve veri yapılarıyla birçok entegrasyon nedeniyle zorlukların yaşandığı monolitten ayrı bir hizmete taşımaktı. Bu proje deneyseldi; kimse hızlandırmanın mümkün olup olmadığını bilmiyordu.

Elbette devam edip her şeyi yeniden yazmayı ve mükemmel hale getirmeyi önerebilirim. Monoliti ve dahili hizmetleri araştırarak başladım ve entegrasyon risklerini araştırdım. Daha sonra Miro'da basit bir diyagram kullanarak bir strateji oluşturdum, her şeyi yinelemelere ayırdım ve ancak o zaman çalışmaya başladım.

Zaman zaman entegrasyonlarda paydaşların ilk öğrendiği sorunlar yaşandı. Öncelikle bunları çözdük. Evet, projede hala teknik borçlar vardı: linterler, tamamlanmamış testler, veritabanındaki eski şemalar - ancak müşterilerin sorunu çözüldü.

Tüm yinelemeler hedefe ulaştı ve 4. denemede %100'e ulaştık. Her şeyi sıfırdan yeniden yazmak 10 yinelemeyi gerektirecekti, ancak daha kısa sürede bile sorunu çözen ölçeklenebilir bir hizmete sahip olduk. Tek soru yaklaşımdır.

Büyüyen Bir Projedeki Geliştiricinin Kodeksi

• Mükemmeliyetçilikten vazgeçin. Dünya sorunları çözen teknolojilerle doluyken, projeleri insanlara faydalı kılmak için her şeyi bilmenize gerek yok.

• Mümkün olduğunca hazır çözümler kullanın.

• İş değeri önce gelir. Kullanıcılar bir ürün için gelmiyor, sorunlarının çözümü için geliyorlar.

• Riskleri başlangıçtan itibaren değerlendirin ve bunları paydaşlara açık bir şekilde iletin.

• Kısa vadeli planlar yapın. Görev iki yıldır biriktirilmiş durumdaysa, büyük olasılıkla kullanıcıların buna ihtiyacı yoktur.

• Geri bildirimleri ve ölçümleri mümkün olan her şekilde toplayın. Metrikler büyüme noktalarını bulmanın güvenilir bir yoludur.

• Başlangıçta "doğru" mühendislik kalıpları kullanılmadığında bile ölçeklenebilir çözümler elde edilebilir.