Üst düzey programcıların her zaman kitap kullanma önerileri iyi bir fikir midir? [kapalı]

Küçük bir geliştiriciyim ve yalnızca 5 yıldır bu sektörde bulunuyorum. Şu anki şirketimde bir kıdemli var, ona Infestus diyelim. Zaman zaman parlama ve sıfırdan tamamen yepyeni bir şey yapma fırsatı veriliyor.

En yeni örneklerden biri, çok iş parçacıklı uygulamada bir singleton yapmak zorunda kalmamdı. Bu yöntemi kullanmaya karar verdim . Infestus gördüğü andan itibaren hızlıca beni aptal olarak adlandırdı ve bu yaklaşımı kullanmamı söyledi . Ona neden onu daha iyi olduğu için neden fırlattığını sorduktan sonra, bu ve Java hakkındaki bu kitabın daha iyi olduğunu söylüyor.

Ve bu yaygın bir kalıptır: ne zaman yeni bir şey yapma şansım olursa, hızlıca Infestus tarafından vurulur ve yönteminin daha iyi olmasının tek nedeni, bu kitapların ünlü programcılar tarafından yazılmasıdır. Bana her zaman bana hangi kitapları programlayacağını "öğrenebileceğim" için okumam için kitap vermeye çalışıyor.

Sadece 5 yıldır para için programlama yapıyorum, ancak bir problemi çözmek için kitabı en iyi yollardan sadece kör bir şekilde takip etmek her zaman iyi bir fikir midir, yoksa her zaman denemeyi denemeli miyim? Infestus'tan gelen sürekli şikayet barajı, asla yeni bir şey denememe ve kitaplardaki örnekleri takip etmeme neden oluyor.

EDIT : Ben tamamen kayboldum. Evet, kör bir şeyi takip etmenin kötü bir fikir olduğunu biliyorum. Ama çok tanıyor gibi görünen bu tanrısal programcı Infestus, bana düzgün programlamanın tek yolunun kitap okumak ve her şeyi bir T'ye kadar takip etmek olduğunu söylüyor. Kitaplar tek doğru yol ise.

EDIT2 : Infestus benim patronum değil. Kodun gözden geçirilmesinden sorumlu kıdemli geliştiricilerden sadece biri. İncelemelerden sonraki yorumlarının çoğu, böyle ve böyle bir yöntemin yanlış olduğu kitap adlarından oluşur.

Tüm kariyerin boyunca böyle programcılarla karşılaşacaksın. Kendi başınıza deney ve öğrenme konusunda yanlış bir şey yoktur. Tabii ki kitaplar harika. Örnekler çoğu zaman temiz bir ortamda çalışır, ancak başka bir şirketin geliştiricisiyseniz, temiz (başkalarının müdahalesi olmadan) çevre diye bir şey yoktur.

İşleri "doğru" şekilde yapmayı bilmek her zaman güzeldir, ancak görüşler yıldan yıla değişir. Öyleyse ne yapabileceğini öğren. Üst düzey geliştiriciden elinizden geleni yapın, kendi öğrendiğiniz bilgilerinizle harmanlayın. Sonunda, kıdemli bir geliştirici olacaksınız ve bu deneyimlerden faydalanacak ve gençlere eğitim vereceksiniz.

Sadece bu konuda salak olma.

Sana gerçekten aptal mı dedi , yoksa sadece kodu mi kaldı? Aptalca bir şey aramak tatsızdır, ancak bu öneriyi geçersiz kılmaz. Bence Infestus değerli bir öneride bulundu ve gelecekte önerilerini ciddiye almalısınız. Çok fazla okuma yapıyor gibi gözüküyor ve en azından bu durumda fikri iyi bilgilendirilmiş durumda. Senkronizasyon hem pahalı hem de zorlu. Önerilen uygulaması sizinkinden daha verimli ve basittir ve çalışması garanti edilir.

Bana her zaman bana hangi kitapları programlayacağını "öğrenebileceğim" için okumam için kitap vermeye çalışıyor.

Bu ona göre. Size aktif olarak yardım etmeye çalışıyor, ama egonuzun yoluna girmesine izin veriyor gibi görünüyorsunuz. Kodunuzu kişisel olarak eleştirmeyin. Kodun üretilmesi ucuz ve değiştirilmesi kolaydır. Birisi size bir şeyi yapmanın daha basit bir yolunu gösteriyorsa, onlara teşekkür edin.

