Başka bir deyişle ... Programlama ile ilgili en sık karşılaşılan ve sinir bozucu yanlış anlama nedir?
Hangi yaygın ve uzun süredir devam eden mitleri/yanılgıları buluyorsunuz programcılar için zor/düzeltmek zor.
Lütfen, bunun neden bir efsane olduğunu açıklayın.
Bir programcı olduğunuz için, [kişinin] virüs bulaşmış makinesini nasıl tamir edeceğinizi biliyorsunuz.
İş arama yaparken beni çıldırtan ortak bir İK şey: tüm kodlama becerilerinin dile özgü olduğu varsayımı, komut setlerini aşan bir yazılım mühendisliği uzmanlığı yoktur. Java ve Perl'deki bir başka beş yıllık deneyim), C # kullanan bir projede tamamen işe yaramayacağınız anlamına gelir.
"Evet, bir öğrenme eğrisi var. Ama bundan daha zor geçişler yaptım. Sana bir anlaşma yapacağım, ilk ay için bana% 80 öderim ve eğer olmazsam ... oh , bekleyin, aslında bu konuşmayı yapmıyoruz, çünkü İK maymunuz basitçe uygulamamı sildi. "
Yazmıyorsanız, çalışmıyorsunuzdur.
Zombi boş bakışlarının ve kahve yürüyüşlerinin, kafasında bir şeyler düzenleyen programcılar için gerekli olduğuna inanıyorum.
geç bir projeyi hızlandırabilirsiniz, sadece daha fazla insanı fırlatarak.
Bu yazma yazılımı kolaydır.
Zaman içinde ve bütçe üzerinde çalışan tüm bu projeleri nasıl açıklarsınız ve insanlar (politikacılar, medya vb.) Hala şaşırır ve müşteriler "küçük web sitelerinin" (veya her neyse) aslında 6 birkaç bin dolarlık geliştirme ve maliyetler (pound, Euro, [tercih edilen para birimini ekleyin])
Bulanık ve sürekli değişen gereksinimlerle, bazen herhangi bir yazılımın bitmesinin şaşırtıcı olduğunu düşünüyorum!
Bundan biraz daha karmaşık olduğunu biliyorum;)
Uygulamanın karmaşıklığı doğrudan kullanıcı arayüzünün karmaşıklığıyla orantılıdır. Bu nedenle, bir hafta sonu boyunca Google veya Twitter'ı oluşturabilmelisiniz.
Tüm programcılar matematikte iyidir. :-)
Bilgisayarlarla hacklenen herhangi bir genç çocuk, deneyimli bir çalışma programcısı ile eşdeğerdir (veya daha üstündür).
Benim 14 yaşındaki yeğeni bilgisayarlar ile iyi ve onu çim biçmek için ona 10 $/saat ödüyorum. Bir sonraki FaceBook'u yazmak için neden altı rakam ödedim?
Bu gerçek zamanlı hızlı demektir.
"Paketlerin gerçek zamanlı olarak işlenmesi gerekir." değersizdir ve kötü ikiz ... cevap verir "X'in ne kadar hızlı olması gerekir?" "Gerçek zamanlı" ile muhtemelen değersizdir. ... cahil değil aptalca çevreliyor.
Gerçek zamanlı, basitçe söylemek gerekirse, Y fonksiyonunun her zaman X zaman alacağını ve herhangi bir sapmanın ciddi bir hatayı gösterdiğini ifade eder. X süresi "gerçek zamanlı" olarak tanımlanmaz, altı mikrosaniye veya altı gün olabilir. Yapabileceğiniz belirle fonksiyon Y zaman alacaktır "gerçek zamanlı" olarak tanımlar. Gerçek zamanlı sistemler bu tanım ile belirleyicidir.
Öyleyse kes şunu ..
Neden buggy kodunu yazmak ve daha sonra hataları bulmaya çalışan kodu okumak yerine, ilk seferinde doğru yazmıyorsunuz?
:-) :-) :-) :-)
Üniversiteye gitmediyseniz, bu işe uygun değilsiniz
Bu erken optimizasyon, hiç optimize etmemeniz gerektiği anlamına gelir. Hiç kimse diğer herhangi bir veritabanı tasarım sorunu daha erken optimizasyon olarak tasarım (herhangi bir veritabanı sistemi için kritik) performans düşünmek istedim çünkü daha korkunç kötü veritabanları gördüm. Çöp, bilinen performans katilleri var, onları ilk tercihiniz olarak kullanmayı bırakın.
Başka bir efsane, veritabanını yeniden düzenlemek çok zor. Hayır, ancak etkili bir şekilde yapmak için tasarım aşamasında yeniden düzenleme yapmayı düşünmelisiniz. Ve BTW, bu sinir bozucu tasarım tabanlı performans sorununu ne kadar uzun süre düzeltmek için beklerseniz, o kadar zor olacaktır.
Başka bir kötü mit, veritabanı tasarımı OOP ilkelerini yansıtmalıdır. Hayır, veritabanları OOP prensipleri olmayan kümelerle çalışacak şekilde tasarlanmıştır. Bazı OOP şeyleri korkunç performans sorunlarına neden olurken, diğerleri veritabanı terimleriyle acı saçar.
Son olarak, uygulamada veri bütünlüğünü zorunlu kılmalısınız. Veritabanları uygulamayı geçecek ve uygulama değiştirildiğinde kuralları kaybedecek, çoklu uygulamalar bunlara erişecek ve genellikle uygulamadan geçmeyen şeyleri düzeltmek için doğrudan sorgular çalıştırmaya ihtiyaç duyulacaktır. Hiç iyi veri olan datbase veri bütünlüğünü zorunlu kılan bir veritabanı görmedim.
Bazı efsanevi mutlak en iyi uygulamaların kaynağı olduğunu.
Hiçbir sapma haklı gösterilemez.
Bir şeyi en iyi uygulama olarak tanımladığını iddia eden hiçbir belge sorgulanamaz.
Pazarlamanın bir ton küçük özellik eklemenin, tek ama oldukça ağır bir özellik eklemekten daha az iş olduğunu düşünüyor gibi görünmesi. Bu da muhtemelen "görev değiştirmenin ek yükü olmadığı" yanılgısının daha belirgin bir durumudur.
Bu yorum kodu gerekli değildir veya "iyi kodun yorumlara ihtiyacı yoktur". Bazen karmaşık bir kod parçasının ne yaptığını açıklamanız gerekir. Dahası, kod bölümlerini yorumlamak çok daha etkili bir şekilde okumaya yardımcı olur.
En kötü efsane: Uzun bir süre programlama yapıyorsanız, kolayca Proje Yöneticisi olabilirsiniz.
Ve eğer uzun süredir programlama yapıyorsanız, proje yöneticisi olmalısınız.
Projemizde Java, C # ve C++ dışında bir şey kullanırsak, bunu destekleyecek herhangi bir programcı bulamayacağız.
Java sadece farklı sınıfları olan C++.
Muhtemelen gördüğüm en tehlikeli olan, çünkü çok kolay kabul edildiğinden, hızlı bir şekilde kod yazabilmenin iyi olması ve bu nedenle belirli bir dilde [buraya özellik gir] ne kadar hızlı kodlayabiliyorsanız, dil o kadar iyi olur dır-dir.
Bu, erken optimizasyonun ciddi bir örneğidir, çünkü oluşturmaktan çok daha fazla iş sürdürmek koduna girer. Bu, hızlı bir şekilde yazılması kolay olan koddan daha kolay okunabilen, anlaşılabilen ve hata ayıklanan kodların yazılmasının çok daha önemli olduğu ve okunması kolay kodların kolaylaştırılmasının dil kalitesinin çok daha kullanışlı bir ölçümü olduğu anlamına gelir.
bir programcı olarak en son donanım trendleri, overclock, kasa modu, vb. hakkında her şeyi biliyorsunuz.
İmalat dersleri yazılım geliştirme sürecine uygulanabilir.
Programcılar yapmanın çok zor olduğunu/sadece imkansız olduğunu söylediklerinde, İK tembel ve motivasyonsuz olduklarını düşünüyor
İşletmem için açık kaynaklı bir program olmalı. Sadece indirmek ve benim ihtiyaçlarına Tweak değil.
Birden fazla kişinin bana doğrudan ikili programda veya matematiksel semboller kullanarak programladığımızı düşündükleri konuşma boyunca yarı yolda gerçekleştirmenin nasıl bir şey olduğunu sormuştum.
Bu efsaneyi ortadan kaldırmak isteyip istemediğimi bilmiyorum, bu gerçekten akıllı görünmemi sağlıyor!
Bence en büyük yanılgı, kodu okumak ve anlamak mümkün olmaktan daha kolay bir şekilde yazmak mümkün olmasıdır.
Programlama aynı Montaj hattı işi gibidir. Belirli bir süre (belki de iş arkadaşlarınızla) bir ürün üzerinde çalışıyorsunuz ve sonunda gönderiyorsunuz. Tıpkı bir tuğla ev inşa etmek gibi.
Aksine: Programlama çok fazla yaratıcılık ve planlama içerir. Bu bir sanat. Mason gibi, bir programcı da bir tuğla şekillendirme ile tüm bir katedrali planlama arasındaki farkı bilir.
Bir programı C++ 'ya taşımak otomatik olarak daha hızlı çalışmasını sağlar.
Bir tür görsel tasarımcıya sahip herhangi bir programlama ortamı, iş kullanıcılarının programı "yazabilmelerini" ve gerçek programcılara ihtiyaç duymamasını sağlar.
OOP yeniden kullanımı. Programlamada pazarlanan en büyük yanlıştır.
Sözdizimini öğrenmenin zor kısmı.
2 efsane ortaya çıkarmak istiyorum. Bir çok arkadaşım Java ve JavaScript'in tamamen farklı olduğunu anlamıyor ve bildiğim birçok programcı birden fazla dil olduğunu anlamıyor. sadece programlamaya başlıyordu ve benden biraz yardıma ihtiyacı vardı, 'tabii ki hangi dilde çalıştığını bile bilmiyordu.
Bothkisi de benim için çok önemli.
"1" dışında bir öncelik atamak, görevin asla yapılmayacağı anlamına gelir.
Bir yöneticinin hata izleme aracını öncelikler 1a, 1b, 1c, 1d ve 1e ile özelleştirmemi istedi, böylece her şeyi öncelik 1'in bir varyasyonu olarak atayabilirdi, ancak yine de işi düzenleyebiliriz.
Ve evet, tüm "öncelik 1" sorunlarını aştım. Ancak hala 2-5 öncelikli konulara geçmeden önce, yönetici bu konuların önceliklerini beş öncelik 1 seviyesine yeniden atamamı sağladı.
(Bu efsanenin programlama için spesifik olmadığını, ancak bu konudaki diğer birkaç cevap için doğru olduğunu anlıyorum.)
Bilgisayar yazdığınız kodu anladığı sürece önemli olan budur. Bu nedenle yorum yazmak ve iki harften uzun değişken adları kullanmak zaman kaybıdır. :-(
Klavye formu programlama yeteneği ile ilgilidir. Cidden, lisemdeki öğretmenlerden biri bana "Hızlı yazamıyorsanız hızlı kod yazamazsınız" dedi. Cevabım şöyleydi: "Büyük Amerikan Romanını sadece el yazısı ile yapabilirsem yazabiliyorum."
Prototip programcı:
Bu Macarca gösterim, değişken adlarını, ne tür veriler içerdiği yerine bir türle (int iArraylength = 5; gibi) ön eklediğiniz anlamına gelir (int xcTextfield = getTextfield (). Coord.x;)
"Systems Hungarian gösterimi"! = "Apps Hungarian gösterimi"
Hata ücretsiz yazılım. Daha sonra her programın hala Bugs ile çalışacağını ve tüm oyunun müşteri Gereksinimlerini yerine getirmekle ilgili olduğunu öğrendim.
Herkes tarafından OOP (C #, C++, Java) dilinde yazılmış herhangi bir kodun otomatik olarak Nesneye Yönelik ve "Yeniden Kullanılabilir" olması.
Sadece bir kez benden bir satır kod bloğunu veya bir mimaride miras dışında herhangi bir deseni olmayan bir sınıfı yeniden kullanmam istendi (hatta sayılmaz). Görünüşe göre, kopya yapıştırma OO dili ve OOP kendisi arasındaki farkı bilmeyen herkes için iyi bir kod yeniden kullanımı olarak sayılır).
Sık sık gerçekleşen favori bir TDWTF: Code-Refuse
Bu web uygulamaları "7x24" olabilir.
Herhangi bir iş personeline hangi kesinti süresine izin verildiğini sorun ve her zaman% 100 çalışma süresinde ısrar ediyorlar. Haftada 1 dakikalık kesinti süresinin hala% 99,99 olduğunu ve büyük bir hizmetten daha küçük bir kuruluş için neredeyse ulaşılamaz olduğunu unutmayın.
C/C++ ile yazılmış tüm programlar Java/C # eşdeğeri programlardan daha hızlı yürütülür.
Herhangi bir soruna/soruya tek bir "en iyi" araç/çözüm/cevap olduğunu
En büyük efsane kolay olmasıdır.
Yönetici olan programcılar:
"Üç hafta mı? Geçmişte kodladım, ne kadar zor olabilir?"
Herhangi bir M.Sc. bir programlama kursu ile bir yazılım geliştiricisi olarak işe almak yeterlidir.
Bir programcı olduğunuz için, fotokopi makinesinin nasıl düzeltileceğini bilirsiniz.
Hangi yanlış fikirler uzun zamandır yaygın
Programcılar arasında performans sorunlarının nasıl bulunacağı konusunda çok yaygın bir inanç vardır. Bu onları bulmak için onları ölçmeniz gerekir.
En basit karşı örnek (istenmeyen) sonsuz döngüdür. Tamamen gereksiz olan şeyleri yapmak% 100 zaman alır.
Sorunu nasıl buldun? Bir hata ayıklayıcı altına alıp duraklatın, durdurun veya kesinti yapın. Sonra yığına bakarsınız, çünkü döngü üzerinde bir yerde olduğunu bilirsiniz. Kanunda yakaladınız. Ölçtünüz mü? ya da sadece bulmak?
Bunun sonsuz bir döngü olmadığını varsayalım, gerekli olduğunu düşündüğünüzden daha uzun sürüyor. Gereksiz çalışmanın% 90'dan az,% 90,% 50 veya% 20 gibi olduğunu varsayalım. Aynı fikir. Duraklarsanız, bu yüzde, onu eylemde yakalama şansınızdır. (Yüzde yakalamak için ne olduğunu bilmek zorunda değilsiniz.)
Sadece emin olmak için birkaç kez duraklatabilirsiniz. Bir şey yaptığını görür görmez, iki kadar az sayıda örnekle, daha hızlı bir şeyle değiştirebildiğinizi, Nice hızlandırması için düzeltebilirsiniz. Sadece bu da değil, sadece başka sorunları bulmak daha kolay hale geldi, çünkü zaman daha kısa ve daha büyük bir yüzde alıyorlar. Bu kod çok optimal olana kadar "Kartopu" olabilir.
Tabii ki, sorunu ölçmek istiyorsanız, daha fazla örnek alın, ancak bu bulmak için bir önkoşul değildir.
İnsanlar bana, neyse ki, örnekleme profillerinin bunu daha iyi yapmaktan ziyade yaptıklarını söylüyor. Birçoğu sorunu kendileri için görmektense tartışmayı tercih eder.
Yönetici olmak kodlayıcı olmaktan daha iyidir. Yönetici olmak BORING. Saf yönetime giren herkes, başlamak için programlamayı hiç sevmedi.
Bilgisayarlar ve yazılımlar çalışma sürecini kendi kendine geliştirir.
Programcılar arasında: Delphi öldü, ölüyor ya da yaşam desteği alıyor.
Bir yöneticinin, geliştiricilerinin yazdığı kod hakkında jack-squat bildiğini.
C/C++ adında bir dil var
Ya da diller o kadar yakın ki beceriler birbirinin yerine geçebilir.
Bu yazma yazılımı aslında kod yazmakla ilgilidir.
Birçok kişi JavaScript'in C++ ile benzer olduğunu düşünüyor ve aslında prototip mirasını kullandığını anlamıyor.
Programlama dilleri her zaman değişir.
Bu geçmişte uzun zaman önce olmuş olabilir ...
Ama günümüzde değişiklikler çoğunlukla mevcut kodu kırmamaya çalışan ekstra özellikler.
Programcılar neden hata yazmakta ısrar ediyor? (Asla bir hata raporu doğru yapamaz bir pazarlama + test kişi geliyor).
Bütün hollywood zihniyeti (daha iyi bir isim eksikliği için) bir film/tv dizisindeki bir programcı her konuştuğunda ihtiyacı olan her teknolojiyi eklemesi gerekir ( I bir PHP ön uç ve bir MySQL arka uç !!! 11 ) gerekir ... Ve sonra biraz mantıklı değil elbette.
Eğer bu şekilde konuşsaydım, muhtemelen çıldırmış olurdum.
Bir sorunu tanımlamak için İngilizce'yi (veya ana dilinizi) kullanma:
sorunu gösteren kodun derlenebilir bir örneğini sunmaktan daha yararlıdır.