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

Birkaç yıldır profesyonel bir kodlayıcı oldum. Kodumla ilgili yorumlar genellikle aynı olmuştur: iyi bir kod yazar, iyi bir şekilde test edilmiştir, ancak daha hızlı olabilir .

Peki kaliteden ödün vermeden nasıl daha hızlı bir kodlayıcı olabilirim ? Bu soruya göre, kapsamı C # ile sınırlayacağım, çünkü öncelikli olarak kodladığım şey (eğlenmek için) - ya da Java, bunun birçok önemi var.

Yaptığım şeyler:

• İşi halledecek minimal çözümü yazın
• Bir dizi otomatik test yazın (gerilemeleri önler)
• Her türlü şey için tekrar kullanılabilir kütüphaneler yazın (ve kullanın)
• İyi çalıştıkları yerlerde iyi bilinen teknolojileri kullanın (örn. Hazırda Bekletme)
• Yerine oturdukları tasarım desenlerini kullanın (örn. Singleton)

Bunların hepsi harika, ama hızım zamanla artıyor gibi hissetmiyorum. Ben bunu ben (hatta% 10) benim verimliliği artırmak için bir şeyler yapabiliriz eğer, bu benim rakiplerine göre% 10 daha hızlı olduğu için, kendine iyi. (Bende hiç yok.)

Bunun yanında, yöneticilerimden sürekli olarak bu geri dönüşü aldım - ister küçük ölçekli Flash gelişimi isterse işletme Java / C ++ gelişimi.

Düzenleme: Ne demek istediğimi hızlı bir şekilde ve yavaş olduğumu nasıl bildim hakkında bir sürü soru var gibi görünüyor. Daha fazla ayrıntıyla açıklığa kavuşturmama izin verin.

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

Bunun bir kısmı, önemli sayıda akranımı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 genel olarak iyi belgelenmiş, okunabilir ve test edilebilir.

Oracle'da sürekli diğer ekip üyelerinden daha yavaş hataları çözerdim. Bunu biliyorum, çünkü bu etki hakkında yorumlar alırdım; bu, diğer (evet, daha kıdemli ve deneyimli) geliştiricilerin, çalışmamı aldıklarından daha az zamanda, neredeyse aynı kalitede (okunabilirlik, bakım yapılabilirlik ve test edilebilirlik) yapabileceği anlamına geliyor.

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

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

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 adlı kitabından bir bölüme atıfta bulunuyor. Geçiş devam ediyor:

Seramik öğretmeni açılış gününde sınıfı iki gruba böldüğünü açıkladı. Stüdyonun sol tarafındaki herkes, yalnızca sağladıkları işin miktarına, sadece sağdakilerin kalitesine göre derecelendirileceğini söyledi. Prosedürü basitti: sınıfın son gününde banyo terazisini getirip "miktar" grubunun çalışmalarını tartıştıracaktı: "A" olarak değerlendirilen elli pound pound, "B", vb. Bununla birlikte, "kalite" ile derecelendirilenlerin, "A" almak için yalnızca bir tane, hatta mükemmel bir tane bile pot üretmesi gerekiyordu. Eh, sınıflandırma zamanı geldi ve merak uyandıran bir gerçek ortaya çıktı: en yüksek kalitede çalışmaların tümü, miktar için derecelendirilen grup tarafından üretildi. Öyle görünüyor ki "miktar"

Temel olarak ellerinizi daha hızlı ve daha sık kirletmek, becerilerinizi daha iyi hale getirir; zamanınızı çalışmak için "mükemmel" bir yöntemle ilgili ders çalışarak ve teorik olarak geçirmekten daha iyi hale getirir. Tavsiyem, çalışmaya devam et, teknolojiye ayak uydur ve tasarım araştır.

Hiç kimsenin bahsetmediği bir olasılık, gayet iyi yaptığınız ve yöneticilerinizin çok iyi olmadığıdır. Verimliliği nasıl ölçüyorlar? Size özel örnekler verebilirler mi yoksa sadece genel bir algı mı? Diğer insanların çalışmalarını tamir etmek için harcadığınız zamanı sizinkine göre dikkate aldılar mı?

Yaptıkları iş için pek çok insanın kredi kazandığını gördüm.

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