Ve evet, okumak sizi daha iyi bir programcı yapacaktır. Tanıdığım tüm uzmanlar kapsamlı bir şekilde okuyor. Çok fazla okumadıysanız, en iyi ihtimalle vasatsınız ve beş yıl içinde artık pazarlanabilir olmadığınızı fark edebilirsiniz.

Bir kitap okumak kör olmamalıdır: yazar sizi sunarken yaklaşımının esasları hakkında ikna etmeye çalışmalıdır. Büyüklerinizin sizi tercih ettiği yaklaşımını açıklayan bir kitapta göstermesi makul olur, kendisinin açıklamasını istemek yerine, tercihlerinin faydalarını, kitaplara güvenmeden açıklayabilmesi gerekirken, bu aynı zamanda çabanın bir kopyasıdır. kitabın yazarı çoktan yaptı.

Öyleyse, kitabı okuyun, kitabın yazarının ne dediğini görün ve eğer sizi şaşırtıyorsa, ya da anlamanızı onaylamak istiyorsanız ya da kabul etmiyorsanız, o zaman kıdemli ile onun hakkında konuşun, ama şimdi Daha verimli bir tartışma yapabilir.

Herhangi bir sağlıklı ilişki için üç anahtar unsur vardır. İletişim, dürüstlük ve güven. Tüm ilişkilerin, hatta çalışma ilişkilerinin bile önemi var. Bu endişeler hakkında amirinizle konuşmalısınız.

Belirli bir tasarımı savunmanın nedenlerini anlamıyorsanız, ona bunu söyleyin . Ona kitabı okumadığını ve neden yapma şeklinin daha iyi olduğunu anlamak istediğini söyle. Önemli olan şeyleri yapma şeklini anlamaya çalışmanız gerektiğidir .

Bence bu kişiye de daha fazla saygı göstermelisin. Kafanızda, ona aşağılayıcı isimler diyorsunuz ve “öğrenme” olarak düşündüğünüz şeye yaklaşımını eleştiriyorsunuz. Buna dikkat et. Öte yandan, sana aptal dediğini söyledin . Bu hiç hoş değil ve ona aptal diyecek kadar havalı olmadığını söylemelisin.

Fikirler aptal olabilir. Hepimiz hata yaparız ve hatta bazı şeyleri özleriz, hatta yaşlıları bile. Bir tasarımda bir kusur olduğunda, sorulması gereken en iyi soru "Neden bu şekilde yapıyorsun? Durumda kırılmaz mı? X, Y, Z? B tasarımı daha iyi olmaz mı?"

Bu yazılım üzerinde başkalarıyla birlikte çalıştığınızı unutmayın. Öğrenmesi zor bir yetenek. Sıfırdan hiçbir şey yazmamanızın bir önemi yoktur, kodunuzu yapabileceğiniz en iyi kod haline getirerek her zaman parlamaya yer vardır.

Ve "en iyi" çok sık okunabilir ve anlaşılabilir demektir . Programcılar, başkalarının kodlarını okumak için çok zaman harcıyoruz. Bu kod açık ve okunabilir ise, bu kodun gerçekten değerli olmasını sağlar. Mükemmel kod yazmayı öğrenmenin yollarından biri de birçok iyi kodu okumaktır. Kitaplarda çok iyi kodlar buluyorsunuz. Bu yüzden bir veya iki iyi programlama kitabı okumak sizi daha iyi bir programcı yapar.

Çalıştığınız şirkette, muhtemelen öyle. Bu senin yapmanı istedikleri şey.

Bu mühendis Infestus, genç geliştiricileri eğitmek için “kitapta yazıldığını ve bu yüzden” olduğunu söyleyerek çok zayıf bir iş yapıyor. O bir vaiz değil, o bir mühendis ve onu kırabilmeli ve kavramları deneyimleyip öğrenebilecekleri şekilde sunabilmelidir.

Şirketinizdeki bilgili geliştiricilerle konuşmanızı, onlara farklı programlama tekniklerinin avantajları ve dezavantajları, vb. Hakkında sorular sormanızı öneririm. sana daha iyi bir anlayış vermeli.

