Nasıl daha hızlı bir programcı olunur?

Son iş değerlendirmemde sadece bir zayıf nokta vardı: zamanındalık. Bunu geliştirmek için yapabileceğim bazı şeylerin zaten farkındayım, ancak aradığım şey biraz daha.

Kaliteden ödün vermeden çıktılarının hızını artırmak için ne yaptıkları hakkında ipuçları veya tavsiyeler var mı?

Zaman çizelgelerini nasıl değerlendiriyor ve onlara bağlı kalıyorsunuz? Daha kısa sürede daha çok iş yapmak için ne yaparsınız?

Herhangi bir geri bildirim büyük beğeni topluyor, teşekkürler,

Bilgisayarı Kapat. Bir kalem ve biraz kağıt al. Tasarımınızı eskiz. Akranlarınızla gözden geçirin. O zaman kodu yaz.

Bazı fikirler...

• Altın kaplamadan kaçının - yalnızca sizden istenenleri yapın (gereksinimler açısından)
• İş gereksinimlerini anlayın ve ilk defa doğru yapın
• Çevrenizi ve araçlarınızı iyice anlayın
• Harika bir daktilo ol, fare yerine klavye kısayollarını kullan
• Tekrarlı bir yaklaşım benimseyin ve doğru yolda olmanızı sağlamak için akıl sağlığı kontrolleri yapın
• Tekerleği yeniden icat etmeyin, geçmiş işleri ve başkalarının çalışmalarını tekrar kullanın
• Dikkat dağıtıcı şeyleri kaldırın, e-postalarınızı kontrol etmeye, dışarıya bakmaya, iş arkadaşlarınızla konuşmaya vb. Devam etmeyin.
• Kendinizi fazla işlemeyin - ne zaman ara vermeniz gerektiğinin farkında olun

Kendiliğinden "daha hızlı" bir programcı olma arzunuz övgüye değer. Ancak, zamanında teslim olmamak, yavaş olduğunuz anlamına gelmez, bu, projenin kötü bir şekilde planlandığı anlamına gelir. "Daha hızlı" bir programcı olmak işe yaramaz; bu sadece son teslim tarihini daha hızlı geçen kişi olacağınız anlamına gelir.

Siz (ve ekibiniz) aşağıdaki hatalardan birini (veya hepsini) yapıyorsunuz:

• yapılması gereken işi küçümsemek ;
• planlama sırasında büyük bir gereksinimin veya mimari parçanın eksik olması ;
• iş tahminlerini takvim tahminleriyle karıştırmak ve toplantılar / telefon / diğer ek yükler gibi şeyleri hesaba katmamak;

Yukarıdaki üç yöntemden herhangi birini ele almanın birden fazla yolu vardır. Ancak bunlardan herhangi birini geliştirmeden önce, işlerin neden böyle yürüdüğünü bilmeniz gerekir. Otopsi yapın gerçek zaman alınır ve ekstra zaman nereye gittiğini anlamaya vs son iki veya üç proje üzerinde tahmin ediyor.

Tekrarlıyorum - kod yazarken yavaş olmak , bu durumu hesaba katmayı planlıyorsanız , son tarihin eksik olmasına neden olmaz .

Gerçekten, gerçekten editörünü öğren. Bir IDE kullanıyorsanız, sunduğu tüm özellikleri kullandığınızdan emin olun. Seçtiğiniz editörünüz için klavye kısayollarını öğrenmek için bir kopya kağıdı edinin. Sık kullanılan dizinler için bir kabuk ayar kısayolu kullanıyorsanız

“Kaliteden ödün vermeden çıktılarının hızını artırmak için ne yaptıkları hakkında ipuçları veya tavsiyeler var mı?”

Pek çok kişi, (a) basit, (b) güvenilir ve (c) doğru olan bir şey pahasına "nihai" kalite için gayret gösterir.

Gelişiminizi hızlandırmanın en önemli yolu , yaptığınız şeyi basitleştirerek , mümkün olduğu kadar basit olmasını sağlamaktır.

Zamanında teslimat yapmada sorun yaşayan çoğu insan çok fazla yol kat ediyor. Ve verilen nedenler genellikle saçma. Genellikle gerçek gereksinimler değil, yalnızca algılanan gereksinimlerdir.

Pek çok kişinin müşterinin "beklediğini" söylediğini duydum. Bu kötü bir politikadır.

Mümkün olan en basit şeyi oluşturun. Müşteri daha fazlasını istiyorsa, daha fazlasını oluşturun. Ama önce mümkün olan en basit şeyi yap.

