Bir meslekte programlama olarak dipte bir yarış mı? [kapalı]

Bana göre programlama endüstrisi en altta bir yarış içinde. Aşağıdakileri uygularsak:

1. En iyi uygulamaları uygulamak için zaman ayırmamak
2. Diğer kişilerin kodunu mümkün olduğunca kullanmak (sorumluluk olarak özel kod)
3. Verimliliği artırmak için giderek daha yüksek seviyeli dilleri kullanmak
4. GUI tabanlı geliştirme, "programlamayı" büyük ölçüde basitleştiren ve insanların kodun arkasındaki sıhhi tesisatı anlamalarını gerektirmeyen "araçlar"

Bu şeyler bana, başka bir ofis çalışanı gibi olma yarışında olduğumuzu gösteriyor. Beceri gerektirmeyen şeylerin (değiştirilmesi kolay), önceden oluşturulacak şeylerin (daha az proje süresi) işveren tarafından çıkarları.

Buradaki amacım şudur: a) Beceri ile işverenin ekonomik çıkarları arasında yanlış hizalama var mı? ve b) varsa, mesleki standartları uygulamak için onu nasıl hafifletirsiniz?

Bence çok keskin bir soru sordun.

GUI kodlama araçlarının oluşturulması, programcıları, robotların montaj hattı işçilerini bir işten çıkardığı kadar işsiz bırakıyor. Bence iş kaybı olsa da, bir sonraki işlerin olduğu yerde de bir değişim var.

Bir görevi yerine getirme teknolojisi değişiyor, ancak görev hala tamamlanmalı: Arabalar sürülmeden önce hala yapılmalı / monte edilmeli; Uygulamanın çalışması için kod / işletme mantığının hala bir araya getirilmesi gerekir.

Teknolojideki değişimler, programcılar için seçenekler sunar: GUI tabanlı programlama veya program GUI araçlarını öğrenin ... veya ... tamamen başka bir şey.

Çalışanların becerileri ile işverenin çıkarları arasında bir yanlış hizalama olabilir, ancak özellikle işveren anlayışlıysa, uzun süre değil. Bu nedenle, hem işverenin hem de çalışanın çıkarları için çıkarlarını gözeterek, çıkarlarına en uygun olanıdır. Fakat bir tanesi kaçınılmaz olarak diğerinin önünde olacak. Umarım sensin (-:

En iyi dileklerimle,

KM

Bahsettiğiniz trendlere bir tane daha ekleyeceğim, ki IMHO bunları açıklar:

Her zamankinden çok daha fazla programcı (ihtiyaç var) var.

Programlama gerektiren veya içeren görevlerin sayısı her geçen gün artmakta ve programcı sayısından daha yüksek bir oranda artmaktadır. Günümüzde ortalama bir arabada birkaç mikroçip var. 5 yıl içerisinde buzdolabınızda ve kızartma makinenizde bir çip olabilir. 10 yılda iç çamaşırın mı? Ve birileri bunları yapabilmek için tüm bu yazılımı üretmeli. Dolayısıyla, ne otomatik hale getirilebilecek olursa olsun otomasyonu yapmak ve "üretkenliği" geliştirmek için mümkün olan her türlü çaba var (ancak tanımlanmıştır). Ve gittikçe daha fazla taze beyin toplanıyor.

Bu, günümüzdeki aktif programcıların çoğunun deneyimsiz ve / veya işlerine hazırlıklı olmadıkları anlamına gelir. Yeterli bir tecrübe seviyesine ulaşmak birkaç yıl alır ve kendinizi orada tutmak için sürekli öğrenme gerekir. Sonuç olarak, programlama işlerinde gittikçe daha fazla zorlanıyor. Fakat onları arayan herkes için hala yeterli zorluk var .

Yukarıdaki şeylerin aleyhine şeytanın avukatı oynayalım:

En iyi uygulamaları uygulamak için zaman ayırmamak

Birçok insan yapmaz, birçok insan yapar. On yıllarca önce, ünite testini ve çevik yaklaşımı keşfettiğimde, meslektaşlarımdan hiçbiri ne olduğu hakkında en ufak bir fikre sahip değildi. Günümüzde üniversitelerde neredeyse standart bir malzeme olduğu için pek çok yeni mezun zaten bunu anladı.

Diğer kişilerin kodunu mümkün olduğunca kullanmak (sorumluluk olarak özel kod)

Neye karşı olarak? Tekerleği yeniden icat etmek? Veya bundan kaçınmak için başkalarının kodunu mu kullanıyorsunuz?

Sorunları çözmek için (çoğunlukla) paramızın ödendiğine dikkat etmenin önemli olduğunu düşünüyorum ve kod yazmanın bir son değil, sadece bunun için bir araç olduğunu . Tek bir kod satırı yazmadan bir problem çözülebilirse, müşteriyi mutlu eder. Özellikle bu şekilde daha güvenilir ve hızlı bir çözüm üretmeyi başarırsak. Bununla bir problem görmüyorum.

Verimliliği artırmak için giderek daha yüksek seviyeli dilleri kullanmak

Meclisteki herşeyi kodlamanın aksine mi? ;-)