IMHO, burada ayrı ayrı ele almanız gereken 2 husus var:

• Adamın gerizekalı olması, sizi isimleri çağıran biri ve öyle olması nedeniyle (üst düzey, sen değilsin, eğer ikinizden biri hakkında şikayet ederse, şüphenin yararına olacaktır) kabadayı benzeri davranış ve sadece kötü.

Bununla seviyesine inmemeye çalış. Onu geri kabadayı ya da patron ya da "bir şey" ona anlatmaya çalışmayın. Davranışının bu yönünü göz ardı etmek için elinizden geleni yapın, bunun aşırı olduğunu unutmayın (yani verimliliğinizi etkiliyorsa ve böyle bir şey varsa) bu konuda bir şeyler yapmalısınız.

• Size kodunuzun kötü olduğunu söylemesi (ve nasıl uygun şekilde yapılacağı). Açıkçası anlattıklarınızdan, adamın tonunu göz ardı ederek, davranışının bu yönü o kadar da kötü değil. İşleri çok daha hızlı öğrenir ve onları doğru bağlamda görerek, sizi düzeltmek ve yalnızca neyi yanlış yaptığınızı değil, aynı zamanda nasıl doğru yapabileceğinizi (sadece kendi başınıza öğrenmeye kıyasla) nasıl yapacağınızı söylerken daha iyi bir şekilde görmenizi sağlarsınız. kişisel deneme / hata deneyleri ve benzerlerinden)

Bir süre önce birilerinin başlangıçta "mükemmel kodum" olduğunu düşündüğüm şeyi düzelttim ve sadece bana daha sonra başından beri haklı olduğunun farkına varmak için ne yapacağımı söylediğine üzüldüm. iyi ve Tanrıya şükür bunu gördü! :) Bu yüzden "hey, u bana ne yapacağımı söyleme, mista!" ve bunun yerine, her biri biri beni düzelttiğinde, önce gerçekten, nesnel olarak, kodumu tekrar kontrol et, sonra kontrol et, ve gerçekten doğru olmadığından emin ol, ben de bu işi yapan benim. Bu benim suçumsa, yardımından ona teşekkür ediyorum ve çözümünün nasıl çalıştığını gerçekten anladığımdan emin oluyorum (kopyalayıp / yapıştırmak yerine).

Ve bazen, teklif edilen düzeltmenin aslında başlangıçta yaptığımdan daha kötü olduğunu anlıyorum, bu noktada diğerleriyle konuşmaya çalışıyorum. Dürüst olmak gerekirse, hiçbir şeyin bir hata yapmadığınızda düzeltilmeyi kabul edebileceğinizi gördüklerinden daha hızlı bir şekilde başkalarının size saygı duymadığını fark ettim, ama aynı zamanda, siz olduğunuzu söylemekten çekinmeyin böyle düşündüğün zaman kim haklı, hemen onayladığın zaman, sadece egoya değil, gerçek bir araştırmaya dayandığını kanıtlayabilirsin.

Bu noktada, adamla ne önerdiği ve ne önerdiği hakkında gerçekten konuşmaya çalışmalısınız. Ona ne düşündüğünü, belirli bir çözüme nasıl ulaştığını ve neden ondan daha iyi olduğunu düşündüğünü göster (dürüst ve nesnel bir şekilde düşündüğünde). Ya da önerisinin sizinkinden daha iyi olduğunu öğrenirseniz, ona söyleyin, yardım için takdirinizi belirtin. Bu, bazı yanmış köprüler yeniden inşa edebilir.

Kendi başınıza deney yapın ve elinizden geleni yapın. Yeterince kitap okuduktan sonra, belirli konularda birden fazla kitap olduğunu keşfedeceksiniz ve birbirleriyle çelişebilecekler. En iyi olduğunu düşündüğünüz şeyi deneyin ve zamanınız varsa ya da karşılaştırmak / karşılaştırmak istiyorsanız her ikisini de deneyin.

Patronunla baş etmek tamamen farklı bir konu ve yaklaşım. Birisinin bir kitapta olduğu gibi bir şey yapmasını isteseydim, onlara söylerdim. Bu sadece benim, çünkü akıl okuyucuları ile ilişki kurmuyorum. Patronunuz bunu bir alışkanlık haline getirir, sadece yeni bir proje aldığınızda kitap veya referans tavsiye edip etmediğini sorun.

