İlerledikçe kodunuzu derlemenin bir yararı var mı?

Son zamanlarda bazı gerçek kodları yazmak için bana bir saat verdikleri bir iş görüşmesi yaptım. Muhtemelen 100 satırdan az büyük bir miktar değildi. Yaklaşık 45 dakika sonra derledim, çalıştırdım ve çalışmasını sağladım. Derleme hataları ve birkaç ufak hatayla uğraşmak için 5-10 dakika harcadım, ama genel olarak çok yumuşaktı. (Bu arada, onlardan bir teklif aldım.)

Bununla birlikte, beni şaşırtan şey, tamamlanmış kodu teslim ettikten sonra görüşmeci, yanlış yaptığım tek şeyin “devam ederken derlememek” olduğunu söyledi. Ona aradaki farkın ne olduğunu sordum ve “kodu bitirip zamanında derlemeseydin ne yapardın” dedi.

Anladığım kadarıyla bu geçersiz bir argüman çünkü belirli bir kod uzunluğu için "derlemek için kod almak" genellikle sabit sayıda derleme hatası düzeltmeyi içerir ve oldukça sabit bir zaman alır, ki bu sizden sonra yaparsanız aynı olmalıdır. Kodu yazmayı tamamlayın ya da kodlama zamanınızla birleştirirseniz. Eğer bir şey varsa, eksik noktalı virgül aramak için kodunuzu kesmek muhtemelen verimliliğiniz için zararlı olacaktır. Aşırı durumlar dışında, türetilmiş sınıflardaki sanal işlevler, vb. Gibi durumlarda, son vakalar hakkındaki belirsizlikleri denememe rağmen, tecrübeli bir geliştirici tarafından yazılan kodun, zaman zaman yazım hatasını ekleyerek, hatta derlemesini beklemek makul görünüyor. eğer değilse

Başka bir benzer olayda, bir röportajda tamamlanmamış bir kod temeli verildi ve bitirmemi istedi ve çalışması için gerekli değişiklikleri yaptım. Mevcut kodu okuyarak başladım ve birkaç dakika sonra (koda bakmayı bitirmeden önce bile) görüşmeci bana bunun yeterli olduğunu söyledi. Ona ne yapacağını sorduğumda (yani "neyi yanlış yaptım"), derhal derhal kodu almakla başlayacağını söyledi.

Bu neden alakalı bile? Benim düşünceme göre ve deneyimlerime göre, bir kod parçasının derlenip derlenmeyeceği temel olarak rastlantısaldır, noktalı virgüllerin eksik olup olmaması gibi şeyleri içerir ve temel programın doğruluğuyla ilgisi yoktur. (Bana göre, derlemeye odaklanmak, bir makaleyi, dilbilgisini kontrol etmek için prova okumadan yazım denetimi yoluyla yürütmek gibidir.)

Bana bir parça eksik kod verirseniz, yaptığım ilk şey onu okumak olacaktır. Kodun ne yaptığını ve algoritmanın doğru olduğunu anlayana kadar derlemeye bile çalışmam.

Her neyse, bunlar sadece birkaç yeni olay oldu, ama genel olarak birçok geliştiricinin kodlarını yazdıkça derleme hakkında konuştuğunu duydum ve henüz kimse bana bunu yapmanın yararını söyleyemedi. Kodunuzu ilerledikçe test etmenin faydalarını anlıyorum , ancak neden derliyorsunuz?

Öyleyse sorum şu: Kaçırdığım bir şey var mı? Siz ilerledikçe derlemenin bir yararı var mı? Yoksa bu, kodunuzu sık sık derlemeniz gereken yazılım topluluğu tarafından yayılan bir tür efsane midir?

Siz ilerledikçe derlemenin bir yararı var mı?

Var. Size daha kısa bir geri besleme döngüsü sağlar - genel olarak, tasarım yaparken (UI, yazılım yazarken, görsel tasarım vb.) İyi bir şeydir.

Kısa bir geri bildirim döngüsü, düzeltmeleri daha pahalı hale gelmeden önce hataları daha erken düzeltmeniz anlamına gelir.

