Farkındalık, Anlama ve Sorumluluk »Kod Basitliği #teknolojihaberleri

 Farkındalık, Anlama ve Sorumluluk »Kod Basitliği
 #teknolojihaberleri
Okunuyor Farkındalık, Anlama ve Sorumluluk »Kod Basitliği #teknolojihaberleri

İyi bir programlayıcı olmanın veya olmanın üç ana faktörü vardır: farkındalık, anlayış ve sorumluluk.

Anlayışın konusu hakkında çok konuştum. Heck, en son kitabımı bile adlandırdım Yazılımı Anlamak. Özellikle, bir şeyi ne kadar iyi anlarsanız, o kadar iyi yapacağınızı birçok kez belirttim.

Bununla birlikte, birini mükemmel bir yazılım geliştirici haline getirme anlayışıyla birlikte gelen iki faktör daha var. Kısacası, bir sorunun farkında değilseniz, yaşanacak bir anlayış yoktur. Ve sorunu çözmek için harekete geçmezseniz (bunun sorumluluğunu almakla başlar) o zaman bu konuda hiçbir şey yapamazsınız.

Bu noktaların her biri hakkında çok şey bilmemiz gerekiyor. anahtar nasıl daha iyi bir yazılım geliştirici olunacağına bakar. Bu yüzden, sizinle burada daha derinlemesine gitmek istiyorum.

farkında olma

Bir bakıma, bu özel bir anlayış biçimidir. “Farkındalık”, temel olarak, bir şeyi algılayabileceğiniz ve var olduğunu bilebileceğiniz anlamına gelir. Bunun programlama için geçerli birçok yolu vardır.

En basitlerinden birini alalım: Bir hatanın farkında değilseniz, muhtemelen düzeltemezsiniz.

Bazen insanlar bir problem hakkında bir şeyler yapmak zorunda kalmamak için bunu kullanır. Farkında değillerse, düşünüyorlar, o zaman bunun hakkında bir şey yapmak zorunda kalmıyorlar. Bu olabilir ya da olmayabilir, ama ne olduğu doğru olan sorun var şahsen bunu biliyor olup olmamanız. Sisteminizde milyonlarca kullanıcıyı etkileyen bir hata varsa, o zaman meli farkında ol. Aksi takdirde, kullanıcılarınız acı çekecek. Acıları değil haklı onların çektiği acıların farkında olmamanızla – yani, bilmediğiniz için evrende aniden bir şey olmaz.

Daha ince farkındalık biçimleri var. Örneğin, bazı insanlar aslında değil farkında kod karmaşıklığı. Yeni yazdıkları kodun karmaşık olduğunu bilmiyorlar. Bazen karmaşıklığın bir sorun olduğunu bile bilmiyorlar ya da bakış açısının, yazdıkları kodu okumak zorunda olan başka bir programcının ne olacağının farkında değiller. Kodun eksik yorumları, okunmasının zor olduğunu veya sorunu çözmenin başka bir yolu olduğunu görmüyorlar. Bunların hepsi bir programcının farkındalık unsurlarıdır.

Bir programcı olarak farkındalığınızı geliştirmenin en basit yolu, normal kontrol alanınızın dışındaki kodu okumaya istekli olmaktır. Yani, belki de günlük olarak, videoyu kodlayan kod üzerinde çalışıyorsunuzdur. Ancak bu video da bir yerden geliyor; kullanıcılar bunu sisteminize yüklüyor. Videoların kodlayıcınıza nasıl girdiği ile ilgili bir sorunla karşılaşırsanız, belki de gitmeyi seçmelisiniz. bak Bu kodun gerçekte nasıl çalıştığını.

Bu kulağa basit geliyor ama bazen ben de dahil olmak üzere birçok insan için duygusal olarak zor olabilir. “Oradaki tüm aptallar ve bu berbat ve sadece bunun üzerinde çalışmak zorundayım” diye düşünmek kolaydır. Ama eğer yapmadıysanız bunu nasıl bilebilirsiniz? baktı kodunda mı? Belki de öğrenmene yardım edebileceğin bir şey vardır.

Farkındalık ayrıca, kodunuzda kullanabileceğiniz kitaplıkların, çerçevelerin veya araçların varlığını bilmekle ilgili olabilir. Belki de en son web geliştirme kitaplıklarıyla ilgili her şeyi bilmiyorsunuzdur, ancak bir web geliştiricisiyseniz, en azından farkında onların var olduğunu. Daha sonra hangi çerçeveyi kullanacağınıza karar vermeniz gerektiğinde, hangilerine bakacağınızı bilirsiniz.