GUI tabanlı geliştirme, "programlamayı" büyük ölçüde basitleştiren ve insanların kodun arkasındaki sıhhi tesisatı anlamalarını gerektirmeyen "araçlar"

IMHO herhangi bir araç yanlış kullanılabilir. Bu GUI inşaatçılarının mutlaka mükemmel veya hatta iyi olduklarını söylemek değildir - çoğu (veya en azından bazıları) kendi sınırları dahilinde kullanılabilir. Fakat eğer birisi bu sınırları bilmiyorsa, bu araç veya kullanıcısının sorunu mu?

Genel olarak, (kanıtlayacak kanıtı olmamasına rağmen) delikli kart ve makine kod günlerine geri döndüğüne, kabaca mevcut kodun aynı oranının şu anda olduğu gibi korkunç olduğuna inanıyorum.

• genel kod miktarı ve
• yabancıların şimdiye dek bu kodu görme şansı

çok daha azdı.

Şimdi, İnternet ve Daily WTF ile günden güne en kötü örneklere maruz kalıyoruz. Terörizm ve depremlerle ilgili tüm haberleri izlemek, ünlüleri boşamak ve biraz da bu dünyanın ne kadar tehlikeli ve ahlaksız olduğunu söylemek gibi.

Durumu doğru bir şekilde özetlersin, ancak anlamını tamamen yanlış anlarsın.

Yazılım daha güçlü hale geldikçe, onunla birlikte üstlendiği görevler. Bu nedenle, Access'i kullanabildiğiniz zaman telefon rehberi veritabanı oluşturmak için veritabanı programcısı olmak gerekmeyebilir. Wordpress'e gidebileceğiniz bir blog oluşturmak için bir web programcısı olmanız gerekmeyebilir. Ancak, 15 yıl önce bu şeyleri yapmak için bir programcı olmak gerekliyken, programcıların şimdi yaptığı şey, 15 yıl önce yapılabileceklerden daha büyük bir emirdir.

Bu şekilde koyalım, bundan 100 yıl sonra, facebook veya google kadar karmaşık bir sistem kurmak önemsiz olacak. Onların web sayfalarını konuşmuyorum, veri merkezlerini kastediyorum. Herkes yapabilir. Hala kullandığımız varsayılarak telefonlara yerleştirilecek. ANCAK, yine de programcılar olacak ve bundan böyle 100 yıldan beri bu tür 'önemsiz' sistemler üzerinde çalışmamalarına rağmen, burada hiç kimsenin kapsamını anlamaya başlayamayacağı kadar karmaşık ve karmaşık sistemler üzerinde çalışacaklar. ölçeği. Ve şu anki sistemler gibi bu sistemler ortalama bir ofis çalışanının ulaşamayacağı kadar uzak olacak çünkü programcılar denilen bazı insanlar o dönemin teknolojisini uç noktalarına itmek için uzmanlaşmayı seçecekler.

Şimdi kırk yıl boyunca böyle bir şey okudum ve tahminlerin başında değildim. Daha olmadı.

COBOL, iş programcılarına olan ihtiyacı ortadan kaldırmayı amaçlayan orijinal geliştirme aracıydı ve assembler'den çok daha üst düzeyde bir dildi. Kod kütüphaneleri (kendi kodunu yazmak zorunda kalmaktan kaçınmak için) benzer antikalara sahiptir.

Sıklıkla programlayıcı olmayanların programlama işlerine daha çok benzer şeyler yapmalarını sağlayan bir şeyler ortaya çıkar. 1980'lerin "dördüncü nesil dilleri", Excel gibi fantezi hesap tabloları, rapor üreteçleri ve benzerleri vardı. Düzgün bir şekilde yaptıkları, başarılı olursa, scutwork'ün bir kısmını programlamadan çıkarmak ve programcıların başka, daha ilginç şeyler yapmasını sağlamaktır.

