Tasarımcıları Kod İnceleme Sürecine Getirerek Daha İyi İşbirliği
Yayınlanan: 2022-03-10Geliştiriciler ve tasarımcılar arasında sorunsuz işbirliği herkesin arzu ettiği bir şeydir, ancak herkesin bildiği gibi zor. Ancak günümüzün gelişmiş web'i ile disiplinler arası işbirliği yapmadan gerçekten harika bir ürün oluşturmak imkansız değilse bile zor. Bir ürünü oluşturmak için gereken teknolojilerin çeşitliliği nedeniyle, ürün ancak tüm disiplinler - geliştiriciler ve tasarımcılar, içerik oluşturucular ve kullanıcı deneyimi stratejistleri - projenin ilk aşamalarından itibaren derinden dahil olduğunda gerçekten başarılı olabilir. Bu gerçekleştiğinde, bir ürün oluşturmak için gerekenlerin tümü doğal olarak birleşik bir bütün halinde bir araya gelir ve bu nedenle harika bir ürün.
Bu nedenle, artık hiç kimse şelale süreçlerini gerçekten teşvik etmiyor. Yine de, diğer insanları, özellikle de diğer disiplinlerden insanları dahil etmek, korkutucu gelebilir. En kötü senaryoda, “komite tasarımına” yol açar.
Ayrıca, hem tasarımcılar hem de içerik stratejistleri genellikle tek bir yaratıcı dehanın hala ideal olduğu alanlarda geçmişe sahiptir. Başka birinin işinizi kanıtlaması, yaratıcılığınız için bir tehdit gibi görünebilir.
Öyleyse şelaleden kaçınmak için insanları nasıl erken dahil edebilirsiniz, ancak aynı zamanda komite tarafından tasarım için kendinizi hazırlamadığınızdan da emin olabilirsiniz? Kod incelemelerini öğrenirken cevabımı buldum.
Aha! An
Temmuz 2017'de iki geliştiriciyle birlikte Confrere'yi kurdum ve ilk mühendisimizi çabucak işe aldık (ben kendim geliştirici değilim, daha çok bir UX veya içerik tasarımcısıyım). İşbirliğimiz şaşırtıcı bir şekilde sorunsuz ilerliyordu, o kadar ki, retrospektiflerimizde tekrar eden tema, hepimizin “doğru yaptığımızı” hissetmemizdi.
"Doğru yaptığımızın" tam olarak ne olduğunu saptamak için iş arkadaşlarımla oturdum, böylece şirketimiz büyüyüp ekibimiz genişlese bile bu duyguyu korumaya çalışabilirdik. Tüm ekibin erkenden dahil olmasını takdir ettiğimizi ve birbirimize verdiğimiz geri bildirimlerde dürüst ve açık olduğumuzu anladık. CTO'muz Dag-Inge şunları ekledi: “Çalışıyor çünkü bunu akran olarak yapıyoruz. Azarlanmıyorsunuz ve sadece bir hata listesi alıyorsunuz”.
"Eş" kelimesi bana aha anını veren şeydi. UX, tasarım ve içerik alanında çalışanlarımızın, iş birliği söz konusu olduğunda geliştiricilerden öğrenecek çok şeyi olduğunu fark ettim.
Kod incelemeleri biçimindeki akran incelemesi, yazılımın nasıl oluşturulduğu için çok önemlidir. Bana göre kod incelemeleri, kendi alanlarımızda işbirliğini geliştirmek için ilham kaynağı olmakla birlikte, alanlar ve disiplinler arasında işbirliği yapmak için bir model sunuyor.
Kod incelemelerine zaten aşinaysanız, sonraki bölümü atlamaktan çekinmeyin.
Kod İnceleme Nedir?
Bir kod incelemesi çeşitli şekillerde yapılabilir. Bugün, en tipik kod inceleme biçimi, çekme istekleri (git adı verilen bir teknoloji kullanılarak) olarak adlandırılan şekilde gerçekleşir. Aşağıda gösterildiği gibi, çekme istekleri ekipteki diğer kişilerin bir geliştiricinin ana kod tabanıyla birleştirmek istedikleri kodu tamamladığını bilmelerini sağlar. Ayrıca, ekibin kodu gözden geçirmesine olanak tanır: Geliştirmeye ihtiyaç duyması durumunda, birleştirilmeden önce kod hakkında geri bildirimde bulunurlar.
Çekme isteklerinin açıkça tanımlanmış rolleri vardır: bir yazar ve bir gözden geçiren(ler) vardır.
Örnek olarak, üst düzey mühendisimiz Ingvild'in Confrere'nin kayıt akışında bir değişiklik yaptığını varsayalım. Ana kod tabanıyla birleştirilip sevk edilmeden önce, o (yazar), CTO'muz Dag-Inge'den (inceleyen) bir inceleme talep etmek için bir çekme talebi oluşturur. Kodunda herhangi bir değişiklik yapmaz, sadece yorumlarını ekler.
İncelemede aldığı geri bildirimlere göre nasıl hareket etmek istediği Ingvild'e kalmış. Uygun gördüğü değişikliklerle çekme isteğini güncelleyecektir.
Gözden geçiren(ler) çekme talebini onayladığında, Ingvild değişikliklerini ana kod tabanıyla birleştirebilir.
Neden Kod İnceleme Yapmaktan Rahatsız Ediyorsunuz?
Hiç kod incelemesi yapmadıysanız, yukarıdaki işlem bürokratik gelebilir. Şüpheniz varsa, burada kod incelemenin avantajları hakkında bir sürü blog yazısı ve akademik araştırma var.
Kod incelemeleri, yaptığımız her şeyin başkalarının incelemesine açık olması gerektiği ve bu tür incelemelerin tehdit edici olarak görülmek yerine iş akışınızın hoş bir parçası olması gerektiği konusunda tüm şirket için tonu belirler.
— Bruce Johnson, Full Story'nin kurucu ortağı
Kod incelemesi riski azaltır. Birinin çalışmanızı kanıtlamasını sağlamak ve ayrıca birinin çalışmanızı kanıtlayacağını bilmek , hataları ayıklamaya yardımcı olur ve kaliteyi artırır. Ayrıca, tutarlılık sağlar ve her ekip üyesinin kod tabanının daha fazlasını tanımasına yardımcı olur.
Doğru yapıldığında, kod incelemesi ayrıca işbirliği ve açıklık için bir kültür oluşturur. Başkalarının çalışmalarını anlamaya ve eleştirmeye çalışmak, öğrenmenin harika bir yoludur ve işiniz hakkında dürüst geri bildirim almak da öyle.
Her zaman en az iki kişinin kodu gözden geçirmesi, "benim" kodum ve "sizin" kodunuz hakkındaki fikirleri de azaltır. Bu bizim kodumuz.
Bu avantajlar göz önüne alındığında, bir inceleme sadece kod için yapılmamalıdır.
Sadece Kod Değil, Tüm Disiplinler İçin İlkeleri Gözden Geçirin
İncelemelerde her zaman bir yazar ve bir veya daha fazla yorumcu vardır. Bu, komite tarafından tasarıma düşmeden insanları erken dahil edebileceğiniz anlamına gelir.
Öncelikle, ekibinizin faydalı incelemeler yapma yeteneğini etkileyecek iki önemli faktörden bahsetmeliyim. Bunlarda ustalaşmış olmanız gerekmez, ancak asgari olarak aşağıdakileri hedeflemelisiniz:
- Siz ve meslektaşlarınız birbirinize ve birbirinizin disiplinlerine saygı duyuyorsunuz.
- Kendi rolünüzde kendinize yeterince güveniyorsunuz, böylece hem eleştiri alıp hem de alabileceğinizi hissediyorsunuz (bu aynı zamanda ekibin psikolojik güvenliğiyle de bağlantılı).
Kodu gözden geçirmiyor olsak bile, kod incelemeleri için mevcut en iyi uygulamalardan öğrenilecek çok şey var.
Ekibimiz içinde, incelemeler yaparken aşağıdaki ilkelere bağlı kalmaya çalışıyoruz:
- Yazarı değil eseri eleştirin.
- Eleştirel olun, ancak nazik ve meraklı kalın.
- a) Öneriler b) Gereksinimler, c) Tartışma veya açıklama gerektiren noktalar arasında ayrım yapın.
- Tartışmaları metinden yüz yüze yapın. (Video sayıları)
- İyi tarafları övmeyi unutmayın! Zeki, yaratıcı, sağlam, orijinal, eğlenceli, hoş ve benzeri nedir?
Bu ilkeler, işbirliğimizin neden bu kadar iyi çalıştığını tartışana kadar aslında yazılı değildi. Hepimiz zaten soru sormamıza ve iyileştirmeler önermemize izin verildiğini ve beklendiğini hissettik ve motivasyonlarımızın her zaman birlikte harika bir şey inşa etmek olduğunu ve başka birini eleştirmekle ilgili olmadığını hissettik.
Ne tür geri bildirimler verdiğimiz konusunda net olduğumuzdan ve birbirimizin iyi çalışmalarını övmeyi de hatırladığımızdan, inceleme yapmak moral bozucu olmaktan çok olumlu bir güçtü.
Bir örnek
Ekibimizin disiplinler arasında ve bir süreç boyunca incelemeyi nasıl kullandığı hakkında size bir fikir vermek için, kayıt akışımızı oluştururken ekibimizin farklı üyelerinin yazar ve gözden geçiren rolleri arasında nasıl geçiş yaptığına bakalım.
Adım 1: Gereksinimlerin toplanması
Yazar: Ida (UX)
Hakemler: Svein (strateji), Dag-Inge (mühendislik), Ingvild (mühendislik).
Herhangi bir yapı yoksa beyaz tahta oturumları yorucu olabilir. Üretkenliği ve yaratıcılığı korumak için, beyaz tahtada beyin fırtınası yapmak gibi basit görünen bir şey için bile yazar/inceleyen yapısını kullanırız. Kayıt akışımız için gereksinimleri belirlediğimiz bu durumda, yazar oldum ve ekibin geri kalanı geri bildirimde bulundu ve gözden geçiren olarak hareket etti. Ayrıca 2. adımda elde ettiğim şeyi gözden geçirebileceklerini bildikleri için (düzenlemeler, öneriler ve iyileştirmeler için çok daha fazla fırsat), hızlı bir şekilde çalıştık ve 2 saatten kısa bir sürede gereksinimler üzerinde anlaşabildik.
2. Adım: Mikrokopi ile maket
Yazar: Ida (UX)
Hakemler: Ingvild (mühendislik), Eivind (tasarım), Svein (strateji).
Bir yazar olarak, kayıt akışının mikrokopi ile bir maketini oluşturdum. Kaydolma akışı hem kullanıcı hem de mühendislik açısından anlamlı mıydı? Tasarım ve ön uç perspektifinden akışı nasıl iyileştirebiliriz? Bu aşamada, tüm disiplinlerin geri bildirimde bulunabileceği bir formatta çalışmak esastı (Google Dokümanlar'ı seçtik, ancak InvisionApp gibi bir araçla da yapılabilirdi).
3. Adım: Kayıt akışını uygulama
Yazar: Ingvild (mühendislik)
Hakem: Ida (UX) ve Dag-Inge (mühendislik).
Akış, girdi alanları ve mikroskopi üzerinde anlaşmıştık ve bu yüzden onu uygulamak Ingvild'e kalmıştı. Surge sayesinde, değişikliklerin önizleme URL'lerini otomatik olarak oluşturabiliyoruz, böylece kod okuyamayan kişiler de bu aşamada geri bildirimde bulunabiliyor.
4. Adım: Kullanıcı testi
Yazar: Ida (UX)
İnceleyen: Kullanıcılar.
Evet, kullanıcı testini bir inceleme biçimi olarak görüyoruz. Yeni oluşturulan kayıt akışımızı gerçek kullanıcılarla yüz yüze getirdik. Bu adım bize bir ton fikir verdi ve bunun sonucunda kayıt akışımızdaki en önemli değişiklikler geldi.
Adım 5: Tasarım
Yazar: Eivind (tasarım)
Hakemler: Ingvild (mühendislik) ve Ida (UX).
Tasarım burada 5. adımda aniden ortaya çıktığında, şelale sürecine çok benzeyebilir. Ancak tasarımcımız Eivind, 2. adımdan beri zaten bir gözden geçiren olarak dahil olmuştu. O aşamada bir sürü faydalı geri bildirimde bulundu ve ayrıca kayıt akışının tasarımını mevcut modüllerin ötesinde nasıl geliştirebileceğimizi düşünmeye başlayabildi. tasarım sistemimizde. Bu adımda, Eivind, kullanıcı testinde belirlediğimiz bazı sorunların çözülmesine de yardımcı olabilir.
6. Adım: Uygulama
Yazar: Ingvild (mühendislik)
Hakem: Eivind (tasarım), Ida (UX) ve Dag-Inge (mühendislik).
Ve sonra uygulamaya geri dönüyoruz.
İnceleme neden işe yarar?
Özetle, her zaman sadece bir yazar vardır, bu nedenle komite tasarımından kaçınılır. Bir dizi disiplini erkenden gözden geçirenler olarak dahil ederek, bir şelale sürecine girmekten kaçınırız.
İnsanlar endişelerini erkenden işaretleyebilir ve daha sonra nasıl katkıda bulunabileceklerini düşünmeye başlayabilir. Açıkça tanımlanmış roller, süreci yolunda tutar.
Düzenli İnceleme İzlenecek Yolları
Kod izlenecek yollardan ilham alarak, aşağıdaki ilkelerin rehberliğinde farklı odaklara sahip düzenli gözden geçirme kılavuzları da yapıyoruz:
- Geçiş birlikte yapılır.
- İnceleme ve belgelemeden bir kişi sorumludur.
- Buradaki fikir, sorunları çözmek değil, sorunları belirlemektir .
- Daha sonra bulgulara göre hareket etmek için mümkün olduğunca fazla bağlam sağlayan bir biçim seçin (ör. görsel incelemeler için InvisionApp, metin için Google Dokümanlar vb.).
Erişilebilirlik denetimleri, özellik isteklerini gözden geçirme, tasarımın uygulanmasını denetleme ve buluşsal kullanılabilirlik değerlendirmeleri yapma gibi şeyler için gözden geçirme adımlarını gerçekleştirdik.
Üç aylık erişilebilirlik incelemelerimizi yaptığımızda, erişilebilirlik danışmanımız Joakim önce arayüzü ve belgeleri inceliyor ve paylaşılan bir Google E-Tablosunda bulduğu sorunları önceliklendiriyor. Joakim daha sonra belirlediği en önemli konularda bize rehberlik ediyor.
Sorunları gözden geçirmek için yüz yüze (veya en azından videoda) görüşmek, denetlenme veya mikro yönetim duygusundan ziyade öğrenme için bir ortam yaratılmasına yardımcı olur.
Kendinizi her zaman piyasaya sürülmesi gereken bir şeye bağlı buluyorsanız veya gelen kutunuzun en üstünde ne varsa düzeltiyorsanız, incelemeler bunu düzeltmenize yardımcı olabilir. Halihazırda yaptığınız işleri gözden geçirmek için düzenli olarak yarım gün ayırırsanız, sorunları acil hale gelmeden önce belirleyebilirsiniz. Ayrıca yeniden odaklanmanıza ve önceliklerinizin doğru çizgide olduğundan emin olmanıza yardımcı olabilir. Ekibiniz, mevcut özelliklerin standartlarınızı karşıladığından emin olmadan önce bu yeni özelliği oluşturmaya başlamamalıdır.
Kullanıcı Testi Bir İnceleme Şeklidir
Kod incelemeleri için önemli bir motivasyon, riski azaltmaktır. Bunu, ürününüze her değişiklik yaptığınızda veya yeni bir şey eklediğinizde ve yalnızca bir şeyin belki de aynı seviyede olmadığından şüphelenmenizde değil, hataların veya özelliklerin altında kalma olasılığını azaltırsınız. Kullanıcı testlerine aynı perspektiften bakmamız gerektiğine inanıyorum.
Görüyorsunuz, büyük kullanılabilirlik sorunları olan nakliye riskini azaltmak istiyorsanız, kullanıcı testi sürecinizin bir parçası olmalıdır. Sadece UX tasarımcılarınızın arayüzü incelemesini sağlamak yeterli değildir. Birkaç çalışma, kullanılabilirlik uzmanlarının bile her gerçek kullanılabilirlik sorununu tanımlamakta başarısız olduğunu bulmuştur. Ortalama olarak, uzmanlar tarafından tanımlanan her 3 sorundan 1'i yanlış alarmdı - pratikte kullanıcılar için sorun değildi. Ancak daha da kötüsü, kullanıcıların gerçekte yaşadığı 2 sorundan 1'i uzmanlar tarafından gözden kaçırıldı.
Kullanıcı testini atlamak, kod incelemesini atlamak kadar büyük bir risktir.
Gözden Geçirme Yaratıcılık İçin Ölüm Demek mi?
Tasarım, kullanıcı deneyimi ve içerik alanlarında çalışan insanlar genellikle sanat okullarından veya belki de tek yaratıcının veya yaratıcı sanatsal dehanın ideal olarak kabul edildiği edebiyattan eğitim geçmişine sahiptir. Tarihte geriye giderseniz, bu durum geliştiriciler için de geçerliydi. Zamanla, web geliştirme daha karmaşık hale geldikçe bu zorunlulukla değişti.
İçinizin derinliklerinden gelen yaratıcılık fikrine tutunursanız, gözden geçirme fikri size tehdit edici veya korkutucu gelebilir. Yarım kalmış işinize karışan biri mi var? Ah. Ancak, yaratıcılığı diyalog, işbirliği veya herhangi bir ilham (dışarıdan veya içinizdeki bir yerden) dahil olmak üzere birçok kaynaktan kaynaklanabilecek bir şey olarak düşünüyorsanız, o zaman bir inceleme yalnızca bir varlık ve bir fırsattır.
Web için bir şeyler inşa ettiğimiz sürece, ister kendi alanımızda ister başkalarında olsun, diğer insanlarla işbirliği yapmanın bir yolu yoktur. Ve iyi bir fikir incelemeden kurtulacaktır.
Birlikte harika bir şey yaratalım.