“Çalıştığı sürece” norm mu? [kapalı]

Daha yeni sorumu görün: En altta bir yarışta programlama yapmak bir meslek olarak mı?

Son dükkanımın bir süreci yoktu. Çevik, esasen, projelerinin nasıl geliştirileceği veya yönetileceği konusunda bir planlarının olmadığı anlamına geliyordu. "Hey, işte bir ton iş. Git iki hafta içinde yap. Hızlı tempolu ve çevikiz."

Problemleri olduğunu bildikleri şeyleri yayınladılar. Nasıl yazıldığını umursamadılar. Kod incelemesi yoktu - birkaç geliştirici olmasına rağmen. Adam arabası olarak bildikleri bir yazılım yayınladılar.

Önceki işimde insanlar çalıştığı sürece tutumu vardı, sorun değil. Spesifikasyonu araştırırken yazdığım bazı kodların yeniden yazılmasını istediğimde, bunu reddetti. Kodu tekrar yazmak istedim, çünkü kod birden fazla yerde tekrarlandı, kapsülleme olmadı ve insanların üzerinde değişiklik yapmaları uzun zaman aldı.

Temel olarak, benim izlenimim şudur: programlama aşağıya doğru kaynamaktadır:

1. En son araç / teknoloji hakkında bir kitap okumak
2. Buna dayalı olarak kod atmak, herhangi bir kod yazmaktan kaçınmak, çünkü şirket "özel kod sağlamak" istemiyor
3. Gösteriyor ve bir sonraki şeye geçiyor, "çalıştığı sürece".

Kendime her zaman bir dahaki iş için daha iyi bir dükkan bulacağımı söyledim. Asla olmadı. Eğer öyleyse, kendimi sıkışmış hissediyorum. Teknolojiler her zaman değişir; Buradaki tek profesyonel gelişme, en son MS Press teknoloji kitabını okumaksa, o zaman 10 yıl içinde neler yaptınız, ancak çeşitli teknolojiler hakkında yüzeysel bir bilgi? Endişeliyim:

1. Profesyonel standartlara sahip olmanın en iyi yolu
2. Bu durumda anlamlı bilgi ve deneyim nasıl geliştirilir?

İyi bir geliştirici olmanın en önemli yanı olduğunu düşündüğüm şey hakkında dolaylı olarak tökezlediniz : " çalıştığı sürece " ve iyi tasarlanmış, şık kod arasındaki dengeyi yakalamak.

Tıpkı politikada olduğu gibi, spektrumun bir ucunda konumunuzu belirlemek, ortada nüanslı bir konum almak için çok daha kolaydır. Karşılaştığım geliştiricilerin çoğu iki kategoriden birine giriyor: kodlama kovboy korsanları ve mimarlık astronotları. İkisi arasında bir denge kurmaya çalışıyorum. Bu göründüğü kadar kolay değil.

Sorunuza daha doğrudan cevap vermek için, evet, “işe yaradığı sürece” genellikle norm olduğunu düşünüyorum. Ancak başka bir şeye bakın: meslektaşlarınızı eğitmek ve daha iyi uygulamalar tanıtmak için mükemmel bir konumdasınız. Ancak uç noktalara gitmeyin ve neden hepimizin bunu yaptığımızı unutmayın: Müşterimizin sorunlarını çözmek için.

>> Önceki işimde, insanlar çalıştığı sürece tutumu vardı, sorun değil.

Burada bir azınlık olabilirim ama aynı tavra sahibim ve bir şeyi yeniden yazmanın, buna neden ihtiyaç duyduğumuza dair açık kanıtlar olması gerektiğine inanıyorum. Ve "uf, nasıl kodlandığından hoşlanmıyorum" gibi bir şey ifade etmiyorum - her geliştiricinin kodla ilgili tercihleri ​​vardır. Yeniden yazmak istediğimiz bölümle ilgili bazı sorunlar olmalı:

• Performans problemleri
• Sistemin diğer bölümlerinden daha fazla hata bulundu
• Geliştiriciler bu kısımda çalıştıklarında daha fazla zaman harcarlar
• vb.

Agile, buggy yazılımı piyasaya sürmeye karar veren herhangi bir insandan sorumlu değildir; insanlar.

Bu, kaliteye çok önem verdiğinizi söyledi ve bu iyi. Mükemmeliyetçilikten eminim ve en son teknolojilerle yetinmiyorsanız kendi değerinizle ilgileniyorsunuzdur.

Sorun olduğunu mükemmeliyetçilik için iletkenler erteleme ve erteleme potansiyel sıradanlık .

Bu nedenle iş, hızlıca ve tahmin edilebilir bir hızla değer sunmak için pazara girme ve çevikliği kullanma gibi şeylerde öncelik kazanacaktır .

Şirketinizin iş stratejisini tanımlamadığınızdan, yöneticilerinize bununla ilgili bir soru sorarak başlamanız gerektiğini düşünüyorum.

By hizalanmış olan kendi hedef ve planları (onlar seni tuttu , bunun yerine kendi kişisel hedeflerine odaklanarak onlara katkıda bulunabilir anlamak daha iyi bir konumda olacak onları onlara ulaşmada yardımcı olmak için).

Ben çalışarak eminim understandonların değeri, senin kendi paylaşmak mümkün olacak ve bu verimli bir işbirliğinin başlangıcı olacak.

Ve ne yaptıklarını bilmediklerini keşfederseniz, tek seçeneğiniz istifa etmek olacaktır .

Her şey ne inşa ettiğine bağlı. Sadece bir ay boyunca çevrimiçi olacak bir mikrosit inşa ediyorsanız ve inşa etmek için dokuz gününüz varsa: o zaman işe yaradığı sürece evet.

FA-18 sistemi için uçtan uca algoritmalar yazıyorsanız, mümkün olduğu kadar mükemmel yapılmalıdır.

Pek çok teknoloji cevabında olduğu gibi ... buna bağlı.

Bu şirkete bağlıdır. Ancak, birçok şirket ciddi rekabet ve zaman baskısına sahiptir. Bu tipik bir sebep. Bir diğeri potansiyel olarak yeterli personel olmadan büyük bir iş yükü olacaktır. (Yetersiz olması için bazı çok iyi nedenler vardır, bunlar şirketin suçu olmak zorunda değildir.) Bazı kurumların ıslak kağıt torbadan çıkma yollarını yönetemediklerini belirtti.

80/20 kuralının burada geçerli olduğunu düşünüyorum. Temel olarak,% 80'ini berbat tutman ve% 20'ye girmen için çalışman gerekiyor. Ancak, onların bile değiş tokuş yapmak zorunda kalacağının farkına varın. İş dünyasında, genellikle kesinlikle doğru olması önemli değil. Şu an elinizde olması önemli.

Buradaki tek profesyonel gelişme, en son MS Press teknoloji kitabını okumaksa, o zaman 10 yıl içinde neler yaptınız, ancak çeşitli teknolojiler hakkında yüzeysel bir bilgi?

Bu oldukça berbat olurdu, ancak bu on yılda not edilmesi gereken bazı olağanüstü başarısızlıklar olabilir. Orada çalışmaktan hoşlandığım ya da hoşlanmadığı çok özel şeyleri hatırlayabildiğim birçok yer gördüm ve bu yüzden yeni işyerimde tekrar olmasını sorgulayacağım. Bazen bir şirket Scrum'u uygulamaya çalışırsa veya bir Test Odaklı Gelişme yaklaşımı benimsemeye çalışırsa, ancak bunlar resmi bir sınıf ortamında olmadığı kadar profesyonel bir gelişim olarak görülmesi gerekmediği gibi denenebilecek yeni bir uygulama olabilir.

"Çalışır sürece" çeşitli kovboy kodlama stratejileriyle birlikte yaygın olan çeşitli yerler biliyorum. Bir kaç yeni girişimde, eğer şirket o kadar genç olursa, gerçekten ne yapmaya çalıştıkları fikrini temizlemeye çalıştıkları için mantıklı olabilecek bu tür bir zihniyet gördüm. Çalıştığım diğer firmalarda korkmam gerektiğini bulmak kolay olmasa da oldukça iyi olabilen bir süreç ve olgunluk vardı. Bazı yerlerde görmem ve gitmem gereken bazı süreçler vardı, "Bundan hoşlanıyorum. Bunu daha sonraki çalışma durumları için hatırlayacağım" ve diğerleri nereye gittiğimi, "Bundan gerçekten hoşlanmıyorum." Gelecekte bundan kaçınmaya çalışmak. "

Bir süre böyle bir dükkânda, onları yakaladığı noktada çalıştım. Kelimenin tam anlamıyla çözemediği bilinen hatalara sahip iki veya üç yıllık uygulamalar vardı. Mizanpaj genişliklerini ve yüksekliklerini hesaplamak için 4.000 çizgi uzunluğunda bir döngü düşünün. Bir durumda bir sorunu çözmek için bir kod parçasını düzeltmek, başka bir yerde yirmi sayıya yol açacaktı çünkü önceki geliştiriciler hesaplama sonuçlarını rasgele bir şekilde sihirli sayılarla ayarlayarak bantla aynı sorunları kullanıyorlardı. Kod toksikten başka bir şey olarak tanımlanamadı.