Ne olduğunu önemli sürekli olarak karar verme sürecini iyileştirmek için geri bildirim kullanıyor. Bunu yapmanın tek yolu, başka bir beceri kazanmak gibi, tecrübe, 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çlara ve tekniklere maruz bırakın. Neyin işe yaradığını koru.
• Karar alma cihazınızı eğitmek için tasarlanmış programlama alıştırmaları yapın *.
• Gelişiminizi kusur oranı ve hızı gibi nesnel ölçütler ve kod kalitesi ve uygunluk gibi öznel ölçütler temelinde izleyin.

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

* http://codekata.pragprog.com/

Aslında, daha yüksek hız için bir miktar kaliteden ödün vermeniz isteniyor .

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

^{1 - Özellikle "iç takım ustası" nı düşünüyorum, ama muhtemelen başkaları da var.}

İyi şeyler yapıyormuşsunuz gibi geliyor - orta vadede sizi daha hızlı hale getirecek, bu yüzden gerçekten yavaş olmanız belli değil. Bunu gerçekten sen biliyorsun. (ama bu çok gerçek bir olasılık - PeopleWare, aynı görev için geliştiriciler arasında 10 katına kadar verimlilik farkı olduğunu iddia ediyor).

Bu yüzden size bazı önerilerim var:

1. Zaman göreceli bir şeydir, bu yüzden belki mesele sizin gerçek hızınız değil, verdiğiniz zaman algısıdır. Bunun bir hafta alacağını ima edebilirsiniz, ancak diğerlerinin 3 hafta geçirebileceği iki hafta geçirdikten sonra ... 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öneticinizle ve akranlarıyla söylediklerini görmek için konuşma zamanı - onlardan öğrenecek çok şey olmalı.

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

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

Yıllar / aylar boyunca, sürüş ve otoyollarda takılmaya başladığınızda, sürüşünüzü eğlenceli hale getiren yol boyunca birkaç püf noktası öğrenirsiniz. Biz buna deneyim diyoruz. Bu “püf noktaları” (özellikleri dediğim) yardımcı olan şey.

Benim durumumda, kodlama (hatta @ home) ve bazılarının kullanımlarını öğrenerek tasarım desenlerinin gerçek kullanımını öğrendim. Bu nedenle, bir tasarım deseni gerektiren bir sorunla karşılaştığımda, hangilerinin işe yaradığını ve durumum için neden işe yarayıp yaramadığını görmek için geçmiş tecrübelerimi kullanırım.

Özetle:

• Tecrübe , güven ve daha iyi yazılımları artıran özellikler yaratır.

Not: Tecrübe aynı zamanda başkalarından öğrenmekten de geliyor. Örneğin, SO'dan Yardım, Çift Programlama, Akran Değerlendirmeleri, vb.

Mesele şu, uzun vadeli toplam maliyete bakarken daha az pahalıysanız.

Başka bir deyişle, dikkatlice hazırlanmış hata düzeltmeleriniz (test vakaları ve dokümantasyon dahil) yüksek kalitedeki hata düzeltmelerini daha hızlı çalışanlarınız tarafından yapılan hata düzeltmelerini sürdürmek zorunda kalmanın maliyetinden ağır basıyor mu?

Eğer evet ise, o zaman üstlerinizin bu gerçeğin farkında olmanız gerekir. Değerlendirmenizi onaylamak için ölçme ve gerekli verilere sahip olup olmadıklarını tartışmak zor olabilir.

Eğer hayır ise, bunun neden böyle olduğunu düşünmelisiniz :

• Çok deneyimsiz misin?
• Orada olması gerektiğine inandığınız şeyleri istemediğiniz şeyleri yapmak için çok zaman harcıyor musunuz?
• Düzeltmenin ne zaman biteceğini belirlemek zor zamanlarınız mı var?
• Kodunuz, düşündüğünüzden daha düşük kalitede mi?
• Kod geliştirme işlemine farklı bir yaklaşımla yaklaşmanız gerekir mi, çünkü şimdi yapma biçiminizi hızlandırmanız çok uzun sürüyor mu?
• Bu site gibi şeylere çok fazla zaman harcadın mı?

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

Sorgulayan insanların yaptıkları soruların hepsi gerçekten yavaş olup olmamanız aptalca. 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 benim bir numaralı programcı olarak 1 numaralı hedefimdir ve asla yapılmayacağım. Her zaman kaliteden ödün vermeden daha hızlı olmaya çalışıyorum, buna takıntılıyım. İşte benim için şu ana kadar yararlılık derecesinde, sonunda bazı deneysel fikirlerle çalıştığım şey:

1) Öğrenmeyi asla bırakmayın: Bilgisayarları genel olarak programlama ve kullanma hakkında her şeyi öğrenin. Zayıf olduğunuz alanları bulun ve öğrenin. İşinizle ve C # ile tamamen ilgisiz görünse bile, onu ararsanız, bunu yaptığınız işe uygulamanın yollarını bulacağınızı garanti ederim. Öğrenme de tecrübe ile ilgilidir, bu yüzden sadece bir şeyler okumayın, deneyin ve becerilerinizi geliştirin. Windows kullanmaya alışkınsanız, Unix'i veya tersini deneyin. Normalde IDE kullanmak isterseniz komut satırı araçlarını ve metin editörlerini deneyin veya bunun tersi de geçerlidir. Daha önce hiç duymadığınız veya çok fazla şey bilmediğiniz bir araç veya teknoloji duyuyorsanız, ilerlemenin baştan çıkarmasına izin vermeyin. Yukarı bak! Kutunun dışında düşünmekten ve başkalarının pratik olmadığını söyleyen deneysel yeni teknolojileri öğrenmekten korkmayın;

2) Projeleri bölme: Projelerinizi mini projelere bölmeye çalışın. Her gün veya en fazla birkaç günde bir yeni sürüm yayınlamaya çalışın. Kendinize "Salıverebileceğim asgari işlev miktarı nedir ve yine de kullanıcı için yararlı olan bir şey serbest bırakın" diye sorun. Bu yaparak öğreneceksiniz bir beceridir. Yöneticilerinizi bunu yapmanıza izin vermeye ikna etmeniz gerekebilir, ancak genellikle sonuçlardan oldukça hızlı bir şekilde memnun kalacaklardır. Bunu yaparak, özelliğiniz için gerekli 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ızla ilgili tüm özelliklerin yerine yalnızca en önemli özelliklere öncelik vermenizi sağlar. Bu, zihninizi açık ve odaklanmış tutarak daha hızlı düşünmenizi sağlar. Buna karşılık yasal olarak daha hızlı programlanırsınız. Yöneticileriniz veya en azından yöneticinizin yöneticileri, şimdi programladığınızı, olduğundan çok daha hızlı bir şekilde algılayacağınızı, muhtemelen daha fazla sürüm çıkardığınıza inanıyor olabilir. Bunun bir diğer büyük yararı, sürümlerin tamamlanmasının ne kadar süreceğini tahmin etmekte çok daha iyi olacağınız ve yöneticileriniz bunun için sizi seveceğidir. Zaten çok sayıda otomatik sınama yaptığınız için, kararlı sürümleri sık sık yapmakta sorun yaşamazsınız. Yine de, otomatik yapı sisteminizi güçlendirmeniz gerekebilir. Martin Fowler serisinde Sürekli Teslimat kitabını okumanı şiddetle tavsiye ederim. Zor bir okuma ve son derece tekrarlayan, ancak yine de çok yararlı çünkü. Ayrıca yöneticilerin şu anda olduğundan çok daha hızlı bir şekilde programlama yaptığınızı algılaması da muhtemeldir, çünkü daha fazla sürüm çıkarırsınız. Bunun bir diğer büyük yararı, sürümlerin tamamlanmasının ne kadar süreceğini tahmin etmekte çok daha iyi olacağınız ve yöneticileriniz bunun için sizi seveceğidir. Zaten çok sayıda otomatik sınama yaptığınız için, kararlı sürümleri sık sık yapmakta sorun yaşamazsınız. Yine de, otomatik yapı sisteminizi güçlendirmeniz gerekebilir. Martin Fowler serisinde Sürekli Teslimat kitabını okumanı şiddetle tavsiye ederim. Zor bir okuma ve son derece tekrarlayan, ancak yine de çok yararlı çünkü. Ayrıca yöneticilerin şu anda olduğundan çok daha hızlı bir şekilde programlama yaptığınızı algılaması da muhtemeldir, çünkü daha fazla sürüm çıkarırsınız. Bunun bir diğer büyük yararı, sürümlerin tamamlanmasının ne kadar süreceğini tahmin etmekte çok daha iyi olacağınız ve yöneticileriniz bunun için sizi seveceğidir. Zaten çok sayıda otomatik sınama yaptığınız için, kararlı sürümleri sık sık yapmakta sorun yaşamazsınız. Yine de, otomatik yapı sisteminizi güçlendirmeniz gerekebilir. Martin Fowler serisinde Sürekli Teslimat kitabını okumanı şiddetle tavsiye ederim. Zor bir okuma ve son derece tekrarlayan, ancak yine de çok yararlı çünkü. ve yöneticileriniz bunun için sizi sevecek. Zaten çok sayıda otomatik sınama yaptığınız için, kararlı sürümleri sık sık yapmakta sorun yaşamazsınız. Yine de, otomatik yapı sisteminizi güçlendirmeniz gerekebilir. Martin Fowler serisinde Sürekli Teslimat kitabını okumanı şiddetle tavsiye ederim. Zor bir okuma ve son derece tekrarlayan, ancak yine de çok yararlı çünkü. ve yöneticileriniz bunun için sizi sevecek. Zaten çok sayıda otomatik sınama yaptığınız için, kararlı sürümleri sık sık yapmakta sorun yaşamazsınız. Yine de, otomatik yapı sisteminizi güçlendirmeniz gerekebilir. Martin Fowler serisinde Sürekli Teslimat kitabını okumanı şiddetle tavsiye ederim. Zor bir okuma ve son derece tekrarlayan, ancak yine de çok yararlı çünkü.

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

4) Vim'i öğrenin. Bu komutları Visual Studio'da ViEmu ile veya Eclipse içinden bir eklenti ile veya Emacs içinden kullansanız bile, verimlilik kazanırsınız. Vim'i öğrenmenin en iyi yolu, onu kullanmaya başlamak ve ustalaşana kadar kendinizi asla (devre dışı bırakma / eski aletlerine geri dönme) için zorlamaktır. İlk başta acı vericidir, ancak asla geri dönmek istemeyeceksiniz, hatta onsuz çalışmak zorunda kaldığınızda bile cüret edebilirsiniz. Bazıları bunun hızınızı fazla artırmayacağını söylüyor. Ancak daha hızlı, özellikle de kodu okurken ve değiştirirken BİZ NE YAPARIZDIR ve bu vesileyle kendimi çok fazla zaman kazanırken buldum.

5) Bu sonuncusu mutlaka tavsiye edilmez, çünkü iyi bir fikir olduğundan emin değilim 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 testleri yaptığınızdan emin olabilirsiniz. SpecFlow ile başarılı oldum, ancak orada daha iyi bir şey olduğundan şüpheleniyorum. Özellikleri yazmak bile oldukça teknik olabilir; bu nedenle, önce yöneticinize / müşterinize, önemli ölçüde değiştireceğiniz kaba bir taslak sürümü yazmanız veya her şeyi kendiniz yazıp sadece okuyup tamamlamanız gerekebilir. Bu, bu listedeki 2 numaralı size yardımcı olacaktır. Ayrıca kabul testleri daha pratik olabilir ve birim testlerinden daha az kod gerektirir. Bu, onların yerini değiştirdiklerini, farklı şeylerin farklı araçlarını söylemek değildir.

6) Bu daha da deneysel ve tartışmalı. Aslında bunu kendim yapmadım, bu yüzden tam olarak tavsiye edemem. JetBrains'ten Meta Programlama Sistemini öğrenin ve kullanın. İstediğiniz yazılımı kendileri oluşturmak için yöneticinizin / müşterinizin kullandığı araçları oluşturmak için kullanın. Davranışınızı çok basit ve anlaşılır bir şekilde belirtmek için yöneticinizin / müşterinizin kullandığı araçları yapmak için kullanabilirseniz, birim ve kabul testleri yapmayı durdurabilirsiniz. Buradaki fikir programcıdan kurtulmak değildir. Programcıların, müşteri / yönetici tarafından kullanılan araçlara (insanlar değil, araçlar) istenen bazı işlevleri kolayca oluşturamadıkları durumlarda yeni özellikler eklemesi gerekecektir. MPS ya da buna benzer diğer araçların geleceğin yolu olduğuna inanıyorum.

Beynini daha fazla kullan ve daha az test yap. Dürüst olmak gerekirse, test yerini aldı, ancak pahalıdır.

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

Son olarak, doğru yerde olmayabilir. Kare iş, vb yuvarlak kazık

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

Büyük, bitmiş bir proje alıp, saat başı "son" kod satırı sayısını alırsanız, programcıların çok daha azını, tahmin edebileceğinizden daha yavaş kodladığını göreceksiniz.

Günde sadece birkaç satır koddan bahsediyoruz. Zamanın geri kalanında hata ayıklamak, yeniden yazmak ve genel programcı işleri yapmak için harcarsınız.

Eski deyimi duymuş olabilirsiniz - yazarken bir hata yakalarsanız, oluşturma zamanında yakalarsanız, 10 kat daha iyi olan QA'yı yakalamaktan 10 kat daha iyi olan, oluşturma sırasında yakalarsanız, zamandan 10 kat tasarruf edersiniz. serbest bıraktıktan sonra yakalamaktan ..

Peki nasıl hızlandırıyorsun? Hiçbir şekilde yazma hızına odaklanmam - hataları azaltmak ve kodunuzla diğer "gelecekteki etkileşimleri" geliştirmek, zamanınıza daha iyi bir yatırım yapmalıdır.

Okunabilir, net kod kritik. Kodunuzu bir kez yazarsınız, ancak onlarca kez okunur. Okunabilirlik için yazmak size satır boyunca çok fazla sorun kazandıracak (aynı zamanda çok zaman kazandıracak). HİÇ geri dönüp kodunuzu okumak ve bir saniye bile düşünmek zorunda kalırsanız, o zaman yanlış yapıyorsunuz.

Çift programlama QA süresini kısaltabilir ve bir programcının günde yalnızca birkaç satır ürettiğini düşünüyorsanız, ikisi aynı hızda kodlayabiliyorsa ancak daha az hatayla kodlarsanız, YOLUNA BAŞLAYINIZ.

Savunma kodlaması (örneğin, parametre kontrolü) sorunları azaltabilir ... Eğer ekibinizde gerçekten iyi bir analist / mimar varsa, o zaman iyi bir başlangıç ​​tasarımı ile biraz zaman kazanabilirsiniz.

Aksi takdirde, tasarım becerilerinizi geliştirmeye devam edin. Tecrübe kazandıkça, işe yaramayacak ve onlardan kaçınacak şekilleri daha iyi tanıyabileceksiniz, daha önce zaman alıcılarını vb.

Çalışırken detaylı 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 .

Tam olarak NASIL harcadığınızı daha iyi anladıktan sonra, neyin iyileştirilmesi gerektiğine dair daha iyi bir fikir edinebilir ve çabalarınızı orada odaklayabilirsiniz.

İdeal olarak, iş arkadaşlarınızdan bazılarını da bunu yapmaya zorlayabilir, sonuçlarınızı karşılaştırabilir ve birbirlerinden fikir edinebilirsiniz. Muhtemelen sizin de faydalanabilecekleri güçlü yanlarınız vardır.

Belki de işleminizin otomatikleştirilebilecek bir kısmı için çok fazla zaman harcadığınızı ya da günün belirli bir bölümünde çok fazla dikkat dağıtıcı olduğunu ve günün başka bir bölümünü sessiz olduğunu öğrendiniz, sonra görevlerinizi planlayabilirsiniz. o vb

Veya belki de test etmenin düşündüğünüzden daha fazla zaman aldığını ve bunun sizi daha hızlı yaptığını algıladığınızı yeniden düşünmeniz gerekir.

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

Listenden iyi gidiyorsun.

İş arkadaşlarınız daha yüksek CRAP numarasına sahip kod yapıyorlarsa, daha hızlı gidecektir. CRAP, döngüsel karmaşıklığı ve Test kapsamını birleştiren, çizgi roman adı verilen bir metriktir.

Yapmanız gerekenden daha CRAP olan bir kod yazmayın. ;)

Sana önereceğim tek değişiklik kütüphaneleri kullanmak,

1. Şirketiniz kütüphaneler satıyor
2. Tekrarlayan kodu bir kütüphaneye yerleştirdiniz

Okuyorsun ve yapıyorsun ve bu harika. Fakat procuedural veya OO kodunu düşünmekle sıkışmış olabilirsiniz, Kendinizi İşlevsel programlamaya (Haskell mı diyorsunuz?) Ve Prolog'a maruz bıraktınız mı?

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

Ve son olarak, teori. En azından grafik teorisinin ilkel bir anlayışınız var mı? (Bazı programlar ağaçlar, DAG'ler veya bir noktada yalnızca düz grafiklerle çalışır. Ağlar grafiklerdir)

Bob Amca'ya teklif vereceğim :

Hızlı gitmenin tek yolu iyi gitmek.

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

- "Araç Sıradanlığı", Robert C. Martin

Bildiğim kadarıyla:

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

Bir yönetici olarak, herhangi bir 2 seçebilirsiniz.

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

Aklıma gelen başlıca şeyler şunlardır:

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

Kodlama becerisi alanında da yapabileceğiniz bazı şeyler var eminim ama bu tür şeylerin her yerinde olduğunuzu sanıyorum. Yukarıda listelediklerim genellikle geliştiriciler tarafından göz ardı edilir.

Hızlı yazma kursuna gidebilirsin. Daha hızlı yazmanın sorun olup olmadığını bilmiyorum ama "yavaş yavaş kodlama" yalnızca yavaş yazma hızlarından kaynaklanıyor olabilir.

Peki ya kod üreteçleri? Bazen kod tekrar eder. Yeniden düzenleme, bir kısmını kaldırabilir, ancak o zaman bile, aynı yeniden yapılandırılmış işleve tekrarlayan çağrılar yapabilirsiniz. Birlikte çalıştığınız veri ve kod bağlı olarak, kod jeneratörler (Excel, Perl, Java, yazılmış her neyse ...) olabilir çok zaman kaydedin. Ve UI geliştirme için kod üreten araçların kullanılması genellikle bir beyin fırtınası değildir.

Ve nihayet, belki de ölçümler yanlıştır. Her şeyden önce mümkün olan en hızlı şekilde ayarlayabileceğiniz hızda kodladığınızı ve zaman çizelgelerinin çok kısa olduğunu ve yavaş bir kodlayıcı gibi göründüğünü düşündünüz mü?

Sorunuzdaki düzenlemelere göre, iş arkadaşlarınızdan bazılarının yolunu izleyebileceğiniz ve işe yarayacak en hızlı çözümü bir araya getirebileceğinize benziyor - belgeler ve kalite güvencesi!

Veya ... belirli bir alanda daha fazla tecrübe ve uygulama yapın, böylece kod tabanını ve API'yi iyi tanırsınız, uykunuzdaki çözümleri kodlayabilirsiniz. Bu yapılabilir ancak daha fazla zaman gerektirir. Eğer daha üst düzey ve daha deneyimli olduğu bilinen daha hızlıdır diğer geliştiricilerin daha sonra yapılacak tek şey varsa - siz gerekir haline daha üst düzey ve deneyimli!

OP’nin “hız için fedakar kalite” görüşüne itirazım var.

Profesyonel kodlayıcıların (programcılar) 3 nesneyi sağlamaları gerekir:
1) Kod istenildiği gibi çalıştırılmalıdır
2) Teslimat zamanında olmalı
3) İyi kalitede, dokümantasyona sahip vb.
4) Diğer vb.

OP zaman içinde yapmadığı için OP'nin muhtemelen o kadar yavaş suçlandığını düşünüyorum.

Bu, etrafta dolaşılması zor bir av 22. Halen tecrübe eksikliği ve birçok yönden bir miktar bilginin zaten çoğundan daha hızlı olmasına rağmen, bu durum ölçülmesinin daha zor olduğudur .

Şahsen bu noktada yapabileceğiniz en iyi şey kendinizi ölçmektir. Nasıl çalıştığınız hakkında kendinize geri bildirimde bulunun, belki de çalışma alışkanlıklarınızdaki basit değişiklikler sizi daha üretken yapabilir.

Kesinti nedeniyle postaları düşündüğümden çok daha fazla yiyordu. Şimdi postalara günde iki kez cevap veriyorum ve bazı günlerde neredeyse 1 saat verimlilik kazanıyorum. Pomodoro gibi yöntemleri deneyin , ölçü 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 ne yapabileceğimi görmeme izin verdi.

Squeak'in hızlı kodlamadaki avantajı, yalnızca "birinin OOP becerisini kazanma" nın ötesine geçiyor. Modern GUI'lerin ve IDE'lerin Smalltalk'te keşfedilmesinin bir nedeni var, JUNIT’in Java’ya SUNIT limanı, "OOP" terimi Smalltalk’i tarif etmek için icat edildi.

Kişi her zaman 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 haricindeki olası istisnası olan herhangi bir şeye karşı gıcırtıyla eşleşirdim ve hatta hangisinin Aslında Squeak'e yerleşik hiper kart benzeri tesisler olduğu için daha hızlı.