Bir buçuk yıldan beri uygulama geliştiricisi olarak çalışıyorum (uzun zamandır bilmiyorum) ve ilk büyük projemi aldım.

Çok düzgün gitmediğini söylemeye gerek yok, bu yüzden projeye dahil olan kıdemli bir programcıdan nasıl yaklaşılacağı konusunda tavsiyeler aldım.

Elimdeki görevi büyük ölçüde düşünmekte olduğumu ve tasarım kalıplarını düşünmek için çok fazla zaman harcamadan önce bu ölçekte bir projeyle uğraşmadığımı söyledi. Akıllıca sözleriyle bana "Gelecek F * ck, şimdilik inşa et" dedi.

Bu trend programcıları böyle bir projeye devam ederken genellikle izler mi? Örneğin, bir konsept model kanıtı yapmanız istenirse, mümkün olan en kısa sürede uygulanabilir bir örneği ezmek tipik bir eğilim midir?

Düzenleme: Bunun yol açtığı tartışmaların ışığında, bu durumun oldukça aşırı olduğunu belirtmek isterim: kontrolümüz dışındaki faktörler nedeniyle çok sıkı son teslim tarihlerine sahibiz (yani hedeflediğimiz pazar, eğer yapmazsak ilgisini kaybedecektir) onlara bir şey gösterme) ve tavsiyesi bu özel görev için çok etkili oldu.

Kaptanı Kurtarmaya Açık!

Burada Yüzbaşı Belli olacağım ve bulunacak bir orta yol olduğunu söyleyeceğim.

Gelecek için inşa etmek istiyor, kendini teknolojik bir seçime ya da kötü bir tasarıma kilitlemekten kaçınıyorsun. Ancak, 3 ay boyunca basit olması gereken bir şeyi tasarlamak ya da 2 yıl ömrü olacak ve takip eden projeleri olması muhtemel olmayan hızlı ve kirli bir uygulama için uzatma noktaları eklemek istemezsiniz.

Ayrımı bulmak zordur, çünkü her zaman ürününüzün başarısını tahmin edemezsiniz ve daha sonra genişletmeniz gerekirse.

Şimdilik İnşa et ...

• proje hurdaya kavuşacak
• proje kısa bir ömre sahip
• Proje uzantılarına sahip olmamalı
• Projenin risk etkisi değeri yoktur (çoğunlukla görüntü bakımından)

Genel olarak, şirket içi projeler veya bir müşteri için inşa edilmiş bir şey şimdilik geliştirilmelidir. Düz gereksinimlere sahip olduğunuzdan emin olun ve neye ihtiyaç duyulduğunu ve neyin ihtiyaç duymadığını bilmek için gerektiğinde onlarla bağlantı kurun. "Sahip olmak güzel" bir şeye çok fazla zaman harcamak istemeyin. Ama domuz gibi de kodlama.

Genel Sorunu daha sonraya bırakın, eğer gerekli ve çabaya değerse:

Gelecek için inşa edin eğer ...

• proje halka açılacak
• Proje tekrar kullanılması gereken bir bileşendir.
• proje diğer projeler için bir basamak taşıdır
• Proje, takip projeleri veya geliştirmeleri olan hizmet yayınları içerecek

Halka açık bir şey için inşa ediyorsanız veya başka projelerde yeniden kullanılacaksa, kötü bir tasarımın sizi rahatsız etmek için geri dönme ihtimalinin çok yüksek olması olasılığına sahiptir, bu nedenle buna daha fazla dikkat etmeniz gerekir. Ancak her zaman garanti edilmez.

Kuralları

Aşağıdaki ilkelere mümkün olduğunca iyi uyduğunuzu söyleyebilirim ve kendinizi verimli, uyarlanabilir ürünler tasarlama konumuna getirmelisiniz:

• biliyorum ki YAGNI ,
• KISS ,
• Ne zaman kaşıntı kaşımak istersiniz ve bir ek düşünün, onu yazın. Proje gereksinimlerinize geri dönün ve eklerin öncelik olup olmadığını kendinize sorun. Birincil işletme değeri ekleyip eklemediklerini sorunuz .