Örneğinizi ödünç almak için, C benzeri bir dilde kodladığınızı }ve programın ortasında bir yerde unuttuğunuzu söyleyin .

Eğer ifadeyi yazdıktan hemen sonra derlerseniz, derleme hatasını yaptığınızdan ve saniyeler içinde oraya ve daha sonra düzelteceğinize emin olabilirsiniz.

Ancak bunu yapmazsanız, kodu okumak için tam olarak bir yer bulmak }ve emin olmak için iyi bir zaman harcamanız gerekecektir , bir kez düzeltmenin gerçekten amaçlandığı şekilde bir hata bulduğunuzda. Bu kodun bir parçasını bıraktıktan bir süre sonra gerçekleşir. Yazdığınız andaki kadar net olmazdı.

Şimdi, evet, sonuç aynı, ancak derleyicinin size yardım etmek için hazırladığı sözdizimsel konularda çok fazla zaman kaybettiniz - ilerledikçe derlediğiniz zaman çok daha kısa bir süre.

Derleme olduğu , özellikle gibi türleri kapsamlı kullanan dilde, test bir şekilde Haskell'e veya ML . Diğer dillerde, size çok az şey anlatan sözdizimsel bir taramadır.

"Gittiğinizde derleyin" derken bana durumsal bir alışkanlık geliyor. Görüşme yapan kişinin kişisel önyargısından daha sık derleme yapmak için "seğirmek" olduğu için eşit derecede iyi işaretlenmiş olabilirsiniz. Nitpicking gibi geliyor; kimse bir röportaj olduğunu itiraf seviyor aced testi; Maaş müzakerelerinin ölçeklerini belirlemektedir.

Tüm yapı sistemleri hızlı değildir. Ben (C ++) proje üzerinde çalışmış Yap 30 saniye sadece harcayacağı istatistik o inşa veya olmasın için gerekli olup olmadığını belirlemek için 'ting her şey ve en dosyaları değişiklikler yapmış olsaydı inşa etmek birkaç dakika alacaktı. Bunu her 10-15 dakikada bir daha sık yapmakta isteksizdik. Hiç kimse kuşkusuz delikli kartlarınızı almayı ve bunları farklı bir binaya taşıyarak derlemeye başladığında bir fıkra sağlayacak.

Kafanızda eksiksiz bir ünite yaptığınızı ve onaylamanız için hazır olduğunuzda derleyin. İş akışına bağlı olarak dakikada bir veya haftada bir kez.

Öyleyse sorum şu: Kaçırdığım bir şey var mı?

Evet: aklın bir derleyici değil. Bir derleyici saniyede n bağlam anahtarı yapabilirken, kararınız veremez. Zihninizin bir günde yapabileceği bağlam anahtarlarının sayısı, kod tabanına ilişkin deneyim / aşinalık, kodda zihinsel olarak nasıl yerleştiğiniz, kodun ne kadar temiz olduğu, sorunun ne kadar karmaşık olduğu gibi bir dizi faktöre bağlıdır. Ne kadar yorgunsanız, sık sık kesiliyorsanız veya gürültülü bir ortamda vb.

Bir kod tabanını (aynı anda) derlemek, ilk kez ("20 dosya içeren proje" düşünün), sizi düşündüğünüzden bağlam değiştirmeye zorlar (örneğin, "bu değer burada 5'e, ardından for loop blablabla ve karmaşık algoritma geri dönüşünde doğru değeri verir "), düşündüğünüzle tamamen ilgisi olmayan bir derleme problemine (farklı dosya / modül / fonksiyon / ön koşullar / sözdizimi / değişken isimleri, ön koşullar vb.) ).

Bir kerede ne kadar fazla kod derlerseniz, fikrinizi değiştirerek o kadar fazla bağlam yapmanız gerekir. Bu, küçük bir kod tabanı için bir sorun değildir, yazdığınız tüm kodlar bir saat içinde yazdıklarınız olduğunda. Ancak, varolan bir kod tabanında çalışırken, birden çok (ve çoğu kez belgelenmemiş) karşılıklı bağımlılıkla büyük bir sorundur.

Siz ilerledikçe derlemenin bir yararı var mı?

