Programlamada zararlı ayarlamalar

Merak ediyorum, programlamada ne tür bir cazibe projenizde gerçekten zararlı olduğu ortaya çıktı?

Mesela bir şeyi yapma dürtüsünü hissettiğinizde ve bunun projeye fayda sağlayacağına inanıyorsanız ya da başka bir şey olduğuna inandırmak için kendinizi kandırıyorsunuz ve bir hafta sonra gerçek sorunları çözmediğinizi, bunun yerine yenilerini yarattığınızı veya En iyi durumda, iç canavarınızı gözle görülür bir etkisi olmadan memnun etti.

Şahsen ben kötü kod kırıcı değil çok zor buluyorum. Birçok kötü eski kodla çalışıyorum ve yeniden yapılandırmamın hiçbir şeyi bozmadığına dair hiçbir test yapmadığımda dokunmamaya çalışmak için derin nefesler alıyor.

Kullanıcı arayüzünde benim için bir başka şeytan, tam anlamıyla, UI düzenini değiştirmek için saatler harcayabilirim çünkü yapmaktan zevk alıyorum. Bazen kendime kullanılabilirlik üzerinde çalıştığımı söylüyorum, ama gerçek şu ki sadece etrafta hareket etmeyi seviyorum.

Programcılığın şeytanları neler ve onlardan nasıl kaçınıyorsunuz?

Erken genelleme benim büyük böcekimdir; Sorunu ilk önce ele almak ve genel dava için çözülmesi gereken bir gerçek var olana kadar beklemek yerine, her zaman genel davanın önüne çıkarım ve olması gerekenden daha karmaşık bir ton kod yazarım.

Güncelleme:

Ayrıntılı bir açıklama için " Sin # 1 - Erken Genelleme " bölümüne bakınız.

“Buna geri dönüp daha sonra düzelteceğiz. Şimdi çalışmasına ihtiyacımız var!”

Son başvuru tarihi çok uzak, yapmak için fazlasıyla zamanım var, neden internette gezinmek için biraz zaman harcamıyorsunuz?

“Bu sadece çöpe atılmış kavram kanıtı kodu. Bundan hoşlandıklarında, gerçekten iyi olacağım.”

1. Üstlenmeden yayınlanmadan önce birkaç gün kodunun bir kısmını.
2. İnternet: En büyük dikkat dağıtıcı şey.
3. Yeni teknoloji : Ellerimi yeni teknolojiden uzak tutamıyorum.
4. Optimize et: Optimize et, Optimize et. .. ve daha fazlası Optimize Et
5. Mükemmellik : Koddan asla tatmin olmadım.
6. TODO: Asla yapılmayacak zaman todos.
7. Zaman tahmini: Pek çok Başbakan bunu "tahmin" olarak kabul etmiyor. Gerçek olarak kabul ediyorlar.
8. Sözler: Çok fazla söz vermek.

Mevcut çerçeveler ve kütüphaneler olduğunda, her şeyi şirket içinde inşa etmeye çalışmak için düşen av.

Tekrarlayan şeytanlarım: Erken optimizasyon ve mühendislik.

Ve hala onlardan% 100 kaçınamıyorum ...

Aşırı iyimser tahminler

Yöneticiniz size bakarken ve yanma hissinin bağırsaklarınızın söylediğinden daha düşük bir tahminde bulunmadığını hissettiğinizde ... yapmayın!

Sonuçta, bağırsaklarınız muhtemelen çok düşük!

Projenizde bir teknoloji / araç / dil kullanmak, tamamen yeni öğrendiğiniz için.

Ne kadar iyi bir geliştirici olduğunuzu kanıtlamaya çalışmak için.

Yazdığınız kodu kendiniz olarak kabul etmek için.

Biraz ara verip stackoverflow.com; 'a bakacağım;)

En kötü günaha:

Ah, peki .. Sanırım küçük bir kirli numara / kesmek / düzeltmek zarar vermez.

Tahmin et ne oldu, acıtıyor. :)

Bir kod çözmenin bir problemi çözmenin son çare olduğunu unutmak .

Özellik Sürünme

Bir plan yapın, ona bağlı kalın ve dağıtın. Ve sonra geri dönüp insanlar için soruyorsunuz şeyler ekleyin.

Bunu tekrar ve tekrar gördüm. Otur, tasarımını yap ve kodlamaya başla. Kullanıcılar, favori özelliklerinin "eksik" olduğu konusunda kafamın karıştığını saçma duyuyorlar ve bunun için lobicilik yapmaya başlıyorlar. Patronunuz onu 11. saatte eklemenizi talep ediyor, konuşlandırmayı kirletiyor, her yere böcek sokuyor ve 3 ay sonra, herkes yerleştikten sonra, sizden kaldırmanız isteniyor, çünkü kimse neden koyduğunuzu çözemiyor ilk etapta o boktan retro özelliği! Tasarımın geri kalanının anlamsız yaptığını söyleyemez miydin?

1. Daha fazla özellik ekle

2. Rekabet bu özelliğe sahiptir. Dolayısıyla bu bir zorunluluktur, dolayısıyla strateji, konumlandırma, vb. Analiz etmekten daha fazla programlama özelliği olmalıdır.

3. Yarışma bu özelliğe sahip DEĞİLDİR. Yani bu farklılaşan bir özelliktir, dolayısıyla strateji, konumlandırma, vb. Analiz etmekten daha fazla programlamadır.

4. Bir iş problemini daha fazla programlama ile çözme. örneğin, web sitenizin barındırıldığı linux sunucusunu yönetme konusunda daha fazla uzmanlık, daha fazla özellik programlama yoluyla elde edilemez. Bazen her şeyi C # .Net'e yeniden kodlamak yerine, sorunu nasıl çözeceğinizi öğrenmek zorundasınız.

5. Pazarlama problemini daha fazla programlama ile çözme. örneğin, Seth Godin’in mor inek kavramını kötüye kullanmak, dolaylı olarak bir “mor inek” yapmak için ürününüze daha fazla özellik programlayarak bir pazarlama problemini çözüyorsunuz. Bazen, sadece mutant bir canavar.

6. Bu senaryoyu yazarken harcadığınız zamanın gerçekten önemli şeyleri programlamak yerine gelecekte saatlerce geri kazanılacağını savunarak kendinize daha fazla programlama yaparak verimlilik sorununu çözme

7. Kodlamayı planlıyor ancak henüz kodlamıyorsunuz çünkü “doğru yapmak” istiyorsunuz

8. Kirli bir sürümü kodlamak ve "daha sonra daha iyi hale getirecek" ancak bir daha "daha iyi yapmak için" geri dönmeyeceğine söz vermek

9. Bir mockup veya site haritası yapmamak, çünkü "çok zahmetli". Sadece rakiplerin makbuz sayfalarını ve "sonradan" serbest çizim site haritasını çizerim. Ve sonra doğrudan aklımda gördüğüm ilk sayfayı programlamaya gir.

İtiraf: Kişisel olarak 1, 3, 7, 8 hatalar yaptım. Ayrıca 2, 4, 5, 6 da yaptım ama çoğu zaman yapmadığım için kendimi kandırdım.

Şu anda 9 remedyim.

EDIT Sorunun çözüm getirmemizi gerektirdiğini anlamadı.

1) Daha fazla özellik ekleyin Sadece yapma. İşletmeniz, pazarlamanız, kurucularınız, danışmanlarınız vb. İle çalışın ve başvurunuzu sadece 1 şeye soyun.

Twitter, Groupon , vb. Şeyleri nasıl sıyrtıklarını , başarılarını sağlayan tek bir şeyi nasıl okuduklarını okuyun .

Eğer sadece büyük şirketler kurmak istiyorsanız işe yarayacağını düşünüyorsanız, tekrar düşünün. Bu hat için Ctrl + F "Ben yazılım eklemek daha fazla özellik, daha kötü satar. (Bu çoğu yazılım geliştiricilere, söylemek, son derece unintuitive gereksiz olduğunu.)" Bölümünde bu bağlantı

2) Yarışma bu özelliğe sahiptir. Yani bu bir zorunluluk olmalı

1. çözüme bakın

3) Yarışma bu özelliğe sahip DEĞİLDİR. Yani bu farklı bir özellik

1. çözüme bakın

4) Bir iş problemini daha fazla programlama ile çözme.

Size öğretmek, danışmanlık yapmak veya sizin için yapmak için birini işe almanız gerekiyorsa ve nasıl yaptığını belgeleyin, böylece bir dahaki sefere kendiniz yapabilirsiniz. SADECE YAP!! Kodu yeniden yazmayın, GO'yu geçmeyin, $ 200 biriktirmeyin.

5) Bir pazarlama problemini daha fazla programlama ile çözme.

İnsanlar ne sattığınızı anlamıyorsa, bu bir pazarlama sorunudur. Solüsyon 1'e dönün ve dönün.

6) Verimlilik problemini daha fazla programlama ile çözme

Bekle.

Verimliliğinizin, 2 haftadan daha uzun bir süre boyunca belirli bir üretkenlik probleminden muzdarip olduğunu ve bunun 2 hafta daha makul bir şekilde gerçekleşeceğini hissedene kadar bekleyin.

Şimdi, bu sorunu çözmek için bir komut dosyasını programlamak için harcanan zamanı değerlendirin. En kötü tahmininizi almayı ve 2 ile çarpmayı unutmayın.

Tahmininizi saat başı ücretinizle çarpın.

Şimdi alternatif çözümleri inceleyin: dış kaynak kullanımı, kullanıma hazır bir çözüm satın alın, bu konuda hiçbir şey yapmayın, vb.

En uygun maliyetli çözümü seçin.

Bağlı kal.

7) Kodlamayı planlıyor ancak henüz kodlamıyor çünkü "doğru yapmak" istiyorsun

Git egzersiz yap. Kıçınızı motive edecek ve hareket etmeyi planlamanızı sağlayacak endorfinlerin acelesini hissedeceksiniz. Bunu biliyorum çünkü sadece 5x5 tezgah baskısı ve 5x5 ağız kavgası yaptım.

8) Kirli bir sürümü kodlamak ve "daha sonra daha iyi hale getirecek" ancak hiçbir zaman "daha iyi yapmak" için geri dönmeyeceğine söz vermek

GTD’de bir gıdıklama dosya sistemi kurun. ve agresif takip. Kendinize ve başkalarına verilen tüm sözleri takip edin.

9) " Mockup" ya da site haritası yapmamak "zahmetli" olduğu için.

Bir balsamiq maket masaüstü sürümü için USD75 harcayın. Bunu biliyorum çünkü 3 hafta önce aldım. Gerçek dünyadaki çizimim berbat olsa da, maketlerimi yeniden yapmamı sağladı çünkü hepsi 1'de bir sanatçı, mimar ve vizyoner gibi hissediyorum. Balsamiq'te kullanılan yazı tipi bilinçsizce RAD'de size yardımcı olacak taşa ayarlanmamış, sadece bir mockup olduğunu hatırlatır.

EDIT işlemini sonlandır

Birkaç bira daha iyi ve daha uzun süre çalışmama yardımcı olacak.

“Evet, 2000 hatlı spagetti devasa karmaşasını bir günde yeniden canlandırabilirim…”

“Bunun için test yapmadan geçebilirim. Test etmek çok zor.”

ve bu kötü bir kardeş.

“Testin yazmak veya anlamak ne kadar zor olursa olsun, bunun için bir test yapmalıyım.”

Erteleme ve iyimser görev tahmini benim en büyük günahlarım.

Birincisine germe, şınav veya çekmeli (veya herhangi bir diğer fiziksel egzersiz), ikincisini tahmin etmeden önce karamsar bir ruh hali.

"Çok daha 'dir kolay için' sıfırdan işlevselliği reimplement mevcut kodu anlamak daha iyidir."

İçinde bulunduğum projenin çektiği büyük zararlı günaha, 'İç Platform Etkisi'. Bu, artık çoktan gitmiş olan Mimarların, yılda yaklaşık 20 milyon dolar üreten bir projeyi yaratan, ancak güncelleme ve bakımını yapmak için 60 milyona mal olan, sonsuz bilgeliklerine dayandıkları bir yaklaşımdır (açıkça kaba rakamlar ancak bu problemin).

NIH - Burada İcat Edilmedi

Üçüncü taraf çözümlere adil bir şans vermek konusunda gerçekten çok zorlanıyorum. Herkes doğal olarak kendileri için tasarlanmayan üçüncü taraf çözümlerine kuşkuyla yaklaşmalıdır, ancak bu konuda% 100 objektif olmakta zorlanıyorum.

Zaman tasarrufu o kadar büyük olabilir ki, 10'un 9'undan 9'unun üçüncü taraf çözümünden kaçınılması durumunda bile çalışacak olanı gerçekleştirecek kadar objektif olmam gerekiyor .

Müşterilerin fiili veritabanının bir kopyasını analiz etmek yerine, tedarik edilen "örnek verilere" karşı tasarım, kodlama ve veya birim testi. Son tarih kısaydı ve geldiğini söyleyip duruyorlardı ama olmadı. Konuş verildiğinde patlama harikaydı. Gerçekten, bir müşteriden 3 ana müşteriye sahip olmasını beklerdi.

Gerçek verilerin bir kopyasını alıncaya kadar bir daha asla projeye başlayamam .

Bir yerde bunu yapan bir kütüphane olmalı .

Yakından ilişkili

Eklenti Fetiş

Mükemmeliyetçilik öldürür; Muhtemelen en büyük sebep projeler başarılı olamaz.

Bazen programlama beni şişeye götürür.

Yeniden düzenleme yerine yeniden yazma.

Bunu yapmanın daha iyi bir yolu olması gerektiğini düşünüyorum. "Yeterince iyi" olabilecek bir şeye razı olmayacağım. Mükemmeliyetten daha azını alamıyorum! Genellikle bu, bir problem üzerinde farklı bir perspektife sahip olabilecek başkalarıyla konuşarak veya çözümü farklı bir açıdan görerek önlenir.

Her şeyi o noktaya otomatik hale getirmek, aletleri fiili çalışmadan ziyade sürdürmeye harcanır.

Çözüm: tıpkı kod optimizasyonunda olduğu gibi, önce verimlilik darboğazlarını bulun ve yalnızca keşfedildikten sonra onları iyi bir otomasyonla iyileştirin .

Programcılığın şeytanları neler?

Bazılarının söylediklerinin dışında.

Önceliklendirme : Projeye ilişkin yüksek öncelikli çalışmayı göz ardı etmek ve ilk önce projedeki diğer şeyler üzerinde çalışmak, çünkü daha ilginçtirler!

Onlardan nasıl kaçınıyorsunuz?

Biraz daha kendine disiplin ile. Cidden, öz disiplin ve doğru olanı yapmak için öz motivasyon bu "şeytanların" çoğundan kaçınmaya yardımcı olur.

Henüz müşteriden onay alamadık, ancak son başvuru tarihi yaklaşıyor, işte başlayabilmeniz için işte bazı ön şartlar.

Daha sonra, projeyi comps ile eşleştirmek için projeyi oluşturduktan sonra ...

İşte müşterinin revizyonları, sadece birkaç küçük şeyi değiştirmek istiyorlar *

(* ana işlevsellik tamamen farklıdır)

Daha sonra, sıfırdan başlamak yerine orijinal kusurlu modele dayalı olarak orijinal kodunuzu yeniden düzenlemeye devam edersiniz, çünkü kısa bir son tarih baskısı altındasınız ve bunların son revizyonlar olduğunu varsayalım.

Her zaman bununla biraz ısırdım. Bir web geliştiricisi olarak kaçınılması zor. En iyi tavsiyem, değişiklikleri doğru şekilde yapabilmeniz için daha fazla süre zorlamak.