Şahsen, düşünmeye ya da aşırıya eğilimli olduğumu biliyorum. Gerçekten fikirleri yazmak için yardımcı olur ve ek özelliklere ihtiyacım olursa sık sık yeniden düşünün. Genellikle, cevap hayır ya da "daha sonra iyi olurdu" değil. Bu son fikirler tehlikelidir, çünkü kafamın arkasında kalıyorlar ve onlar için plan yapmamam için kendimi zorlamam gerekiyor.

Fazla mühendislik yapmadan ve daha sonra kendinizi engellemeden kodlamanın en iyi yolu iyi bir minimal tasarıma odaklanmaktır. Daha sonra, ancak nasıl zaten düşünmeden uzatabilirsiniz bileşenleri olarak güzel şeyleri yıkmak olabilir sonra uzatılabilir. Geleceği tahmin edemezsin.

Sadece basit şeyler inşa et.

Dilemmata

Overengineering

Bu trend programcıları böyle bir projeye devam ederken genellikle izler mi?

Cehennem evet. Bu bilinen bir ikilemdir ve yalnızca ürünü umursadığınızı gösterir. Yapmazsan, bu daha endişe verici. Daha azının her zaman gerçekten daha fazla olup olmadığı ve daha kötüsünün her zaman gerçekten daha iyi olup olmadığı konusunda anlaşmazlık vardır . MIT ya da New Jersey gibi biri olabilirsin . Burada kolay bir cevap yok.

Prototipleme / Hızlı-n-Kirli / Daha Az

İşe yarar bir örneği olabildiğince çabuk parçalamak tipik bir eğilim mi?

Bu yaygın bir uygulama, ancak projelerin büyük çoğunluğuna bu kadar yaklaşılmıyor. Yine de, prototipleme bence iyi bir trend, ancak ortalama bir dezavantajı var. Hızlı ve kirli prototipleri gerçek ürünlere tanıtmak veya bunları yönetim baskısı veya zaman kısıtlamaları altındaki gerçek ürünler için baz olarak kullanmak cazip olabilir. O zaman prototiplik sana musallat gelebilir.

Prototiplemede bariz avantajlar var , fakat aynı zamanda kötüye kullanma ve suistimal için çok fazla potansiyel var (çoğu, sonuç olarak daha önce listelenen avantajların tam tersi).

Prototip Ne Zaman Kullanılır?

Prototiplemeyi kullanmak için en iyi proje türleri hakkında ipuçları var :

[...] prototipleme, kullanıcılarla pek çok etkileşime girecek sistemlerde en faydalı olanıdır.

[...] prototipleme, çevrimiçi ekranların analizinde ve tasarımında, özellikle ekran diyalogların kullanımının daha fazla kanıt olduğu işlemlerin işlenmesinde çok etkilidir. Bilgisayar ve kullanıcı arasındaki etkileşim ne kadar büyük olursa, fayda o kadar büyük olur [...]

"Bugüne kadarki hızlı prototiplemenin en verimli kullanımlarından biri, yinelemeli kullanıcı gereksinimleri mühendisliği ve insan-bilgisayar arayüz tasarımı için bir araç olmuştur."

Diğer yandan:

Toplu işleme veya çoğunlukla hesaplamalar yapan sistemler gibi az kullanıcı etkileşimi olan sistemler prototiplemeden çok az fayda görür. Bazen, sistem işlevlerini gerçekleştirmek için gereken kodlama çok yoğun olabilir ve prototiplemenin sağlayabileceği potansiyel kazanımlar çok küçüktür.

Etrafında yeşil bir canavarı varsa, prototipi bütçede tuttuğundan emin ol ...

Programlamaya başladığınızda, sadece kendiniz olsa bile her şey bir kavram kanıtıdır. Bir fikrin hızlı ve kirli bir şey veya prototip gerektirdiği durumlar vardır çünkü zaman önemli bir faktördür. Geliştiriciler arasındaki büyük korku, küçük uygulamanın üretime hazır olduğunu ya da sonsuza dek aynı oranda özellikler ekleyebilmeniz gerektiğini düşünen paydaşlardır. Büyük bir proje üzerinde çalışıyor ve bunun böyle olmadığını görüyorsunuz.

Büyük projeler genellikle daha karmaşık gereksinimlere sahiptir, bu yüzden karmaşık tasarımları denemek ve uygulamak için bir cazibe vardır. Bunları okumak, araştırmak ve uygulamak için çok zaman harcayacaksınız. Bu büyük bir zaman kaybı olabilir, ancak hepsi öğrenmenin ve tecrübe kazanmanın bir parçasıdır. Belirli bir tasarımın ne zaman kullanılacağını bilmek zordur ve genellikle deneyimle gelir. "Bu" projede "bunu" denedim ve işe yaramadı ama şimdi "burada" üzerinde çalışması gerektiğini gördüm.

Çok fazla plan yapmalı ve planlamalısınız, fakat hepsini bir kerede yapmayın. Kesinlikle her şeyin başında yapılması gerekmiyor. Birinin ilk büyük projesini şöyle yaratmasını tercih ederim:

1. Biraz tasarlayın ve tartışın.
2. Bir şeyler yapan bir sürü kod yazın.
3. Sorunları tanıma ve DUR kodlama.
4. Tasarım konusunda ciddi olun ve momentumunuzu ya da kod mojo'nuzu kaybetme konusunda endişelenmeyi bırakın ve proje yöneticisini görmezden gelin (Ona bir iyilik yapıyorsunuz.).
5. Projeyi kontrol altına alın. Mesajlarını düzelt. Herkesin planı anladığından emin olun. Projeyi kontrol altında tutun.

Bazen, sizi mevcut kod tabanında nasıl uygulayacağınız konusunda gerçekten endişelendiren bu özelliklerden birine çarpıyorsunuz. Bu "sadece işe yaraması" zamanı değil. "Bazen çekiç yerine bir tabure almalısın" diyen bir patronum vardı. Bunu masamda "düşünürken" yakaladıktan sonra söyledi. Bir çok patronun aksine, beni şaşkına çevirdiğimi varsaymadı ve daha fazlasını yapmamı istediğini anladığımdan emin oldu. Cin.

Sonuçta, kodunuz tasarımdır. Belgeler, diyagramlar, toplantılar, e-posta, beyaz tahta tartışmaları, SO soruları, tartışmalar, küfürler, öfke uyarlamaları ve kahve üzerinden sessiz sohbetler tarafından desteklenir. Daha fazla tasarım yapamayacağınız bir nokta var ve yalnızca kodu yazmaya çalışacağınız kusurlardan dolayı daha fazla tasarım zamanı atma riskiniz var. Ayrıca, ne kadar çok kod yazarsanız o kadar iyi kodlayamayacağınız bir tasarım hatası ortaya çıkarabilirsiniz. Dışkıya tekrar zaman.

Programcılar genellikle geleceği düşünmeden şimdi çalışan bir şey inşa ediyor mu?

Evet.

Öyle mi yapmalılar?

Hayır.

İlk bakışta, “gelecek hakkında düşünmek” , KISS ve YAGNI gibi yerleşik tasarım ilkelerini ihlal ediyor gibi görünüyor;

Ama aslında değil. Geleceği düşünmek, basit, genişletilebilir ve yönetilebilir bir yazılım tasarlamak anlamına gelir. Bu, özellikle uzun vadeli projeler için önemlidir. Zamanla yeni özellikler gerekli olacak ve sağlam bir tasarıma sahip olmak yeni parçalar eklemeyi kolaylaştıracak.

Tamamladıktan sonra bir proje üzerinde çalışmayacak olsanız bile, yine de akıllıca geliştirmelisiniz. Onun işi ve en azından ne kadar iyi iş yapıldığını unutmamak için iyi yapmalısın.

Çevik geliştiriciler , gelecekte ihtiyaç duyacağınızı düşündüğünüz şey yerine, şimdi ihtiyacınız olan şeyleri tasarlamanızı teşvik eden "İhtiyacınız Olmayacak (YAGNI)" deyişine sahiptir. Bir tasarımın gelecekte çalışacak şekilde genişletilmesi için önerilen yol yeniden yönlendiricidir.

