/Nasıl "daha hızlı" bir programcı olunur?
Nasıl "daha hızlı" bir programcı olunur?
Son iş değerlendirmem sadece bir zayıf noktayı içeriyordu: zamanındalık. Bunu geliştirmek için yapabileceğim bazı şeylerin farkındayım ama aradığım şey biraz daha.
Kaliteden ödün vermeden çıktılarının hızını arttırmak için yaptıklarına dair ipuçları veya tavsiyeleri var mı?
Zaman çizgilerini nasıl tahmin edersiniz ve bunlara nasıl bağlı kalırsınız? Daha kısa sürelerde daha fazlasını yapmak için ne yapıyorsunuz?
Herhangi bir geri bildirim büyük beğeni topluyor, teşekkürler,
11 Eyl 2009 Nick Gotch
Bilgisayarı Kapat. Bir kalem ve biraz kağıt al. Tasarımınızı çizin. Akranlarınızla gözden geçirin. Sonra kodu yazın.
11 Eyl 2009 gatorfax
Altın kaplamadan kaçının - sadece sizden istenenleri yapın (gereksinimler açısından)
İş gereksinimlerini anlayın ve ilk seferinde doğru yapın
Ortamınızı 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 olduğunuzdan emin olmak 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ı yeniden kullanmayı düşünün
Dikkat dağıtıcı unsurları ortadan kaldırın, e-postaları kontrol etmeye, dışarıya bakmaya, iş arkadaşlarınızla konuşmaya vb. Devam etmeyin.
Kendinizi fazla çalışmayın - ne zaman mola vermeniz gerektiğini bilin
11 Eyl 2009 Mayo
Kendi başına "daha hızlı" bir programcı olma arzunuz övgüye değerdir. Ancak, zamanında teslim edilmemek yavaş olduğunuz anlamına gelmez, projenin kötü planlandığı anlamına gelir. "Daha hızlı" bir programcı olmak yardımcı olmayacaktır; sadece son teslim tarihini daha çabuk aşacağınız anlamına gelir.
Siz (ve ekibiniz) aşağıdaki hatalardan birini (veya tümünü) yapıyorsunuz:
hafife alınması yapılması gereken iş;
eksik planlama sırasında büyük bir gereksinim veya mimari eser;
kafa karıştırıcı toplantılar/telefon/diğer ek yük gibi şeyleri hesaba katmamak üzere takvim tahminleriyle iş tahminleri;
Yukarıdaki üç taneden herhangi birini ele almanın birden çok yolu vardır. Ancak, herhangi birini geliştirmeden önce, şeylerin neden oldukları gibi gittiğini bilmeniz gerekir. Bir postmortem yapın Son iki veya üç proje tahmininde, alınan gerçek zamana karşı tahminler ve uzatma zamanının nereye gittiğini anlayın.
Tekrar edeceğim - kod yazmada yavaş olmak son tarihi kaçırmaya neden olmaz, eğer bu gerçeği doğru bir şekilde hesaplamayı planladıysanız.
11 Eyl 2009 Franci Penov
Gerçekten, gerçekten editörünüzü öğrenin. IDE kullanıyorsanız, sunduğu tüm özellikleri kullandığınızdan emin olun. Seçtiğiniz düzenleyiciniz için klavye kısayollarını öğrenmek için bir hile sayfası alın. sık kullanılan dizinler için kısayollar
11 Eyl 2009 slashnick
"Kaliteden ödün vermeden çıktılarının hızını artırmak için neler yaptıklarına dair ipuçları veya tavsiyeleri var mı?"
Birçok, birçok insan (a) basit, (b) güvenilir ve (c) doğru olan bir şey pahasına "nihai" kalite için çaba gösterir.
Gelişiminizi hızlandırmanın en önemli yolu basitleştirmek ne yaptığınızı kesinlikle mümkün olduğunca basit hale getirmektir.
Zamanında teslim ile ilgili problemleri olan çoğu insan, çok fazla yol teslim ediyor. Ve verilen nedenler genellikle aptalca. Genellikle algılanan gereksinimlerdir, gerçek gereksinimler değildir.
Birçok insanın bana müşterinin ne beklediğini söylediğini duydum. Bu kötü bir politika.
Mümkün olan en basit şeyi oluşturun. Müşteri daha fazlasını gerektiriyorsa, daha fazlasını oluşturun. Ama önce mümkün olan en basit şeyi yapın.
11 Eyl 2009 S.Lott
Kodunuzu mükemmel hale getirmekten kaçının, sadece çalışmasını sağlayın. İşletmenin beklentisi bu.
Ancak çoğu zaman, hızın artması kaliteden ödün vermek anlamına gelir.
11 Eyl 2009 user8685
Yeniden kullanım - Önceki projelerin herhangi bir akıllı bitini etkisiz hale getirmeye çalışırım, böylece bunları gelecekteki girişimlerde tekrar kullanabilirim. Her zaman kendinize "bunu bir gün tekrar kullanabilir miyim?" Diye sormaya değer.
11 Eyl 2009 Phil Jenkins
TDD kullanıyorsanız "kırmızı, yeşil, refactor" ifadesini izlemelisiniz:
Başarısız bir test yazın (kırmızı). (Genellikle kodunuzda henüz bulunmayan işlevler için kullanılır.)
Testlerinizi geçmek için korkunç kodlama suçları uygulayın (yeşil). Gerekirse sabit kod.
Refactor, muhtemelen kısa bir süre için testleri kırmak, ancak genel olarak tasarımı geliştirmek.
11 Eyl 2009 bryanbcook
Tüm dillerinizin/kitaplıklarınızın belgelerini yerel olarak bilgisayarınıza indirin, ardından ağ kablonuzu çıkarın/kapatın Wi-Fi .
Burada komik olmaya çalışmıyorum. Bu gerçekten bana yardım ediyor!
11 Eyl 2009 mcjabberz
Çok uzun süredir Yığın Taşması'nı okurken dikkat edin. "Derleme" mazereti sadece bu kadar uzun süre çalışır. :)
11 Eyl 2009 Matthew Jones
Görevleri çok sık değiştirmekten kaçının. Dikkatinizi dağıtan şeyler ve görev değiştirme, görevlerinizi yönetmek için Mylyn gibi araçlar kullansanız bile bir günü öldürebilir.
Ayrıntı düzeyi (ör. 30 dakika) bulun ve yalnızca eldeki görevle ilgili şeyler üzerinde çalışın. Başka herhangi bir şey (yeni hata raporları, diğer konularla ilgili e-postalar, ilgisiz prosedürel konular) en azından "bir sonraki kontrol noktasına" kadar ertelenir. İçeri girmemeniz için e-posta bildirimlerini açmayı devre dışı bıraktığınızdan emin olun.
Ekibinizde, bir şeylerin gerçekten eridiğini ve derhal ilgilenmenizi isteyip istemediğinizi size bildirecek bir arkadaşınız varsa özellikle etkilidir.
11 Eyl 2009 Uri
İlk seferinde doğru, en iyi şekilde yapın. Bu, başlamadan önce bir süre durup düşünmeniz gerektiği anlamına geliyorsa, yapın. Zamanın% 90'ında çalışır.
11 Eyl 2009 ck01
olabildiğince çabuk dokunma tipi öğrenin.
11 Eyl 2009 AJ Johnson
Ben yarın yap .
İşlerin Tamamlanması da son derece faydalıdır.
Zaten kısa bir dikkat sürem var, bu yüzden bu kitaplar odaklanmamı sağlıyor ... tekrar ne yapıyordum?
Pratik ve sıkı çalışma.
Zaman ve çaba sarfetmelisiniz. Kullandığınız araç, hız ve yaratıcılığın izlemesi gereken araçlar konusunda daha rahat ve kendinize güven duyduğunuzdan.
Herhangi bir beceriyi geliştirmek istiyorsanız, özellikle bu konuda çalışmanıza izin verecek egzersizler tasarlamanıza yardımcı olabilir. Yavaşlığınız tasarım aşamasındaysa, çevrimiçi çalışmak için tasarım sorunları bulmaya çalışın. Aynı egzersizi tekrar yapmak onu daha hızlı tamamlamanızı ve hız uygulamanızı sağlar. Ben şahsen TopCoder algoritması egzersizleri sırf programlama hızı uygulamak için seviyorum. Tasarım zorlukları da var, ama ben denemedim.
11 Eyl 2009 DisplacedAussie
The Zone hakkında bilgi edinin, kendinizi nasıl içine alacağınızı öğrenin ve içinde olmadığınızda nasıl tanıyacağınızı öğrenin.
"Bölgede" olduğumda son derece üretkenim ve kod sadece benden dışarı akıyor, genellikle 1 gün içinde 2 veya 3 gün kodlama alabilirim. Ama çoğu zaman o yere ulaşmanın zor olduğunu düşünüyorum, kendimi erteleyici buluyorum, başka şeylerden rahatsız oluyorum (örneğin Stack Overflow).
11 Eyl 2009 Dustin Getz
IDE ve çerçevenizi iyi bilmek. Her küçük şey için Google'a başvurmak zaman alır.
11 Eyl 2009 Mike Hall
13 Eyl 2009 ZeroCool
Geliştirmeye başlamadan önce:
Posta kutunuzdan çıkış yapın
Tüm IM istemcileri kapatın
Kibarca akranlarınızdan konsantre olmanız için size zaman vermesini isteyin
Tabii ki, internette gezinmeyi bırakın
Her kesintiye uğradığınızda, zihniniz düşüncelerini takip etmek için zaman harcadığınız için yavaşlarsınız. Her kesinti için, insan zihninin, kesintiden önceki düşünce sürecine geri dönmesinin 5-10 dakika sürdüğünü duydum. Kesinti başına bu kadar çok zamanla, bütün gün boşa harcamak fazla zaman almaz.
Şirketimizdeki insanlar aslında takvimlerinde zaman ayırmayı ve her gün birkaç saat boş bir konferans salonuna geçmeyi başardılar.
11 Eyl 2009 dhable
Gelişiminizi öğrenin IDE giriş ve çıkış. Kısayol tuşlarını öğrenin. Fareyi daha az kullanmayı öğrenin. Bunun benim için çok zaman kazandığını görüyorum.
11 Eyl 2009 D3vtr0n
Meslektaşlarınızdan daha yavaş mısınız yoksa tahminleriniz daha fazla aşırı duyarlı mı?
11 Eyl 2009 pjc50
Daha hızlı yazılım üretmek için, yapılacak en iyi şeyin çalışma zamanı API'nızı mümkün olan en iyi şekilde öğrenmektir. Bir LINQ uzantısı ne zaman yapılacaksa liste mantığını yazmayın; bağlamanın işe yarayacağı bir sürü olay dinleyicisi oluşturmayın.
Tahmin olarak, bu deneyim ile geliyor. Daha iyi tahminler bulmanıza yardımcı olması için tahmin yazılımını kullanabilirsiniz.
Şahsen, genç seviyedeki geliştiricilerle buldum, ilk tahminleri ne olursa olsun, 2 ile çarptım, sonra ikiye katladım. Bu, tüm öğrenme, toplantılar, boşa harcanan zaman, vs.'yi açıklayacaktır. Daha üst düzey geliştiriciler tahminleri üzerinde 2 kat daha fazla çalışma eğilimindedir.
Çoğu zaman soru, tahmininizin yanlış olup olmadığı değildir. Tüm doğru şeyler için tahmin hesabınız yapıldı mı? Kodlama çabası veya takvim zamanı açısından tahminlerinizi ve zaman çizelgelerinizi veriyor musunuz? Gününüzdeki her zaman ve bunun ne kadarının gerçek olduğunu, toplantılar, öğrenme, hata ayıklama vb.
11 Eyl 2009 James Schek
Zımni olabilecek iki şey var, ancak burada cevaplar arasında henüz üretkenliği artıran bir şey görmedim:
Bir çeşit derleme ve dağıtım komut dosyası kullanın. Uygulama sunucusunu derlemek, dağıtmak, yeniden başlatmak ve böyle bir zaman ya da odak emmek, tek tıklamayla bir şey olmalı.
Bir çeşit sürüm kontrolüne sahip olun. Bir değişikliği geri alamadan kodlamak zorunda kalmak, yumurta üzerinde yürümeye çalışmak gibidir
11 Eyl 2009 Buhb
Birkaç fikir akla geliyor:
Tahminlerinizle ilgili başka görüşler alın - "Hey, bu zaman diliminde bu tür bir özelliği yapabileceğinizi düşünüyor musunuz?" Gibi bir şey sorabileceğiniz başka geliştiriciler var mı? Birisi tahminde kaçırdığınız bir çok şeyi not edebileceğinden, bazı durumlarda diğer kişilerin girdilerinin doğrulukla yardımcı olabileceği fikri.
Tahmin yeteneğinizi geliştirin - Tahminlerde ne kadar kapalı olduğunuzu ve neden kapalı olduğunuzu izlemeye başlayın: Son teslim tarihlerinin karşılanmamasına neden olan diğer iş öğeleri mi? Bir şeyin ne kadar karmaşık olduğunu sürekli olarak küçümsüyor musunuz? Pratik olmadığında tüm zaman çizelgesini veriyor musunuz, ör. sadece prototip elde etmenin haftalar alacağı ve daha sonra başka ne yapılması gerektiğinin yeniden değerlendirilmesi gerektiği belirsizdir. Bunu yapmak, bu beceriyi geliştirmede en fazla yardımcı olabilir, böylece bir şeyin x saat süreceğini söylerseniz, buna tekrar güvenebilirsiniz, çünkü bunu tekrar tekrar yaptınız. Bunu ifade etmenin alternatif bir yolu sadece pratik, pratik, pratiktir.
Muhtemelen bunları zaten dikkate aldınız, ama ben sadece bu fikirleri düşünmemiş olabilecek başkaları için bunu belirtmenin değerli olduğunu düşündüm.
11 Eyl 2009 JB King
İçeride ve dışarıda teknolojiyi bilir.
Dur! Düşünün! Git!
Ortaya çıkabilecek her şey için mimar, ancak yalnızca gerçekten istenen şeyi uygulayın.
KISS - Basit Tutun Aptal
Çok karmaşık hale geliyorsa, muhtemelen iyi düşünülmemiştir. (2 ve 4'e geri dön)
5'te takılı kalmayın. Genellikle sıfırdan başlamak işe yarar (2 ve 4'e geri dönün)
1'e geri dönün.
11 Eyl 2009 Rui Craveiro
Sanırım burada anahtar kelime "zamanındalık". Çok yavaş olduğunu söylemediler, aksine zamanında olmadığını söylediler.
Proje yönetiminde, yöneticinin iş öğelerinizin ne zaman doğru bir şekilde tamamlanacağını tahmin edebilmesi önemlidir. Çabalarınızın zamanında kabul edilmemesinin ana nedeninin, sık sık programa göre teslim edilmeyen ve planlanandan çok daha sonra teslim edilen ürünlere sahip olmanızdan şüpheleniyorum.
Zamanınızı geliştirmek için, becerileriniz, deneyiminiz ve alan adınız göz önüne alındığında belirli bir iş öğesini tamamlamanızı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 zamanında daha sık teslim edebilirsiniz, ancak gerçekten çabalamak istediğiniz şey daha doğru bir tahmindir.
Bunun gerçekten sorun olup olmadığını görmek için bunu yöneticinizle görüşürüm. Aksi takdirde, programın iki katı kadar hızlı programlama yapabilir, alıştığınız sürenin yarısında bir şeyler vaat edebilir ve tahminleriniz yine de aynı hata faktörüne sahip olacağından, zamanınız için hala eleştirilebilirsiniz.
11 Eyl 2009 Larry Watanabe
Kararlı olun, kararlı kalın.
Küçük bir işlevsellik uygulayan bir şey oluşturun ve uçtan uca çalıştığından emin olun. Ardından, yeni işlevsellik parçaları ekledikçe çalışmaya devam edin. Evet, bu kısmen bir TDD uygulamasıdır, ancak TDD yapmasanız bile mantıklıdır.
Buradaki mantık, 2 hafta kodlu, hiç istikrarlı olmayan birini her gördüğümde, her zaman almak kararlı olmak için 2 hafta daha sürmesi.
Eğer kal kararlı olursanız, bu belirsizliği ortadan kaldırırsınız ve gerekirse kendinize son teslim tarihine yaklaşmanız için bir yol verirsiniz.
Bariz karşı argüman, bunu yapmanın sadece bir kez yazmaktan daha fazla zaman alacağı, çünkü ekstra iş yapacağınız için nihai olmayan kodu stabilize edeceksiniz. Bunu bir saniyeliğine almam. works koduna sahip olduğunuzda, 5 satırı değiştirirseniz ve bir şey kırılırsa, tam olarak ara vermenin nerede olması gerektiğini bilirsiniz.
Hiç çalışmadı olan 10.000 kod satırınız varsa ve bir ara bulmanız gerekiyorsa, arama yapmak için bir ton kodunuz vardır.
Sürekli olarak istikrarlı bir FTW olan bir sistemde küçük, artımlı değişiklikler. Hızlı gitmek için yavaş gidin.
25 Eyl 2009 kyoryu
Benim için iyi verimlilik elde etmek, neyi başarmaya çalıştığınız ve oraya nasıl ulaşacağınız konusunda net bir fikir sahibi olmak.
30 May 2010 mdma
Hemen hemen tüm cevaplar burada ve başka yerlerde çok sayıda yerde öldü. Ya da en azından ölüme kadar duydum. IDE'nizi öğrenin, daha hızlı yazmayı, çerçeveleri kullanmayı, kod üretmeyi vb. Kullanın. Evet, elbette bunlar yardımcı olacaktır ve hepsinin efendisi olan birçok programcı olduğundan şüpheliyim. Ancak bu soruları soran programcı türü olmak ve Stack Overflow bunları zaten biliyordunuz. Sadece onları tekrar etmek mi istediniz yoksa biraz havalandırmak mı istediniz?
Ama ya bu duruma gelebilseydik? Yani tüm bu önerilerin ustası mısın? O zaman ne olurdu? İyi. Zaman çizgilerinin daha da azalacağını tahmin ediyorum. Ve tekrar, kalite algısına döneceğiz. Yani, gemimiz kesinlikle ilerlemiş ve on yıllar boyunca gittikçe daha üretken hale gelmiştir. Ancak bu süre zarfında kalite arttı mı (elbette çok erken yıllar hariç)?
Cevabım basit: kaliteli yazılım zaman alır! Sadece diğeri için ticaret yapabilirsiniz (kalite/hız). Ancak evet hepimiz biliyoruz ki, bu değiş tokuşun genellikle ölçeğin hız sonunda ne kadar sonuçlandığı konusunda dürüst değiliz. Ve biz daha erken projelerde daha büyük yalancıyız!
Burada hatalı olmadığınızı söylüyorum . Sorun, algı insanların kaliteli yazılımın ne kadar sürmesi gerektiğidir. Yöneticilerimizin zaman çizgileri türleriyle ve hatta tahmin ettiğimiz kalitede yazılım üretebileceğimize inanmak için kendimizi kandırıyoruz. Kaliteli yazılım yapmıyoruz. Bir uygulamanın belirli köşelerinde çalışan ancak bazen kaliteli flaşlarla çalışan yazılımlar yazıyoruz.
Peki bu konuda ne yapabiliriz? Patronlarımızı her bir projemize yaptığımız yatırımı iki katına ya da üç katına çıkarmamız gerektiğine ikna edemeyiz. Örnek olarak kurşun diyorum. Bir yan proje olarak gerçekten harika bir yazılım parçası oluşturun. Kendi zamanınızı buna koyun ve taviz vermeyin. Her zaman nasıl ilerlediğinize dikkat edin. Görünüşe göre ilgisiz beklenmedik bir süre koymak zorunda kaldığınız görevleri not edin ve gerekçe gösterip getiremeyeceğinizi görün. Bunu çalıştığınız diğer tüm projelerle karşılaştırın. Kendinizle ve bu analizin tüm yönleriyle vahşice dürüst olun olun. İşinizdeki "gerçek" projelerde kaliteli yazılımınızla yaptığınız ekstra şeyler ihmal edilebilir mi? Ama belki denemeniz başarısız oldu. Sebep neydi? Sıkıldınız ve temel özellikleri halletmek için acele ettiniz mi? Henüz kendim gibi bir şey yapmadım, bu yüzden bu düşünceyi bir şüphe ile bitiriyorum - ama gerçek bir şans vermeyi düşünüyorum. Seni haberdar edeceğim :).
Son olarak, performans değerlendirmelerinin çoğunun (hepsi olmasa da) bükülmüş ve olağanüstü manipülatif olduğunu düşünüyorum. Kaliteyi ve hızı% 100 azaltamazsınız. Patronunuz sizi kuruluş tarafından belirlenen bir standarda göre puanlamalıdır. Kuruluşun kalite ve hız arasındaki denge standardı. OrangeSoft Inc.'in% 33 kalite ve% 66 hız beklediğini düşünelim. Bu yüzden, ünite testlerinin üçte biri olan bir kod yazıyorsanız, ancak hız ve daha kısa teslimat süresi ile telafi etmelisiniz! (Bunlar oldukça kaba benzetmelerdir, ancak amacınızı anlarsınız). Ama bunun yerine, Bob kodları çok hızlı yazıyor ama bu çok kötü bir şekilde hatalı. Bu yüzden performans incelemesinde kalite için 3/5 ve hız için 5/5 puan alacak. Carol ise kodu çok daha yavaş yazıyor ancak önemli ölçüde daha az hata üretiyor. Kalite için 5/5, hız için 3/5 puan alıyor. Her iki şekilde de Bob ve Carol yükselişlerine yanaşırlar. Herhangi bir çalışanın mükemmel bir puan alması mümkün mü? Bu adil mi?
12 Eyl 2009 Thiru
Kullandığım teknik evrimsel prototipleme
Daha fazla bilgi için Google'a gidebilirsiniz - ancak bir şey hızlı bir şekilde üretmek gerekiyorsa, tek yol budur. Ayrıca, kullanıcılar sevdiğini söylediğinde, işiniz bitti (... ve belgeleri yapmaya başlayabilir).
11 Eyl 2009 slashmais
Zaman darboğazı nedir? Düşünmenin her zamanki darboğazım olduğunu düşünüyorum, bu yüzden yazma hızımı iyileştirmek (zaten iyi) yaklaşık hiçbir şey yapmaz. Öte yandan, yazmak sizin için hızlı ve doğal değilse, sizi yavaşlatabilir.
Gerekenden fazlasını yapmaya mı çalışıyorsunuz? Genellikle bir işletme, daha az ama daha cilalı bir iş yerine sizden çok iyi işler isteyecek ve kullanılmayacak özellikler ekleyerek iş getirisi olmadan zaman ve para kaybı olacaktır.
Çok aceleci misin? Zaman baskısı altında, insanlar yine de işe yarayacağını umarak sık sık ön tasarım ve planlamadan kaçınırlar. Sık sık değil.
Zamanı doğru mu yönetiyorsun? Gelişim, kesintisiz düşünme süresi parçaları gerektirir, yoksa verimsiz ve dolayısıyla yavaş olursunuz.
11 Eyl 2009 David Thornley
Neal Ford'un mükemmel kitabını okuyun Üretken Programcı .
Birçok yararlı ipucu ile dolu.
Başka yerlerde de belirtildiği gibi, araçlarınız için dokümanları okuyun. Vim wikileri okuyarak her zaman Vim için yeni şeyler öğreniyorum. Benzer şekilde, bash veya zsh için man sayfasını okumak her zaman yeni numaralar verir.
11 Eyl 2009 Rob Wells
Uzun zaman önce optimizasyon konusunda bana gerçekten yapışan bir şey okudum. Kaynağı ya da tam kelimeleri hatırlamıyorum, ama bunun özü şuydu: "Bir programı daha hızlı çalıştırmanın tek yolu daha az yapmaktır. Başka herhangi bir plan da budur." Aynı şey insanlar için de geçerli. Ordunun da "Haste israf ediyor" demesi var. Şimdi aynı şeyleri yapmak, ancak daha hızlı yapmak sadece sorun yaratacaktır. Orada daha üretken olmak için birçok farklı plan var ve bunların etkili olmadıklarını söylemiyorum, ancak ihtiyaçlarınıza göre uyarlanmayacaklar. Ne yaptığınıza bakmak ve üretken olmayan şeyleri bulmak ve bunları kesmek daha iyi. Başka herhangi bir plan bunun sulandırılmış bir versiyonudur.
11 Eyl 2009 Imagist
Çalışmanızı (2) kapsamı (2) kısa olarak tanımlanan küçük görevlere bölün - ör. 2 saat.
Güne sırayla bir kağıda yazarak başlayın. Bazı çizgiler çizin - öğle yemeğinden önce yapılmasını beklediğiniz şeyler, gün sonuna kadar yapacağınız şeyler vb.
Listenizi çalışın, gittiğinizde öğeleri çaprazlayın.
Zaman kutusu işleri - bir şey sürüklenmeye başlıyorsa, yardım istemeden veya daha basit bir şekilde çözmeden önce kendinize araştırma yapmak için bir zaman sınırı verin.
Mümkünse, çalışmanızı bu zaman aralıklarında herkese açık olacak şekilde yapılandırın - hata izleme vb. Tahminler girin.
Kendinizi araştırma, okuma, vb. Zaman öldürerek yakalarsanız, siparişi ters çevirin - örneğin, 1 saatlik bir görevi programda başarıyla tamamlarsanız kendinize 10 dakikalık bir ödül verin.
Stack Overflow için daha az zaman harcamanız gereken birkaç yorum gördüm. Doğru kullanıyorsanız, Stack Overflow sizi daha az değil daha verimli hale getirmelidir. Tartışmalardan uzak durun ve işinizi yapmak için kullanmaya odaklanın.
11 Eyl 2009 Jon Galloway
Eski proje varlıklarını yeniden kullanın.
IDE'nizi öğrenmek için bir gün ayırın. Parçacıklar gibi araçlar sağlamazsa, kod otomatik tamamlama ... yeni bir tane almayı düşünün.
Önemli yerlere her şeye kısayollar koyun, böylece şeylere daha hızlı erişebilirsiniz.
Durum böyle değilse ikinci bir ekran alın.
E-postalarınızı çok sık kontrol etmeyin.
Bir kerede yalnızca bir göreve odaklanmayı deneyin. Bu mümkün değilse, yaptığınız işi yakından takip edin ve ilgisiz 15 görev arasında kaybolmayın.
Kağıt kullanın. Çalıştığım zaman her zaman görevlerimin notlar alabileceğim, kesebileceğim ve basılı olabileceğim basılı bir versiyonuna sahibim. Bir şey okumak veya bir şey yazmak için farklı bir ekrana gitmekten çok daha hızlı. Günün sonunda her şeyi sisteme kopyalamak için 10 dakikam var. Her gün biraz zaman kazandığımı fark ettim.
11 Eyl 2009 marcgg
Programcı olarak her geçen gün kendinizi geliştirin ... Tasarım modellerini öğrenin!
TDD kullanın, ancak uygun bir şekilde, kodunuzdaki hatalar en çok zaman alan şeydir.
Yeniden Paylaşıcı Kullan :)
11 Eyl 2009 Denis Biondic
Diğer cevapların birçoğu tasarım yapmaktan bahsettiğinden, kodlamanın daha saf mekanik yönüne sadık kalacağım. Bunların çoğu muhtemelen açıktır, ancak yine de söyleyeceğim çünkü iş arkadaşlarımın çoğunun bu şeylerden bazılarını yapmadığını fark ettim.
IDE klavye kısayollarınızı çoğunu sol elinizle yapabilirsiniz, böylece hızlı ve öfkeli kod özetleme/yeniden düzenleme için fare elinizi serbest bırakır.
Aşağıdakilerin bir kombinasyonunu kullanarak imlecinizde nasıl gezineceğinizi ve metin seçmeyi öğrenin Ctrl, Shift, ok tuşları, Home ve End.
Aşağıda C++ kurulumum (Visual Assist X ile Visual Studio) bulunmaktadır. Norveççe bir klavyem var, bu yüzden lütfen yanımda taşıyın:
Alt-Z: .h ve .cpp arasında geçiş yap
Ctrl-Shift- <: Kaynaklar arasında bağlama duyarlı atlama. (<benim için Z'nin anahtarı solda, siz İngilizlerin bunlardan birine sahip değilsiniz. O zaman Ctrl-Shift-Z ile eşleştirin.)
Alt- | : Uygulama yöntemi. Önce başlığı yazıp sadece Alt- | her zaman tüm sınıf taslağını birkaç saniye içinde yapabilirsiniz. (| benim için kaçışın altındaki anahtardır.) Bu özellikle cpp ve başlık dosyalarını metin düzenleyicide yan yana yerleştirirseniz doğrudur. Her eylemi gerçekleştirdiğinizde gizlenmeyin.
Alt-R: Sembolü düzeltme işareti altında değiştirir.
Alt-D: Seçilen işlev için bir belge şablonu ekler.
Bu, şimşek hızında kod tamamlamaya ek olarak, sol elle yeniden düzenlemeyi mümkün kılar.
11 Eyl 2009 Nailer
Kod parçacıkları kodlayın, deneyim ve asla coşku durdurun. Her zaman bir şeyler okuyun: programcı blogları, kitaplar, edebiyat, diğer insanların kötü kodları. Maddeler hakkında daha geniş bir görüşe sahip olursanız daha hızlı hale gelirsiniz. Her türlü karmaşık arka plan sürecini hayal edebiliyorsanız ve hedef sistemin tüm karmaşıklığını gerçekten biliyorsanız.
Pragmatic Programmer's Handbook harika bir şey: en iyi uygulamalar ve yazılım geliştirmenin birçok farklı yönünün önemli tuzakları hakkında. Lastik ördek ve malzeme kaba asosyal ve aptalca geliyor. Bununla birlikte, çoğu programlama probleminin doğası, çok karmaşık düşünme eğiliminde olduğumuzdur. Ben basit ve kolay çözümlerin büyük bir hayranıyım: harika numaralar yok, süper zarif kesmek yok: sadece en basit çözümleri kullanmak.
Ekibiniz iyi ise, birlikte çalışmayı deneyebilirsiniz: Bespin ve diğer bazı çerçeveler günümüzde bir dosyanın birlikte düzenlenmesine izin vermektedir. Gerçekten içine iseniz ve iş arkadaşınızın sihir yapıyor;).
11 Eyl 2009 wishi
E-postalarınızı daha uzun aralıklarla kontrol etmeyi deneyin ve Twitter, facebook gibi çevrimiçi sosyal araçları kullanmayı bırakın.
Bunu kullanın wallpaper .
Açık ön görünüm ile çalışmaya çalışın. Genellikle ücretsiz olduğunda konferans odası kullanıyorum, odaklanmama yardımcı oluyor!
Etrafınızdaki diğer programcılarla çalışmayı deneyin.
12 Eyl 2009 Adnan Memon
İşin püf noktası kodu daha hızlı yazmak değil, çalışma kodunu daha hızlı yazmaktır.
Yeriniz ne kadar erken bir hata olursa, düzeltmek için o kadar az çaba harcar - bu, programcı performansını etkileyen birincil şeydir.
Bu, ne kadar hızlı yazdığınız veya derleyicinizin ne kadar hızlı olduğu ile ilgili değildir, bu, hataları tanımlayıp gittikçe onları düzeltebileceğiniz hız ile ilgilidir.
Bu nedenle, çift programlamayı daha hızlı olmanın bir yolu olarak öneririm - gerçekten hatalardan kaçınır. Bu ve test odaklı geliştirme. İki çift göze sahip olmak, hataların kaymasını iki kattan daha fazla zorlaştırır (her neyse düşünüyorum).
Kod testi geri dönüş sürenizi en aza indirmeye çalışın - bu açıkça platformunuza bir araç bağlıdır. Topal araçlarla aptalca gömülü bir sistem üzerinde çalışıyorsanız, geri dönüş süresi oldukça anlamlı olabilir (örneğin bir sistem görüntüsünü yeniden oluşturmanız ve cihazı yeniden başlatmanız gerekiyorsa), VM'ler veya simülatörler burada yardımcı olabilir.
Programlamayı eşleştirmezseniz, diğerlerinden ara sıra gayrı resmi kod incelemeleri isteyin, ancak yalnızca akışınızdaki (ve umarım) akışınızdaki mantıksal molalarda sorun. Şüphesiz sahip olduğunuz resmi kod inceleme sürecinize ek olarak bunu yapın.
Basit tutun - mühendisliği aşmayın. Buna ihtiyacın olmayacak.
13 Eyl 2009 MarkR
Kendi üretkenlik araçlarınızı yazın. Başlangıçta yazmak zaman alabilir, ancak ödeme zaman içinde büyük olabilir.
Her zaman kullandığım bazı araçlar:
Bir SQL formatlayıcı.
Otomatik bir SQL oluşturucu: sadece tabloları seçin.
Basit bir görev önceliği, böylece tüm görevlerimi tek seferde görebilirim.
Beni periyodik olarak engelleyen bir görev hatırlatıcısı.
Sınırlı metin alan ve bir e-tablo ve metin gibi ele almanıza olanak tanıyan bir uygulama.
Zamanımda yol kenarına düşen birçok küçük araç yazdım, ama yine de çabaya değdi.
29 Eyl 2009 Jonathan Swift
Program yaparken müzik dinlemekten gerçekten zevk alıyorum çünkü beni rahatlatıyor ve odaklanabiliyor gibi hissediyorum.
Rahat bir sandalye. Hiçbir zaman okulumun bilgisayar laboratuvarlarını programlamak için kullanmıyorum çünkü ofis koltukları inanılmaz derecede rahatsız.
Önceden bir şeyler yiyin çünkü hiçbir şey motivasyonumu nagging açlığı gibi öldürmüyor.
30 May 2010 Matt Phillips
Uygulama. Bu, ve daha hızlı gitmenizi sağlayan verimlilik araçlarına elinizi sokuyor.
Örneğin (üzerinde çalıştığınız platformdan bahsetmediniz), .NET ortamında Resharper var.
11 Eyl 2009 Randolph West
Tahminleri ve zaman çizelgelerini yeniden müzakere edin. siz, bir şeyin ne kadar süreceğini söyleyen ve "daha önce yapmamıza ihtiyacımız var" veya "streç hedef hakkında" önerilerine yenik düşmeyenlerden emin olun.
Joel Spolsky'nin temelde eseri küçük parçalara bölmeyi savunan tahminler hakkındaki makalesini okuyun ve her birini tahmin edin. Bunlardan herhangi biri gün olarak sayılırsa, her şeyi saat olarak tahmin edene kadar daha fazla parçalayın.
11 Eyl 2009 harriyott
Siz ve patronunuz/değerlendiriciniz programlamak için ne kadar zamanınız olduğunu belirlemeniz gerekir. Çalışmanızın beklendiği andan itibaren toplantıları, e-postaları, belgeleri, testleri ve diğer kesintileri yapın ve nelerin kaldığını görün.
Belirli görevlerin ne kadar sürdüğünü gösteren bir ölçüt almak için zamanınızı izlemeye çalışın. Verimli zamanlar olacak (benim için günün erken saatleri ya da kesintiye uğramadan çalıştığım zamanlar) ve verimsiz zamanlar olacak. Bir ortalama bulun.
Belirli bir görevin programlanmasının 8 saat sürdüğünü belirleyebilirsiniz, ancak bir gün içinde bunu yapacağınızdan şüpheliyim.
Ayrıca kendinizi başkalarıyla karşılaştırmaya çalışacağım. Kurum kültürü uzun saatler içinde olabilir.
11 Eyl 2009 JeffO
Sanırım yavaş değilim, ama verdiğim iş uygun zamanı doldurma eğilimindedir.
Ne olursa olsun, çoğu zaman "Gee, bunu çabuk yaptın" diyorum, ama hızlı bir kodlayıcı olmaktan değil, daha az kodlamadan.
Daha az kodlamanın ana yolunun bir DSL gibi düşünmek olduğunu düşünüyorum. Bir ön işlemci tarafından sizin için oluşturulan kodu alamıyorsanız, bir kod oluşturucu yazın. Süslü olmak zorunda değil. Amaç, tek bir bağımsız gereksinim size verilirse, bu gereksinimi uygulamak için gereken kaynak kod farkı sayısını en aza indirmektir. İdeal olarak, bu sayı 1'dir. Eğer ortalama 3-6 civarında düşebilirseniz, bu oldukça iyi. (Bu sadece daha az yazmanız değil. Bu sayı ne kadar küçükse, koyduğunuz hata sayısı o kadar azdır ve gerçekten zaman kazandırır.)
Bunu yapmak için performans ayarı yapmanızı öneriyorum, çünkü o zaman hangi kodlama uygulamalarının en büyük yavaşlamalara yol açtığını ve ayrıca şişirilmiş koda yol açtığını öğreneceksiniz. Özellikle, aşırı veri yapısı ve olay/bildirim tarzı programlama. Sadece bu şeyler kod hacmine büyük katkıda bulunur.
Günümüzde çok fazla kod hacmi, özellikle dinamik olarak esnekse, kullanıcı arayüzünden kaynaklanmaktadır. Zor bir öğrenme eğrisine sahip olan ancak UI kodunu kabaca bir büyüklükle daraltan Dinamik İletişim Kutuları adlı parçayı yapmanın bir yolunu buldum.
Bunun için kendi yolunu bulman gerekecek, korkarım ama iyi şanslar.
11 Eyl 2009 Mike Dunlavey
Kişisel hayatınızı düzenli tutun. Özellikle demir eksikliğiniz varsa, çok uyuyun, sağlıklı yiyin ve vitamin alın. Ne demek istediğimi biliyorsanız - "içki" uzak dur. Unutmayın, "Hem Şarap hem de Kadınlar akıllı bir adam sapmasına neden olabilir."
Ayrıca, kodunuzun şablonlarını ve normal ifade kalıplarını kullanarak çalışan bir "kod oluşturucu" oluşturun. Kendinizi kopyalama ve yapıştırma, ardından benzer sınıfları arama ve değiştirme bulursanız, bu işlemi otomatikleştirin. Bunu benim PHP benim veri tabloları dayalı tüm temel MVC bileşenleri ile tam bir CRUD uygulaması oluşturabilirsiniz projeleri için yaptım - veri modelleri hariç tüm aynı görünüyor veri tabloları temsil ettikleri için şablonlar halinde kurulurlar ve ilk kodumu oluşturmak için kullanılırlar.
Son olarak, projeyle ilgili tüm insanlara kodun SİZİN düşündüğünüzden 1/4 ila 1/2 kat daha uzun süreceğini söyleyin. Erken kendiniz için daha fazla nefes odası için pazarlık yapın. "Geç" göreceli bir terimdir. Projede, orta akışta değişiklikler meydana geldiğinde, herkese 8 saat daha fazla çalışma eklendiğini önceden bildirin. "FogBugz" da sunulan gibi bir izleme sistemi, önceki deneyimlere dayanarak bir şeylerin ne kadar süreceğini tahmin etmek için kendinize ve yöneticilerinize yardımcı olabilir. "Geç kalmadım - bu işlevi tamamlamak için gereken süreyi kullandım - sadece beklediğimizden daha uzun sürdü."
Başka bir programcı, "Peki bunu daha hızlı yapabilirdim ..." diyebilir. Belki, belki değil, bu tartışmaya ya da kendinizi dövmeye değer bir nokta değil - her zaman bu düğmeye basmaya çalışan "akıllı" bir adam olacak. Düşünürsen seni yavaşlatacak! Bu her zaman kötü bir durum onun patronu olsa da. Bu noktada, başka bir iş aramayı düşünürdüm, çünkü bu tür bir patron kibirli bir JERK, kitabımda.
11 Eyl 2009 JasonMichael
S: Daha kısa sürelerde daha fazlasını yapmak için ne yapıyorsunuz?
C: Her gün ofise gelin ve bitirmek istediğiniz her şeyi (yapışkan notlar) Outlook notlarına yazın. Öğelerin bu sırası üzerinde çalışmaya başlayın. Günün sonunda inanın planladığınızı yaptığınızı hissedeceksiniz ve bu harika bir duygu.
12 Eyl 2009 Cshah
Çift programı - bunun her türlü faydası vardır:
sizi düşüncelerinizi ifade etmeye/açıklığa kavuşturmaya zorlar
size başka birinin nasıl çalıştığı hakkında fikir verir, benimseyebileceğiniz/deneyebileceğiniz birçok fikir
yeni teknolojileri doğrudan tanıyan birinden öğrenir
diğerlerinden küçük üretkenlik ipuçları alın. Her zaman birisinin daha önce anlamadığınız bir menü komutunu veya bazı yararlı Unix komutlarını kullandığını görürsünüz.
12 Eyl 2009 ndp
Daha az kod yazın.
Burada-değil icat-yasaklayın ve sadece yeni olanı yazmak gerekir ortak (ve genellikle tanımlayıcı olmayan) işlevsellik sağlamak için mevcut kütüphaneler/çerçeveler/araç takımları iyi kullanın. Kendiniz yazmanız gereken parçalar için, bunları bir sonraki proje için tekrar yazmak zorunda kalmayacağınız şekilde yeniden kullanarak düşünün.
Günde ürettiğiniz çalışma kodu satır sayısını artırmasanız bile, her satırın daha fazlasını yapmasını sağlayarak daha az zamanda daha fazlasını yapabilirsiniz.
14 Eyl 2009 Dave Sherohman
İşlerin bulduğu tek net şey dikkat dağıtıcı olmamaktır. Hangi, bazı ortamlarda imkansız. Ancak belirli bir göreve ve SADECE bu göreve odaklanabilmek muhtemelen başka bir şeyden daha ağır basacaktır. Bu bağlam anahtarları gerçekten büyük zaman alıcılarıdır.
30 May 2010 Joe
Hokkabazlık mola verirken
30 May 2010 Cornelius
Kahve içmek Yerba Mate Kahve yerine
Her zaman aynı karar, kalite, okunabilirlik ve genişletilebilirliğe karşı hızlı gelişme. Kontrolleri ve sonsuz kod arkası dosyalarını (hızlı ve kirli) veya modülerliği, kalıpları ve uygulamaları (uzun vadeli yatırım) sürükleyip bırakın?
Dürüst görüşüme göre, herkes uzun vadeli kodlama yöntemine yatırım yapmalıdır. Zaman geçtikçe, hızlı gelişme de çok kaliteli olacak.
Bununla birlikte, sorgunuzu anlamadıysam ve hızlı geliştirme, takım oluşturma, kod üreteçleri ve diğer şeyler gibi pratik yönleri açısından cevap arıyorsanız, benim fikrim Resharper'ı kullanmaya başlamak ve sizin için mümkün olduğunca çok şey öğrenmek = IDE :)
11 Eyl 2009 Aggelos Biboudis
ÇERÇEVE KULLANIN !! Hardcoding ile kendinizi rahatsız etmeyin!
11 Eyl 2009 Koosha
Her şeyden önce, son kullanıcılarla yapılan birkaç toplantıya dayalı bir sistem tasarlamamalısınız. Aslında, bir projenin gereksinimler aşamasına dahil olmamanız gerekir, bu iş analistleri ve son kullanıcılar için çalışır.
İkinci aşama teknik gereksinimleriniz olmalıdır, işte bu noktada talep edilen spesifikasyona bir çözüm bulmak için iş analistleriyle çalışmaya başlayacaksınız.
Şimdi önemli olan kısım. Hem son kullanıcı gereksinimlerini hem de fonksiyonel gereksinimleri anladığınızdan emin olun, yalnızca kullanıcıların beklentilerini karşılamadığını bulmak için bir şey başlatmanın bir yararı yoktur. Bir şey anlamadıysanız konuşun.
Şimdi, editöre çarpma zamanı. Ama benim yaklaşımım asla gerçek kod yazmak değil, her zaman ilk önce mutlak bir yorum yığını yazmak, sizin için kolaysa, önemli olan ne olursa olsun, okunması/anlaşılması kolay olduğu sürece sözde kodda yapmaktır.
Yorumlarınızı yaptıktan sonra aşağıdakilerden birini başlatabilirsiniz: a) test senaryolarınızı yazma b) uygulamayı yazma.
Ortamınıza bağlı olarak en iyi (a) ile başlayacaksınız, ama ne yazık ki en çok (b) ile başlayacak ve daha sonra testleri uygulamayı karşılamaya zorlamaya çalışacaksınız. Açıkçası, büyük bir şirketin parçası olsaydınız, bir şey yapmaya başlamadan önce sizin için test senaryolarını yazan bir bölüm olurdu.
11 Eyl 2009 Brett Ryan
Herkes 'e-postayı kontrol ediyor' diyor, ancak son derece teknik e-posta yazmak için harcadığınız zamanı düşünün. Tek bir e-posta yazmak için kolayca bir saat harcayabilirim. Bunu düzeltmek için, ya 1) çok fazla yazamadım ya da 2) kesinlikle gerekli olana kadar teknik şeyleri (ve cevaplamak için kodu okumamı gerektiren şeyler) erteleyebilirim.
11 Eyl 2009 Shin
Aslında kod yazarken CodeRush özellikle kısayollarına hakim olduğunuzda biraz yardımcı olur. Artı ücretsiz: D
12 Eyl 2009 GaiusSensei
Her hafta, şu anda üzerinde çalıştığım şeylerle doğrudan ilgili olabilecek veya olmayabilecek şeyleri yapmak için yeni yaratıcı yollar aramak için biraz zaman harcıyorum. Çoğu zaman, bunun iş akışımı hızlandırdığının farkında olmadığım yeni numaralar veya araçlar bulurum.
12 Eyl 2009 fscmj
IDE'nizi yakından tanıyın.
IDE Visual Studio ise, o zaman kesinlikle tavsiye ederim Sara Ford'un kitabı .
12 Eyl 2009 Jim G.
tasarım örüntülerini öğrenir. Sorunları anlamanıza yardımcı olurlar, sizi daha iyi bir programcı yaparlar.
programınızdaki tekrarlayan parçaları çıkarın. Yazdığınız birkaç programda tekrar eden bir mantık varsa, bunları genelleştirmeyi ve yazdığınız yeni uygulamalarda yeniden kullanabileceğiniz bir sınıf kitaplığına çıkarmayı düşünün. Standartlaştır şeyler: belirli tekrarlanan görevlerin en iyi şekilde nasıl yapıldığını bulmak için biraz zaman ayırın. Başarmak için adımları belgeleyin. Bir dahaki sefere bunları nasıl çözeceğinizi/uygulayacağınızı tam olarak bileceksiniz.
Kod oluşturma faydalı olacaktır (yararlı bir araç kullanılabilir olduğunda). Jeneratörler son zamanlarda popülerlik kazanmaya başladı.
Not: İşlerin işe yaraması daha kötü !! Bazılarının bahsettiği gibi, işleri çalışıncaya kadar hacklemek, sizi şimdilik daha hızlı hale getirecektir. Bununla birlikte, hatalar ne kadar hızlı programladığınız açısından bir şekilde sayılır. Eğer bir işlevsellik parçası yazmak zorunda kalırsam ve iyi yazmaya, iyi bir tasarıma sahip olabilirim, muhtemelen iyi test edilmiş (Birim testleri ile) ve yarım güne ihtiyacım olduğunu söylerim. Ancak bunun olduğunu ve özelliklerinizin işe yaradığını ve tekrar dokunmanıza gerek olmadığını varsayın. Hedefine hızlı bir şekilde ulaşmaya odaklanan başka bir programcı, sınır, istisnai durumları dikkate almayacağı (farkında olacağı) eksik testler nedeniyle (muhtemelen) kötü bir tasarım yapacak. 2 saate ihtiyacı olacak (diyelim). Hatalar içeri girecek, yine koda dokunması, düzeltmesi, muhtemelen uzatması gerekecek (saatler tekrar yatırılacak). Kodun korunması zor olacak vb ... devam et: sonunda çok fazla cevher zamanı harcayacak ve hayal kırıklığı daha yüksek olacak.
12 Eyl 2009 Juri
ergonomik olarak optimize edilmiş klavye düzeni kullanın. Hatta bazıları çok erişilebilir özel karakterlerle programcılara yöneliktir.
17 Eyl 2009 knittl
Evden çalışmak. Zor bir teslim tarihim olduğunda ve tamamen bir soruna odaklanmam gerektiğinde, patronuma evden çalıştığımı söylüyorum. Bu, ortamımı en iyi şekilde kurmamı, kesintileri azaltmamı ve soruna lazer ışını gibi odaklanmamı sağlıyor.
30 Eyl 2009 Pedro Estrada
Deneyiminizle daha hızlı bir hale gelecek ve API'yı çok daha fazla ezberleyeceksiniz.
Kod parçaları için web'de arama günlerim artık daha iyi kodlamayı öğrendiğimden çok daha kısa.
Oh, ayrıca kodunuzu kesmek için fonksiyonel programlama kavramlarını ve lamda'yı kullanmayı deneyebilirsiniz :)
5 Eki 2009 Vince
Yaptığınız şey için heyecanlı olmak verimliliği arttırmanın harika bir yoludur. Eğlenceli olduğundan emin olun!
30 May 2010 Jakob
Fikrinizi kağıt üzerinde çizmenin, unutmayın, bazı fikirleri etmenin harika bir yolu olduğunu düşünüyorum. Profesyonel ya da hobi uzmanları olarak programcılar olarak, ekrana bakmak için çok fazla zaman harcıyoruz. Bir şeyleri tırmalamak, fikirleri birbirine bağlayan aceleci çizgiler çizmek, şeyleri daire içine almak, altını çizmek, vb. Hepsi bir fikre vurgu yapar ve bir fikri hemen yarasadan ya da içinde yapılandırmaya çalışmaktan çok daha hızlı bir şekilde sıralamanıza yardımcı olabilir. bazı bilgisayar destekli formlar.
Yardımcı olan başka bir şey küçük parçaları prototiplemek. Dün gece konuşmacının spagetti çubuklarından ve Marshmallow'dan küçük yapılar inşa etmeyi tartıştığı bir TED ses podcastini dinledik, görünüşe göre bu, küçük grupların sosyal inşaat yeteneklerini test etmek için oldukça yaygın olarak kullanılan bir çalışma ... neyse, her zaman takviye ve bina inşaatını anlayan mimarların yanı sıra, sonuç almak için sürekli bir geri bildirim akışı kullandıkları için çocuklardı. Ben de bunu küçük şeyler yapmanın ve sonuç almanın sadece daha verimli değil, aynı zamanda dev bir yapı inşa edip hata ayıklamak için günler harcamaktan çok daha verimli ve kullanışlı olduğunu gördüğünüz bir programlama fikrine atabileceğinizi düşünüyorum. bazı "eğlenceli" fikirlerimi eminim.
30 May 2010 dscher
Ofiste olduğumda ve odağımı korumam gerektiğinde, e-posta istemcimi kapatıyorum. Hiçbir şey, benim için gelen mesajlara "hızlıca bir göz atmak" için sürekli cazibeden daha hızlı bir şekilde verimliliği yok edemez. Ayrıca aksaklıkları yönetmek ve odağı korumak için Pomodoro Tekniği ile oynuyorum.
30 May 2010 Tim Trout
Mümkün olduğunda kod üreteçlerini kullanın. Bazen Microsoft Excel (veya OpenOffice Calc) bile güçlü bir kod üreteci aracı olarak ortaya çıkıyor.
11 Eyl 2009 Canavar
Basitçe söylemek gerekirse, Beyaz tahta -> görevlere test edilebilir gereksinimlere ayrılır (Her görevi ve ne kadar süreceğini takip etmek için kullandım Team Foundation .)
Gerekli olanı aldığınızdan emin olmak için testi kullanın, hiçbir şey daha az değil. (Performans hakkında endişelenmeyin.)
Her şey yapıldıktan sonra gereksinimden gereksinime gidin ve test edin. Her görev tamamlandıktan sonra kalan süreyi doğru olarak tahmin etmelisiniz.
Tüm gereksinimler karşılandığında geri gidin ve "cilalayın".
Bacak işini ilk önce yapmak, ilk seferinde işleri doğru yaparak zaman kazandıran tüm gereksinimleri gidermeye zorlar.
Düzgün yapılırsa, Yığın Taşması için daha fazla zaman harcanması gerekir :)
11 Eyl 2009 Brad8118
Burada bir sürü harika fikir var. 'Bölgeye' girmeme yardım etmek için 27 dakikalık aralıklarla ayarlanmış bir zamanlayıcı kullanıyorum. Çalışma modundayken, zil sesinin çok ötesinde çalışmak kolay ve akışla çalışmak ağrısız olduğunu görüyorum. Oraya gitmek zor.
11 Eyl 2009 Daver
Hızımı en çok etkileyen fark ettiğim tek şey motivasyon ve eğlenmek. Bu Fuzzy görünebilir, ancak motive olduğum ve eğlenceli bulduğum bir şey yaptığımda son derece etkili olabilirim. Öte yandan, ne de ben gerçekten her kod satırını benden dışarı itmek zorunda gibi hissetmiyorum.
Tatlı noktalarınızı, sizi neyin motive ettiğini ve gerçekten ne tür görevlerden hoşlandığınızı bulun? Bunu yapabilmek için planlamanızı etkileyebilir misiniz? Benim için sorunları ve tasarım sorunlarını çözdüğümde ve projenin bir parçası olduğumu hissettiğimde.
Birkaç ay önce küçük ekibimizin atadığı küçük bir projemiz vardı ve bu gerçekten çok önemli ve gerçekçi olmayan bir son teslim tarihi idi. Ancak hepimiz çok motive olduk ve bunu yaparken çok eğlendik ve mutlu bir müşteriyle zamanında yaptık. Motivasyonumun nedeni, projeye çok dahil olmamız ve bunun için yaratıcı fikirler bulmamız gerekti. Ayrıca gerçekten keyif aldığım parçaları da yapmalıyım.
Ancak son zamanlarda temelde bir kod maymunu olduğum, sadece zihin uyuşturan ve sinir bozucu görevler yaptığım veya sadece geri dönüp beni zor bir şekilde ısırdığımı bildiğim en hızlı yolla bir projeye katıldım yakın bir gelecek ve acı verici bir şekilde yavaştı.
Peki tatlı noktaların nedir?
12 Eyl 2009 Runeborg
Ne yapmak istediğinizi bilin ve onunla ilgilenin
Kodun nasıl yapılacağına ilişkin araştırma yaparak birkaç saat geçirin
Son sonuca ulaşmak için kodu kopyalayıp yapıştırın
İşi yapmak için temel bir GUI üzerinde çalışın, görünmesini sağlamak için zaman harcamayın.
Güzel bir GUI üzerinde çalışmak
12 Eyl 2009 Matt S.
"Zamanındalık", "hızlı" ile aynı şey değildir. Eğer sorun buysa, değerlendirmeniz az önce "yavaş" demeliydi. Bu nedenle önerdiğiniz yolu izlemeden önce sizden ne beklendiğini bildiğinizden emin olun.
Bir şey ifade edebilir; hatta iş arkadaşlarınızdan 20 dakika sonrasına kadar ofise girmediğiniz veya kötü zaman yönetiminizin olduğu anlamına gelebilir. Bunun 'programlama hızınızla' bir ilgisi olmayabilir.
Muhtemelen tasarım ve planlama için çok zaman harcıyorum; iyi bir analiz ve tasarımdan görevleri planlamak daha kolaydır ve daha sonra inanılacak daha iyi tahminler vereceksiniz. Dahası, iyi bir tasarımdan kodlama çok daha basit ve daha yönlendirilmiş bir süreç haline gelir. Ayrıca bir görevi bölmeyi ve diğer geliştiriciler arasında dağıtmayı da mümkün kılar.
12 Eyl 2009 Clifford
C kodlama hızımı neredeyse VIM ile üçe katladım.
13 Eyl 2009 Liran Orevi
CodeRush! Anla! Sevdim!
13 Eyl 2009 Bobby Ortiz
Hızlı yürütme süresi ile hızlı düzenleyici, hızlı derleyici ve yazma yazılımı seçin. Bu şekilde normal programcıdan on kat daha fazla hata yapabilir ve yine de diğerlerinden daha iyi olabilirsiniz. Muhtemelen google uygulamalarının bu kadar popüler olmasının nedenlerinden biri budur. Web geliştirme kötü hatalarla dolu ve buggy platformda daha fazla yazılım yazmak eşek acı. Ancak kod düzenleme ve sonucu görme arasındaki yanıt süresi o kadar hızlı ki, o çöp dağını çalıştırmak c ++ programlarını genişletmekten daha kolaydır. :)
14 Eyl 2009 AareP
Zihninizde IDE'nin önünde bir şeyleri bir araya getirmek için daha fazla zaman harcayın. Bir planınız olduğunda, zaten yapılan işlerin çoğuna sahipsiniz. Uygulama sadece diğer% 20'dir. Platforma özgü sorunlar nedeniyle kod yazarken takılırsanız, plana sadık kalın ve gerisini uygulamaya ve test etmeye devam edin. Sonunda, geride bıraktığınız tüm noktaları tek tek çözerek mücadele edin - bazılarının ilişkili olması ve birkaçının çözülmesi gerisini bulmak için yeterli olabilir. Genellikle bu tür sorunlar için geçici çözümler kullanıyorum, koddaki belirli yerlere "// TO CHANGE" yorumları ekliyorum ve sonunda çözüme yetecek zamanım yoksa, kalite ve performans üzerinde en fazla etkisi olanları yeniden yazıyorum son teslim tarihine kadar.
17 Eyl 2009 luvieere
Kendi kod kütüphanenizi oluşturun
Yeni bir özelliği her kodladığınızda, onu mümkün olduğunca genel tutmaya çalışın, ancak çok genel değil. Kısa vadede bu biraz daha yavaş olacak, ancak kod liberiniz büyüdükçe uzun vadede, birçok yeni iş uygulamasının benzer ihtiyaçları (her zaman değil) olduğu için her yeni proje daha hızlı tamamlanacak, ancak kod yeniden kullanılabilir.
18 Eyl 2009 Darknight
Daha hızlı demek daha iyi demek değildir. Daha hızlı ve daha iyi bir programcı olmayı başarırsanız. Her şey dengeleniyor. Bunu ne kadar süre yapabilirsiniz? Düşünme, sabır ve planlama her zaman işe yarar. Bazen gelişme dünyasında "hızlı" en kötü sonuçları getirebilir.
20 Eyl 2009 Ryuken
Analiz. Yaptığınız her şeyi aşamalı olarak uygulayabileceğiniz daha küçük özelliklere bölün. Daha sonra, bu küçük parçalardan herhangi birini yaptığınızda ve hiçbir şeyi kırmadığını doğrulamak için test ettiyseniz, konuşlandırın ve Olan Güçlere gösterin.
Küçük yinelemeleri kullanmak genellikle daha büyük projeyi daha hızlı ve daha iyi bitirmenize yardımcı olacaktır, çünkü gittikçe geri bildirim alırsınız ve geri izlemenize ve yeniden yapmanıza gerek kalmaz. Ancak bunu yapmasa bile, sağlam bir psikolojik yararı olan ve yöneticinizin veya müşterinizin güvenini geri kazandıran sürekli ilerleme gösteriyorsunuz.
Test odaklı geliştirme de bu yaklaşımda çok yardımcı oluyor. İlk başta testler yazmak ilk önce işleri yavaşlatır gibi görünebilir - ancak o zamanı kaçınacağınız hatalara geri döndürür ve bunları nasıl yazdığınıza bağlı olarak, testlerin kendileri, bu Güçlere gösterebileceğiniz bir çıktı olabilir ve hepsini yazmadan önce uygulamanın davranışını onaylayın.
25 Eyl 2009 SFEley
C dilinde programlıyorsanız, daha hızlı bir programcı olmak için bit kesmek öğrenmek şarttır. Ayrıca Topcoder.com'da üst sıralarda yer alan kodlama uygulamalarını okuyun. Kodları çok küçük ve verimlidir.
25 Eyl 2009 avd
Tasarlarken ve kodlarken yavaşlayarak daha hızlı bir programcı olun.
Ne yaptığınızı düşünün.
Tasarımınızın sonuçlarını düşünün.
İlk seferde doğru alın (kendi kodunuzu şiddetle test edin).
daha yavaş hissedebilir , ancak veriminiz 4 saat içinde bir yinelemeyi çeviren ve daha sonra 6 tur QA'ya ihtiyaç duyan kod jokeylerinden daha hızlı olacaktır. kod geçer.
2 Eki 2009 mmc
Re: Nasıl tahmin ve ona sopa:
Tahmin ederken, Hofstadter yasası ve bu alıntıyı unutmayın: "Her şey olduğundan daha uzun sürer". Bir şeyin ne kadar sürmesi gerektiği konusunda makul bir tahminde bulunun, sonra ağzınızdan çıkmadan önce ikiye katlayın veya üçe katlayın. Komplikasyonlar, aksilikler, dikkat dağıtıcı şeyler, unuttuğunuz şeyler vb. Olacaktır.
Tahminlere bağlı kaldığınızda, çalışmanızı verimli bir şekilde tamamlamak için elinizden geleni yapın. Sorun ortaya çıktığında, gecikmeleri erkenden iletin. Bu herkese beklentilerini ayarlaması için zaman tanır. Açıklamanız makul ise, daha fazla zaman veya yardım verilebilir veya dikkat dağıtıcı (gürültülü bir komşu gibi) yolunuzdan kaldırılabilir.
9 Eki 2009 steamer25
Aşağıdaki uygulamalar iyi bilinir, ancak sık sık son tarihler nedeniyle çeşitli nedenlerle ihmal edilir, bu nedenle burada belirtmeyi hak ederler (aslında, bunlar daha fazla harcamadan kaçınmak için önceden zaman harcama mekanizmasıdır daha sonra):
test odaklı geliştirme; yalnızca gerçekten gerekli olan kod miktarını yazmanıza yardımcı olur ve özellik eklerken veya yeniden düzenlerken hataların girmesini önlemenize yardımcı olur
yorumlar yazın, ancak yalnızca kodun bunu garanti edecek kadar karmaşık olduğu yere
Refactor ve basitleştirin sık sık kodunuz
ygun kaynak kontrol yazılımı (Git veya Mercurial gibi) kullanın -işvereniniz başka bir şey kullanıyorsa, kendi yerelinizi kullanın-
İşlem kod sık sık değişir: her özellik veya yeniden düzenleme için bir işlem yapın, çünkü bir şey ters giderse geri dönüş sizin için daha az maliyetli olacaktır
Korkma --- şube; Git özellikle çok hızlı ve "güvenli" bir dallanma mekanizmasına sahiptir (örneğin Subversion'a kıyasla)
25 Kas 2009 Nick Toumpelis
Ben şahsen kod yeniden kullanılabilirlik hakkında her şeyi düşünüyorum. Her seferinde tamamen özel şeyler yapmadığınız sürece, başvurabileceğiniz ortak kullanım işlevleri kütüphanesine sahip olmalısınız. Önceki projelerde kullandığım işlevlerin bir bütün "hurdalığı" olan bir utils.php var. Ben benzer bir şey yapmak zorunda zaman bir ton tasarruf.
İyi şanslar ve cesaretiniz kırılmasın. Sanırım hepimiz zaman zaman yavaş ya da "aptal" hissettik. Sahip olduğumu biliyorum!
9 Oca 2010 Code Monkey
Statik analiz araçlarını kullanın.
Derleme zamanında daha fazla hata bulmanıza yardımcı olurlar, aksi takdirde çalışma zamanında izlemeniz gerekir.
Özellikle çok iş parçacıklı uygulamalar oluştururken GERÇEK bir yardımdır.
11 Oca 2010 Oliver Weiler
Bunların hepsi iyi öneriler. Sadece en az kodla değil, minimum yedek kodla işlerin nasıl yapıldığını bilmek için kendi üretkenlik tekniğimi eklerim.
Genellikle bu, daha az veri yapısının daha iyi olduğu anlamına gelir.
Minimum fazlalık ile kod yapmak yaratıcılık ve bir öğrenme eğrisi yükleyebilecek şekilde şeyler yapmak için isteklilik gerektirir. Verimliliğin fiyatı budur. İşte bir örnek.
30 May 2010 Mike Dunlavey
Yerel ES6 vaatleri neden mavi kuşlardan daha yavaş ve bellek yoğun oluyor?
Bir SQLite veritabanı için gerçekçi, gerçek dünyadaki maksimum boyut nedir?
Bir değerin listede olup olmadığını kontrol etmenin en hızlı yolu
Python 3'te neden "1000000000000000 (1000000000000001)" aralığında bu kadar hızlı?