it-swarm.asia

Daha Hızlı Kodlama (Kaliteden ödün vermeden)

Birkaç yıldır profesyonel bir kodlayıcıyım. Kodum hakkındaki yorumlar genellikle aynıdır: iyi kod yazmış, iyi test edilmiş, ancak daha hızlı olabilir .

Peki kaliteden ödün vermeden nasıl daha hızlı kodlayıcı olabilirim? Bu soru uğruna, kapsamı C # ile sınırlayacağım, çünkü öncelikle kodladığım (eğlence için) - veya önemli olan birçok yönden yeterince benzer olan Java.

Zaten yaptığım şeyler:

  • İşi yapacak asgari çözümü yazın
  • Bir dizi otomatik test yazın (regresyonları önler)
  • Her türlü şey için yeniden kullanılabilir kütüphane yazma (ve kullanma)
  • İyi çalıştıkları yerlerde iyi bilinen teknolojileri kullanın (örn. Hazırda Bekletme)
  • Yerine oturdukları yerde tasarım desenleri kullanın (örn. Singleton)

Bunların hepsi harika, ama hızımın zamanla arttığını düşünmüyorum. Ben ilgilenirim , çünkü üretkenliğimi artırmak için bir şey yapabilirsem (% 10 bile), bu rakiplerimden% 10 daha hızlı. (Bende yok.)

Bunun yanı sıra, küçük ölçekli Flash geliştirme veya kurumsal Java/C++ geliştirme olsun, bu geri bildirimleri yöneticilerimden sürekli olarak aldım.

Edit: Hızlı olarak kastettiğim ve yavaş olduğumu nasıl bildiğim hakkında birçok soru var gibi görünüyor. Daha fazla ayrıntıyla açıklığa kavuşturayım.

Çeşitli projeler ve çeşitli teknolojiler (Flash, ASP.NET, Java, C++) üzerinde çeşitli şirketlerde küçük ve orta ölçekli ekiplerde (5-50 kişi) çalıştım. Yöneticilerimin (doğrudan bana söyledikleri) gözlemi “yavaş” olduğum.

Bunun bir kısmı, akranlarımın önemli bir kısmının hız için kaliteden ödün vermesidir; buggy, okunması zor, bakımı zor ve otomatik testler yazmak zor olan kodlar yazdılar. Kodum genellikle iyi belgelenmiş, okunabilir ve test edilebilir.

Oracle'da sürekli olarak diğer ekip üyelerinden daha yavaş hataları çözerdim. Bunu biliyorum, çünkü bu konuda yorumlar alıyorum; Bu, diğer (evet, daha üst düzey ve deneyimli) geliştiricilerin işimi beni aldığından daha kısa sürede, neredeyse aynı kalitede (okunabilirlik, sürdürülebilirlik ve test edilebilirlik) yapabileceği anlamına gelir.

Neden? Neyi kaçırıyorum? Bu konuda nasıl daha iyi olabilirim?

Son hedefim basit: bugün 40 saat içinde X ürününü yapabilirsem ve yarın 20, 30, hatta 38 saatte aynı ürünü oluşturabilmem için kendimi bir şekilde geliştirebilirsem, bilmek istediğim şey bu - oraya nasıl giderim? Sürekli iyileştirmek için hangi süreci kullanabilirim? Kodun yeniden kullanılmasıyla ilgili olduğunu düşünmüştüm, ama bu yeterli değil, öyle görünüyor.

148
ashes999

Jeff Atwood'un bu konudaki yaklaşımını burada bulabilirsiniz http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html .

Makalede temel olarak David Bayles ve Ted Orland'ın Art & Fear kitabından bir bölüme atıfta bulunuyor. Geçit:

Seramik öğretmeni açılış gününde sınıfı iki gruba böldüğünü açıkladı. Stüdyonun sol tarafındaki herkes, sadece ürettikleri iş miktarına, sağdaki herkes ise sadece kalitesine göre derecelendirilecek. Prosedürü basitti: sınıfın son gününde banyo tartılarını getirecek ve "miktar" grubunun çalışmasını tartacaktı: "A" olarak derecelendirilen elli pound tencere, kırk pound "B" ve benzeri. Bununla birlikte, "kalite" üzerine derecelendirilenlerin, "A" elde etmek için sadece bir tencere - mükemmel bir tane de olsa - üretmeleri gerekiyordu. Sınıflandırma zamanı geldi ve merak uyandıran bir gerçek ortaya çıktı: En yüksek kalitede çalışmaların hepsi miktar için derecelendirilen grup tarafından üretildi. Görünen o ki, "miktar" grubu, iş yığınlarını titizlikle çalkalarken - ve hatalarından öğrenirken - "kalite" grubu, mükemmellik hakkında teorileşmişti ve sonunda çabaları için görkemli teorilerden daha az gösterecekti ve ölü kil yığını.