Sonunda patronumun bu mevcut kodu paftaları işlemek için kullanabileceğimi söylediği yeni bir proje verildi. Her nasılsa onu "değiştirmeme" izin vermesi için ikna ettim, bu yüzden bana biraz zaman verdi. Yerine yardımcı olmak için iyi tasarlanmış bir kütüphane yazmak için zaman kullandım. Bu yeni projedeki hatalar tam anlamıyla çözmem için 10 saniye sürdü. Neyin yanlış gittiğini görmek için koda bakmadan bile sorunları tanımlayabilirdim.

Bunun yöneticim için bir dönüm noktası olacağını düşünmüştüm, ancak elimdeki tek şey arkadaki bir pat oldu ve bana esasen "Sizin de sanırım yolunuz işe yarıyor" dedi.

O zamandan beri başka bir dükkan için çalışmaya başladım ve burada işler daha iyi. Mesele şu ki, fikirlerini değiştiremezsin. Sadece git başka bir yerde çalış.

Hala ümitim var; ekonomide, er ya da geç bu tür şirketleri işsiz bırakan bir tür evrimsel süreç var. Fakat belki de teknolojik ilerlemenin yüksek hızı çok fazla sayıda yeni niş üretmektedir, bu nedenle zayıf rakipler bile hala yeterince "yiyecek" bulabilir.

İyi bir yerde çalışma şansınızı artırmak istiyorsanız, birkaç haftada bir yeni şeyler yazmak yerine birçok müşteriye sattıkları bir ürünü arayın. İyi bir kod tabanına sahip olmak ve sürekli mevcut kodu bozmadan yeni özellikler ekleyebilmek daha fazla ilgi çekmelidir.

Bana üniversitedeki ana arkadaşımı hatırlatıyor. Bir VLSI tasarım dersi alıyordu ve ilk ödevinde mikrometre genişliğinde ve bir kilometre uzunluğunda olan bir bileşenle geldi. Simülasyonlar kusursuz geçti.

Eleştirmenlerine verdiği cevap şuydu: "Tek bildiğim bokun işe yaradığı."

Pareto prensibi oldukça iyi bir normdur.

80-20 kurallı bir projeden tecrübe sahibim ve çok iyi çalıştı. Bence "Mükemmelliğiniz için çizgiyi nereden çiziyorsunuz?" Sorusunun cevabı da yardımcı olabilir.