Ne yaparsan yap, yeni projeler üzerinde çalışmayı bırakma. Bu durumla nasıl başa çıkılacağı konusunda ipuçları vermemizin kolay olduğunu biliyorum, işe ya da çalışmayabilirler, ancak bununla yaşamak ve olumsuzluktan muzdarip olan sizsiniz. İyileşeceksin, ama bu genellikle yeni şeyler üzerine daha fazla kod yazmaktan, başarılardan ve başarısızlıklardan ders almaktan geliyor.

Kitapları kör bir şekilde takip etmek kötü bir fikirdir, ancak bir kitabı tam olarak takip etmekle ve onu kör bir şekilde takip etmek arasında bir fark vardır .

Bir kitapta şeyler anlamaya çalışıyoruz, genellikle olduğu bunu öğretmek için çalışıyor ne bir fikir alıyoruz ederken, tam olarak ilk başta takip etmek uygun. Muhtemelen, işiniz bittiğinde hala her şeyi anlayamayacaksınız - bu böyle şeyler genellikle böyle gider - ama kitabı ilk önce tam olarak takip etmek, sorularınızı anlamaya çalıştığınız gibi, denemek için bir şeyler verecektir. Kitaptakilerle aynı fikirde olmamanın yollarını bulacağınız ihtimalleri yine iyi, ancak kitabın ele almaya çalıştığı sorunları anlayacaksınız, böylece zaman kendi kodunuzu yazmaya başladığında Onları daha sonra sizi ısırmaya bırakmamak yerine, kendi yollarınızla (veya belki de en azından kısmen onların yoluyla) ele alın.

Java'ya özgü olmayan, ancak yine de özellikle bu toplulukta yaygın olan bir başka şey. Sanırım hangi kitaplardan bahsettiğinizi tahmin edebiliyorum ve bunlar Java topluluğunun sözlüğünün önemli bir bölümünü oluşturuyor. Bunları ve bir şeyleri açıklama şekillerini anlamak, bulduğunuz diğer Java kodunu anlamanız gerektiğinde çok yardımcı olacaktır. Bu başlı başına değerli bir beceri.

Kitap okumak ve blog yazıları yazmak programlamada çok yararlıdır. Tüm geliştiricilerin okuması gereken bazı kitaplar var.

Ancak, farklı programlama kavramları ve teknolojilerini öğrenen tek kaynak kitap değildir. Günümüzde isteğe bağlı video tabanlı eğitim çok popüler oluyor. Profesyonellere yüksek kaliteli eğitim sağlayan Pluralsight'ı kontrol edebilirsiniz .

Aslında, yalnızca yardım etmeyecek kitapları okursanız. Okumak dışında yapmamız gereken başka şeyler de var. Daha fazla ayrıntıyı burada bulabilirsiniz .

Ona, yönteminde özellikle neyin yanlış olduğunu sormalısın. Açıkça cevaplayamıyorsa, sadece kendini üstün hissetmeyi seven sıradan bir adam olduğundan emin olabilirsin.

Kitaplarla ilgili olan şey, çoğunlukla - kötü uygulamaları ve yanlış anlamaları tespit etme şansı daha fazla olan revizyonlardan geçmeleridir. Ayrıca, "büyük isimler", fazladan para satan kitaplar kazanmak için iyi olmaya dayanan deneyimli kişilerdir, bu nedenle söyledikleriyle ilgili bazı asgari kalite güvenceleri vardır.

Bununla birlikte, kitap okumak, bildiri ve diğer kaynakları okumak, elbette uygulama tarafından onaylandığında profesyonel olarak büyümek için iyi bir yoldur. Bu yüzden, bu kitapları okumanız iyi olur (Infestus tarafından önerilenler bile). Ancak, kitapların esas olarak konuyla ilgili kavrayışınızı genişletmesi gerekir, çünkü hemen hemen her zaman aynı sorunu çözmenin başka yolları da olacaktır.

