İçerik
- 01. Kodlama artık kesmiyor
- Genişlik ve derinlik
- 02. Büyük uyarı
- 03. İnternet ne diyor
- Ortamı anlayın
- 04. Birlikte inşa ettiğimiz şeyler
- 05. Devops
- Yığını anlayın
- Gizemli iş
- Kullanışlı araçlar
- 06. Geliştirme bunu düzeltir ... belki
- Hata ayıklama
- 07. Kullanıcılar ne ister
- Rekabetçi pazar
- 08. Çizim ve yazma
- 09. Keyfinize bakın
- 10. Keskin kalın
- Bunu beğendin mi? Bunları oku!
Geliştiricilerin kod üreten hırsız işçilerden daha fazlası olması gerekir. Dijital yaşamımızdan daha fazlasını bekliyoruz ve onu oluşturan da bu adamlar, peki en iyi geliştiricilerin bilmesi gerekenler nelerdir? İşte çok fazla geliştiriciden eksik gördüğüm şeyler. Bu ayrıntılı değildir, ancak makul bir kodlayıcıyı harika bir geliştiriciye dönüştüren bu niteliklerdir.
Ancak bu tek bir şey değil ve özellikle hiçbir zaman XML'i ayrıştırma veya kodu optimize etme becerisi yok. Bu, kod yazma kitaplarında öğretilmeyen şaşırtıcı bir beceriler koleksiyonudur. Biraz fazladan bir şeyler.
Neden böyle havalandırma yapıyorsun? Çünkü geliştirme önemlidir, ancak geliştiriciler çoğu zaman farklı bir dünyaya gönderilir, her zaman yaptıkları için değil. Bu asla işe yaramaz. Geliştirme - teknik olan her şey - bilenler sadece koddan daha fazlasını anladıklarında her zaman başarılı olur.
01. Kodlama artık kesmiyor
Kodlamanın daha az etkileyici hale geldiği bir dünyadayız. Herkes site kurar, bazıları kodlu ama sizin mecbur değilsiniz. Artık siteler, uygulamalar ve özellikler oluşturabilen sadece inek değil.
Web ortaya çıktığından ve insanlar kendilerine öğretebildiğinden beri, kendi kendini yetiştiren geliştiriciler var. Ancak mezunlar bile tehdit altında. Bilgisayar bilimi dereceleri olan kişilerden, AI kursları, çeşitli medya ve kodlama alanlarından özgeçmişler alıyorum ama yine de eksik bir şeyler var. Bazen çok şey eksik.
Bunu ilk söyleyen ben değilim. "Kodlama artık kesmiyor", bölüm 3'ün başlığıdır. Tutkulu Programcıgibi kitaplarla birlikte Pragmatik Düşünme ve Öğrenme programcıları kendilerini kodun ötesinde geliştirmeye teşvik eder; Ekibin sorumlu ve tamamen insan üyeleri olmak.
Genişlik ve derinlik
Geliştiricilerin iki şekilde daha iyi olması gerekir: genişlik ve derinlik. Takımlarındaki insan etkileşimlerinin genişliğini ve inşa ettikleri şeyleri anlamaları gerekir. O / S'ye kadar birlikte çalıştıkları sistemin derinliğini anlamaları gerekir.
Ve bunları okuması gerekenler sadece geliştiriciler değil. Geliştiricilerle çalışıyorsanız, onlardan daha fazlasını beklemeniz gerektiğini düşünüyorum. Ne hakkında konuştuklarını onlara çizmelerini sağlayın. Resimlerle, nesnelerle ve (işe yarıyor) insanlardan kesip çıkararak sistemin onu kullanan insanlar için tam olarak nasıl olacağını açıklamalarını sağlayın.
02. Büyük uyarı
Geliştiriciler hakkında olumsuz konuşacağım, ama sanırım iznim var çünkü ben varım. Ayrıca, burada bahsettiğim en az bir şey tanıştığım birçok geliştirici için doğru. Çalışmaları harika olmasına ve kodlarını bilmelerine rağmen, zaman rekabetçidir. Bir avantaja sahip olmalısın ve bu:
- daha teknik ol
ve
- olmak çok daha insan
03. İnternet ne diyor
"Temel web geliştirme becerileri" için Google'da arama yapmak, beklentilerinizi ortaya çıkarır. Çerçeve bilgisi, x tarayıcı, CSS ve JS. Bilmeniz gereken çerçeveleri, yazmanız gereken platformları ve göz önünde bulundurmanız gereken yeni eğilimleri listelerler.
Bunlar bizim medyamız. Onlar inşa ettiğimiz şeylerdir, ancak bir projeye başarı kazandıran şey onlar değildir. Bir geliştirici, sistemin her ayrıntısını anlayabilir, size bir API'nin her özelliğini ve yeni bir CSS teknolojisini söyleyebilir, ancak yine de kullanılamaz bir şey üretebilir.
Ortamı anlayın
Herkes gibi geliştiricilerin de ortamlarını anlamaları gerekir - ancak hedef kitleyi de anlamalıdırlar, ister kullanıcılar, ister ekip veya diğer geliştiriciler olsun. Ortamlarının dünyaya (başka bir deyişle, üretim ortamına) nasıl uyduğunu ve nasıl bir etkiye sahip olduğunu (insanların onu nasıl kullandığını) anlamaları gerekir.
Bunun "geniş ve derin" kişi olarak tanımlandığını gördüm. Geniş, çünkü dünyayı diğer insanlarla çalışan bir insan olarak anlamanız gerekiyor. Derin çünkü proje bölümünüzün seviyesinin altında kapsamlı bir teknik bilgiye ihtiyacınız var. Bu geliştiriciler projenize büyük bir destek sağlar ve projenin hızını değiştirir; bunlar olmadan teknik olmayan personelin teknik ekipten taşan sıkıcı ayrıntılarla boğuştuğunu görürsünüz.
04. Birlikte inşa ettiğimiz şeyler
Yakın zamanda, site oluşturmak, barındırmayı yönetmek ve işlerini halletmek için kullandığımız her şeyin bir listesini yazdım, böylece katılan insanlar ilk birkaç hafta içinde öğrenecekleri hileli bir teknolojiye sahip olabilsinler. İnsanların bunları bildiğini okuduğumuz gibi alıyorduk, bu nedenle yeni işe alınanlara hızlı bir başlangıç yapmak için her gün kullandığımız her şeyi listeledik.
Yarım düzine teknoloji bekliyordum ama çok daha fazlasını elde ettim. Bu liste - 'kullandığımız' - olağan CMS'leri, programlama dillerini ve tarayıcı teknolojilerini, aynı zamanda ekibin kendilerinin kullandığını bile hatırlamadığı bir dizi aracı içerir. Hepsi kas hafızasıydı. Komut satırına "git", "phing", "thor" yazarken, birinin yapmayacağını düşünmedik bile.
Araçlar oluşturun; CI; sürüm kontrolü için git kabul edildi, ancak özgeçmişlere bakıldığında bunlar pek görünmüyordu. Modaya uygun olanlar görünürdü (ve bazı ajansların bunları eklediğini düşündüğüm için alaycı mı ?!) ama çoğu zaman somut bir deneyim olmadan.
Bu araçlar proje geliştirmeyi hızlandırmak için önemlidir, bu nedenle dilinizden, CMS'den ve birkaç çerçeveden çok daha zengin bir araç setine sahip olduğunuzdan emin olun. Dağıtım, test, CI, güçlü sürüm kontrolüne ihtiyacınız var (ekipler halinde - kendi başınıza değil) ve sadece birkaç öğretici yerine bunların temel kavramlarını anlamanız gerekiyor.
05. Devops
Bu ekstra araçlar ve püf noktaları, insanların "devops" dedikleri şeye tam olarak uyuyor. Devops, iki geleneksel silo karşısında uçar: işlerin yürümesini sağlayan üretim ve yeni şeyler yapan (ve genellikle işlerin yürümesini durduran) geliştirme. Silolar, birbirine çok az sempati duyan iki kampla sonuçlanıyor.
Üretim bilgisi olmayan geliştiriciler, konfigürasyonu veya henüz üretim yığınında olmayan özellikleri kullanarak daha sıklıkla üretime uygun olmayan kodlar üretirler. Üretim ortamının sorunlarının farkında olmadıkları için, özelliği üretime dağıtmak yerine tamamlamak için kodlarlar.
Bu küçük ayrıntılar, sunucu yönetimini yurtdışına gönderme eğilimiyle daha da kötüleşen sancılı gecikmeler yaratabilir.
Yığını anlayın
Devops, sürekli dağıtımı ve çok sayıda otomasyonu kapsayan kendi başına büyük bir alandır. Bu kapsamlı bir özet, ancak geliştiricilerin anlamaları gereken en önemli şey, üzerinde çalıştıkları yığın. Bunu sunucu yöneticisine devretmek yeterli değildir, platformun kodunuz üzerindeki etkilerini anlamanız gerekir.
Rails üzerinde çalışıyorsanız, Rails kodunu okuyun ve Ruby'nin Apache tarafından nasıl çalıştırıldığını öğrenin. Java'da çalışıyorsanız, yapılandırma seçeneklerini öğrenin. Kullandığınız Perl ise, Perl modüllerini nasıl kuracağınızı ve bunları nasıl yapılandıracağınızı öğrenin.
Gizemli iş
"Kullandıklarımız" listesi bunlardan çok şey içerir ve iyi geliştiriciler, tüm bu gizemli çalışmanın nasıl yapıldığını anlamak için bunun üzerine atlarlar. Ve bir kez aldıklarında, dağıtımlar daha hızlı ilerler, işler daha sorunsuz dağıtılır ve herkes daha mutlu olur.
Sürekli dağıtım ve ilgili uygulamalar o kadar standart hale geliyor ki, bunu uygulamayan herhangi bir geliştirici veya şirket, üstesinden gelmek için kendilerini hazırlıyor. Başkası bunu yapmaya başlayacak ve sizden daha hızlı olacak.
Kullanışlı araçlar
"Devops" için Google'da arama yapmak, bu adamların kullandığı araçlar hakkında size bir fikir verir. PHP ve MySQL veya Rails ile ilgili değil. Bu, yazılım göndermek ve projelerin riskli kısımlarını risksiz tutmakla ilgilidir. Dağıtıma, otomasyona ve geliştiriciden üretim ortamına kadar boru hattının olabildiğince hızlı çalışmasını sağlamaya odaklanırlar.
Bu geliştirme tarzının size birbirleriyle ve diğer departmanlar ve şirketlerle daha iyi çalışan geliştiriciler verdiğini göreceksiniz. Üçüncü bir tarafın API'si ile çalışıyorlarsa, diğer tarafta ortaya çıkması muhtemel sorunları anlayacaklardır. Sunucu yöneticileriyle çalışırken, neyin kurulmasına ihtiyaç duyduklarını anlayacaklar ve yazılım sitelerinin üretim sunucularında nasıl olduğunu öğrenecekler. Bunun tersi acı verici olabilir ...
06. Geliştirme bunu düzeltir ... belki
"Temel web geliştirici becerileri" arayışı, Quora'daki Michael Greer'den (The Onion’un CTO'su) güzel bir yanıt getiriyor:
- Tembellik: Herhangi bir şeyi iki kez yapmayı reddeder: bunun için bir senaryo veya algo yazar.
- Korkaklık: Test etmeyi düşünür, yükleme endişesi ve kod etkisi
- Pervasızlık: Sürekli yeni şeyler dener, aynı gün fikirleri ortaya çıkarır
Korkaklık, "detaylara dikkat" i ifade etmenin güzel bir yoludur. Hata ayıklama ve test, W3Schools'a girdiklerinde veya bilgi işlem 101 kursunu başlattıklarında kimsenin bahsetmediği bir geliştiricinin hayatının yüzde 99'udur.
Uygulamaları düzeltme yeteneği, mükemmel problem çözme becerileri gerektirir, ancak yalnızca kodda hata ayıklama becerisi gerektirmez. Bazen kullanıcıların faturalarını indirememelerinin çözümü, PDF'leri oluşturmak için bir gün harcamak yerine sayfayı yazdırılabilir hale getirmektir. Bazen bir bağlantı bir haftalık geliştirmenin yerini alabilir, ancak geliştiriciler sorunları yalnızca çok sayıda kod satırı yazarak çözüyorsa, bu zarif çözüm gerçekleşmez.
Test, birçok araca rağmen birçok geliştirici için harika bir kör noktadır. Xhprof gibi birim testleri, selenyum, yük testi ve profil oluşturma araçlarını kullanın. Uygulamanızın ayak izini küçük tutmak için New Relic gibi şeylerden analizler. Ve bunu geliştiricinin işinin bir parçası olarak düşünün: bu sizin kodunuz, ummak yerine amaçlandığı gibi çalıştığını bildiğinizden emin olun.
Hata ayıklama
Hata ayıklama da hassas bir noktadır. Bir hata ayıklayıcının nasıl kullanılacağı değil, bir sorunun nasıl giderileceği - bu yüzden Michael Greer'in listesine şunları eklerim:
- Sabırsızlık: gerçek sorunu bulmak ve çözmek için ilgisiz bilgileri şiddetle yok sayar
Bu, tüm hata ayıklama tekniklerinin temel taşıdır. İlgisiz olanı görmezden gelmek ve konuyla ilgili anlam bulmak. Maalesef, çoğu saatlerce veya günlerce ilgisizce çekiçlemeye, aynı şeyi 10 kez deneyerek bir sorunu çözmeye yatkındır.
Hata ayıklama üzerine çok sayıda kitap (ne yazık ki yayıncıya önerdiğim kitap değil) ve her geliştirici hepsini okumalı. Gerçekten harika bir geliştirici, bir kod satırı görmeden bir sistemdeki sorunları giderebilir.
07. Kullanıcılar ne ister
Çevrenizdeki insanların ne yapmaya çalıştığını anlayın. Kodun keyfini çıkarın - CSS dosyalarını mükemmel şekilde girinti oluşturma veya bir ray uygulamasını optimize etme sanatını sevin - ancak bunların hepsinin bir amaç için olduğunu unutmayın.
Geliştiricilerin işleri, operasyonları ve iş süreçlerini anlamaları gerekir çünkü onların işleri bunu yürütmeye yardımcı olur. Bu bilgiye sahip geliştiriciler, kullanıcılara yardımcı olan yazılımlar ve uygulamalar geliştirebilirler, ancak bunlar genellikle alışılmadık derecede üretken görünürler. Bunun nedeni, ışıklandırmayı hızlı yazmaları veya yığınla ilgili inanılmaz bilgileri olabilir, ancak büyük olasılıkla kullanıcıların ne istediğine dair bilgilerinden kaynaklanmaktadır.
Rekabetçi pazar
Asıl amacıma geri dönersek, geliştirme kolaylaşıyor ve harika geliştiriciler için pazar daha rekabetçi hale geliyor, iş gereksinimlerini anlayabilen ve bunları karşılamak için mükemmel bir şey getirebilen herhangi bir geliştirici avantaj elde edecek. Pazarı, müşterileri ve neden insanların parayla ayrıldığını anlayın hepsi yardımcı olur.
Verileri ve zamanla nasıl değişeceğini anlayın. Geliştiricinin zihninde, yeni teknolojileri bugün karşılaştığınız veya yaklaşmakta olduğunu gördüğünüz zorluklarla aynı hizaya getirmeleri gerekir. Bu şekilde, MD'ye veya bir müşteriye yeni ve şık bir fikir önerdiğinizde, bu, müşterilerin gerçekte ne istediğine bağlı olacak ve bunun için bütçe / zamanı alacaksınız. (Buna karşılık, tanık olunması gereken en kötü şey, geliştiricilerin yeni favori teknolojilerini tüm hastalıklarımıza çözüm olarak satmasıdır.)
Geliştiricilerin çok fazla kontrolü var - veritabanındaki her alanın son kullanıcı için ne anlama geldiğini bilmeleri gerekiyor mu? Verileri değiştirirsek kullanıcılar ne görecek? Kullanıcılara yardım etmenin daha iyi bir yolu var mı? Çoğu zaman, veritabanı yöneticilerinin görüşü dünyanın, veritabanlarının gerçek dünyanın kötü bir temsili olmaktan ziyade veritabanlarının kötü bir yansıması olduğu şeklindedir. Dünya karmakarışık ve şaşırtıcı derecede uç vakalarla dolu. Bununla başa çıkın, DB yöneticileri.
08. Çizim ve yazma
Çizim, bir şeyin nasıl olacağını iletmenin en doğrudan yoludur. Geliştiriciler fikirlerini beyaz tahta, kağıt ve bira altlıkları üzerine çizebilmeli.
Geliştiriciler, niyetlerini iletmek için kağıt üzerinde prototip oluşturabilmeli, ekran görüntülerini yazdırabilmeli ve üzerine karalamalar yapabilmelidir. Başını sallayan, anladığını ve editörünü açtığını söyleyen geliştiriciye güvenmeyin.
Ucuz bir şekilde başarısız olun: En iyi kodlama, hızlı bir prototip olarak çizimle başlar. Daha sık başarısız olun ve çevrenizdeki tüm geliştiricilerin, bu şekilde başarılı olma olasılığınız daha yüksek olduğundan emin olun.
09. Keyfinize bakın
Ya bir bağlantıyı hareket ettirerek bir problemi çözmek için 10 saat harcamanız gerekirse? Sadece işin üstesinden gelme zorluğu olsa bile, keyfini çıkarın.
Geliştiricilerin (veya herhangi birinin) en kötü tavrı, ekibin başarmaya çalıştığı şeye karşı ilgisizliktir. Ne yazık ki bu yaygındır, çünkü geliştiriciler kendilerini ekibin başardıklarının dışında görürler. (Tutkulu Programcı 'İşinizi ne kadar eğlenceli hale getirebilirsiniz?' sorusunu sorar - deneyin.)
Ve bunun tersi olduğu için çalışmanızı göstermeye hazır olun: Ruby ile ilgili birkaç öğreticiyi 'Experience of Ruby' için denedikten sonra genişlemeyin!
Web ve uygulama geliştirme hala genç bir meslektir, ancak gerçekten büyük geliştiricilerin ihtiyaç duyduğu beceri seti genişliyor. Herkes geliştiriciden daha fazla beklemelidir, çünkü hepimiz kötü arka odadan ne kadar erken çıkarsak ve yaratıcı sürece dahil olursak sonuçlar o kadar iyi olur.
10. Keskin kalın
Bunu güzel bir 10. tura çıkarmak için son bir şey daha ekleyeceğim. Keskin kalın. Rekabet bulun. Her şeyin en kötüsü, tek başına olandır.
"Bulunduğun her grupta daima en kötü adam ol."
En kötüsü - gerçekten, çok kötü - programcılar, kodlayıcılar, tasarımcılar işlerini öğrenir ve şöhretlerine güvenirler. Kalp pili olmadan yavaşlamak çok kolaydır ve rekabeti görmeden kendinizi ortalamanın üzerinde görmek alışkanlık haline gelir.
Yani, daha iyisini bularak yapabileceğiniz en kötü şey olun. İş dışındaki projelere katılın, katkıda bulunun ve geri bildirim ve eleştiri alın, çünkü ne kadar çok eleştiri alırsanız, gelecekte size o kadar az insan verecek. Ne istediklerini kendilerinden daha iyi tahmin ettiğinizde, o zaman herkesin istediği ninja geliştiricisiniz.
Dan Frost, resmi bir AWS iş ortağı olan tam hizmet web şirketi 3EV'in teknik direktörüdür. Yedi yıldır CMS ve web uygulama geliştirme alanlarında çalışmaktadır.
Bunu beğendin mi? Bunları oku!
- Bir uygulama nasıl oluşturulur
- Tasarımcılar için en iyi ücretsiz web yazı tipleri
- Artırılmış Gerçeklik için sırada neler olduğunu keşfedin