Kodunuzu mükemmelliğe göre cilalamaktan kaçının, çalışmasını sağlayın. İşin beklediği bu.

Ancak çoğu zaman, artan hız kaliteden ödün vermeden anlamına gelir.

Yeniden kullanma - Önceki projelerdeki akıllıca bitleri ayırmaya çalışıyorum, böylece bunları gelecekteki girişimlerde tekrar kullanabilirim. Kendine "Her gün yine bunu kullanabilir miyim?" Diye sormaya değer.

Basit tut.

TDD kullanıyorsanız, " kırmızı, yeşil, refactor " ifadesini izlemelisiniz :

1. Başarısız olan bir test yazın ( kırmızı ). (Genellikle işlevler için kodunuzda yoktur.)
2. Testlerinizi geçmek için korkunç yeşil kodlama suçları işleyin ( yeşil ). Gerekirse sabit kod.
3. Refactor , muhtemelen kısa bir süre için testleri çiğniyor , ancak tasarımı genel olarak iyileştiriyor.

Tüm dilleri / kitaplık belgelerini yerel olarak bilgisayarınıza indirin, sonra ağ kablosunu çıkarın / Wi-Fi'yi kapatın .

Burada komik olmaya çalışmıyor. Bu gerçekten bana yardım ediyor!

Yığın Taşması'nı çok uzun zamandır okuduğunuzda dikkat edin. "Derleme" bahanesi yalnızca çok uzun süre çalışır. :)

Görevleri çok sık değiştirmekten kaçının. Dikkat dağıtmak ve görev değiştirmek, görevlerinizi yönetmek için Mylyn gibi araçlar kullanıyor olsanız bile bir günü öldürebilir .

Bir ayrıntı düzeyi belirleyin (örneğin, 30 dakika) ve yalnızca eldeki görevle ilgili şeyler üzerinde çalışın. Başka bir şey (yeni hata raporları, diğer konular hakkında e-postalar, ilgisiz olan usule ilişkin konular) en azından "bir sonraki kontrol noktasına" kadar ertelenir. Açılır e-posta bildirimlerini devre dışı bıraktığınızdan emin olun, böylece emilemezsiniz.

Ekibinizde, eğer bir şeyler gerçekten erimişse ve derhal ilgilenmeniz gerektiğini size bildirecek bir arkadaşınız varsa, özellikle etkilidir.

Doğru yapın, en iyi yol, ilk defa. Bu, başlamadan önce bir süre durup düşünmeniz gerektiği anlamına geliyorsa, o zaman yapın. Zamanın% 90'ı çalışıyor.

En kısa zamanda dokunmayı yazmayı öğrenin .

Ben yarın yapacağım .

İşlerin Yapılması da son derece faydalıdır.

Zaten kısa bir dikkat sürem var, bu yüzden bu kitaplar benim odaklanmama yardımcı oluyor ... tekrar ne yapıyordum?

Pratik ve sıkı çalışma.

Zamanı ve çabayı harcamalısınız. Kullandığınız araçlarla daha rahat ve kendinize güven duyduğunuzda, hız ve yaratıcılığın izlemesi gereken araçlar.

Herhangi bir beceriyi geliştirmek istiyorsanız, özellikle bunun üzerinde çalışmanıza izin verecek alıştırmalar tasarlamanıza da yardımcı olabilir. Yavaşlığınız tasarım aşamasındaysa, çevrimiçi olarak çalışmak için tasarım sorunlarını bulmaya çalışın. Aynı egzersizi tekrar yapmak daha hızlı tamamlamanıza ve pratik yapmanıza izin verir. Şahsen, TopCoder'ın algoritma egzersizlerini , saf programlama hızını uygulamak için seviyorum . Tasarım zorlukları da var ama denemedim.

Bölge hakkında bilgi edinin, kendinize nasıl gireceğinizi ve ne zaman olmadığınızı nasıl tanıyacağınızı öğrenin.

Bir kez "bölgeye girdiğimde" son derece üretkenim ve kod sadece benden akıyor, genellikle 1 günde 2 veya 3 gün kodlama yapıyorum. Ancak bu yere gitmenin genellikle zor olduğunu, kendimi ertelediğimi, başka şeylerden rahatsız ettiğini görüyorum (örneğin Yığın Taşması).

Bölgede ne-kendin-almak-kullanmak-kullanmak-neyin alıntı