Esasen, ellerinizi daha hızlı ve daha kirli hale getirmek, zamanınızı “mükemmel” bir yol hakkında çalışmak ve teorileştirmek için harcadığınız zamandan daha iyi becerilerinizi geliştirir. Tavsiyem, pratik yapmaya devam et, teknolojiye ayak uydur ve tasarım çalış.

160
chrisw

Hiç kimsenin bahsetmediği bir olasılık, iyi durumda olduğunuz ve yöneticilerinizin çok iyi olmadığıdır. Verimliliği nasıl ölçüyorlar? Size belirli örnekler verebilirler mi yoksa sadece genel bir algı mıdır? Sizinkine kıyasla diğer insanların çalışmalarını düzeltmek için harcadıkları zamanı dikkate aldılar mı?

Takımlarının geri kalanı geride bıraktıkları karışıklığı düzeltirken, birçok insanın işlerini yapmak için kredi aldığını gördüm.

72
pdr

İnsanların önemli olduğunu düşündüklerinin çoğu önemli değildir. Yazma hızı önemli değil. Daha hızlı makineler veya aletler önemli değildir. Biz daktilo veya makine operatörü değiliz. Biz düşünce işçileriyiz. Biz karar vericiyiz .

önemli olan, karar verme sürecinizi sürekli olarak iyileştirmek için geribildirim kullanmaktır. Bunu yapmanın tek yolu, başka herhangi bir beceri kazanmak gibi, deneyim, amaçlı uygulama ve sürekli geri bildirimdir.

  • Yan projeler üzerinde çalışın.
  • Açık kaynaklı projeler üzerinde çalışın.
  • Sizden daha iyi olan geliştiricilerle çalışın. Eşleştirme programı!
  • Kendinizi yeni araç ve tekniklere maruz bırakın. Neyin işe yaradığını saklayın.
  • Karar verme cihazınızı eğitmek için tasarlanmış programlama alıştırmaları yapın *.
  • Hata oran ve hızı gibi objektif metriklere ve kod kalitesi ve uygunluk gibi subjektif metriklere dayalı olarak gelişiminizi izleyin.

Son olarak: kalite olmadan hızın işe yaramaz olduğunu unutmayın, bunun tersi de geçerlidir. Yardımcı programınızı en üst düzeye çıkarmak için bu gerilimler arasında bir denge bulun.

* http://codekata.pragprog.com/

39
Rein Henrichs

Aslında, daha fazla hız için bazı kaliteden ödün vermeniz istenebilir.

Bazı geliştirme ortamlarında1, "yeterince iyi" yapacağı zaman, cilalı bir şey üretmek için fazladan zamana değmez.


1 - Özellikle "içsel araç gereç" i düşünüyorum, ama muhtemelen başkaları da var.

25
Michael Shaw

Tüm iyi şeyleri yapıyormuşsunuz gibi görünüyor - orta vadede sizi daha hızlı hale getirecek, bu yüzden gerçekten yavaş olup olmadığınız belli değil. Bunu sadece sen gerçekten biliyorsun. (ancak bu çok gerçek bir olasılıktır - PeopleWare, aynı görev için geliştiriciler arasında 10 kat daha fazla üretkenlik farkı olduğunu iddia ediyor).

Size bazı önerilerim var:

  1. Zaman göreceli bir şeydir, bu yüzden belki de sorun gerçek hızınız değil, verdiğiniz zaman algısıdır. Bir hafta süreceği anlamına gelebilir, ancak diğerlerinin 3 hafta geçirebileceği iki hafta geçirdiniz ... ama sadece 1 hafta yavaş görünüyorsunuz.

  2. Bu geri bildirimi sık sık aldığınız için, belki de yöneticilerinizle ve akranlarınızla söylediklerini görmek için konuşma zamanı - onlardan öğrenecek çok şey olmalı.

  3. Farkı tespit edip edemeyeceğinizi görmek için bir "hızlı kalite" geliştiricisi ile bazı çift programlama yapın.

12
Stephen Bailey

İnsanların gerçekten yavaş olup olmadığınıza dair yaptığı tüm sorgulama saçmadır. Kaliteden ödün vermeden daha hızlı bir programcı olmak, ne kadar yavaş veya hızlı olursanız olun her zaman iyi bir hedeftir. Bu bir programcı olarak benim 1 numaralı hedefim ve asla yapılmayacağım. Kaliteden ödün vermeden her zaman daha hızlı olmaya çalışıyorum, takıntılıyım. Sonunda bazı deneysel fikirlerle birlikte şu ana kadar bana yardımcı olan sırayla işe yarayan şey:

1) Öğrenmeyi asla bırakmayın: Genel olarak bilgisayarları programlama ve kullanma hakkında her şeyi öğrenin. Zayıf olduğunuz bölgeleri bulun ve öğrenin. İşinizle ve C # ile tamamen ilgisiz görünse bile, onu arıyorsanız, genellikle yaptığınız işe uygulamak için yollar bulacağınızı garanti ederim. Öğrenmek de deneyimle ilgilidir, bu yüzden sadece bir şeyler okumayın, deneyin ve becerilerinizi genişletin. Windows'u kullanmaya alışkınsanız, Unix'i deneyin veya tam tersini yapın. Normalde IDE kullanmak istiyorsanız komut satırı araçlarını ve metin editörlerini deneyin veya tam tersi. Daha önce duymadığınız veya çok fazla şey bilmediğiniz bir araç veya teknoloji duyarsanız, ilerlemek için cazip davranmayın. Baksana! Kutunun dışında düşünmekten ve başkalarının pratik olmadığını söyledikleri deneysel yeni teknolojileri öğrenmekten korkmayın; Verimli bir şekilde programlamanın yüzeyini çizmeye yeni başlıyoruz.

2) Projeleri ayırın: Projelerinizi mini projelere ayırmaya çalışın. Her gün veya en fazla birkaç günde bir yeni bir sürüm yapmaya çalışın. Kendinize, "Kullanabileceğim en düşük işlevsellik miktarı nedir ve yine de kullanıcı için yararlı bir şey yayınlayın" diye sorun. Bu yaparak öğreneceğiniz bir beceridir. Yöneticilerinizi bunu yapmanıza izin vermeye ikna etmeniz gerekebilir, ancak genellikle sonuçlardan oldukça çabuk memnun olurlar. Bunu yaparak, özelliğiniz için önemli olduğunu düşündüğünüz şeylerin aslında daha sonra geliştirilebilecek ek özellikler olduğunu fark etmeye başlayacaksınız. Bu, sizin ve yöneticilerinizin üzerinde çalıştığınız özelliklerle ilgili tüm özellikler yerine yalnızca en önemli özelliklere öncelik vermenizi sağlar. Bu, zihninizi net ve odaklanmış tutarak daha hızlı düşünmenizi sağlar. Daha sonra yasal olarak daha hızlı program yapacaksınız. Yöneticileriniz veya en azından yöneticinizin yöneticileri de artık gerçekte olduğundan daha hızlı programlama yaptığınızı algılarlar çünkü daha fazla sürüm çıkarırsınız. Bunun bir başka büyük yararı, sürümlerin ne kadar sürede tamamlanacağını tahmin etmede çok daha iyi olmanız ve yöneticilerinizin sizi bunun için seveceğidir. Zaten çok sayıda otomatik test yaptığınız için, kararlı olan sık sürümleri yaparken sorun yaşamamalısınız. Yine de otomatik derleme sisteminizi güçlendirmeniz gerekebilir. Martin Fowler serisinde Sürekli Teslimat kitabını okumanızı tavsiye ederim. Bu zor bir okuma ve son derece tekrarlayıcı, ama yine de çok yararlı olduğu için.

3) Pomodoro tekniğini kullanın ve sizin için işe yaramayanları uyarlayın/değiştirin. Bunu bu listedeki 2 numara ile birleştirirseniz, BÜYÜK bir verimlilik artışı elde edersiniz.

4) Vim öğrenin. Bu komutları ViEmu aracılığıyla Visual Studio'da veya bir eklenti aracılığıyla Eclipse içinden veya Emacs içinden kullansanız bile üretkenlik kazanacaksınız. Vim'i öğrenmenin en iyi yolu, onu kullanmaya başlamak ve siz ustalaşana kadar kendinizi (devre dışı bırakmak/eski araçlarınıza geri dönmek) asla zorlamaktır. İlk başta acı vericidir, ama asla geri dönmek istemeyeceksiniz ve hatta onsuz çalışmak zorunda kaldığınızda kandırmak isteyeceksiniz. Bazıları bunun hızınızı fazla artırmayacağını söyler. Ancak daha hızlı, özellikle de kodu okurken ve değiştirirken WHAT WE DO, ve bu arada zaman zaman kendimi çok fazla zaman tasarrufu buldum.

5) Bu sonuncusu mutlaka iyi bir fikir olduğundan emin olmadığım için tavsiye edilmez ve aslında verimliliğinizi düşürebilir, ancak yine de orada olacağım. Daha fazla kabul testi ve daha az birim testi yapmayı deneyebilir veya belki de en azından bazı kabul testlerini yaptığınızdan emin olabilirsiniz. SpecFlow ile başarılı oldu, ama orada daha iyi bir şey olduğundan şüpheleniyorum. Teknik özellikleri yazmak bile oldukça teknik olabilir, bu nedenle yöneticinizin/müşterinizin önemli ölçüde değiştirdiğiniz kaba taslak bir versiyonunu yazmasını isteyebilirsiniz, ya da her şeyi kendiniz yazabilir ve sadece okuyup tamamlamasını isteyebilirsiniz. Bu, bu listeden 2 numara ile size yardımcı olacaktır. Ayrıca kabul testleri daha pratik olabilir ve birim testlerden daha az kod gerektirir. Bu onların yerini, farklı şeyler için farklı araçlar demek değildir. Ancak, çok fazla kabul testi yaparsanız daha az birim testinden kurtulabilirsiniz.

6) Bu daha da deneysel ve tartışmalı. Aslında kendim yapmadım, bu yüzden tam olarak tavsiye edemem. JetBrains'ten Meta Programlama Sistemini öğrenin ve kullanın. Yöneticinizin/müşterinizin istenen yazılımı kendileri oluşturmak için kullandığı araçlar oluşturmak için kullanın. Yöneticinizin/müşterinizin davranışı çok basit ve kıvrık olmayan bir şekilde belirtmek için kullandığı araçları yapmak için bunu kullanabiliyorsanız, birim ve kabul testleri yapmayı durdurabilirsiniz. Fikir programcıdan kurtulmak değil. Programcıların, müşteri/yönetici tarafından kullanılan bu araçlara (araçlar değil insanlar değil) istenen işlevleri kolayca oluşturamadığı durumlarda yine de yeni özellikler eklemeleri gerekir. MPS veya buna benzer diğer araçların geleceğin yolu olduğuna inanıyorum.

8

Etkili bir şekilde, kaynayan şey deneyim. Yaptığınız işte daha hızlı olmak, araba sürmek gibi, başlangıçta korktunuz çünkü diğerleri hızlı (veya sarhoş) sürücüler (veya her ikisi) ve güvenli bir şekilde eve (yazılım açısından, kodunuzun gelişmiş olarak çalışır ve iyi çalışır).

Yıllar/aylar boyunca, sürüşe ve otoyollara asıldığınızda, sürüşünüzü eğlenceli hale getiren yol boyunca birkaç numara öğrenirsiniz. Biz buna deneyim diyoruz. O "hileler" (ben özellik diyorum) yardımcı olan şeydir.

Benim durumumda, tasarım kalıplarının gerçek kullanımını kodlamayı (hatta @ home) ve bazılarının kullanımını öğrenerek öğrendim. Bu nedenle, bir tasarım deseni gerektiren bir sorunla karşılaştığımda, hangisinin işe yaradığını ve neden benim durumum için işe yarayıp yaramayacağını görmek için geçmiş deneyimi kullanıyorum.

Özetle:

  • Deneyim güveni ve daha iyi yazılımı artıran özellikler oluşturur.

Not: Deneyim başkalarından da öğrenmekten gelir. Örneğin. SO, Pair Programming, Akran Değerlendirmeleri, vb. Yardım. Geriye dönüp hatalardan ders alamıyorsanız (ya da birisi çabanıza hiç meydan okumuyorsa) bir deneyim yaşayamazsınız.

8
Buhake Sindi

Soru, uzun vadeli toplam maliyete bakarken daha az pahalı olup olmadığınızdır.

Başka bir deyişle, hatayı korumak zorunda kalmanın maliyetlerinden ağır basan (- === -) yüksek kalitede (test senaryoları ve belgeler dahil) özenle hazırlanmış hata düzeltmeleriniz daha hızlı iş arkadaşlarınız tarafından yapılan düzeltmeler?

Cevabınız evet ise, amirlerinizi bu gerçeğin farkında kılmanız gerekir. Değerlendirmenizi doğrulamak için gerekli ölçülere sahip değilse ve gerekli verilere sahip olup olmadıklarını tartışmak zor olabilir.

Hayır ise, neden durum böyle olduğunu düşünmeniz gerekir:

  • Çok deneyimsiz misiniz?
  • Orada olması gerektiğine inandığınız, talep edilmeyen şeyleri yapmak için çok fazla zaman harcıyor musunuz?
  • Düzeltmenin ne zaman tamamlandığını belirlemekte zorlanıyor musunuz?
  • Kodunuz sandığınızdan daha düşük kalitede mi?
  • Kod geliştirmeye farklı bir şekilde yaklaşmanız gerekir, çünkü şimdi yaptığınız gibi hızlanmanız çok uzun sürüyor mu?
  • Bu site gibi şeylere çok fazla zaman harcadınız mı?

Bir düşünün ve sorunuzu bulgularınızla düzenleyin.

8
user1249

Beyninizi daha fazla kullanın ve daha az test yapın. Dürüst olmak gerekirse, testin yeri var, ama pahalı.

Ayrıca, Unix Programlama Sanatı'nı okuyun (ücretsiz çevrimiçi, fiyat değerinde kitap)

Son olarak, doğru yerde olmayabilirsiniz. Kare işte yuvarlak peg, vb.

Nihayetinde okul gibidir: "Öğretmenin istediği çıktı", "yönetimin istediği ve ödediği çıktı" olur.

5

Eğer büyük, bitmiş bir proje alır ve saat başına "son" kod satırı sayısını alırsanız, programcıların hayal edebileceğinizden çok daha yavaş kodladığını göreceksiniz.

Günde sadece birkaç satır koddan bahsediyoruz. Hata ayıklama, yeniden yazma ve genel programcı şeyler yapmak için kalan zaman.

Eski deyişi duymuş olabilirsiniz - yazarken bir hata yakalarsanız, derleme zamanında yakaladıysanız 10 kat daha fazla zaman kazandıracaktır, bu da KG sırasında yakalamadan 10 kat daha iyidir, bu da 10 kat daha iyidir. serbest bırakıldıktan sonra onu yakalamaktan ..

Peki nasıl hızlandırıyorsunuz? Herhangi bir yazma hızı üzerinde durmayacağım - hataları azaltmak ve kodunuzla diğer "gelecek etkileşimlerini" geliştirmek zamanınızın çok daha iyi bir yatırımı olmalı.

Okunabilir, açık kod kritik öneme sahiptir. Kodunuzu bir kez yazarsınız, ancak düzinelerce kez okunur. Okunabilirlik için yazmak size çok fazla sorun kazandıracaktır (bu da çok zaman kazandıracaktır). Eğer hiç geri dönüp kodunuzu okuyun ve bir saniye bile düşünmek zorunda kalırsanız, o zaman yanlış yapıyorsunuz.

Çift programlama KG süresini azaltabilir ve bir programcının günde sadece birkaç satır ürettiğini düşünürseniz, ikisi biriyle aynı oranda kodlayabilir ancak daha az hatayla kod yazarsanız, ileride OLABİLİRSİNİZ.

Defansif olarak kodlama (örneğin, parametre kontrolü) sorunları azaltabilir ... Ekibinizde gerçekten iyi bir analist/mimarınız varsa, iyi bir başlangıç ​​tasarımıyla biraz zaman kazanabilirsiniz.