Bunun en önemli yanı, ürününüzün gereksinimlerini tasarlarken zihninizde tutmak ve gelecekte gerçekleşebilecek bir takım gereksinimler için tasarım yapmadığınızdan emin olmanızdır.

Önümüzdeki iki veya üç yinelemeyi düşünebilecek geliştiriciler için söylenecek bir şey var - müşterilerini veya etki alanını o kadar iyi tanıyorlar ki, gelecekteki ihtiyaçları yüksek doğruluk derecesinde tahmin edebiliyorlar ve onlar için inşa ediyorlar, ancak emin değilseniz, Sizin veya müşterilerin ihtiyaç duymadığı şeylere fazla zaman harcamak en iyisidir.

Bu trend programcıları böyle bir projeye devam ederken genellikle izler mi?

Mentorünüzün ne anlama geldiğinden şüpheleniyorum, nihai çözüm için gerekli olmayabilecek herhangi bir ek karmaşıklığa sahip olmamanız gerektiğinden şüpheleniyorum.

Bir uygulamanın bunu yapması gerektiğini ve bunu büyük ölçüde telafi etmesi gerektiğini düşünmek çok kolaydır.

Tasarım desenlerine gelince, onların bir amaç için bir araç olduğunu hatırlamakta fayda var. Daha önce yaptığınız görüşmelere rağmen belirli bir tasarım modelinin uymadığını tecrübe ederseniz, bu bir kod kokusu olduğunu gösterir.

Örneğin, bir konsept model kanıtı yapmanız istenirse, mümkün olan en kısa sürede uygulanabilir bir örneği ezmek tipik bir eğilim midir?

Proje başlamadan önce hangi dönüm noktalarının olduğu ve her şeyi biraz (dikey dilim) veya geliştirdiğiniz kısımda (yatay dilim) ayrıntılı olarak görmek isteyip istemediklerini görmek için yönlendirmeye değer. İlk tasarımın bir parçası olarak, kodun yazılı olmasa da, her şeyin bir helikopter görünümünü ya da belirli bir alanın derin bir dalışını yapabilmeniz için uygulamanın tümüne binen hikayeye değer buluyorum.

Elimdeki görevi büyük ölçüde düşündüğümü ve böyle büyük bir projeyi hiç ele almadığım için tasarım desenlerini düşünmek için çok fazla zaman harcadığımı söyledi. Akıllıca sözleriyle bana "Gelecek F * ck, şimdilik inşa et" dedi.

Diğer geliştiriciden biraz kovboy zihniyetinin olduğunu düşünüyorum. Günümüzün sadece "şimdi yapan" zorlu bir inek versiyonu. Yeni başlayanlar arasında popüler bir tema haline geldi ve Facebook'taki insanlara "bunu yapmak doğru yapmaktan daha iyi" ifadesini kullandıkları için teşekkür etmiyor.

Bu çekici. Bir konser etrafında duran geliştiricilere, büyük projelerini zamanında, bütçeye ve her şeye göre başlattıkları için ellerini alkışlayan vizyonlar sunar.

Bu idealist bir fantazi ve hayat bu şekilde çalışmıyor.

Bir aptal, sadece “yapabileceğini” ve bitmesini sağlayacağını düşünerek bir projeye koşar. Başarı, görülmeyen zorluklara hazır olan ve mesleğine ince işçilik gibi davranan geliştiriciyi destekleyecektir.

Herhangi bir üst düzey geliştirici eleştirebilir, mahkum edebilir ve şikayet edebilir - ve çoğu yapar!

Size projeyi "fazla düşünmek" olduğunu söyler. Öncelikle seni "düşünmekten" dolayı tebrik ediyorum. Diğer adamdan daha iyi bir geliştirici olmak için ilk adımlarını attın.

Bu trend programcıları böyle bir projeye devam ederken genellikle izler mi? Örneğin, bir konsept model kanıtı yapmanız istenirse, mümkün olan en kısa sürede uygulanabilir bir örneği ezmek tipik bir eğilim midir?