IDE'nizi ve çerçevenizi iyi bilmek. Her küçük şey için Google’a başvurmak zaman alıyor.

Emacs

Gelişmeye başlamadan önce:

• Posta kutunuzdan çıkın
• IM istemcilerini kapatın
• Kibarca, meslektaşlarınıza konsantre olmanız için zaman vermelerini isteyin
• Tabii ki, internette sörf yapmayı bırakın

Ne zaman kesintiye uğradıysanız, düşünceleriyle yeniden harekete geçme zamanınızı alırken yavaşlarsınız. Her kesinti için, kesintiden önce sahip olduğu düşünce sürecine geri dönmenin insan aklının 5-10 dakika sürdüğünü anladım. Kesinti başına bu kadar zaman harcadığı zaman, bütün gününü boşa harcamak çok fazla zaman almaz.

Şirketimizdeki insanlar aslında takvimlerindeki zamanını kapatıp her gün birkaç saat boş bir konferans salonuna geçtiler.

Geliştirme IDE'nizi giriş ve çıkış olarak öğrenin. Kısayol tuşlarını öğrenin. Fareyi daha az kullanmayı öğrenin. Bunun benim için zaman kazandırdığını buldum.

Meslektaşlarınızdan daha mı yavaş ya da tahminleriniz daha aşırı zamana mı dayanıyor?

Yazılımı daha hızlı üretmek için, yapmam gereken en iyi şeyin çalışma zamanınızdaki API'yi olabildiğince iyi öğrenmektir. Bir LINQ uzantısı ne zaman yapacağını liste mantığı yazmayın; Bağlamanın işe yarayacağı bir sürü olay dinleyicisi kurmayın.

Tahmini gelince, bu deneyim ile geliyor. Daha iyi tahminler bulmanıza yardımcı olmak için tahmin yazılımını kullanabilirsiniz.

Şahsen, genç seviye geliştiricilerle buldum, ilk tahminin ne olduğu olursa olsun bunu 2 ile çarpıp iki katına çıkardım. Bu, tüm öğrenmeleri, toplantıları, boşa harcanan zamanı vb. Hesaba katacaktır.

Çoğu zaman, soru, tahmininizin yanlış olup olmadığı değildir. Bütün doğru şeyler için tahmin hesabın var mı? Tahmin ve zaman çizelgelerini kodlama çalışması veya takvim zamanı olarak mı veriyorsunuz? Gününüzdeki her zaman ve bunun ne kadarının gerçek, verimli kodlama vs. toplantılar, öğrenme, hata ayıklama, vb. Olduğunu düşünün.

İma edilebilecek iki şey, ancak burada cevaplar arasında henüz üretkenliği artıran görmedim:

• Bir çeşit derleme ve dağıtım komut dosyası kullanın. App-server'ı derlemek, dağıtmak, yeniden başlatmak ve zaman kaybetmek ya da odaklanmamak, tek tıklamayla bir şey olmalı.

• Bir çeşit versiyon kontrolü var. Bir değişikliği geri alamadan kodlama yapmak yumurta üzerinde yürümeye çalışmak gibi bir şeydir

Akla birkaç fikir geliyor:

1. Tahminleriniz hakkında başka görüşler alın - "Hey, böyle bir özelliği bu zaman diliminde yapabileceğinizi düşünüyor musunuz?" Gibi bir şey sorabileceğiniz başka geliştiriciler var mı? Başkalarının girişinin, bazı durumlarda tahmin yaparken kaçırdığınız şeyleri not edebileceğinden, bazı durumlarda doğrulukta yardımcı olabileceği fikri.

2. Kestirim becerilerinizi geliştirin - Kestirmelerde ne kadar kaldığınızı ve neden kapalı olduğunuzu izlemeye başlayın: Diğer iş kalemleri teslim tarihlerinin karşılanmamasına neden oluyor mu? Bir şeyin ne kadar karmaşık olduğunu sürekli olarak hafife alıyor musunuz? Pratik olmadığında bütün bir zaman çizelgesi veriyor musunuz, örneğin sadece bir prototip hazırlamanın haftalar alacağı ve daha sonra ne yapılması gerektiği konusunda bir yeniden değerlendirme yapılması gereken şeyin ne kadar belirsiz olduğu soruluyor mu? Bunu yapmak, bu beceriyi geliştirmede en çok yardımcı olabilir, böylece bir şeyin x saat alacağını söylerseniz, buna tekrar güvenebilirsiniz, çünkü tekrar tekrar yaptınız. Bunu belirtmenin alternatif bir yolu sadece pratik, pratik, pratiktir.