Yaptığınız değişikliklerin etkisi ve yan etkileri üzerinde daha fazla odaklanmanıza izin vermek için fikrinizin yapması gereken bağlam anahtarlarını en aza indirirsiniz. Ayrıca, sizi daha az yorgunlaştırır (ve hatalara daha az eğilimlidir) ve çıktınızın kalitesini artırır (yani, bir dosyayı bir seferde değiştirdiğinizde ve derlerken, on dosyayı derleyip değiştirdiğinizden daha kolay hale getirebilirsiniz).

Çok kısa aralıklarla derlerseniz (derleme işleminin kısa sürecek şekilde optimize edildiği varsayılır) derleme hatalarını "bölgeden" çıkmadan düzeltmek mümkündür.

Yoksa bu, kodunuzu sık sık derlemeniz gereken yazılım topluluğu tarafından yayılan bir tür efsane midir?

Yazılım topluluğu tarafından da yayılır, ancak bunun arkasında iyi sebepler vardır.

Anladığım kadarıyla bu geçersiz bir argüman çünkü belirli bir kod uzunluğu için "derlemek için kod almak" genellikle sabit sayıda derleme hatası düzeltmeyi içerir ve oldukça sabit bir zaman alır.

Orta ila büyük eski kod tabanlarının (yüzlerce veya binlerce kaynak dosya) bakımında (deneyimsiz) deneyiminiz yokmuş gibi geliyor. Bu, bu tutumun (yani “giderken derle”) en çok yardım edeceği yerdir ve bu tür bir alışkanlığı oluşturduğunuz yer burasıdır.

Sizi inceleyen insanların da benzer bir sonuç çıkardıklarını hayal ediyorum ("büyük kod tabanlarında deneyiminiz çok az ya da hiç yok").

Bence burada biraz profesyonel züppe var. Görünüşe göre, "düzenli olarak derleme gereksiniminiz olmadıysa, o zaman karmaşık olan hiçbir şeyle hiç çalışmadınız - gidip biraz daha fazla tecrübe edinin ve tam olarak bizim gibi çalışmayı öğrendiğinizde geri dönün" gibi görünüyor.

Fakat belli ki bunun başka bir yanı var. Bazı projeler derlemek için bir yaş alır. Küçük düzenlemelerden sonra bile derlemek için 30 dakika veya daha uzun süren çerçevelerle çalıştım. Bir başlık dosyasını düzenlemeniz gerekirse, Heaven size yardımcı olur. Tam yeniden derlemeler genellikle bir gecede yapılır ve hatalarınızı yakalamak için derleyiciye güveniyorsanız, kısmi bir yapı sırasında algılanmayacak olan nadir hatalar vardır. Bu şartlar altında her 5 dakikada bir derleme yapmazsınız - tembel hissetmezseniz .

Derleyici mantıksal ya da anlamsal hatalar konusunda size yardımcı olamaz ve sözdizimi hataları gününüzün derlemesinin yarısını harcamanın değerli olmasını önlemek için çok zor değildir. Tabii ki, arada bir yazım hatası yapacaksınız, ancak hem dokunma tipinizi hem de okuyabileceğinizi varsayacağım. Seçme özgürlüğüne sahipseniz, hataları görsel olarak vurgulamak için mizanpajı iyi kullanan bir kodlama stili kullanın; bir daha asla bir küme ayracı, ayraç veya noktalı virgül düşürmeyeceksiniz. Biraz alıştırma yapmak ve çoğunun alıştığından biraz daha fazla disiplin olması gerekiyor, ancak bu mümkün. Bir seferde birkaç saat boyunca, düz bir metin editöründe kod yazabilir ve ilk kez ondan dokuz kereden daha iyi bir şekilde derleyebilirim. Tabii, daha sık derleyebiliyordum, ancak son olarak düzeltmesi daha kolay bir hatam olduğunu hatırlayamıyorum.

Sürekli bir yeniden derleme hayranı değilseniz, iyi bir şirketsiniz. İşte Donald Knuth:

Asıl sorunuza göre, derleme ve “birim testleri” derleme fikri, nadiren, tamamen bilinmeyen bir ortamda kendimi hissettiğimde ve neyin işe yarayıp neyin işe yaramadığı hakkında geri bildirim gerektiğinde bana çok çekici geliyor. Aksi taktirde, hiçbir zaman gerçekleştirmem ve hatta düşünmemem gereken faaliyetlere çok fazla zaman harcanır.

Bunların hepsi ... söyleniyor eğer sen derleme neden olmaz, serbest eylemdir bir bağlamda çalışıyoruz? Evde, kişisel projelerde, her 30 saniyede bir kez ctrl-S'ye ve neredeyse derhal "derleme" kısayoluna, derleyicinin ön ucundan sürekli olarak kodun gerçek zamanlı hata vurgulamasını sağlamak için çalıştığını gösteren bir IDE'ye çarptım. Neden bedava bir öğle yemeği yiyorsun?

İlerledikçe derlemenin yararları var. Ancak görevde kalmanın OK kodlama stratejisi olduğuna katılıyorum.

Artımlı derlemeye en önemli yararı, derlemenin ve test etmenin sona ermesini beklediklerinde birçoğunun aldıkları zihniyettir : sonunda kodun bu noktada çalıştırılmasından daha çok endişeliyiz. Derleyicinin şikayet etmeyi bırakması için "bu braketi eklemeliyiz" ya da "ah, sadece büyük harf kullanmalı" deriz, bu sözdizimi hatasının gizlendiğinin altında yatan anlamsal bir hata olup olmadığını düşünmeden. Gerçekten sözdizimsel hataları genellikle kendilerini anlamsal hatalara yerleştiririm (sohbet doğru değil).

Örnek olarak, bir değişkenin anlamını değiştirdiğimi ve bunun sonucunda adını değiştirdiğimi söyleyin. İsim değişikliği, daha sonra kodda bir sözdizimi hatası oluşturur, ancak sadece düzeltici ismini düzelterek isimlendirirseniz, bu hatanın neden oluştuğunu göz ardı ettim .

Kodunuzu ilerledikçe test etmenin faydalarını anlıyorum, ancak neden derliyorsunuz?

Ancak buna göre derleme yaparken kodunuzu ilerledikçe nasıl test edeceksiniz?

Aşırı durum test odaklı bir gelişmedir (TDD). TDD'nin stratejinizle çalışmadığı açıktır, çünkü TDD son derece kısa yazma testi, derleme (başarısız olmalı), yazma kodu, tekrar derleme, çalışma testi, düzeltme hataları, tekrar derleme, yeniden düzenleme, derleme işlemleri anlamına gelir. -Başka, deneme testi ve benzeri şeyler ...

Yani herkes TDD yapmıyor, en azından her zaman değil (ben de itiraf ediyorum). Mevcut stratejinizle, TDD'yi deneme şansınız hiç olmayacak. Ancak TDD'yi yapmadığınızda bile, kodunuzu daha düzenli bir şekilde test etmek için IMHO son derece yararlıdır - bu, düzenli olarak derlemediğinizde mümkün değildir. Testiniz başarısız olduğunda, hata ayıklamaya çalışıyorsunuz (bu, birkaç dakika önce yazdığınız güzel görünen algoritmanın neden yapmanız gerektiğini düşündüğünüz kadar iyi davranmadığını anlamanıza yardımcı olabilir). Derleme olmadan ne kadar çok kod yazarsanız, test etmeden ne kadar çok kod yazarsanız , problemi çözme zamanının "O (1)" olduğunu tahmin edemediğiniz bir durumda karşılaşmanızın olasılığı daha yüksektir . sen yazdın.

Aslında derleyici hatalarının deneyimli bir geliştirici için önemli olmaması gerektiği konusunda size katılıyorum. Onları tamir etmenin maliyeti zaman içinde endişelenecek kadar önemli ölçüde arttığını sanmıyorum. Tüm derleyici hatalarının düzeltilmesinin bir zorlamadan hemen öncesine kadar ertelenmesi mümkün olsaydı, bunu daha küçük ve daha konsolide bir kesinti sağlayacağı için yapardım.

Ne yazık ki, derleyici hataları bulmak derleyicilerin yaptığı tek şey değildir. Açıkça ifade etme riski altında, programınızı çalıştırmak için derleme yapmak gerekir ve deneyimli geliştiricilerin bile yarattığı daha karmaşık, ince ve ilginç çalışma zamanı hatalarını bulmak için programınızı çalıştırmak gerekir. Ve bu tür böcekler daha zordur ve bu nedenle, hata ayıklamayı daha uzun süre ertelemenizin önüne geçmek için daha zordur, çünkü bunlar birbirlerini inşa edebilir veya maskeleyebilirler.

Ancak, bir görüşme çalışmasında birini, sonuna kadar derlemeyi ertelemek için mutlaka işaretlemem. Görüşme alıştırmaları çok basit olma eğilimindedir ve deneyimli geliştiriciler genellikle sınırlarını bilir. Yazdıklarınız hakkında ne kadar güveniyorsanız, derlemeler arasında o kadar uzun süre devam edersiniz. Bu sadece insan doğası.

Bunun için sizi işaretlememek için, güven, haklı olmak gerekirdi. Derleme yapmadan bir şeyler yazmakla 45 dakika geçirmiş olsaydınız, hata ayıklamak için bir 45 dakika daha istemeniz durumunda, size karşı ağır bir şekilde tartılırdım.

Sık sık derleme ile ilgili önemli olan, gördüğüm kadarıyla diğer cevaplardan eksik olan şey şudur: nadiren derler ve büyük miktarda derleyici hatası alırsanız, bunların çoğu anlamsızdır, çünkü ilk hata tarafından üretilirler. Bunun nedeni yanlış tür, yazım hatası veya bazı bildirimleri geçersiz kılan düz sözdizimi hatası olabilir.

Her zaman ilkini düzeltebilir, tekrar derleyebilir, bir sonrakini düzeltebilir ve böyle devam edebilirsiniz, ancak büyük kod tabanı ile bu yavaş olabilir. Ancak, uzun derleyici hataları listesi ve bağımsız olan nokta hatalarını gözden geçirmeye çalışırsanız, alakasız mesajları okumak ya da ikincil hata noktasından gerçek nedene kadar kod gezinmek için çok zaman harcarsınız.

Düzenli yapılanmalar için devam eden bir başka şey, hiçbir şeyin sizi derlemeniz gereken tam bir kod bloğuna sahip olduğunuzda derlemeye başlamanızı engellememesidir. Derleme devam ederken, derleme bitene kadar yeni düzenlemeleri kaydetmediğiniz sürece, daha fazla kod yazmaya devam edebilirsiniz. Bu yüzden pratik yapmayı beklemeye harcanan zaman yoktur. O zaman yazacağınız her şeyi yazana kadar beklerseniz, hiçbir şey yapmadan derlemeyi beklemeniz gerekir. Bu, temel olarak, modern IDE'lerin arka planda otomatik olarak yapabileceklerinin manuel versiyonudur.

Yeterince deneyimli bir programcı için derleme kodu hiçbir zaman darboğaz değildir.

Bir dili yeterince iyi tanıdığınızda (örneğin, artık sözdizimi hakkında düşünmeniz gerekmediği ve sadece işlevsellik kodu olduğu zaman) basit sözdizimsel hatalar yapma eğiliminde değilsinizdir. Yaptıklarınız genellikle yazım hataları veya kopyala-yapıştır hatalarıdır ve sadece birkaç derleme geçişi ile kısa sürede temizlenebilirler.

Düzenli olarak derleme yapmadan tüm gün kod yazıyorum, sonra derleyeceğim ve sadece hangi sözdizimi hatalarını düzelteceğim ve kodumu yapmadan önce derleyici raporlarını uyarıyorum ( "test edilmesi gerekiyor!" Yazan bir notla ). Birkaç dakika içinde 1.000'den fazla C veya C ++ kod satırını temizleme sorunum yok.

Diğer taraftan hata ayıklama ve test işlemleri bir süre alan şeydir. Mantıksal hatalar her türlü nedenden dolayı ortaya çıkar ve henüz yazmayı unuttuğum alt rutini anlatacağım ya da ikili ağacımın işe yaramadığını, çünkü node->leftne zaman yapıştırıldığımı anlayacağımı fark edecek bir derleyiciyle tanışmadım node->right.