Bu kalıp sonsuza dek sürmeyecek, ancak programlama gerçekten yokuş aşağı gittiğine ikna etmek için teorik argümanlar ve öngörülerden daha fazlasına ihtiyacım olacak.

COBOL'den modern geliştirme araçlarına konu, yanlış bir spesifikasyon alma ve onu kesin ve yararlı bir şeye dönüştürme becerisinin yerini almamasıdır. Programcıların temel yeteneği budur ve neden uzun süredir gitmiyoruz.

Assembly ve FORTRAN programcıları muhtemelen yapılandırılmış programlama ve yaygın tercümanlar resme girerken aynı şeyleri söylediler.

Günün sonunda, yazılım önceden elle yapılan bir şeyi otomatikleştirmek için yaratılmış bir yaratımdır. Ilımlı bir şirketteki bir muhasebe departmanı daha önce düzinelerce insana ihtiyaç duyuyordu, şimdi bütün bu işler bir ya da iki kişinin işi ile gerçekleştirilecekti. Sonuç olarak, kale direkleri taşındı ve şimdi bu ekstra yetenek standardının bir muhasebeciden gelmesini bekliyoruz.

Film yapmak, her zamankinden daha fazla Pixar alır. Bilgisayar hızındaki muazzam artışa rağmen, bununla birlikte animatörler sahnelerinde sürekli artan karmaşıklık ve ayrıntı talep ettiler. Toy Story calibre animasyonu, 1995 yılında olduğu gibi 2010 yılında da kabul edilemez. Araçları geliştikçe yetenekleri ve beklentileri de var.

Sürükle ve bırak veya diğer programlama metodolojileri ortak olduğunda, dünya daha zorlu ve karmaşık problemlere çözüm talep edecek ve bunları çözmek için bu yeni fantezi araçlarını kullanan programcılara ihtiyaç duyacaklar. Kale direkleri hareket edecek.

Hala yapacak çok işim olacağına işaret eden cevapların çoğuyla aynı fikirdeyken, düşünmeniz için farklı bir cevap vereceğim:

Evet öyle ve öyle olmalı

Başkalarının yapamayacağı sorunlara bir çözüm tasarlamak için buradayım. Araç setinde, tasarımımı nasıl uygulayacağımızla ilgili tüm küçük ayrıntılarla başa çıkmak için sorun çözmekten zaman alan bir şey israf.

Daha yüksek bir dile veya daha basit ve daha soyutlanmış bir araca gitmekten korkmamın tek nedeni, bu araçların sık sık benim önümde olan varsayımlar yapması ve istenen uygulamayı elde etmek için varsayımlar üzerinde çalışmak için zamanımı gerektirmesidir.

Çözülecek sorunlardan her zaman daha iyi problemler vardır. Tüm dev zinciri bu kadar basit hale gelse bile, okul öncesi çocuklar onu kullanabildilerse, tasarlanan çözümlerin çoğu, insanların daha iyi bir çözüm için ödeme yapması için yeterince yetersiz ya da yetersiz olacaktı çünkü çoğu insan, tüm son vakalarla ilgili sorunlara doğru çözümü görmekte kötüydü. ve iyi bir çözüm yapmak için düşünmeniz gereken şeyler.

İşlerimiz, sorunları diğerlerinden daha iyi çözmek için, takım zinciri karmaşıklığı, büyük resim görünümünde, yoldan çekildiği ve iyi bir şey inşa etmenize ve inşa etmenize izin verdiği müddetçe çok önemli değildir.

Programlama teknolojileri değişebilse bile, bir yazılım ürününün altında yatan karmaşıklık hala oradadır. Yazılım, diyagramlar veya akış çizelgeleri kullanılarak (veya başka bir 'basit' şekilde) tamamen yazılabilirse, yazılımın tüm karmaşıklığının hala anlaşılması ve ele alınması gerekir. Bu nedenle, işverenlerin, ürünlerini yenilemek veya yeni özellikler eklemek için şirketin ürünlerini tanıyan programcı (lara) sahip olmaları önemlidir. Ve çalışanların bir yazılım ürününü öğrenmesi biraz zaman alabilir.

Rafı ne otomatik hale getirebilir veya çekebildiğiniz önemli değil, paketlenmiş yazılımların çoğu iki kategoriye ayrılır:

1. Kullanımı basit, ancak işletmenin gerçekten ihtiyaç duyduğu şeyle tam olarak uyuşmuyor
2. Son derece özelleştirilebilir, ancak özelleştirmeyi anlamak ve kaldıraç yapmak için bir uzman gerekir