Genel olarak, yeni programlama dilleri, yeni tasarım kalıpları, testler hakkında fikirler, yeni çerçeveler vb. istemek Yeni sistemler ve programlama yöntemleri hakkında bilgi sahibi olmak. Öfke dolu yeni bir dil duyduğumda, gidip en azından web sitesinin ön sayfasını okudum ve bazen belgelerine biraz girdim. Bu şekilde en azından şeyin var olduğunu biliyorum ve gerekirse gerekirse daha fazla şey öğrenebilirim. Sorunları çözmenin farklı yollarının farkında değilsem, o zaman bir yazılım mühendisi olarak elimde çok daha az araç var. Farkındalığımı bu şekilde artırmak, zor bir durumla karşılaştığımda seçeneklerimi arttırıyor.

Bunların hepsi aşırı basit gelebilir, ancak oldukça doğrudur:

Programlama ve programlara ilişkin farkındalığınızı geliştirerek programcı olarak kabiliyetinizi artırabilirsiniz.

anlayış

Başka yerde dediğim gibi:

Bir şeyi ne kadar iyi anlarsan o kadar iyi yapabilirsin.

Farkındalık ilk adımdır – bir şeyin var olduğunu biliyorsunuz. Ondan sonra anlama iyi yapmak için. Size telafi edilmiş bir psuedocode dilinde bir örnek vereyim:


işlevi print_hello () {
   temiz ekran()
   display_hello ()
}

Bu programın ne yaptığını düşünüyorsunuz? Terminali temizliyor gibi görünüyor ve ardından “Merhaba” kelimesini yazıyor. Dürüst olmak gerekirse, sadece tahmin ediyorum. Belgelerine veya kodlarına bakmadım temiz ekran veya write_hello. Eğer koda baksaydım, görürdüm temiz ekran aslında tüm ekranı beyaza çevirir ve write_hello “HELLO” kelimesini ekran boyunca on beş farklı dilde ve renkte yazdırır. Fakat bunu anlamak için bir şeye bakmadan bunu asla bilemezdim.

Bu basitleştirilmiş bir örnek gibi görünebilir, ancak bu olur her zaman programlamada. Artık clear_screen'in ne yaptığını bildiğime göre, düşünmek veya yeniden yazmak için zaman harcamak zorunda kalmadan başka bir yerde kullanabilirim. Buggy programı yerine yapmak istediğim şeyi yapan bir program yazabilirim. Mantıklı olan bir test yazabilirim. Bütün bunlar sadelik, istikrar ve “iyi programlama” olarak düşündüğümüz diğer tüm nitelikleri arttırıyor. Ve bunların hepsi anlayıştan kaynaklanıyor.

Özellikle “Programcılar Neden Emiyor” gibi birkaç makalede biraz gözden geçirdiğim başka anlayış biçimleri var. Bir programcı yapan veya kesen kilit nokta. Yararlı olan başka beceriler de var – hızlı yazmak, iyi iletişim kurmak, önceliklerinizi uygun şekilde yönetmek ve diğerleri. Fakat anahtar amaç anlayıştır. Bu olmadan, sen olabilirsin En hızlı dünyadaki programcı, ancak yalnızca korkunç ve sürdürülemez sistemler yazıyor. Takımdaki en çekici kişi sen olabilirsin, ama tamamen çalışan bir kod yazmayı başaramazsın. Hızlı ya da büyüleyici olmanın kötü olduğunu söylemiyorum – bunlar da faydalı beceriler – ama anlamadan, seni harika bir geliştiriciye dönüştürmeyecekler.

sorumluluk

Bu konu hakkında biraz konuştum, ilk kitap çıktıktan kısa bir süre sonra yazdığım O'Reilly blogunda bir yazı yazmıştım, fakat kaç tane codeimpimpity.com okuyucusunun bu yazıyı okuduğundan emin değilim, aslında çok önemli bir anahtar olmasına rağmen harika bir programcı olmak üzerine gelin.

Şimdi ilk önce bir şeyi açıklığa kavuşturmak istiyorum. Buradaki “sorumluluk” derken, “yanlış giden bir şey için suçu üstlenmek” anlamına gelmez. Bu ortak bir sorumluluk tanımıdır, ancak kullandığım değil. Bu durumda “sorumluluk” derken demek istediğim, “bir şeyin sebep olma veya kontrol altında olma isteği”. Örneğin, odam için sorumluluğum varsa, temizlemeye hazırım. Bu ben demek değil var temizlemek için, tamamen istekli olduğum için. Ve “ah evet, odamı temizlemeye tamamen istekliyim” ile ilgili büyük bir PR ifadesi değil, sonra da gidip üç saat boyunca dağınıklığa uzanıyorum. Hayır, gerçekten istekliyim. Mesela, en sevdiğin tatlıyı yemeye hazır mısın? Bu istekli. En sevdiğin tatlıyla ilgili olabileceğin her şey için heyecanlı olman gerektiğini söylemiyorum, sadece olması gerektiğini söylüyorum gerçek isteklilik yer.

Peki bu programlama için nasıl geçerlidir? Çok sık sık bu olumsuz örneğe rastladım:

“Bu kodu tekrar gözden geçirmek istemiyorum, çünkü ona sahip değilim.”

Bu aptalca. Düzenleme yeteneğine sahip misiniz? Kaynak kodunu okuyabilir misin? Sahiplere değişiklik göndermeye izin veriliyor mu? Öyleyse sen teorik olarak yetenekli tamir. Şimdi, bu, tüm dünyadaki tüm kodları her zaman sabitlemeye devam etmeniz gerektiği anlamına gelmez, çünkü bazen gelişim hedeflerinize göre yapmak için doğru zaman değişimi değildir. Ama bu cümleyi bile söylemekten nefret ediyorum, çünkü çoğu zaman insanlar bunu temizlemek için bir bahane olarak kullanıyorlar, ayrıca:

“Bu ekibin kodunu temizlemek için zaman harcayamam, çünkü projem daha uzun sürecek.” Veya, “Güvendiğim bu kodu temizlemek ekibimin hedeflerinin bir parçası değil.”

Tamam, bu teorilerin iki kusuru var. (Ve inan bana, onlar teoriler, gerçekler değil.)

Birincisi, genellikle bir şeyin yapılması daha uzun sürer. doğru şekilde Kötü, çılgın veya karmaşık kodlara bağlı olduğunuzda. Genellikle, aslında alarak sona erer az refactor'a geçme ve daha sonra özelliğinizi, ihtiyaç duyduğunuz şekilde çalışmayan dağınık veya korkunç bir kütüphanenin üzerine yazmayı denemek için harcadığınız zamandan fazlasını yazın. Bu nedenle, genellikle hedeflerinize fazladan fazla zaman eklemiyorsunuzdur. Sizin gibi görünmesinin nedeni, “bir şeyler” yapmak ile bir şeyler almak arasındaki farkı düşünmemenizdir. aslında bitti.

“Gerçekten bitti mi?” Derken ne demek istiyorum? Demek istediğim, işe yarıyor, sürekli hatalarla dolu değil, kolayca idare edebiliyor, hayatınızı bir geliştirici olarak emmiyor ve taşıyabiliyorsunuz. diğer üretken şeyler yapmaya.

Sorunu bu şekilde düşünün. Bir duvar ördüğünüzü hayal edelim ve en altta ayakkabılı tuğlalarla başlıyorsunuz. Sonra bunların üzerine birkaç kat daha tuğla koyuyorsunuz. Ancak dördüncü tuğla katmanına geçtikten sonra, alttaki tuğlalar kırılmaya başlar. Öyleyse gidip üzerlerine ayakkabılı odun ekleyerek ayakkabılı tuğlaları yamaladınız. Birkaç kat daha tuğla eklersiniz ve şimdi duvar yıkılmaya başlar. Böylece paslı demir çubuklarla desteklersin ve işine devam edersin. Bu şekilde devam edersen, bütün hayatını sadece duvarı koruyarak geçireceksin. Hayatında büyük bir problem olacak. Muhtemelen nihayetinde ondan uzaklaşacak ve şu an sürdürmesi gereken bir duvar felaketiyle başka birini bırakacaksınız, anlama Çünkü ayakkabılı yapı malzemelerinin çılgın bir birleşmesi gibi gözüküyor. Dürüst olmak gerekirse, bu oldukça acımasız.