Bir görüşmeci ile savaşmanın genellikle mantıksız olduğunu düşünürken, tarzınızın savunmaya değer olduğunu düşünüyorsanız, yazdığınız kodda hata ayıklamak için kendinize yeterli zaman bıraktığınızı belirtmeniz gerekir . İyi bir programcının ihmal edemediği şey budur.

ps - Kodunuzu okuduğunuzda incelemenizi izlemiş olsaydım sizi anında işe alırdım. Bir profesyonelin yaptığı her zaman budur.

Hayır, yeterli miktarda kod yazana kadar derlemeye devam etmek mantıksız değildir (ve 'yeterli miktar' kodlayıcıya ve yazılan koda bağlıdır).

Örneğin, onu düzeltmek için zamanını alan harika bir kodlayıcıysanız ve çok büyük miktarlarda veya karmaşık kodlar yazmıyorsanız, düzenli olarak derlemek bir israf ve muhtemelen bir dikkat dağıtıcıdır. Eğer değilseniz, her işlevi derlemek iyi bir şey olabilir. Bu kişiye bağlıdır.

Buna bir örnek olarak, JavaScript kodu yazdığınızı düşünün - derleyici yok. Bunun yerine (çoğu JavaScript kodunun doğası göz önüne alındığında) kodlamanın sonuçlarını görmek için programı çalıştırır (veya sayfayı yeniler). Şimdi, mantıklı olmak için yeterince kod yazana kadar bunu yapamazsınız. Sonuç olarak, JavaScript geliştiricileri mümkün olduğu kadar sık ​​"derleme" eğilimindedir, bu da çok sık olması gerekmez.

Kısacası, burada doğru cevap yok - görüşmeci yanlış değil, ama sen de değilsin. Sizi üretken kılan şeyleri yapın ve ne yapmanız gerektiğini söyleyenleri unutun. Kodlama ile ilgili F7düzenli olarak vurma eğiliminiz (ya da vermeme) kesinlikle sonuç olmamaktan çok daha önemli faktörler vardır .

İyi bir geliştirme ortamıyla, gerçekten kodu test etmeyi planlamıyorsanız derlemek için çok az neden görüyorum. Arka plan sözdizimi kontrol araçları, her zaman tam olarak tanımlanmayan birkaç vaka (dosyalar arasında yayılan değişiklikler içeren) olduğunu kabul etmeme rağmen, görüşmecinin hakkında konuştuğu her şeyi yakalar.