Üçüncüyü unuttum Sanırım standart üretkenlik yazılımı (e-posta, tarayıcı, word proc, vb.). Birinci kategorideki yazılım, yazılım geliştiricilerini raf dışı yazılımı özelleştirmek için işe alır (bu mümkün ise). Bir geliştiriciyi işe alabilirler çünkü içeride ve dışarıda özelleştirilebilir sistemi bilen kişi ya çok aranır (SAP, PeopleSoft, vb.) ya da ölmekte olan bir cinsdir (SAP ve PeopleSoft'a benzeyen herhangi bir sistemi düşünmeyin) aynı pazar penetrasyonuna sahip).

Geliştiricilere her zaman ihtiyaç duyulacaktır. Gördüğüm şey, daha önce elle kullanılan, sıkıcı, tekrarlanan çalışmaların otomatikleştirildiğinin daha fazlası olduğudur (veri erişimi için elle bir O / RM kullanarak veri kodunu yazmayı düşünün). Bu, geliştiricilerin işletmeye daha az çabayla daha fazla değer katmalarını sağlar.

Argümanlarını kabul etmiyorum:

1. En iyi uygulamaları uygulamak için zaman ayırmamak

bunun haricinde.

1. Diğer kişilerin kodunu mümkün olduğunca kullanmak (sorumluluk olarak özel kod)

Kod tekrar kullanımı en iyi uygulamadır. Kullanılan kod test edildi. Tabii ki, birçok kişi tarafından bakımı yapılan ve kullanılan iyi kaynaklardan gelen kodları kullanmalısınız.

1. Verimliliği artırmak için giderek daha yüksek seviyeli dilleri kullanmak

Verimlilik kendi başına fena değil - öyle mi?

1. GUI tabanlı geliştirme, "programlamayı" büyük ölçüde basitleştiren ve insanların kodun arkasındaki sıhhi tesisatı anlamalarını gerektirmeyen "araçlar"

Takım işi yaparsa: Kullanın. Değilse: reddet. Söz tutarsa ​​ve insanların gerçekten kodu anlamalarına gerek yok - aferin! Bunun, sahip olmayan bir söz olduğunu söylüyor gibisin?

(Buradaki sayılar otomatik olarak yanlış yapılır. :))

Görsel programlama, metin tabanlı programlamaya göre daha az geçerli değildir veya küçük harfleri hak ediyor.

Görsel olarak programlama yaparken bazı açıklar ve zorluklar var, ancak göz ardı edildiğinde temel bileşen sıhhi tesisatının göz ardı edilebilecek derecede tehlikeli olması, görsel bileşenler ve daha önemlisi görsel tasarımcılar tarafından tekelleştirilmemiştir. Temel sıhhi tesisatın yok sayılması her türlü gelişme için bir risktir.

Labview'ı deneme şansınız varsa, potansiyeli (hatta Lego NXT ortamında uzmanlaşmış bir değişkeni) görebilirsiniz. Kusurlar veya eksiklikler olmasa da, miras yararları vardır. Görmek inanmaktır.

Programlama uygulamaları yalnızca üretkenliği artırmak ve belirli gelişim türleri (en altına yarışınız) için maliyetleri düşürmekle kalmaz, aynı zamanda uygulama yeteneklerini ve müşteri beklentilerini de arttırır (bu nedenle en üste bir yarış teşvik eder). Goole ve Facebook'un üst düzey teknoloji uzmanlarına ulaşmak için ödedikleri bonuslara tanık olun.

Programlama kadar değişime yönelen varoluş mühendisliği ile ilgilenen başka bir meslek yok. Bir şeyi basitleştirdiğiniz anda, yeni fikirler doğuran yeni sorunlara bir kutu açabilirsiniz.

Bu yüzden, bireysel uygulayıcının kötü uygulamaları, hümanizmden yoksun davranışları ve kötü alışkanlıkları ile yeni zorluklara, fikirlere ve kullanıcı deneyimlerine doğru ilerlememize yardımcı olmak için başkalarının kod ve çözümleri paylaşma çabalarını kirletmem.

Aşağıdakileri uygularsak:

O NE LAN? Bu listenin tutarsız olması mı demek istediniz? Listeler, her öğe için uyarı vermeden geri ve ileri gitmek yerine aynı taraftan gelmelidir. Dolayısıyla listeniz okumalısınız:

Aşağıdakileri uygularsak: