it-swarm.asia

İşçilik karşılığını veriyor mu?

Olası Kopyalar:
İlk aşamalarda Prototipleme ile Temiz Kod karşılaştırması
Açıkçası Kovboy kodlamasını mı tercih edersin?

Bazı şirketlerde çalıştıktan sonra, yüksek kaliteli, iyi test edilmiş yazılım yazma taahhüdümün, özellikle teknik olmayan geçmişe sahip yöneticiler, sürdürülebilir kodun faydalarını görmediğinde, kariyer gelişimine yol açmayacağını anlamaya başlıyorum, ve teknik borç dağlarını tırmandırırken yüksek üretkenliğe sahip olan geliştiricileri tercih ediyor.

Bunun için iyi yazılmış bir koda bağlı kaldığımı söyledim, çünkü kendimi ödüllendirici buluyorum - iyi bir iş yaptığınızı bildiğinizde aldığınız hissi, bunun için kredilendirilmeyeceğinizi bilmenize rağmen.

Kısmen, temiz kod yazarken farklı teknolojiler ve yaklaşımlar benimseyerek verimlilik açığını kapatabilirim - çözümler arasında dinamik diller, çok dilli programlama ve konfigürasyon üzerinde kongre bulunur.

Ama ikilemim var - işçilik karşılığını veriyor mu?

137
murungu

Deneyimlerime göre, cevap ne yazık ki hayır. Özensiz kesmek için bir işçilik kültürünü zorlamak, nesne yönelimli olarak yazılmış prosedür koduna göre tasarım kalıpları ve eski eski teknoloji ile kalmakta yeni teknolojiyi benimsemek istemem nedeniyle birçok işimi kaybettim. Ben bu seçimleri pişmanlık değil, ama gerçek şu ki geliştirici kardeşlerimizin çok azı işçiliği biliyor veya önemsiyor; Yazılım yazmanın "doğru" yoluna daha az önem verebilecek ya da yıllardır yaptıklarından daha iyi yollar olduğu konusunda tamamen cahil olan daha fazlasımız olduğunu söylemeye cesaret ediyorum. Tabii ki, işçiliğimi düşünerek kendi kodumu yazmaya çalışıyorum ama bu büyük ölçüde nafile bir çaba ve genellikle biraz eklemeye çalıştığınız hiçbir işçiliği izlemeyen bir kodunuz olduğunda acı vericidir. Tuttuğum işler bile, yeni şeyler üzerinde çalışmak yerine küçük hata düzeltmelerine düştüm (çünkü yeni gelişime atandım, "radikal fikirlerimi", yani işçiliği), sonunda bıkkın/bıkkın ve işçiliği anlayan bir şirket bulma umuduyla başka bir şirket ara.

Yazılım işçiliğini bilen tek kişi olan değil veya SOLID ilkelerini veya ORMS/IoC/SOC/vs, çünkü insanlara hayır demeye çalışarak yokuş yukarı savaşmak zorunda değiller, tüm işlevlerinizi bir VB6 Modülü olabilecek dev bir sınıfta toplamanın kötü olduğunu; bin satır için devam eden bir yöntemi olan bir kod dosyasına sahip olmak kötüdür; tüm mantığınızı bir düğmenin olay işleyicisine koymak kötüdür. İşten atılma riski yoktur çünkü takımınızı yeni ve daha iyi şeyler yapmanın yolları hakkında eğitmeye devam edersiniz; kod tabanının uzun ömürlülüğünü ve sürdürülebilirliğini artıracak yollar, sadece şaşkın bakışlarla veya işten çıkarmayla karşılanacaktır çünkü iyi bir şey olan neden bile bilen yalnızca kişisiniz ya da kendinizi geliştirmek için teknik bloglara/podcast'lere abone olan tek kişidir.

Altı yıl içinde bir yazılım geliştiricisi olarak çalıştığımda, aslında işçiliğe önem veren altı şirketten tam olarak bir işim vardı. Diğer her yer faydaları bilmiyor hatta anlamadı - takımdaki diğer insanlara bir şeyler açıklamaya çalışmak bu garip "Ne ...?" sanki söylediğim hiçbir şeyi anlamadılar gibi. Şirketler, uzun vadede bakımı kolaylaştıracak uygun geliştirme tekniklerini teşvik etmekten ziyade, hiçbir şeyi iyileştirmeyen ve yeni bir şey geçirmenin farkında bile olmayı reddeden tembel geliştiricileri tutmayı tercih ederdi, bunun yerine uzun süre fedakarlık yapmaya çok istekli olurlar. kısa vadeli dönem. Her seferinde.