Temel bağımlılıklarınızdaki kötü kodların etrafını “hacklediğinizde” veya “yama” yaptığınızda, yazılımınızı o duvarı inşa ettiğiniz gibi oluşturuyorsunuz. Daha az açıktır çünkü programların yüzünüze düşebilecek çok büyük bir fiziksel yapısı yoktur. Ancak yine de, aynı inşa prensibi geçerlidir – üstüne bir karmaşıklık ekleyerek temel bir karmaşıklığı çözdüğünüzde, sistemin karmaşıklığını arttırırsınız. Sen yerine çözmek Temel karmaşıklık, sistemin karmaşıklığını azaltır.

Ve bunun önemli olmadığını belirtmek istiyorum kim her şeyden önce karmaşık bir şey yaptı. “Başka birinin yaptığı”, yukarıdaki kuralların hiçbirini değiştirmez. Ve şimdi karmaşıklığın kime ait olduğu önemli değil. Etrafında dolaşırsanız, sistemi daha karmaşık hale getireceksiniz. Düzeltirseniz, sistemi daha az karmaşık hale getireceksiniz. Bir seçim yapıyorsun – bu güce sahipsin, ya sen kutu sorumlu olmak. Evet, bazen bu onu düzeltecek başka birini bulmayı gerektirir. Ama benim tecrübeme göre, daha sık, değişimi kendiniz yapmaya istekli olmanızı gerektirir.

Ve tabi ki, belki hepsini biliyorsundur. Ama yine de, “Ah, peki, bu küçük parçayı bu sefer biraz daha karmaşık hale getirebilirim, çünkü bu sadece bu. bir şey Bunu yapıyorum. ”Biliyorsunuz, bazen haklı olabilirsiniz, özellikle de kısa bir süre için bir şeyi kesmek zorunda kaldığınız bir tür meşru acil durum varsa. Ancak, daha sık olarak, siz ve diğer herkesin bakımı için bir kabus haline gelebilecek olan büyük bir kırık duvar karmaşasına katkıda bulunuyorsunuz. Bu küçük karmaşıklıklar, sorumlu olmayan bu seçimler, sonunda kimseyle uğraşmak istemeyen dev karışıklıklara neden oluyor.

Dolayısıyla, bu şekilde “sorumluluk” derken, demek istediğimlerin büyük bir kısmı “normal çevreniz dışındaki şeyleri değiştirmeye istekli olmak” dır. Sonsuz bir çevre olmak zorunda değildir. Bir yere bir çizgi çizip “Bu noktanın ötesinde, gerçekten başka birinin sorunu” diyebilirsiniz. Örneğin, projelerimde sık sık “Tamam, o kadar fazla iş yapmayacağım” diyen bir çizgi çizdim. Tamamen şirket dışından gelen kod hakkında, çünkü bu, zamanımın kullanılmasının bir üretkenliği değildi. ”Ama zaman zaman, dilleri programlamaya karşı hataları doldurmaya ya da geliştirici araçlarına düzeltme ekleri göndermeye kadar düşündüm. karmaşıklığa neden oluyor ya da hayatımı zorlaştırıyordum. Yani, aslında Bugzilla'nın ana mimarı oldum, çünkü düzeltilmesi gereken birçok şey olduğunu düşündüm. Ben herkesin gitmesi gerektiğini söylemiyorum o uzak. Ancak, projenizin kapsamı dışındaki bazı kodların sorumluluğunu kabul ederek daha iyi bir programcı olacağınızı söylüyorum. Ve bu kapsamı ne kadar yaygınlaştırırsanız, o kadar iyi bir programcı olursunuz.

Oh bu arada, orada olduklarını söyledim. iki Yukarıdaki teorileri ile kusurları. İkincisi, o grup sadece insanlık olsa bile, aslında bir gruba aitsiniz. Etraftaki tek kişi sen değilsin. Başkalarının koduna katkıda bulunmak sorun değil. Aslında hepimiz aynı takımdayız.

Bir şirket için çalışıyorsanız, bunlara rastlarken bunları düzelterek şirkete bir bütün olarak yardımcı oluyorsunuz. Ve dünyadaki tek bir geliştirici iseniz, yaygın olarak kullanılan bir kütüphane, popüler bir araç veya bazı kötü örnek kodları düzeltirken dünyayı diğer programcılar için biraz daha iyi bir yer haline getiriyorsunuz. Web bir yerde. Ve dürüst olmak gerekirse, seni daha iyi bir programcı yapar. Burada söylediklerimin hepsi bu. Tanıdığım en iyi programcılar, ne olursa olsun doğru giden her şey için geniş sorumluluk almaya istekli olanlardır. ne dokunmaları gereken kod parçası veya ne takım işleri halletmek için konuşmalılar. Sana bunu söylüyorum çünkü yardımcı olacak sen.