"Pareto prensibi" terimi Pareto verimliliğini de ifade edebilir. Pareto prensibi (aynı zamanda 80-20 kuralı, hayati azınlığın kanunu ve faktörlerin seyrekliği prensibi olarak da bilinir), çoğu durumda, etkilerin kabaca% 80'inin nedenlerin% 20'sinden geldiğini belirtir. İş dünyası düşünürü Joseph M. Juran, 1906'da İtalya'daki arazinin% 80'inin nüfusun% 20'sine sahip olduğunu gözlemleyen İtalyan iktisatçı Vilfredo Pareto'nun ilkesini önerdi ve ismini verdi; bahçesindeki bezelye tohumlarının% 20'sinin bezelyelerin% 80'ini içerdiğini gözlemleyerek prensibi geliştirmiştir. İşletmelerde ortak bir kuraldır; örneğin, "satışlarınızın% 80'i müşterilerinizin% 20'sinden geliyor". Matematiksel olarak, bir şey yeterince büyük bir katılımcı grubu arasında paylaşılıyorsa, "% k katılımcıların (% 100 - k) alındığı" 50 ile 100 arasında bir sayı olmalıdır. K sayısı 50'den (eşit dağılım durumunda, yani nüfusun% 100'ünün eşit hissedar olduğu) yaklaşık 100'e (az sayıda katılımcı kaynağın neredeyse tamamını oluşturduğunda) değişebilir.Matematiksel olarak% 80 sayısı için özel bir şey yoktur, ancak birçok gerçek sistem, dağıtımdaki bu orta düzey dengesizlik bölgesinin çevresinde bir yerdedir. Pareto prensibi sadece aynı ekonomist tarafından da tanıtılan Pareto verimliliğiyle teğet bir ilişki içindedir. Pareto, halk arasında gelir ve servet dağılımı bağlamında her iki kavramı da geliştirdi.

Kaynağa Bağlantı

Spesifikasyonu araştırırken yazdığım bazı kodların yeniden yazılmasını istediğimde, bunu reddetti. Kodu tekrar yazmak istedim, çünkü kod birden fazla yerde tekrarlandı, kapsülleme olmadı ve insanların üzerinde değişiklik yapmaları uzun zaman aldı.

Alınma ama yönetici olarak o ifadeyi aşağıdaki satırlar boyunca bir yerlerde okudum:

"Zaten yazdığım bazı kodları yeniden yazmak için iki kez ödeme yapılmasını istediğimde, şirketim ödemek istemiyordu. İlk yazdığımda yaptığım karışıklığı temizlemek için fazladan para istedim. meslektaşları hayatlarını zorlaştırdıkları için bana kızdı. ”

Şikayet ettiğiniz kendi kodunuzsa - dayanacak fazla bir şeyiniz yok.

GÜNCELLEŞTİRME

Bu POV'un popüler olmadığını anlıyorum. Ancak, profesyonel bir geliştiricinin sorumlulukları ve tutumlarıyla da hiç uyuşmadığını sanmıyorum.

Başlamak için temiz kod yazarsanız (ve bunu yapmak için birçok neden vardır - kodunuzun üretim kullanımını görüp görmeyeceğini düşünmeden bağımsız olarak), o zaman bu sorunu daha az düzenli olarak uygularsınız.

Tahminlerinize temiz kod ve yeniden düzenleme zamanı eklerseniz, kod tabanını düzenli tutma planınız da olur. Eğer program baskısı nedeniyle gerekli zamanı alamazsanız - gelecekteki tahminleriniz, ortaya çıkan teknik borçlarla başa çıkmanın bir sonucu olarak artmalıdır.

Bir noktada, gelecekteki tahminleriniz (veya tahminlerinizi çevreleyen belirsizlikler) yeniden yazma için tartışmakta olduğunuz kaldıraç oranını (yöneticiniz işlemi daha hızlı yapmak için yalvarıyorsa) size kaldıracaktır. Olmazsa, o zaman işletmenin tahmini tahmininizi kabul ettiğini ve devam etmekte olan masrafları yerine yenisiyle ödemeyi tercih ettiğini kabul edin. Bu tamamen bir iş kararı - teknik değil.

Unutmayın, zaman çizelgesi müzakere zamanı kodu yazmadan önce - sonra değil. Kod yazıldıktan sonra (ve "işler"), müşteriler, yöneticiler ve yöneticiler, orijinal maliyete yaklaşan veya bu değeri aşan "bakım" için başka bir fatura görmek istemezler. İşletmenizin düşündüğünüz kadar güçlü hissediyorsanız, kendi zamanınıza göre yeniden yazmaktan çekinmeyin - işten yapmasını istediğiniz şey budur.

Yöneticinizin bakış açısından, size yeniden yazma planını vererek kıçını çizgiye sokuyor. Verememeniz veya verdiğiniz kadar üretkenliği arttırmanız durumunda - o zaman çantayı tutan kişi o kalır. Sizi dinlemenin nispeten küçük sakıncası ile karşılaştırıldığında, hangisini tercih edeceğini tahmin edin.

Eğer elde edeceğiniz iş buysa, geri dönüp eski kodu yeniden yazmak yerine her seferinde daha iyi kod yazmaya odaklanın. Hala üçüncü taraf paketlerini yapıştırma alemine girebileceğiniz bir kalite yelpazesi var.

Vaktiniz varsa ve sürdürdüğünüz mevcut bir bileşenin kodunu geliştirmek istiyorsanız, ne iş yaptığınız sürece izin istemeden bunu yapamaz mısınız? Bileşeni kullanan bir sonraki proje için tahminlerinize zaman ayırın.

Daha düşük seviyeli programlama için, eğer işinizden öğrenme memnuniyeti alamazsanız, o zaman belki açık kaynaklı bir projeye bakmanın zamanı gelmiştir?

Q303, sorunuzu ilginç buldum ve bu Programcıları , geliştiricilerin teknik borcu ele almasına izin vermek için yöneticileri nasıl ikna edeceğiniz konusunda okumayı hak eden bir soru bulabileceğini hissettim .

Genel olarak, evet, norm olduğunu düşünüyorum. Çalışıyor ancak optimal olmayandan daha az olan yazılımın, çalışmayan yazılımdan çok daha iyi olduğunu anlayın. Ayrıca “çalışma” tanımının, her bireyin algısına ve önyargılarına göre değişebileceği argümanı var. Yeni bir sistem uyguladığınızda, eski sistemin daha iyi olduğunu düşündüklerini söyleyen biri vardır. Ve bir geliştirici ile konuştuğunuzda, kendisinin crappy yazılımı üzerinde çalıştığını kabul etmek konusunda isteksiz olması muhtemeldir.