Özetlemek gerekirse: Zanaatkarlık ancak tüm ekip onu kucaklarsa ödenecektir. Bir kişi işçiliği kucaklar ve diğerleri ne gerektirdiğini bilmiyorsa, hiç ödemez ve muhtemelen size zarar verir.

ZEYILNAME

Sadece benim açımdan kanıtlamak için, bunu Haziran 2011'de yazdım. Temmuz '12'de çalıştığım şirkette tam olarak burada belirtilen nedenlerden dolayı geliştirici olarak izin verdim: Bu 13 aylık süre boyunca, bizi zorlamaya çalışıyordum sürdürülemez olan saçmalıkları kesmek yerine işçiliğin bazı özelliklerini kullanmaya doğru (bir örnek vermek gerekirse, dahili CRM yazılımımızı dahili olarak sahip olduğumuz ve yeniden başlatılması gereken 70 kadar kullanıcıyı destekleyebildiği diğer şirketlere satmaya çalışıyorduk çökme nedeniyle günde birkaç kez). Bir "kıdemli" geliştirici çabalarımı yolun her adımında engelledi ve teknik olmayan CTO, iyi kalitenin bir amaç olduğunu bizzat bana söylemesine rağmen her zaman onunla taraf tuttu ve benimle konferans salonuna getirilmemle sonuçlandı. CTO ve HR, my geliştirme becerilerinin "güçlü noktam değil" olduğunu ve şirketin itmeye çalıştığımdan farklı bir yöne (yani, böyle şeyler olan bir ortam) gitmek istediği söylenecek kod incelemeleri ve kod kuralları ve işçilik gibi) ve hizmetlerimin artık gerekli olmadığını.

Başka bir iş bulmam yaklaşık 5 ay sürdü ve bu iş bazı SQL'lerin ötesinde herhangi bir gelişme yapmıyor; Tüm gün boyunca tescilli uygulamalarla çalışıyorum ve tekrar geliştirme yapma arzum ve arzum tamamen gitti, çünkü her zaman yukarıdaki gibi senaryolardan bıktım. Son zamanlarda iki iş görüşmesi yaptım ve daha sonra bu pozisyon için düşünülmediğim (eski "Başka bir adayla gittik" mazereti) çünkü bence şirketler vizyonlarında "gemide olmayacağımı hissettiler" yazılımın "büyük ölçüde, kısmen, iyi tasarım ilkelerine uyma ve yazılım işçiliğine bağlı kalmaya olan hevesime.

İki yıl önce söylediklerimi tekrarlamak için: Çoğu durumda, en azından tecrübelerimden, işçiliği, başka kimse hakkında bir lanet vermezse, işten çıkarılmanıza veya işten çıkarılmanıza neden olur ve çoğu şirket o; çoğu şirket bunun ne olduğunu bile bilmiyor. İyi bir tasarımdan veya ORM'ler veya SOLID ilkelerinden veya bunun gibi bir şeyden her bahsettiğimde, boş bakışları ve kendimi ayağından vurduğum bu batma hissini görmeye alışkınım çünkü benimle röportaj yapan adamın bu şeylerin ne olduğu hakkında hiçbir fikri yok Ne yazık ki, bu batma hissinin her seferinde doğru olduğu kanıtlanmıştır.

80
Wayne Molina

İşte düşünmek için bazı sayılar :

  • 2000 yılında, araştırmalar, yazılım sistemlerinin toplam maliyetinin% 90'ının bakım ve evrime harcandığını bulmuştur. Genel olarak, araştırmalar bir yazılım sisteminin maliyetinin en az% 50'sinin bakımda olduğunu bulmuştur.
  • Yalnızca ABD'de yıllık bakım maliyetleri 70 milyar dolara yaklaşıyor.

Projenin başlangıcından sistem ömrünün sonuna ulaşana kadar iyi mühendislik ilkelerini takip etmek için zaman harcayarak, bu rakamlar azaltılabilir, bu da kuruluşunuzun alt çizgisi için iyidir. Burada, gelecekteki geliştiriciler için etkili teknik belgeler üretmekten iyi yazılmış kod ve testler göndermeye kadar birçok yön vardır. Şimdi daha iyi hale getirmek için biraz fazla zaman harcayabilirsiniz, ancak yol boyunca bakım aşamalarında ödeyecek.

63
Thomas Owens

İşçilik karşılığını veriyor mu? Öyle, ama bir sonraki seviyeye taşımanız gerekiyor.

Kendi şirketinizi kurun ve rekabeti aşan bir ürün sunun. O zaman iyi çalışmalarınızın tüm sonuçlarını kendi müşterilerinizle birlikte vereceksiniz.