Bu tam olarak bir kavram kanıtı. Bir şeyi olabildiğince çabuk püre haline getirme çabasıdır, böylece insanlar geri adım atar ve ona bakarlar. Hataları, yanlış yönlendirmeleri ve boşa harcanan zamanı / parayı önlemek için yapılır.

Farklı kavramların ispatı vardır. Bittiğinde çöpe atılan bir şey inşa edebilir veya proje için bir başlangıç ​​noktası gösteren bir şey inşa edebilirsiniz. Tüm bunlar neye ihtiyacınız olduğuna ve konseptin nihai ürüne ne kadar yakın olduğuna bağlıdır.

Aynı zamanda fikirlerinizi göstermek için bir fırsat. Bazı şeyleri ummadıkları bir seviyeye getiren bir prototip sunduğum zamanlar oldu.

Tasarım genellikle açık uçlu olduğundan, çok fazla veya çok az uygulanması çok kolaydır. Doğru miktarı ancak proje bittikten veya atıldıktan sonra bileceksiniz. Ya da o zaman bile.

Başarı için genel bir tarif yok, ancak aşırılıkları tanımayı öğrenebilirsiniz. Önündeki her şeyin eksiksiz tasarımı, önemsiz şeylerin ötesinde neredeyse hiç işe yaramaz. Rafine etmek için komponentler bırakmak yeterlidir ve sadece yapılabileceği hissine sahip olabilirsiniz veya sorunları erken keşfetmenin bir yolu vardır.

Sen nasıl yukarı görünebilir artan Eğer aşina değilseniz çalışır gelişme. Başarılı yöntemler genellikle bir veya daha fazla düzeyde yinelemelidir, sıkı geribildirim almak ve bazı iskeletlerde büyümek.

Planlamayı bırakıp kodlamaya başlamak için tavsiyeleri dinlemenin birkaç iyi nedeni vardır;

1. Bir geliştirici olarak yalnızca 18 ay sonra, üniversitenizin not ortalaması ne olursa olsun, gelecek için plan yapabilecek kadar iyi bir beklentiniz olabilir. Bu, parlak ama deneyimsiz geliştiricilerin kavrayabilmesi için son derece zor bir şey, çünkü tamamen bilmediğiniz şeyleri bilmemekle ilgili. Eski eller vizyonunuzdaki bu zayıflığı farketmiş olabilir ve akıllıca sizi sadece bu işe girmeniz ve elinizden gelenin en iyisini yapmanız için teşvik etmiştir.

2. Genç geliştiriciler, kodlamaya başlamadan önce tasarımı mükemmelleştirmeye takıntılı hale gelebilir. Kod yazma korkusuyla karşı karşıya kalabilir (performans kaygısı) veya kod yazıcısının bloğuna sahip olabilir (yazarların bloğu gibi). Tasarımda dally çünkü gerekli iş çıkışı yoktur. Genç dev, muhtemelen her şeyden "korktukları" önerisine öfkeyle cevap verecektir. Belki projenin sonunda onlar olduğunu anlarlar. Endişelenmeyin ve kod yazmamanın önerisi, kod yazıcının bloğu için bilinen tek tedaviyi oluşturur. Yaşlı bir el bu tavsiyeyi akıllıca önerebilir.

3. Sert zamanlama kısıtlamaları varlığında, projeyi tamamlama şansınız sınırlıdır. Çok uzun plan yapın ve ne kadar iyi olursa olsun, zamanında uygulayamazsınız ve asla pazarlanamazsınız. En baştan kesmeye başla, belki de ilk kez şanslı olursun. Ürünü mucizevi bir şekilde teslim ediyorsunuz. Ya da belki de çok şanslı değilsin ve yarı pişmiş bir cüruf parçasını teslim et, ancak zamanında pazara girip bir şeyler öğreniyorsun. Ya da belki başarısızsın. Ama "belki başarısız olursun" hala "piyasaya çıkmamıştı" den daha iyi bir ihtimal, çünkü çok uzun zamandır planladın. Kilit anlayış, şansınızın başlangıçtan sınırlı olduğudur, bu yüzden hackleyerek hiçbir şey kaybetmezsiniz. Yöneticiniz başarı şansının çok az olduğunu biliyor olabilir ve bir öğrenme alıştırması olarak küçük bir kaynak tahsis eder. Başarısızlıktan başarıdan daha iyi öğreniyoruz. Belki de “Ne zaman bir projeyi ne zaman alabilirim?” Diye sordunuz mu?