Ve bu arada, bir kütüphane veya API tüketicisi olarak çoğu zaman en iyi yenilemek için bir yer, çünkü o kütüphane veya API'nin nasıl tüketilmesi gerektiğini yazarlardan daha iyi bilirsiniz. En azından, ne problemin olduğunu söyleyen koda karşı bir hata yaz. Aksi halde yazarlar bir problem olduğunu nasıl bilebilirler? Sadece büyülü bir şekilde bilmelerini bekleyebilirsin, ama inan bana, çok sık yaparlar. değil biliyorum. Deneyiminiz, onlar için çok değerli olabilir!

özet

Genel olarak, daha iyi bir programcı olmak istiyorsanız, kendinize sormanız gereken şey farkındalığı, anlayışı veya sorumluluğu geliştirip geliştirmemeniz ve ardından bir süre buna odaklanmanızdır. Emin değilseniz, farkındalıkla başlayın, ardından anlayışa devam edin ve sonunda daha fazla sorumluluk alın. Bunu diğer yönde yapmak çok zor – anlamadığınız bir şeyin sorumluluğunu kolayca alamazsınız (sadece çok kafa karıştırıcı olurdu ve bu konuda çok iyi olmazsınız) ve bir şeyi anlamak imkansızdır farkında değilsin. Yani farkındalık, anlayış ve sonra sorumluluk doğru sıradır.

Geliştirmeniz gerektiğinin farkındaysanız, yeni bir kod okuyun, yeni bir programlama blogu bulun, kitap başlıklarına bakın, en yeni teknolojiler hakkında başka programcılarla konuşun – sorunların, çözümlerin, bilginin daha fazla farkında olmanıza yardımcı olan herhangi bir şey , desenler, insanlar, kuruluşlar, ilkeler veya işinizde size yardımcı olacak herhangi bir şey.

Odaklanmak istediğinizi anlıyorsanız, o zaman daha fazla belge okuyun, her bir işlevin nasıl çalıştığını anlamak için daha fazla zaman harcayın, programcı arkadaşlarınızla ilgili daha fazla soru sorun, sözlükteki bazı kelimeleri araştırın, sizin teknolojinizle ilgili makaleleri okuyun. İşinizle ilgili bazı bilgilerin eksiksiz ve tam olarak anlaşılması için herhangi bir yöntemi kullanmak veya kitap okumak.

Ve son olarak, sorumluluk daha çok üstlenmeye karar vererek çoğunlukla elde edilir. Bir sorun ortaya çıktığında, ortadan kaldırmak yerine onu çözmeye karar verin. Takımınızın dışında bir zorluk olduğunda, sorunun bir parçası olmak yerine sorunu çözmeye yardım etmeye karar verin. Özel bir sorumluluk türü de var; başka birinin çözmesi gereken bir problem olduğunda, onlara yardım etmeye istekli olunması, veyaYapmaları gereken şey buysa, kendi başlarına çözmelerine izin vermeye istekli olun. Sorumluluk sadece her şeyi yapmanız gerektiği anlamına gelmez. Ayrıca, başkalarının da işlerini yapmalarına yardımcı olmak istemek anlamına gelebilir.

Basit, bireysel adımlarla yaptığınız sürece yukarıdakileri yapmak bile zor değil. Bir gecede bütün evrenin farkında olmak zorunda değilsin. Yarın, şimdiye kadar yazılmış her programın her kelimesini anlamak zorunda değilsiniz. Ve bu blog gönderisini okuduğunuz için var olan her bir yazılımı değiştirmeye istekli olmanıza gerek yok. Küçük bir şeyle başla. Ardından bir sonraki şeye, bir sonraki şeye ve bir sonraki şeye geçin ve zamanla, istediğiniz kadar bir programcı olursunuz.

Keyfini çıkarın.

-Max




Haberin Kaynak Linki

Yapılan Yorumlar

Bir Cevap Yazın

This site uses Akismet to reduce spam. Learn how your comment data is processed.