Aksi takdirde tasarım becerilerinizi geliştirmeye devam edin. Deneyim kazandıkça kendinizi çalışmayan kalıpları daha iyi tanıyabilir ve bunlardan kaçınabilirsiniz, daha önce zaman batışlarını tanımlayabilirsiniz.

5
Bill K

Bildiğim kadarıyla:

  1. iyi
  2. hızlı
  3. ucuz

Yönetici olarak herhangi 2 tanesini seçebilirsiniz.

Hızla aldığınız yorumlar için endişelenmeyin. Bir kodlayıcı olarak, birlikte tokatlanmış bir şeyden daha iyi düşünülmüş ve iyi yazılmış bir kod tutmayı tercih ederim.

3
Nico

Çalışırken ayrıntılı bir denetim yapmayı düşündünüz mü? Zamanınızı nasıl harcadığınızı gösteren kalem ve kağıt takibi veya kendinizi izlemek için Rescue Time gibi bir şey kullanın.

Zamanınızı tam olarak NASIL harcadığınızı daha iyi öğrendikten sonra neyin iyileştirilmesi gerektiğine dair daha iyi bir fikir edinebilir ve çabalarınızı oraya odaklayabilirsiniz.

İdeal olarak, bazı iş arkadaşlarınıza bunu yapmaları için meydan okuyabilir, sonuçlarınızı karşılaştırabilir ve birbirinizden fikir edinebilirsiniz. Muhtemelen onların da yararlanabileceği bazı güçlü yönleriniz var.

Belki de işleminizin otomatikleştirilebilecek bir bölümüne çok fazla zaman harcadığınızı veya günün belirli bir bölümünde birçok dikkatinizin dağıldığını ve günün başka bir bölümünün sessiz olduğunu fark edersiniz, o zaman görevlerinizi planlayabilirsiniz vb.

Ya da belki de testin düşündüğünüzden daha fazla zaman aldığını ve bunun sizi daha hızlı hale getirdiği algısını yeniden düşünmeniz gerektiğini öğreniyorsunuz.

Başka bir şey yoksa, çalışabileceğiniz bazı kriterler verir.

3
DKnight

Listenizden iyi gidiyorsunuz.

Meslektaşlarınız daha yüksek CRAP numarasına sahip kodlar yapıyorlarsa, daha hızlı gideceklerdir. CRAP, siklomatik karmaşıklığı ve Test kapsamını birleştiren komik olarak adlandırılmış bir metriktir.

Sizden daha fazla CRAP kodu yazmayın. ;)

Sizin için önerebileceğim tek değişiklik kütüphaneleri kullanmaktır, yoksa aşağıdakileri yazmayın:

  1. Şirketiniz kütüphaneler satıyor
  2. Yinelenen kodu bir kitaplığa yeniden girdiniz

Okuyorsunuz ve yapıyorsunuz ve bu harika. Fakat procuedural veya OO kodu, Kendinizi İşlevsel programlamaya (Haskell deyin mi?) Ve Prolog hakkında düşünmeye sıkışmış olabilirsiniz.

OO programlama tekniğinizi keskinleştirmek için Smalltalk/Squeak ile oynadın mı?

Ve son olarak, teori. En azından grafik teorisinin temel bir anlayışına sahip misiniz? (Bazı programlar bir noktada ağaçlar, DAG'lar veya sadece düz grafikler ile çalışır. Ağlar grafiktir)

3
Tim Williscroft

Alıntı yapacağım Bob Amca :

Hızlı gitmenin tek yolu iyi gitmektir.

Her zaman hız için kalite ticaretinin cazibesine kapıldığınızda yavaşlarsınız. Her zaman.

-- "Vehement Sıradanlık", Robert C. Martin

3
Johnsyweb

OP'nin "hız için kaliteden ödün vermesi" görüşüne bir itirazım var.

Profesyonel kodlayıcıların (programcılar) 3 nesneyi karşılaması gerekir:
1) Kod istendiği gibi çalıştırılmalıdır
2) Teslimat zamanında yapılmalıdır
3) İyi kalitede, dokümantasyonda vb.
4) Diğer vb.

Bence OP muhtemelen Yavaşça suçlandı çünkü OP zamanında yapmadı.

2
9dan