Kendi kusurlarını görmek oldukça içten içe ve ego içermeyen bir geliştiriciyi alır, bu yüzden, bunun kalanını okumadan önce bir süre meditasyon yapın, kendi zayıflıklarınızı gözden kaçırmak için bahane verin.

Her geliştirici analiz, planlama ve düşünce gerektiren diğer görevlerde özellikle iyi değildir. Düşünce zor ve kurudur. Bir günlük çalışmadan sonra sizi rahatsız eden ve sıkan bırakan bir tür zihinsel ter gerektirir. İki kutu Canavarınızla akış halinize girmek kadar eğlenceli değil ve rock'ınız yüksek sesle çıktı ve kodlama, kodlama, kodlama. Düşünmeyi sevmeyen geliştiriciler, planlamanın iyi bir fikir olduğu fikrine direneceklerdir. Önceden planlama gerektirmeyen dev metodolojiler önerirler. Planlamayı vurgulamayan şirketleri ve yöneticileri severler. Planlama yapmama maliyetinin çok yüksek olmadığı işlere yöneliyorlar. Bütün gece kodlama seanslarına değer veriyorlar ve bu düzeltmeyi bir hata nedeniyle tüm işleri kapalı olan müşterilere yaptırıyorlar.

Bazı geliştiriciler, demo yapmak için yeterince iyi bir şey elde etmenin, tamamen ve her koşulda çalışmasını erteleyebileceği ve belki de başka bir geliştiricinin üzerine atılabileceği, hatta başlangıçta "işi bitirmek" için şeref aldıkları anlamına geldiğini bile fark etmişlerdir.

Zaten facebook kırılmadan bir eğilim göremiyor yöneticileri var. İndirimli lastik mağazasını yöneten bir iş bulmak yerine, bu yöneticiler sorununuzu cumaya kadar kodlamalarına ihtiyaç duymalarını sağlar. API'yi tasarlamanız veya algoritmanızın ölçeklenebilir olup olmadığını test etmeniz gerektiğini duymak istemiyorlar. Bu sadece onlar için teknoloji mumbo-jumbo. Sizi kodlamanız için teşvik edecektir, çünkü müşterilerin dosyalarını aktarmalarına yardımcı olmak için perl komut dosyaları yazarken yazılım hakkında anladıkları tek şey budur. (İlk satış işlerinde 'yazılım mühendisi' unvanı vardı. Yazılımın çok sıkıcı ve zor olacağını kim bilebilirdi?)

Bana kodunu göster, sana kim olduğunu söyleyeyim.

Kodunuz ziyaret kartınız. Dağınık kod yazarsanız, diğer insanlara kendiniz hakkında ne söylersiniz? Sadece bunu düşün. Ofiste gerçekten kötü bir kod parçası bulduğumuzda, kendimize sorduk, kim yazmış ve ne halâ üniversiteden geçti?

Kodladığın şey oluyorsun

Kodunuz yaşam için programınızdır.

Kötü kod yazan bir programcı striptiz kulübünde dans eden bir balerin gibidir

Bazı insanlar striptiz kulübünde dans etmeyi umursamıyor. Fakat eğer uzun boylu dansçılarsa, yeteneklerini boşa harcıyorlar. Zavallı dansçıysanız ama güzel bacaklarınız varsa, birçok kişi için soyunabilirsiniz.

Sonunda, Gogol'un romanı 'Portre'yi okumalısınız ve ana karakterin hikayesiyle uyarılmalısınız. Arkadaşın, portredeki adama benziyor. Sana para ödüyor, ama bunun için yüksek bedel ödeyeceksin.