Olduğu gibi, aslında bir sonuç üretebilecek en küçük kod birimini derlemeye ve çalıştırmaya çalışacağım. Yarım saat önce, bazı arama sonuçları yazdırmanın bir yolunu yaratıyordum ve daha iyi görünmesi için sonuçta değişiklikler yaparak yarım düzine deneme baskısı yaptım (.pdf'ye, kağıda değil) - 10 başına 1 derleme oranı çizgiler.

Benim düşünceme göre ve deneyimlerime göre, bir kod parçasının derlenip derlenmeyeceği temel olarak rastlantısaldır, noktalı virgüllerin eksik olup olmaması gibi şeyleri içerir ve temel programın doğruluğuyla ilgisi yoktur. (Bana göre, derlemeye odaklanmak, bir makaleyi, dilbilgisini kontrol etmek için prova okumadan yazım denetimi yoluyla yürütmek gibidir.)

Deneyim çok farklı: aldığım derleme hatalarının% 5'inden azı sözdizimi ile ilgili . Dili iyi biliyorum, hata aldığımda çoğunlukla yazım hatası oluyor, anlambilimin doğru olmadığını söylüyor .

Bu nedenle, derleyicimin geri bildirimlerinden mümkün olduğu kadar çabuk faydalandığım için mutluyum. Gerçek zamanlı olarak derleme hatalarının altını çizen bir IDE kullanarak daha önce hiç deneyiminiz oldu mu? Daha kısa bir geri besleme döngüsüne sahip olmak çok değerli olabilir.

Bana bir parça eksik kod verirseniz, yaptığım ilk şey onu okumak olacaktır. Kodun ne yaptığını ve algoritmanın doğru olduğunu anlayana kadar derlemeye bile çalışmam.

Başkası tarafından yazılmış kod üzerinde çalışmanız bekleniyorsa, her şeyi okumak için her zaman vaktiniz olmaz. İyi haber şudur: iyi yazılmış kodun çok düşük bir bağlantısı vardır ve ihtiyaç duyduğunuz kodun yalnızca bir kısmı hakkında bağımsız olarak düşünmenizi sağlamalıdır.

Bu durumlarda henüz okumadığınız kodun doğru olduğunu varsaymanız ve bir sorun olduğunda tembelce araştırmanız gerekir.

Belirli bir kod uzunluğu için "kodun derlenmesi" genellikle sabit bir sayıda derleme hatasının düzeltilmesini içerir ve oldukça sabit bir zaman alır; bu, kodu yazmayı tamamladıktan sonra mı yoksa ara vermeden mi yaptığınızla aynı olmalıdır. kodlama zamanınla.

Bağlam değiştirme beyniniz için maliyetlidir, bu nedenle küçük hataları düzeltmek yazdıklarında düzeltmek daha verimli olabilir.

EDIT: Tüm ekip aynı kaynaklar üzerinde çalışırken, kaynak kontrolü ile bir benzetme yapabilirim. İlerledikçe derlemek, sık sık taahhütte bulunmak gibidir, sonunda her şeyi birleştirmek ve çözmek zorunda kaldığınızda çok fazla acı çekmekten kaçınmaya yardımcı olur.

Metnin altındaki kırmızı çizgiler gibi şeyleri devre dışı bıraktığınızı söylüyorsunuz. Bunu bir e-posta yazarken veya teknik bir belge yazarken de yapıyor musunuz? Ardından, hataları gidermek yerine tüm sayfaları tekrar tekrar prova okumalısınız.

Başka bir avantaj, kodunuz üzerinde çalışırken, her zaman derlemeye veya derlemeye devam etmeye devam ederseniz, birçok semantik tabanlı IDE özelliğinden (güvenli yeniden adlandırma, yeniden düzenleme, sembol kullanımlarını bulma ...) yararlanabilirsiniz. .

Bu özelliklerin nasıl yardımcı olduğunu daha iyi anlamak istiyorsanız, onların faydalarını deneyimlemelerini sağlamayı ve pratik yapmayı deneyebilirsiniz. Ayrıca onlara kullanılır herkesle bazı çifti-programlama yapmaya çalışacağız ve nasıl görebiliyordu onlar onlardan yararlanırlar.

Bunun hakkında biraz daha uzun düşündüm, çünkü görüşmeci ile ilgili çok yanlış bir şey olduğunu ve ne olduğunu tam olarak anlayamadığımı hissettim. İşte sorun: Son yirmi yılda yazdığım herhangi bir kod için, uygulanabilir bir algoritmayı derleyen kodlara dönüştürmek için gereken zaman miktarı minimum düzeyde olmuştur. Bu alandaki verimliliğin herhangi bir kazanımı, toplam gelişim süresi üzerinde tamamen ihmal edilebilir düzeyde çok az etkiye sahiptir ve bu alanda algılanan verimsizliklerden dolayı bir adayı reddeden bir görüşmeci, iyi bir geliştirici yapan şey hakkında hiçbir fikre sahip değildir.

Kodun ne yapılması gerektiği hakkında bilgi toplamaya, kullanılması gereken dış hizmetler hakkında bilgi ve özellikleri toplamaya, bir araya getirilmiş kod yerine düzeltilebilir ve korunabilir bir kod oluşturacak global bir tasarım oluşturmak ve algoritmalar bulmak için çok zaman harcanması gerekir. bu, işe gelinceye kadar birlikte yayan kod yerine çalışma koduna yol açar (açık olarak hiçbir hataya sahip olmayan bir kod veya açık bir hataya sahip olmayan bir kod).

Öyleyse, derleyen küçük bir zaman kodu yazma kodu gelsin.

Ardından, kodun çalıştığından ve kodun çalıştığından ve çalışmaya devam edeceğimizden emin olduğumuzdan emin olmak için daha fazla zaman harcanır. Birim testler yazarak, kodlama ile ve büyük ölçüde iyi tasarlanmış kod ile ilk etapta yapılır.

Bu görüşmeci cevabımda on kelimeyle kapsanan bir şeye odaklandı. Asıl çalışma süresinin yüzde 10'unu veya daha azını temsil eder. Ve bu geliştiricinin güvenilir ve çalışma kodu üretme yeteneği üzerinde neredeyse sıfır etkisi var.

"İlerledikçe derleme" nin avantajı, sürekli geri bildirim almaktır ve doğru yöne itilmeden önce çok yanlış gitme şansınız olmaz. Senin gibi yetenekli bir programcı için, bu büyük bir düşünce değil, ama diğerleri için. Başka bir deyişle, “ilerledikçe derlemek”, davanızda bazı potansiyel verimlilik kayıpları olsa da “maksimum zararı en aza indirmenin” bir yoludur.

Bugünlerde şirketler bitmiş bir ürünle ilgilenmiyor. Başından beri "kontrol altında" olduğunu bilmek istiyorlar. Onlar için, "oraya gitmek eğlencenin yarısıdır."

Diğer cevaplar burada sık derleme için iyi bir savunma monte iş ancak soru etrafında odaklanmıştır beri görüşmeler , bundan böyle açısını mücadele etmek istiyorum.

Görüşmelerde tam tersini yapıyorum: Adaylar derleyici kullanamazlar. Beyaz tahtaya kısa programlar yazarlar ve sonra bunları tartışırız. Derleyiciyi (veya yorumlayıcıyı) çok sayıda geliştiricinin koltuk değneği olarak kullandığını ve bunun çok nadiren derlemekten çok daha büyük bir zaman kaybı olduğunu gördüm. Size çok para teklif ediyorsam ve derleyici olmadan FizzBuzz'ı bile doğru yazamıyorsanız, oyuncak egzersizlerinden 100 kat daha zor olan problemler üzerinde çalışarak asla uzun süre kesmeyeceksiniz. röportajda. Yine de bu basit egzersizler, görüşmenin diğer bölümlerinden daha fazla adayı yok etti.

Mülakatın amacı, adayın ve iş dünyasının karşılıklı uyumunu değerlendirmektir. İyi bir görüşme sorusu, sorunun hedeflerini ve görüşülen kişinin nasıl değerlendirileceğini belirtmelidir. Görüşme yapan kişiye hileli bir soru sormak ve ardından gizli cevabı bilmedikleri için cezalandırmak, görüşmeci veya görüşülen kişiye yardımcı olmaz. Ne yazık ki, çoğu programcı - kıdemli olanlar bile - diğer programcılarla röportaj yapmak için eğitilmemişlerdir, bu yüzden sadece adayları değerlendirmek için etkili teknikler olup olmadıklarına bakılmaksızın, klişelere güvenirler ve görüşme sırasında sordukları aynı soru türlerini sorarlar. ya da değil.

Yaklaşımımın "gerçek yol" olduğunu iddia etmiyorum, ama bana çok iyi hizmet etti. Büyük harfle başlayan birçok yazılım metodolojisi gibi, görüşme için de eşit sayıda "zorunlu" var. Hepsi ranza. Sizin ve işiniz için uygun olanı yapmanız gerekir.

Daha büyük projelerde, birkaç alt rutinde, bu parçaları daha büyük şemada kullanmadan önce test etmek istiyorsunuz, çünkü bazı parçaların zaten çalıştığını biliyorsanız hata ayıklamak daha kolaydır.

Bu küçük parçaları test etmek için derlemeniz gerekir.

Görüşme yapan kişinin bu durumu, bu şekilde tasarlanmamış küçük bir programla karıştırması olabilir.

İkinci görüşme ile ilgili olarak, derlemenin bir yararı, programların ne yaptığını (veya yapmadığını) birkaç saniye içinde gözlemleyebilmenizdir. Oradan kodu okumak ve çabalarınızı ilgili parçalara odaklamak daha kolaydır. Belki de görüşmeci beklediği şey buydu.

Bu gibi bilinmeyen bir kod tabanını baştan sona okumak oldukça verimsiz olabilir (bir derleyici değilsiniz);