Kod hakkında konuşan bir kodlayıcı
Tom burada yazıyor, web ve yerel her şey için tutkulu bir geliştirici. Birkaç satır kod yazmaya başladığımdan beri birçok ay geçti. Muhteşem bir “Merhaba Dünya” anıydı ve o zamandan beri gerçek zamanlı uyarı sistemlerinden, doktorları günlük görevlerinde destekleyen tıbbi uygulamalardan çok platformlu toplantılara kadar çok daha fazla kod satırı yazdım-&- zamanlama-yönetim yazılımı. Ben de yol boyunca bazı şeyler öğrendim ve bugün, özellikle proje ortasındaki yoğun zamanlarda, kodlamanın her zaman o kadar fazla odaklanmayabilecek bir yönünü paylaşmak istiyorum. Bir kodlayıcının sorumluluğundan veya daha doğrusu bir kodlayıcının kod mirasından bahsedelim.
Javascript Piramitleri
Bir mimarın işi sadece yeni bir binanın temel düzenini, duvarların, pencerelerin ve kapıların şekillerini veya evin öğle saatlerinde güneşle orantılı olarak hizalanmasını tanımlamak değildir. Tüm bunların yanı sıra mimar, binanın uzun yıllar dayanması gerektiğini, kuvvetli rüzgarlar, şiddetli yağmurlar, dondurucu kışlar ve sıcak yazlardan oluşan vahşi doğaya dayanması gerektiğini biliyor. Mimarın işinin nihai amacı, binada yaşayan insanların güvenli bir yuvaya sahip olmalarını sağlamaktır. Her şey yaptığı işin uzun ömürlülüğü ile ilgili. Her şey onun mirasıyla ilgili.
Yazılım geliştirmede, özellikle startuplarda çalışırken, işler çok hızlı hareket etme eğilimindedir. Yeni özellikleri hızlı bir şekilde göndermek, pazarda çekiş kazanmak ve kullanıcıları etkileşimde tutmak önemlidir. Geliştirme sırasında odak, mevcut sprintle veya bu yüksek öncelikli özelliğin en kısa sürede uygulanmasıyla sınırlı olma eğilimindedir.
Yine de kodlama yaparken, testlerin tamamen yeşil yanması veya sadece ulaşılması gereken son teslim tarihi ile sınırlı kalmamalı. Vahşi doğadayken, uygulamalar günlük çalışma rutinleri için onlara güvenebilecek insanlar tarafından kullanılır. Bugün inşa ettiğim program, yarın geride bırakacağım mirastır.
Örnek olarak web'i ele alalım: Şu anda aradığım işlevselliği sağlayan bileşenleri NPM aracılığıyla bulmak hiç bu kadar kolay olmamıştı. Hızlı bir şekilde kurulurlar ve kod tabanının geri kalanına bağlanırlar. Ancak, uygulamamın uzun ömürlülüğü söz konusu olduğunda, 3. taraf bağımlılıkları tüm güncelleme sürecini durdurabilir, b/c güncellemesinin bir bağımlılığın diğerinin çalışmasını durdurduğunu güncellemesi. Neyin kendim tarafından uygulanacağına, çatalla veya doğrudan bir paket yöneticisinden yükleneceğine karar vermek, dengeleyici bir eylemdir.
Ancak, 3. taraf sağlayıcılardan gelen kodlar iyi olabilir. Kütüphaneyi veya çerçeveyi kullanmadan önce bazı faktörleri kontrol etmek önemlidir: geçmişte bakım ne kadar iyiydi, şu anda kaç aktif katkı var, gelecekteki değişiklikleri veya iyileştirmeleri özetleyen bir yol haritası mevcut mu, paket tamamen topluluk tarafından mı yönetiliyor veya destekleniyor mu? gelişimine yardımcı olmak için sponsorlar?
Harici koddan kendi kod tabanıma geçerken, kendime sürekli hatırlatmam gereken bir şey, bir hedefe daha hızlı ulaşmak için geliştirme sırasında köşeleri kesmemek. Kısa vadede ne kadar cezbedici olursa olsun, kötü planlanmış kodlar intikam alacak ve geri ısıracaktır. Kodu yazmaktan çok düşünmek, birçok sorunu hafifletmeye yardımcı olur. Burada kesinlikle önemli bir faktör deneyimdir, ancak genç geliştiriciler de en başından itibaren sürdürülebilir kodun önemini anlamalıdır. Şu anda hatalara yol açan şey, proje zaman çizelgeleri nedeniyle asla düzeltilemeyebilir ve yalnızca geçici çözümlerle çözülebilir, bu da ya karışık koda, kötü kullanıcı deneyimine ya da her ikisine birden yol açar.
makinist zihniyeti
Hakkında yazmak istediğim düşünceli kodlamanın diğer bir yönü, bir uygulamanın hedef kitlesi olan kullanıcıdır. 9'dan 5'e kadar elektrikli sürgü cetvelimin ekranının önünde otururken, kod satırlarını karıştırırken ve atandığım konuya odaklandığımdan, akılda tutmak zor, sonunda tüm çalışmalarım sonunda bitti. günlük iş sırasında kısmen veya tamamen kullanan biri tarafından kullanılmak üzere. Teknik bilgisi olmayan kişiler için bir uygulama mı yoksa diğer geliştiriciler için API'ler mi geliştiriyor olmam gerçekten önemli değil - oluşturduğum şeylerin kullanımında ergonomik olması gerekiyor.
Kullanıcıların uygulamanızla garip ve çoğunlukla açıklanamaz şekillerde etkileşime girebileceğini ilk elden deneyimlerden biliyorum. Yaratıcı olarak, hizmetimin "istenmeyen" davranışını reddetme eğilimindeyim, hatta buna çok fazla zaman ve enerji harcadıysam daha da fazla. Yine de geri bildirim alırken sakin olmak ve gerekirse kendimi onu dinlemeye zorlamak, izleyicinin gerçek, gerçek kullanım davranışını anlamada önemli bir rol oynar.
Geliştiriciler olarak, özel bir tür fizik ve yerçekiminin geçerli olduğu ve tüm kuralları bildiğimiz, kodlama yaparken bir düzen ve tekdüzelik dünyasında yaşıyoruz. Yaratıcıları ve sakinleri olduğumuz için, kendimizi kucaklamamız ve tamamen içine sokmamız gereken bir dünya. Ancak geri bildirimle karşı karşıya kalmak, yani bu dünyanın dışından gelen eleştiriler genellikle geliştiriciler tarafından reddedilmesine yol açar. Kullanıcı raporlarının ve seçeneklerinin ele alınması, geliştirme için ilgili girdiler olarak öğrenilmeli ve değerlendirilmelidir. Bu öğrendiğim bir ders ve projenin her aşamasında değişikliklere ve geri bildirimlere açık olmak için büyük ölçüde yardımcı oluyor.
süreç.çıkış();
Özetlemek gerekirse, yalnızca bugün yazdığınız kodu değil, insanların gelecek yıllarda kullanacağı kodu da düşünün. Nihai ürünün ergonomik ve verimli bir şekilde kullanılabilmesi ve hedef kitlenin gerçek talebini yansıtabilmesi için harici kod paketlerinin kullanımı ile projenin yapısı ve uygulamaları hakkında dikkatli kararlar verin. Geri bildirimi anlamak çok önemlidir ve gurur duyulabilecek kaliteli bir ürün sunmaya büyük ölçüde yardımcı olur.
- Tom