"Kendi başıma git" yaklaşımınızla ilgili mesele şudur: bakış açınızı koruyabilir misiniz? Çözümünüzün diğerlerinden daha iyi olduğunu nasıl kanıtlarsınız? Bazı zamanlar kendi başınıza parlak çözümler tasarlayabilirsiniz, ancak diğer bilinen çözümlerle karşılaştırıldığında, diğerlerinin lehine, en azından kullanım durumlarına sahip olduklarından, sizin neden daha iyi olduğunu belirleyebilmelisiniz. O zaman yaratıcı ve düşünceli olun, ama en önemlisi etkili olun.

Olsaydım, o kitapları okurdum. Bu size daha fazla argüman vererek size yardımcı olacak ve aynı zamanda Infestus'un bu kitapları belki argüman olarak yanlış götürdüğünü ve o kitapların içeriğini bilmediği için henüz farkedilmediğini görebilirsiniz. Ya da gerçekten onun k olduğunu bulabilirsiniz.

Tecrübelerime göre, konuların programlanması konusunda endişe duydukları zaman, kitaplarda yeterli açıklamalar içeren bilgilerin kalitesi ve sunumu, internette aynı konu bilgisini ararken daha iyi bir büyüklüktür. İnternet genellikle doğru açıklama, içerik ve kaliteden yoksundur.

İnternetteki söz konusu bilgilerin miktarı daha yüksektir.

Genel stratejim, kitaplardan daha derin bir anlayış elde etmeyi öğrenmek ve bundan sonra internetten farklı uygulamalara maruz kalmayı öğrenmek ve deneyimlerimi genişletmek. (Ve genellikle nasıl bir şey yapmamasını görmek için).

Her yaklaşımın esasını araştırır ve kendi kararınıza gelirdim. Yaklaşımınızın daha iyi olduğunu düşünüyorsanız, biriniz diğerini ikna edene kadar Infestus ile konuşun. Bir anlaşmaya varamazsanız, ikinci bir fikir isteyebilir ya da ne kadar güçlü hissettiğine bağlı olarak Infestus'un yaklaşımını kabul edebilirsin.

Singleton durumunda, enum yaklaşımına karşı yapabileceğiniz bir argüman, enumsların sınıfları uzatamayacağı yönündedir. Sık sık böyle kod yazarım:

public class DateSerializer extends AbstractSerializer<Date> {
  public static final DateSerializer SINGLETON = new DateSerializer();

  private DateSerializer() {}

  public byte[] serialize(Date date) { ... }
}

Bu, enums ile yapılamaz. Enum yaklaşımı her durumda işe yaramadığı için, tutarlılık uğruna, bir extendsmaddeye gerek olmadığında bile kaçınılması gerektiğini savunabilirsiniz .

Enums kullanmaya karşı yapılabilecek bazı diğer argümanlar:

• Bu bir hack - amaçlanmadıkları bir şey için enums kullanıyor
• daha önce görmemiş okuyucular için kafa karıştırıcı

Bilgi kaynağı olarak kitaplara çok güveniyorum - bunlar mükemmel temeller ve Infestus'un boş zamanlarınızda becerilerinizi gerçekten hızlandırdıkları için önemli miktarda kitap tüketmeniz gerektiği konusunda haklı olduğunu düşünüyorum. Tüketmeniz gerektiğini düşündüğüm halde, yalnızca bilgi kaynağı olan kitaplar değildir - yerel kullanıcı grubunuza katılın, ilgili teknoloji haber bültenlerini gelen kutunuza gönderin, blogları okuyun.

Ben buna yol olduğunu, bir kitapta belirli bir şekilde yazılır çünkü iddiasıyla Ancak katılmıyorum gerekir yapılabilir. Evet kitaplar harika tavsiyeler veriyorlar ve uzmanlar tarafından yazılmışlar ve uzmanlar tarafından gözden geçiriliyorlar ancak karşılaştırmalı olarak basit bir kitapta yer alıyorlarsa, bir kitabın yazmaya, düzenlemeye ve yayınlamaya başlamasının tipik olarak en az iki yıl sürmesinin başladığını söyleyebilirim. . Teknolojideki değişimin hızı çok hızlı ve iki yıl öncesinin tavsiyesi bugün için doğru bir tavsiye olmayabilir. Genel ilkeler genellikle zaman testine dayanır, ancak belirli bir etkinliği optimize etmek, yeni bir donanım biti veya yeni bir yazılım sürümü ile geçersiz hale getirilebilir.