Bu dolaşmak zor bir 22 yakalamak. Yine de deneyim eksikliği olabilir ve birçok yönden bir miktar bilgi zaten çoğundan daha hızlı olsa da, yakalama ölçülmesi daha zor .

Kişisel olarak bu noktada yapabileceğiniz en iyi şey kendinizi ölçmektir. Kendinize nasıl çalıştığınıza dair geri bildirim sağlayın, belki de çalışma alışkanlıklarınızdaki basit değişiklikler sizi daha üretken hale getirebilir.

Postaların sadece kesinti yüzünden düşündüğümden çok daha fazla yediklerini gördüm. Şimdi sadece günde iki kez postaları yanıtlıyorum ve bazı günlerde neredeyse 1 saat verimlilik kazandım. pomodoro gibi yöntemleri deneyin, bir ölçüm aracı olarak kullandım. Düzenli aralıklarla (15 dakika) o sırada ne yaptığımı not ederdim. Bu, günlerimin nasıl yapılandırıldığını ve verimliliği en üst düzeye çıkarmak için neler yapabileceğimi görmemi sağladı.

2
Newtopian

Aklıma gelen temel şeyler şöyle:

  • Yazma hızınızı artırın.
  • Verimlilik kazancı sağlayan araçlar kullanın. Örneğin ReSharper.
  • Daha hızlı makineler veya aletler. More RAM veya yarıiletken sürücü gibi).

Eminim kodlama becerisi alanında da yapabileceğiniz bazı şeyler var ama bu tür şeylerin üzerindeymişsiniz gibi geliyor. Yukarıda sıraladığım şeyler genellikle geliştiriciler tarafından göz ardı edilir.

2
mpenrow

Bir hız yazma kursu alabilirsiniz. Daha hızlı yazmanın sorun olup olmadığını bilmiyorum ama "çok yavaş kodlama" sadece yavaş yazma hızlarından kaynaklanıyor olabilir.

Kod üreticileri ne olacak? Bazen kod tekrarlanır. Yeniden düzenleme bazılarını kaldırabilir, ancak o zaman bile aynı yeniden düzenlenmiş işleve tekrarlayan çağrılarınız olabilir. Çalıştığınız verilere ve koda bağlı olarak, kod üreteçleri (Excel, Perl, Java, neyse yazılır ...) çok zaman kazandırabilir . Ve UI geliştirme için kod oluşturma araçlarını kullanmak genellikle zekice bir şeydir.

Ve son olarak, belki de metrikler yanlıştır. Diğer her şey göz önüne alındığında mümkün olan en yüksek hızda kodlama yaptığınızı ve zaman çizelgelerinin çok kısa olduğunu ve sizi yavaş bir kodlayıcı gibi görünüyor mu?


Sorunuzdaki düzenlemelere dayanarak, bazı iş arkadaşlarınızın yolunu alabilir ve çalışacak en hızlı çözümü birlikte ele geçirebilirsiniz - ve belgeler ve KG lanetlenebilir!

Ya da ... belirli bir alanda daha fazla deneyim ve uygulama edinin, böylece kod tabanını ve API'yi uykunuzdaki çözümleri kodlayabileceğiniz kadar iyi bilirsiniz. Bu yapılabilir, ancak daha fazla zaman gerektirir. Sizden daha hızlı olan diğer geliştiricilerin daha kıdemli ve daha deneyimli oldukları biliniyorsa, yapılacak tek şey vardır - siz gerekir daha kıdemli ve deneyimli!

Squeak'in hızlı kodlama avantajı "kişinin honlama OOP beceriler) 'in ötesine geçiyor. Modern GUI'lerin yanı sıra IDE'lerin Smalltalk'ta icat edilmesinin bir nedeni var. Java SUNIT, "OOP" terimi Smalltalk, vb. Tanımlamak için icat edildi.

Kişi, başarmayı umduğu her şey için en uygun dili ve ortamı kullanmalıdır, ancak genel prototipleme için, en azından, HyperCard'ın olası istisnası dışında gıcırtıyla herhangi bir şeye karşı eşleşirdim ve hatta hangisinin olduğunu görmek için kıyaslama gerektirecektir Squeak içine yerleştirilmiş hipercard benzeri tesisler olduğu için daha hızlı.

0
user22340