Muhtemelen bunları zaten göz önünde bulundurduğunuzu kabul ettim, fakat sadece bu fikirleri düşünmemiş olanlar için bunu belirtmenin faydalı olacağını düşündüm.

1. İçte ve dışta teknolojiyi bilir.
2. Dur! Düşünün! Git!
3. Ortaya çıkacak olanı seçin, ancak yalnızca gerçekten isteneni uygulayın.
4. KISS - Basit Aptal Tutun
5. Çok karmaşıklaşıyorsa, muhtemelen iyi düşünülmez. (2 ve 4'e geri dön)
6. 5. Sıkışmış olmayın Sık sık sıfırdan başlamak için öder (2 ve 4'e geri dönün)
7. 1’e geri dön.

Bence burada anahtar kelime "zamanındalık". Zamanında olmadığını, çok yavaş olduğunu söylemediler.

Proje yönetiminde, yöneticinin iş kalemlerinizi ne zaman tam olarak tamamlayacağını tahmin edebilmesi önemlidir. Çabalarınızın zamanında alınmamasının ana sebebinin, sık sık programda teslim edilmeyen ve planlandığından çok daha sonra teslim edilmiş öğelere sahip olmanızdan şüpheleniyorum.

Zamanlılığınızı artırmak için, becerileriniz, deneyiminiz ve etki alanınız verilen belirli bir iş öğesini tamamlamanın ne kadar süreceğini anlamak için daha fazla zaman harcamak isteyebilirsiniz. Bu, proje yöneticinize daha iyi tahminler vermenizi sağlayacaktır. Buradaki anahtar "daha iyi" ... her şeyi bir şekerleme faktörü ile doldurarak daha sık zamanında teslim edebilirsiniz, ancak gerçekten çabalamak istediğiniz şey daha doğru bir tahmindir.

Bunun gerçekten sorun olup olmadığını anlamak için bunu yöneticinizle görüşeceğim. Aksi takdirde, tahminlerin hala aynı hata faktörüne sahip olacağından, iki kere daha hızlı bir şekilde programlama yapabilir, zamanın yarısında şeyler vaat edebilir ve zamanlamanız için eleştirilmeye devam edebilirsiniz.

Kararlı ol, istikrarlı ol.

İşlevselliğin küçük bir bölümünü uygulayan bir şey oluşturun ve çalıştığından, baştan sona emin olun. Ardından, yeni işlev parçaları eklerken çalışmaya devam edin. Evet, bu kısmen bir TDD uygulamasıdır, ancak TDD yapmasanız bile mantıklı gelir.

Mantığı ben kararlı olmamıştı kod 2 hafta olan biri gördüğüm her zaman, her zaman için başka bir 2 hafta sürer olmasıdır olsun kararlı.

Eğer varsa kalmak kararlı, o belirsizliği kaldırmak ve gerekirse ayrıca tarihine yakın kendinize kapsam için bir yol aşağı verir.

Açıkça söylenen karşıt argüman, bunu yapmanın sadece bir kere yazmaktan daha fazla zaman alacağı, çünkü ekstra çalışma yapmadığınız için son olmayan kodu dengeleyebilirsiniz. Bunu bir saniyeliğine satın almam. Eğer kod varsa çalışır , sen 5 satırları değiştirmek ve bir şey biliyorsun, kırar tam kırılma olmuş olmalı nerede.

Hiç çalışmayan 10.000 kod satırınız varsa ve bir ara bulmanız gerekiyorsa, aramanız gereken bir ton kodunuz vardır.

Sürekli istikrarlı FTW olan bir sistemde küçük, artımlı değişiklikler. Hızlı gitmek için yavaş git.

Benim için iyi bir üretkenlik elde etmek, neyi başarmaya çalıştığınız ve oraya nasıl ulaşacağınız hakkında net bir fikir sahibi olmaktır.

Hemen hemen tüm cevapların burada ve başka yerlerde sayısız yerde öldüğü söylendi. Ya da en azından ölümüne duydum. IDE'nizi öğrenin, daha hızlı yazmayı öğrenin, çerçeveler kullanın, kod üretmeyi kullanın vb. Ancak bu soruları soran ve Stack Overflow gibi sitelere sıkça rastlanan programcı türü olarak zaten bunları biliyordunuz . Sadece onları tekrar etmek mi istedin yoksa biraz havalandırmak mı istedin?

Ama ya o duruma ulaşabilseydik? Tüm bu önerileri usta mı demek istedim? O zaman ne olurdu? İyi. Tahmin ediyorum ki zaman çizgileri daha da azalacak. Ve yine, kalite algısına geri döneceğiz. Yani, zanaatımız kesinlikle ilerledi ve on yıllar boyunca gittikçe daha verimli hale geldi. Ancak bu süre zarfında kalite arttı mı (tabii ki çok erken yıllar hariç)?

Cevabım basit: kaliteli yazılım zaman alır ! Sadece birini diğeriyle takas edebilirsiniz (kalite / hız). Ama evet, hepimiz biliyoruz ki, bu değişimin, ölçeğin hızıyla ne kadar sona erdiği konusunda dürüst değiliz. Ve projelerin başlarında bile daha fazla yalancıyız!

Burada hatalı olmadığını söylüyorum . Buradaki sorun insanların kaliteli yazılımın ne kadar sürmesi gerektiği konusundaki algısı . Yöneticilerimizin zaman çizelgesi türleriyle kaliteli yazılım oluşturabileceğimize ve hatta tahmin edebileceğimize inanıyoruz. Kaliteli bir yazılım üretmiyoruz . Bir uygulamanın bazı köşelerinde çalışan, ancak bazen kaliteli flaşlarla çalışan bir yazılım yazıyoruz.

Peki bu konuda ne yapabiliriz? Patronlarımızı, her bir projemizdeki yatırımı ikiye veya üçe katlamamız gerektiğine ikna edemiyoruz. Ben örnek olarak kurşun diyorum. Yan proje olarak gerçekten harika bir yazılım parçası oluşturun. Buna kendi zamanınızı koyun ve ödün vermeyin. Tüm bunlar, nasıl ilerlediğinize dikkat edin. Beklenmedik bir süre koymak zorunda kaldığınız ve ilgisiz olup olmadığınızı görmek zorunda olduğunuz açıkça ilgisiz işleri not edin . Bunu, çalıştığınız diğer tüm projelerle karşılaştırın. Be vahşice dürüstKendiniz ve bu analizin tüm yönleriyle. İşyerindeki "gerçek" projelerde kaliteli yazılımınızla yaptığınız ekstra şeyler ihmal edilebilir mi? Ama belki senin girişimin başarısız oldu. Sebep neydi? Sıkıldınız mı ve sadece temel özellikleri yerine getirmek için acele ettiniz mi? Henüz kendim böyle bir şey yapmadım, bu yüzden bu düşünceyi bazı şüphelerim ile sonlandırıyorum - ama gerçek anlamda bir şans vermeyi düşünüyorum. Seni haberdar edeceğim :).

Son olarak, çoğu (tümü olmasa da) performans değerlendirmelerinin bükümlü ve olağanüstü derecede manipülatif olduğunu düşünüyorum. Kaliteyi ve hızı% 100 kısaltamazsınız. Patronunuz sizi organizasyonun belirlediği bir standarda karşı atıyor olmalı. Kuruluşun kalite ve hız arasındaki değiş tokuş standardı. OrangeSoft Inc.'in% 33 kalite ve% 66 hız beklediğini düşünelim. Bu nedenle, ünite testlerinin üçte biri olan bir kod yazıyorsanız, bunu hızlandırması ve düşük teslimat süresi ile telafi etmesi gerekir; (Bunlar oldukça kaba analojiler ama sen anladın). Fakat bunun yerine, Bob'un son derece hızlı kod yazdığı, ancak kötü niyetli bir şey olduğu söyleniyor. Bu yüzden performans incelemesinde kalite için 3/5, hız için 5/5 olacak. Öte yandan Carol, kodu çok daha yavaş yazıyor ancak önemli ölçüde daha az hata üretiyor. Kalite için 5/5 ancak hız için 3/5 puan alıyor. Her iki şekilde de, Bob ve Carol zamlarını aldılar. Herhangi bir çalışanın mükemmel bir puan alması mümkün mü? Bu adil mi?

Kullandığım teknik evrimsel prototip oluşturma

Daha fazla bilgi için google’a gidebilirsiniz - ancak hızlı bir şekilde bir şeyler üretme ihtiyacı varsa, gitmesi gereken tek yol budur. Artı, kullanıcılar bundan hoşlandığını söylediğinde, senin yaptığını (... ve dokümantasyonu yapmaya başlayabilir) yararı var.