Infestus'tan sizinle önerilerde bulunmasını isteme önerisi mükemmel bir sorundur - uzaklaşın, her şeyi okuyun ve cevaplamak / çözmek için çoktan düşünceli bir sürü soru ile geri dönün. yöntem.

5 yıl sonra neden hala küçük olduğun hakkında sorular vardı. Benim için, birinin küçük olup olmadığının temel ölçüsü yılların deneyimi değil, ne kadar kaşıkla beslenmeleri gerektiğidir. Orta seviye bir geliştiricinin nispeten kendi kendine yeterli olmasını, üzerinde hareket edebilecek ve durumlarını genişletebilecek düşünceli bir bilgi kaynakları tüketicisi olmasını bekliyorum. Ayrıca, gençlere öğretmeye başlayabilecekleri bir aşamada olmaları gerekir, çünkü konularını net bir şekilde açıklayabilmeleri için konuyu iyi anlarlar. Diğer temel uzmanlık güvendir - eğer işi yaptıysanız, bir şeyler okuduysanız ve uygun bir şey ürettiyseniz, bir çocuğun onaylama gerektirdiği için bir tartışma mahkemesinde ayağa kalkmaktan çekinmeyin.

İşyeri davranışlarını bir kenara koymak, üst düzey geliştiricilerin sahip olduğu bir mentor rolünün gerçekliğini bir kenara koymak, kendi keşif arzunuzu bir kenara bırakmak, bir hakaret davranışını belirlemek ve kitaplara yönelik fetişler koymak ...

Bir takımdaki bir kod incelemesinin amaçları 1) kodu doğrulamak ve 2) kodu yazan kişinin kod geliştirmenin arkasındaki anlamı anlamasını sağlamaktır. "Bunu değiştir çünkü Martin Fowler GoF kitabında öyle söyledi" demenin yeri değil. Ancak, "bunu değiştir çünkü [kısa açıklama]; bunu GoF kitabında tartışırken daha fazla ayrıntı var" deyin.

Üst düzey geliştiriciniz, en azından basit ve inceliksiz bir değişiklik için bir açıklama yapmıyorsa ve "[kitap] yüzünden" sözlüğünü kullanmakta ısrar ediyorsa, biraz zeki ve ahmak oluyor. Bununla nasıl başa çıkıyorsun? Bir takım toplantısında sözlü olarak belirtiniz ve takım arkadaşlarınızdan bu yararlı kitap referansıyla birlikte değişimin avantajını veya gerekliliğini kısaca açıklayan bir veya iki tane ifade vermelerini isteyin. Kitap referansı için ona teşekkür ettiğinizden emin olun.

Kabul edin, amacınız değişiklik önerisini takdir etmek ve göreviniz ya da işiniz için motive olmamaktır. Ona bunu söyle. "Kodumu incelerken değişikliğin avantajını veya gerekliliğini kısaca açıklayabilirseniz, değişiklik önerisini daha çok takdir edeceğim; çünkü kitap referanslarınızı biraz moral bozucu olarak buluyorum."

Kitap referansları ile basit bir açıklama yapmayı reddetmeye devam ederse, sektörde farklı bir görüşle eşit veya daha fazla ünlülük içeren başka bir kitap veya kaynak sunabilirseniz ve senaryounuza uyuyorsa, kendi kitabınızı ekleyebilirsiniz. Orijinal kodun korunmasını dikkate alarak inceleme yorumunuzdaki referans. Bunu yeterince zaman yap, geri tepebilir. Karşı argümanın doğru ve önemli ölçüde daha önemli olduğuna çok dikkat edin; Bir üst düzey geliştiricinin hatalı olmasına ve hala yolunda olmasına izin vermek sorun değil, bu öğrendiğim ve öğrenmeye devam ettiğim bir şey.

Sadece kitaplardan programlama yapmanın imkansız olduğunu söyleyebilirim, ama iyi olanlar size büyük bir destek verecek. Karate'ye benziyor - sadece kara kuşak elde edemezsiniz;) Bu particiler davasında Bay Infestus'un Joshua Bloch'un "Etkili Java" ya atıfta bulunduğuna inanıyorum. Java gelişimi ile ilgili gerçekten harika bir kitap ve eğer zaten kullanmadıysanız kesinlikle okumalısınız.