Çalışan işlerin çoğunda insanlar tanıma çabası içindedir ve asla bulamazlar. Bu tanıma geldiği birçok durumda, ancak daha sonra kişi bir sonraki yere taşındığında gerçekleşir. Sonra iyi kelimelerle hatırlanacaksınız, ancak etkili bir şekilde ölüm sonrası.

31
user8685

Deneyimlerime göre, çoğu programcı "işçilik" hakkında konuştuğunda, genellikle gelecekteki özellikleri işlemek için önceden tasarlanmış aşırı tasarlanmış kod anlamına gelir. "Yeterince iyi" kavramı genellikle düşük kalite ile karıştırılır ve "zanaatkarlık" ın tersi olarak kabul edilir.

Aksine, en iyi hazırlanmış programlar basit ve doğrudantır, yapmaları gerekeni yapmak için yeterli kod içermezler ve özensiz programlardan daha kolay ve hızlı yazılır ve test edilir. Zanaatkârların zamanını alan ve özensiz programcıdan daha yavaş hale getiren, asla gelmeyecek bir gelecek için akıllı numaralar ve planlama.

28
Dave

İşte ekibimin bir zamanlar sahip olduğu bir seçim. Çalıştığım şirket yılda 10 milyonu aştı. Katıldığım bölüm 500 bin/ay kaybediyordu, işletme patronların evindeki bir güvenlikle finanse edildi.

Seçim 1. En iyi uygulama. Her şey ..... sahibi iflas etmiş olurdu.

Seçim 2. 10 hafta içinde büyük fuar. 8 geliştirici, savaş modu. Tasarım yok, doküman yok, test yok. Sahibi 3 yıl sonra sattı ve bölümü 200 milyonu aşan kişisel banka hesabına 50 Milyon koydu. (ne heyecan verici bir yolculuktu)

Kod, herhangi bir yazılım standardına göre ve açıkça, saçmalık, belgesiz, sürdürülemez ve okunamayan bir ifadeydi. Ancak (şaşırtıcı bir şekilde benim için bile) güvenilirdi. Herhangi bir business standardına göre, kod sitem ötesinde idi.

Bugüne kadarki kariyerimin en önemli özelliği, "Kepçeler çok para kazandıran ve bununla gurur duyan boktan bir kod yazmak, çünkü tam olarak yapmam için bana ne ödeme yaptım."

(Şeytanları burada biraz savunuyorum oynuyorum):
Çok fazla yazılım geliştiricisi faturaları kimin ödediğini ve ne yapmaları gerektiğini unutuyor ve "usta işçiliği" ve "en iyi uygulamaları" aşırı mühendis için bir bahane olarak kullanıyor.

Gördüğüm her BP savunucusu a) Satıcı veya b) Akademisyendir. Bir BP'nin nadiren yayınlanan BP hakkındaki görüşünü görürsünüz ve nadiren Sermaye faydaları, zaman maliyeti, fırsat maliyeti vb.

27
mattnz

İşçilik, bakım modundayken yeni bir ürünü hızlı bir şekilde kapıdan çıkarmaya çalışmak yerine işe yarar.
Birçok ürün hiçbir zaman bu aşamaya gelmediği veya bakım sözleşmesi yaptıklarında, orijinalini oluşturan şirketten farklı bir şirkete verildikleri takdirde, kendi işçiliğinizin faydalarını asla doğrudan elde edemezsiniz, ancak diğerleri iyi olabilir yıllar sonra bir iş görüşmesi sırasında sizinle ne zaman buluşursa ve buluşursa, özellikle iğrenç bir yapıda isminizi hatırlayın.

15
jwenting

Bazı cevaplara katılıyorum ve bazılarına katılmıyorum. Seviyorum @ Thomas Owens bakımla ilgili sayısal verilere bağlantı. Gerçekten evde ne kadar bakım olduğu ve biraz işçilikle ne kadar zaman/para kazandırabileceğiniz noktasını yönlendirir.

Birkaç kişi işçiliğin daha sonra, ancak daha sonra ödediğini söyledi. Kesinlikle daha sonra karşılığını verir. Ya iyi kodunuzu kendiniz koruyup kendinize zaman/paradan tasarruf edersiniz ya da kodunuzu her gördüklerinde ve kodunu korumanın ne kadar kolay olduğunu gördüğünüzde sıcak bulanık kalp şeklinde mutlu düşünceler gönderen birisine iletirsiniz. .

Bazıları şimdi bunun işe yaramadığını söyledi. Bu ifadeye kesinlikle katılmıyorum. Değişimin hızla gerçekleştiği çeşitli ortamlarda çalıştım. Bazı durumlarda (bir film alıntılamak için) "ağız dolusu arasında sizi yakalar". Sağlam bir çerçevede iyi hazırlanmış, okunabilir, yapılandırılmış bir kodunuz varsa, bu değişiklikler geldiğinde bunlarla başa çıkmak çok daha kolaydır. Şahsen, herhangi bir proje için iyi bir omurga yapısına sahip olmanın, işletme kararsız olduğu veya müşterinin ihtiyaçlarının hızla geliştiği için gereksinim değişikliklerini azaltmaya yardımcı olduğunu buldum.

Aynı şekilde, yakın zamanda projesine iyi bir bel kemiği olmayan ve düzenli olarak sürdürülemez bir kod yazan bir meslektaşla ilgili bir duruma tanık oldum. Gereksinimler onun üzerinde değiştiğinde, çalışmalarının çoğunu "formüle geri döndürmek" ve başlangıçta tekrar başlamak zorunda kaldı.

12
Joel Etherton

Kısa cevap -

Büyük organizasyonlarda - yüksek şans.

Daha küçük organizasyonlarda veya solo giderseniz (işçiliğinizi ürün veya hizmet olarak sunar) - yüksek şans.

9
amol

Zanaatkarlık ödüyor, ancak daha sonraya kadar değil.

Sorun şu ki, BT ile ilgili kuruluşların çoğu genç ve henüz kapsam yazılımının uzun süre yaşaması beklendiğini fark edebilmek için zaman ve bunu yapabilmek için iyi inşa edilmesi gerekiyor bu yüzden değişiklikler gerektiğinde iğrenç masraflar olmadan düzgün bir şekilde.

Bu, bir organizasyonda bir iş bulmanız gerektiği anlamına gelir bu gerçekleşmenin yapıldığı yerde ve buna göre uyarlanmış çalışma şekli. Değilse, çabalarınız takdir edilmeyecektir ki bu çok tatmin edici değildir.

7
user1249

Yazılımınızda bir hata bulunduğunda büyük bir utanç hissediyor musunuz?

Mevcut projeniz üzerinde çalışmak yerine hataları her zaman düzeltmek için eski projelerinize geri dönmek istiyor musunuz?

Geleceğin geliştiricilerinin bir hatayı düzeltmek yerine kodunuzu yeniden yazmasını ister misiniz?

Çoğu yönetici zaman içinde iyi geliştiricilerin kim olduğunu görür. Bu geliştiriciler daha görünür ve genellikle daha ilginç projelere sahip olma eğilimindedir. Kariyer gelişimi, mesleki gelişim ile ilgili gerçek çalışmalardan daha fazla olma eğilimindedir. Kariyer ilerlemenin sertifika almasını istiyorsanız, iş sınıflarına gidin, normal kapsamınızın dışındaki projelere dahil olma fırsatlarını arayın. İşinizi yaptığınızda maaş ödülü kazanırsınız. Ötesinde, ilerlemeyi görmeye başlarsınız.

6
SoylentGray

Bu, zanaatkâr olma tekniğiyle değil, zanaatkâr zanaatkârla ilgili. Leonardo kendine petrol boyasında sorun yaşamaya değip değmeyeceğini sorar mı? Uzman bir marangoz, yaptığı bir mobilya parçasının her bir parçasını dikkatlice zımparalaması gerekip gerekmediğini sorar mı?

Hayır, biz zanaatkârız ve yaptığımız da bu. İşleri farklı bir şekilde yapmak doğamıza aykırı olacaktır ve "minimum çaba gerektirir" yolunda ilerlemeye başladığınızda, işte gurur ve sürekli iyileştirme dürtüsünü kaybedersiniz.

Bununla birlikte, göz önünde bulundurmanız gereken pratik şeyler vardır, ancak başka birine göstermek için utanacağınız hiçbir şeyi asla yapmayın.

5
Homde

İşçilik ödüyor mu ??

Evet, ancak herkes için eşit olarak ödemez.

  • Kod tabanı üzerinde nihai sorumluluğu üstlenen lider geliştirici veya geliştirme yöneticisi için ödeme yapar.
  • Kod tabanındaki dar alanında değişiklik yapması gereken geliştiricinin karşılığını verir.
  • Geliştirmenin bir hata düzeltmesi yapması veya değiştirmesi veya kesmesi gerektiğinde iş için ödeme yapar.
  • Ancak, saldırgan, inatçı bir son teslim tarihine uymak zorunda olan geliştirici, yönetici veya işletme için değil ödemektedir.

İki Yorum:

  • Bir geliştirici olarak, kodunuzu değiştirmeniz ve desteklemeniz isteneceği için, "işçilik" yolunu büyük ölçüde desteklemelisiniz.
  • Bir sonraki işinizi seçerken, çalışma ortamının "işçilik" yolunu destekleyip desteklemediğini belirlemeye çalışın.
    • Değilse, her zaman hacky kodundan ortaya çıkacak sorunu telafi etmelisiniz.
1
Jim G.

Ürün sevkiyatında çalışan bir yazılım mühendisi olarak, şirkete birkaç katkınız vardır:

  • Şirketi onlara maliyet daha fazla para = bu yıl.

  • Şirketi onlara maliyet daha fazla para kazanmak gelecek yıl.

Hızlı kod yazmak ilkine nasıl ulaştığınızdır; kodun kalıcı olarak yazılması, ikincisini nasıl elde ettiğinizdir. Siz ve iş temsilciniz (ticari çıkarları temsil eden diğer kişi yöneticisi) yapılanlara öncelik vermek için birlikte çalışmalısınız.

Deneyimlerim kod asla ölmez ve iyi yorumlanmış ve modüler kod yazmak çok hızlı bir şekilde zaman içinde karşılığını verir.

1
Paul Nathan

Bazı şirketler, müşterileri yıllarca bakım yapmaktan kurtarırlar, bu nedenle, asgari düzeyde olan ve bunu sürdürmek çok uzun zaman alan hızlı 1.0 ürünler sunmak onların çıkarınadır.

Dahası, bu tür kan emiciler için, demo komut dosyasından farklı ilk etkileşimde işler bozulduğunda bakım maliyetlerini haklı çıkarmak her şeyin yolunda gitmesinden daha kolaydır.

Belki de bu tür bir şirket haline geldi, bu yüzden şirket kültürü gerçekten de işçiliği teşvik etmiyor.

1
wildpeaks

Geliştiricinin iyi kod yazma yeteneğine sahip olduğunu ve bu nedenle sürdürülemeyen kod yazma ile değil arasında bir seçim olduğunu varsayacağım.

Sıkı bir son tarihiniz var mı?

Evet, hallet. Lansmanı geciktiren kişi olmak istemezsiniz.

Hayır ise: bencil ya da bencilci misiniz?

Hayır - iyi kod yazın, onunla temas eden herkes için iyidir.

Evet ise: kod incelemesinin yapıldığı bir durumda mısınız?

Evet - korunabilir kod yazın, aksi takdirde akranlarınızın ve patronunuzun işinizle ilgili gördüğü şey kalitesiz olmasıdır.

Hayır - size kalmış, ancak bir çözüme ne kadar çabuk ulaşırsanız, başka şeyler yapmak için o kadar fazla zamanınız olur.

Hayır ise, yazdığınız kodu koruyacağınız bir durumda mısınız?

Evet - kötü kod yazın. Sonra onu düzeltme ve bir kahraman gibi görünme şansına sahip olursun. İnsanlar mutlu olacak çünkü bir süre boyunca hayatlarını kolaylaştırıyorsun. Hepsini birden yaparsanız, sizi unutabilirler. Bu, bonus ve promosyon şansınızı artıracaktır.

Hayır ise koruyucularla veya aynı bölümde çalışacak mısınız ??

Evet - muhtemelen iyi kod yazmak en iyisidir, çünkü işiniz için bir övgü kaynağı olacaklar ya da en kötü sessizlikte.

Hayır - Kodunuzu yazın ve devam edin. Ne kadar kötü olduğu önemli değil, başka biri düzeltebilir.

1
Matt Ellen

Daha iyi ödenen tüccarlar. En önemli şey işin yapılmasıdır. Kullanıcı, kullanıcı deneyimini etkilemeyen teknik ayrıntıları önemsemez.

Kod yazarken bazen sanatçı ustadan daha iyidir. Esnaf sadece kitaplarda anlatıldığı gibi çalışmalarını yaparken, sanatçılar oturur ve soruna çözüm getirir.

Ayrıca, 'yapılması gerektiği gibi' bir şey yapmanın genellikle sürdürmek için daha yüksek teknik beceriler gerektiren bir kod yazdığınızı unutmayın. Şirket iyi (ve dolayısıyla pahalı) bir programcı tarafından iyi bir kod yazma 'ucuz işgücü' ne dayandığında, bu temel anlamak için daha fazla bir şey gerektirir, en uygun çözüm değildir.

0
Danubian Sailor