Kodunuzun "yapıcı" eleştirisi hangi noktada yararsızlaşıyor?


39

Geçenlerde küçük bir geliştirici olarak başladım. Takımdaki en az deneyimli insanlardan biri olmanın yanı sıra, erkek egemen bir ortamda çalışan her türlü zorlukla gelen bir kadınım. Son zamanlarda sorun yaşıyorum çünkü işim konusunda çok fazla haksız yere bilgi veren bir eleştiri alıyorum gibi hissediyorum. Size son zamanlarda olanlardan bir örnek vereyim.

Takım liderliği yaptığım bazı şubelere basmak için çok meşguldü, bu yüzden hafta sonlarına kadar onlara ulaşamadı. Postalarımı kontrol ettim, gerçekten herhangi bir iş yapmayı kastetmedim ve iki dalımın değişken isimler temelinde reddedildiğini, hata mesajlarını daha açıklayıcı hale getirdiğini ve bazı değerleri config dosyasına taşıdığını tespit ettim.

Şubemi bu temelde reddetmenin faydalı olduğunu sanmıyorum. Hafta sonu boyunca birçok insan çalışıyordu ve ben de çalışacağımı asla söylememiştim. Etkili olarak, bazı insanlar muhtemelen engellendi çünkü değişiklikleri yapmak ve yeniden göndermek için zamanım yoktu. Çok zamana duyarlı bir proje üzerinde çalışıyoruz ve bana göre müşteriye şeffaf olan şeylere dayanarak kodun tamamen reddedilmesinin faydası yok gibi görünüyor. Yanılıyor olabilirim, ancak zamanım olduğunda bu tür şeylerin yama tipi işlemlerde ele alınması gerektiği gibi görünüyor.

Şimdi, bazı ortamlarda bunun norm olacağını görebiliyorum. Bununla birlikte, eleştiri eşit derecede dağılmış görünmüyor, bu da bir sonraki sorunuma yol açtı. Bu sorunların çoğunun temeli, bir başkasının yazdığı ve asgari derecede saldırgan olmaya çalıştığım bir kod tabanında bulunmamdan kaynaklanıyordu. Dosyanın başka bir yerinde kullanılan değişken isimlerini taklit ediyordum. Bunu söylediğimde, açıkça "Başkalarını taklit etme, sadece doğru olanı yap" demiştim. Bu belki de bana söylenebilecek en faydalı şey. Önceden kontrol edilen kod kabul edilemezse, neyin doğru neyin yanlış olduğunu nasıl söyleyeceğim? Kargaşanın temeli temel koddan geliyorsa, sanmıyorum '

Bu durumda kendimi çok iyi hissettiğimi ve hayal kırıklığına uğradığımı hissediyorum. Beklenen standartlara uyma konusunda çok daha iyi oldum ve daha önce eksik olan ADD hata kontrolüne bir kod parçasını yeniden tararken, daha önce eksik olan bir kod parçasını değiştirdiğimde, kendimi hayal kırıklığına uğrattığımı hissediyorum. hataları yeterince ayrıntılı hale getirin (ve şube bu temelde reddedildi). Ya başlamak için hiç eklemediysem? O kadar yanlış olsaydı, başlaması gereken koda nasıl girdi? Bu yüzden kendimi çok iyi hissettiğimi hissediyorum: Sürekli olarak bu sorunlu koda rastladım; Bunu taklit ettiğimde, "yanlış" olur ve eğer yeniden kırılırsam, yeterince yapamadığım için dolandırıldım (ve bütün yolu gidersem, böcekleri tanıtmak, vb.). Yine, eğer bu böyle bir sorunsa, herhangi bir kodun kod tabanına nasıl girdiğini anlamıyorum,

Herneyse, bununla nasıl başa çıkarım? Lütfen üstte bir kadın olduğumu söylediğimi ve bu adamların diğer adamların kodlarını incelerken genellikle decorum için endişelenmeleri gerekmediğinden eminim ama dürüst olmak gerekirse bu benim için işe yaramıyor. ve daha az üretken olmamı sağlıyor. Bu konuda müdürümle konuşursam, çevreyi idare edemeyeceğimi düşünecek diye endişeleniyorum.


18
Ben bir erkeğim, genç (bu şirkette) ve benzer bir çifte standart hissettim. Kod temeli sık sık bok gibi görünüyor ve henüz daha yüksek bir standarda uymam bekleniyor. Geçmişte yapılan "ölüm yürüyüşleri" yüzünden içeri girdiği anlaşıldı. Ayrıca, görünüşe göre benden 5 yaş daha genç görünüyorum. Meslektaşlarım gerçek yaşımı öğrendiğinde, bir gecede daha akıllı oldum. İnsanlar kusurlu maymunlardır. Öğle yemeğini onlarla paylaşmanız ve şakalarına gülmenizde yardımcı olur, ancak aşırıya kaçmayın. Çocuklar her şeyi bir flört olarak yorumluyorlar.
İş

4
@Job: Eğer kod tabanı işe yaramazsa daha iyi olmalı, bu nedenle taahhütleriniz daha yüksek bir standarda sahip olmalıdır. Aksi takdirde daha da berbat olur, değil mi? :)
Macke

@Marcus, haklısın, ama kuralların açık bir şekilde belirtilmesi ve aynı kuralların herkese uygulanması durumunda asıl faydası olacaktır. Ayrıca, aynı kod standartlarına uymakla ilgili olarak, askerin dediği gibi söylenecek bir şey var. Günah keçisi olarak bırakılan küçük bir adam gördüm. Yönetim, mühendislerin çok fazla böcek ürettiğinden şikayet ediyordu. Mühendisler iyi bir iş bulamadılar çünkü yönetim onlara sabit tarihler verdi. Yani, bir şeyler ters gittiğinde, her zaman suçlayacak ve bırakacak en ufak tefekleri olan genç bir adam vardır. en.wikipedia.org/wiki/Dedovshchina
İş

3
Bana gösterilen bir şey "Onlar erkeklere alışkındır, böylece decorum kullanmazlar" dır. Açıkça bir ayrımcılık sorunu olmadığı sürece, bunu emmek zorunda olduğunu söyleyebilirim. Bir şantiyeye gidip diğer tüm çerçevelerden farklı muamele görmeyi bekler miydiniz? Sertleştirilmiş. Erkek egemen bir ortamda çalışıyorsanız, olduğu gibi farklı sosyal normlarla başa çıkabilmeniz ve uyum sağlayabilmeniz gerekir. Bu kadar "hassas" olmayın.
Rig

1
Bunun birkaç yıl geçtiğini biliyorum, ancak bunun gelecekteki okuyucular için önemli bir konu olduğunu düşünüyorum. Takım liderinizin daha iyi bilmesi ihtimalini dışlamayın; Muhtemelen daha kıdemlidir ve problemli stil kaygıları için bir sezgi geliştirmiştir - bu durumda herkese buna öğrenme ve büyüme fırsatı olarak bakması için meydan okuyorum. Anlamadığınız meselelere saygı duyulmasını isteyin ve meslektaşınızın kuru kişiliğini kötü niyetli olarak yanlış yorumlamamaya dikkat edin.
weberc2 20.03.2015

Yanıtlar:


41

Kadın olarak seçilme şansın var, ama aynı zamanda sadece küçük bir geliştirici ve iş için yeni olman da mümkün.

Hata kontrolü ve anlamlı mesajlar önemlidir. Koda bir şey ekleyecekseniz, doğru ve ekibin standartlarına uygun olduğundan emin olun. Benzer şekilde, başka birinin kodunu değiştiriyorsanız, mümkün olan yerlerde onu geliştirmeye çalışın - her şeyi yeniden yazmaya devam etmeyin, ancak bulduğunuzdan biraz daha temiz bırakmaya çalışın.

Ekibinizin takip ettiği kodlama standartlarının yazılı bir sürümü var mı? Olmazsa, hepsini yazmak iyi bir fikir olabilir. Yaptığınız hataları not ederek ve değişikliklerinizi incelemeye göndermeden önce başvurabileceğiniz bir kontrol listesine ekleyerek çabayı önemseyebilirsiniz. Bir yan etki olarak, bu yazılı standardı gelecekteki reddelere itiraz etmek için itiraz etmek için kullanabiliriz.

Sizinle takım lideriniz arasında bir anlayış eksikliği olabilir gibi görünüyor. Onunla bire bir görüşme istemeniz ve iyileştirmek için neler yapabileceğinizi tartışmanız yararlı olabilir. "Yapmam gereken şeyden hala çok fazla kaçık eksik olduğumu hissediyorum. Küçük bir geliştirici olarak büyümek ve gelişmek istiyorum. Oraya gitmeme yardım edebilir misin?" Gibi bir şeyle başa çıkabilirsiniz. ve ne olduğunu görün.


Anna'nın cevapları genellikle çok makul. +1. Çalıştığın yerde çalışmak beni deli eder. Yönetiminiz toplantı son tarihlerini umursamıyor mu? Kod çalışırsa, gönderin. Sonra temizle. Heck, Pazartesi günü bile temizleyebilir ve bir sonraki sürümde itebilirsin. Müdürünüzün bu davranışı benim iş yerime asla uçmaz ve politika yerine son teslim tarihlerine yoğunlaşabildiğime sevindim. Umarım durumunuz iyileşir ve bir çözüm bulursunuz. :)
jmort253

11
@ jmort253 Teşekkürler. :) "Kod çalışırsa, gönder" ifadesi tehlikeli bir tutum olabilir. Çalışma kodu her zaman iyi kod değildir (kesinlikle bozuk koddan daha iyi olmasına rağmen) ve kod kalitesi uzun vadede önemlidir. Daha sonra temizlik yapmak neredeyse hiçbir zaman gerçekleşmez, çünkü diğer son tarihler ortaya çıkmakta ve daha acil şeyler ortaya çıkmaktadır. Bunun için bir terim var - "teknik borç".
Adam Lear

@Anna, uygun kodun önemine katılıyorum. Uygun olmayan kodun Linus Thorvalds'ın Linux için sunulan bir yamayı anında reddetmesi için yeterli olduğunu okudum (ancak şu anda bulamıyorum).

@ Anna / Thorbjorn - Bazen sadece bir son teslim tarihi geçmişse müşterinin istediğini yapmak zorundasın. Müşteriniz, 15.000 ABD Doları değerindeki işletme kazancını kaybederse, çok büyük bir anlam ifade etmeyecektir, çünkü yalnızca büyük harf kullanım hatalarını temizlemek istediğinizde. Ne yazık ki, teknik borcun% 100'ünü elimine etmeye çalışmak her zaman mümkün değildir. Bir ipotek almak yerine hayalinizdeki evi satın almak için yeterli para biriktirmek için 40 yıl beklemek benzer olacaktır. Tabii, özgür ve net olursunuz, ama bütün hayatınızı gölgeli toprak ağaları ile uğraşarak geçirirsiniz.
jmort253

Açık kaynaklı projeler kar projelerinden farklıdır. Birçok açık kaynaklı proje daha sıkı standartlara sahip olabilir, çünkü her zaman sahip olunan / kaybedilen kar yoktur. Özel projelerin farklı hedefleri vardır ve bazen bu iş hedefleri önceliklidir. Kodun uymaması gerektiğini söylemiyorum, sadece bazen yapmanız gerekenleri yapmanız ve geri dönüp konuşlandırmadan sonra sorunu çözmek için disipline sahip olmanız gerekir.
jmort253

25

Bu şeyi kişisel olarak biraz fazla alıyor gibisin. Yapma; bu tür şeyler her zaman olur.

Girişinizi reddetme nedenleri (değişken adlandırma, yorum kalitesi, yapılandırma yeri) benim için oldukça standart görünüyor.

Bunun zamanlaması takımınızın liderliği kararıydı ve siz yerinde olsam endişelenmezdim. Birisi hafta sonu boyunca engellenmişse, takım lideri check-in'e izin vermeyi seçebilir ve daha sonra düzeltmenizi isteyebilir. Başka bazı dev'ları engelleyebilse bile, onu geri atmanın uygun olduğunu hissettiği zaman, bu onun sorumluluğudur.

Takım liderine gelince, başkalarını taklit etmemenizi, doğru olanı yapmanız gerektiğini söylemenizi sağlar, size kod tabanını daha iyi hale getirmek için bazı inisiyatifler vermeye çalışıyor gibi görünüyor. Bu iyi bir işaret. Kararını kullanman için sana güveniyor , bu yüzden devam et ve doğru olduğunu bildiğini yap. Bu, başkalarının kodunu değiştirmeye gitmeniz gerektiği anlamına gelmez, ancak yazdığınız kodun kalitesi için sorumluluk almanız gerektiği anlamına gelir.


2
+1 İlişkilere ve duygulara odaklanıyorsunuz. Çalıştığınız programcılar ses açısından çok kuru ama sadece kod konularına odaklanıyorlar. Bu çalıştığım programlama ortamlarında oldukça yaygın. Bu arada cinsiyetten bağımsız olarak bunu gördüm.
Michael Durrant

14

Diğer cevaplara bir ek:

Bir Lider Geliştirici olarak, genellikle küçüklerin ilgisini çekerim, çünkü birkaç yıldır çalışan insanlardan daha dövülebilirler. (Benim ppl becerilerim o kadar iyi değil ... henüz.)

Bir süredir çalışmakta olan (ve iyi maaş alan) birisini değiştirmek ve kod seviyesinden memnun olmak (kalitesi artırılsa bile) çok zor. Bu adamlar daha iyi / harika programcılar olmaları için onları yönlendirmeye çalışmanızın umrunda değil. Kod fabrikasında çalışmaktan mutlular.

Kendin gibi, yeni çocuklar OTOH, rehberlik etmek ve neyin doğru olup olmadığını bilmek için can atıyor. Ayrıca, geri dönüşü absorbe edebiliyorlar ve yollarını daha iyi hale getirebiliyorlar. Onlar böyle şekillendirilmezler.

Bu tavsiyeleri yürekten alıp günlük hayatınızın bir parçası haline getirirseniz, kısa sürede mevcut kod tabanından daha üstün olan bir kod yazacağınızı göreceksiniz.

Yani ...

.. sadece bir şeyler yapma potansiyeline sahip olduğunuz için daha fazla geribildirim alıyor olabilirsiniz. :)


Bu, birçok iyi noktayı ortaya çıkarır.
sevenseacat

13

Seçilmiş olmanız tamamen olası çünkü küçük bir geliştiricisin.

Açıklamanıza göre, takım liderinin algıladığı gibi standardı takip etmemiş gibisiniz .

Çözüm basit:

  • Standart ise, izleyin.
  • Standardı anlamadıysanız, açıklama isteyin.
  • Standart veya talimatların yorumunuz takım liderinden farklı ise, açıklama isteyin

Ondan bir savaş yapmayın; Eğer takımı "yanlış" yapmaya çalışırsan kazanırsan bile kaybedersin. Uygun dersi alın ve büyümeye devam edin.


1
Biri, tanımladığı gibi salaklarla uğraşırken "T" ye kadar bir "standart" izlemeye çalışmak pek de işe yaramaz. Tanımlar ve anlambilim üzerine sonsuz bir argüman olacak.
MrDatabase

4
@MrDatabase Onlar bana salak gibi ses gelmiyor. Belki biraz titiz, ama şeytanın çoğu ayrıntıda olur ve standartlarınızı değiştirmeye başladığınızda tüm uygulamanız yokuş aşağı hızlı ilerleyebilir.
Adam Lear

3
Standartlara saygı duyulması gerektiği doğru. Ancak, bunun gerçekten bir standart olmadığını açıkça göstermektedir (önceki geliştiriciler buna uymuyordu). Bu yüzden iş arkadaşları onun üzerine "standart" empoze ediyorlar ("hey bak ..." gibi bir şey demeden, bunun tutarsız göründüğünü biliyoruz, ancak gerçekten kod tabanımızı geliştirmeye çalışıyoruz ") ikiyüzlü ve yararsızdır. İş arkadaşları böyle davrandığında, daha farklı ve daha akıllı bir yaklaşım izlemelisiniz.
MrDatabase

@ user15859: Cevabımı kastediyorsanız, bu benim niyetim değildi. Sanırım aynen Anna'nın cevabında söylediği şeyi de söyledim. Suç amaçlanmadı. Bahsettiğiniz standart ihlalleri uzun süreli bakım için önemlidir ve standartların uygulanması kapsamındaki herhangi bir belirsizlik takım liderinizle çözülmelidir. Tembel olsaydın buraya göndermezdin. Beceriksiz olsaydın çok fazla umursamazdın. İkisinin de olduğuna inanmıyorum.
Steven A. Lowe

1
Bence Woot4Moot'un "tembellik ve beceriksiz" ifadesini yorumunda bir cümle olarak kullandığı sırada ne söylediğini kastettiğini düşünüyorum. Bence, OP'nin gerçekte neler olduğuna dair yorumuna dayanarak harekete geçmesi için bir miktar başvuru ve alan sağladığı için cevabınızın iyi olduğunu düşünüyorum.
jmort253

10

Yazarın notu

Birkaç yıl sonra; Bu durumu nasıl hissettiğimi daha doğru yansıtacak şekilde düzenledim. Cevabımı daha fazla nüansa sokuyorum çünkü bu durumlarda nüans hakkında daha fazla şey öğreniyorum. 'Siyah ya da beyaz' bir cevap istemek kolaydır, ancak hepimiz bunun o kadar basit olmadığını biliyoruz. Cevabım şimdi bunu yansıtıyor.

Tanımladığınızdan; Yaşamakta olduğunuz davranış cinsiyetinizle ilgisi var gibi görünmüyor. Bu, cinsiyetle ilgili herhangi bir tedavi yaşamadığınızı söylemek değildir (umarım öyle değildir), yalnızca tanımladığınız şey cinsiyetle ilişkili görünmüyor.

Takım lideriyken herkese eşit davrandım. Teknolojide birisine cinsiyetlerinden dolayı kötü davranmak için yer yok. Sana oluyorsa bununla nasıl başa çıkacağımı bilmiyorum.

Takım liderinizin kadınlara ve erkeklere eşit davranması konusunda güvenmeniz önemlidir. Olmadığına dair bir kanıt varsa, eski sözler geçerlidir: Ortamınızı değiştirin veya ortamınızı değiştirin.

Eşit olarak demek istediğim, herkese eşit davranmaksızın cinsiyete eşit davranmasıdır. İşini doğru yapıyorsa, başkasını eleştirdiğini görmemelisin; ve seni eleştirirken onu görmemeliler. Diğerlerinin önünde, özel olarak davranışını düzelten son beş dakikayı geçirmiş olsa bile, takım liderinin kendine güven göstermesi çok önemlidir.

Şimdi gündeme getirdiğiniz sorunlara:

Belirlediği standarda uymayan kodu kontrol ettiniz, bu yüzden şubenizi reddetti. Eğer onun yerinde olsaydım, aynı şeyi aynı şekilde yapmazdım, ama astlarımın (tuhaf bir kelime; çünkü onlar için "üstün" olarak bir lider düşünmüyorum.) Liderlik etmek, ancak doğru (yeterince değil) durumu açıklar) ne yapılması gerektiğini bilir. Standartların ne olduğunu bilmiyorlarsa, lider olarak benim hatam. Düzeltmek bana kalmış. Bu durumda, bir hata yapmış olabilirsiniz, ancak bunun gerçekleştiği gerçeği, ya 1) yapmanız gereken doğru şeyin ne olduğunu söylemediğinizden ya da 2) uygun şekilde akıl hocası olmadığı anlamına gelir. Senin de suçun değil.

Programcı olmanın en önemli parçalarından biri, üzerinde çalıştığınız kod tabanının birçok farklı kişi tarafından korunabilmesi gerektiğinin farkına varmaktır. Değişken mesajlar veya kodu okuyamayacağından sapan diğer şeyler müşteriye karşı şeffaf değildir , çünkü kodda okunması zor olan sorunları çözmek daha uzun sürer.

Ekibiniz kodlama kuralları yazdıysa, onları takip edin. Olmazsa, o zaman diliniz için bir tür topluluk sözleşmesi yapılmalıdır (.NET ve C # için Microsoft, pek çok şirketin takip ettiği bir standarda sahiptir).

Takım liderinize kodlama kurallarının nerede olduğunu sorun, böylece onları takip ettiğinizden emin olun. İki geliştiricinin yönergeleri tutarlı bir şekilde takip etmediği toplantılara iki kez giriş yapın, böylece hiçbir şey olmadığını söylediğinde, başkalarının da onunla sorun yaşadığını ve herkesin bundan faydalanabileceğini belirtebilirsiniz. bu kurallar.

Size adil davranıyorsa, o zaman bunu görecek ve bu yapılacaklar listesinin başında olmalı. Size adil davranmıyorsa, devam ederse cephaneniz vardır.

"Sonra anlatacağım" demek kötü. Daha sonra asla olmaz. Doğru yapmak için zaman ayırın. Programlamada daha sonra yoktur.

Küçük bir geliştirici olduğunuzda zor. Gerçekleştirmeniz için baskı altında hissediyorsunuz ve size bakan birçok insan var ve yaptığınız her hata sonsuza dek kaynak kontrolünde adınıza bağlı.


1
"Daha sonra anlatacağım" hakkındaki yorumu ikinci olarak vereceğim. Bunu her duyduğumda bir nikel olsaydı, bu yorumu yazarak burada olmazdım. :-)
Eric King

Net için stil polisi var. Açın, böylece StyleCop mutlu olana kadar bu kod oluşturulmayacak. Bu insan öznelliğini ortadan kaldırır iş gücü zorbalığıdır. Teknoloji, Michael Phelps'in # 1 mi yoksa 2 mi olduğuna karar vermenize yardımcı olabilir. Artistik patinajda , ancak ... figureskating.about.com/od/famousskaters/tp/scandals.htm Takım lideri olmak, güç açma konusunda olmamalıdır. Bir takımda [favoriler] olmamalıdır. Böyle bir izlenimin oluşmadığından emin olmak için dikkatli olunmalıdır. Bunu yapmanın iyi bir yolu, kodu kontrol edip size tarafsız bir cevap verecek kuralları açmaktır.
İş

3

Yazınızın hiçbir yerinde, etrafta başkalarına nasıl davranıldığından bahsetmiyorsunuz. "Kadin oldugunu" çünkü "kadin oldugunu" "hissettigini" tekrarlamaya devam ediyorsun.

Cinsiyetinizden bağımsız olarak küçük bir programcı gibi davranıldığını düşünüyorum ve bunun için şükretmelisin, çünkü eşitlik budur. Ayrıca, yapılacaklar listesine koyup şimdiye kadar dolaşmamaları yerine, şimdi yapılması istenmekte olan küçük, 5 dakikalık uzun kod kodlu estetik değişiklikler konusunda büyük bir yaygara yaptığınızı da hissediyorum.

Yazınızın hiçbir yerinde hafta sonu böyle şeyler yapmanızın istendiğini söylemediniz. Düzeltmeleri pazartesi sabahı kontrol etmek mükemmel olabilir.

Takım lideriniz zevklerim için biraz sersemletici olabilir, ancak görevinizden gelen isteklerinde yanlış bir şey görmüyorum.

Lütfen cinsiyet kartını boşuna oynamayı bırak . Bunun tanımlanmamış olduğunu ve cinsiyet eşitliği kavramını baltaladığını düşünüyorum.


1

Şubemi bu temelde reddetmenin faydalı olduğunu sanmıyorum. Hafta sonu boyunca birçok insan çalışıyordu ve ben de çalışacağımı asla söylememiştim. Etkili olarak, bazı insanlar muhtemelen engellendi çünkü değişiklikleri yapmak ve yeniden göndermek için zamanım yoktu. Çok zamana duyarlı bir proje üzerinde çalışıyoruz ve bana göre müşteriye şeffaf olan şeylere dayanarak kodun tamamen reddedilmesinin faydası yok gibi görünüyor. Yanılıyor olabilirim, ancak zamanım olduğunda bu tür şeylerin yama tipi işlemlerde ele alınması gerektiği gibi görünüyor.

Kodunuzu görmeyen ya da proje zamanlamanız hakkında bir şeyler bilen biri olarak faydalı bir şey söylemek zor. Ancak, lideriniz sorumlu davranırsa ve iyi bir iş çıkarırsa, başkalarının gerçekten engellenmediğini ve sprintin geç kalmayacağını bilir. Yani, bunun için endişelenme. Belki de taahhüdünüz üzerindeki etkiyi abartıyorsunuz. Aksi halde: Projeniz zaman açısından kritik öneme sahipse ve tüm testleri geçerse, göz açıp kapayıncaya kadar yayınlandıktan sonra düzeltilebilecek kodu reddetmek çok seçici olacaktır.

Çalışmasını Sağlayın Yapmasını Sağlayın Hızlı Yapın

Dolayısıyla, lideriniz , ne yapması gerektiğini bilmesi gereken bir profesyonel olarak taahhüdünüzü reddetme kararı aldıysa

Şimdi, bazı ortamlarda bunun norm olacağını görebiliyorum. Bununla birlikte, eleştiri eşit derecede dağılmış görünmüyor, bu da bir sonraki sorunuma yol açtı. Bu sorunların çoğunun temeli, bir başkasının yazdığı ve asgari derecede saldırgan olmaya çalıştığım bir kod tabanında bulunmamdan kaynaklanıyordu. Dosyanın başka bir yerinde kullanılan değişken isimlerini taklit ediyordum. Bunu söylediğimde, açıkça "Başkalarını taklit etme, sadece doğru olanı yap" demiştim.

Bir Junior olarak, bir şirketin kod tabanına girenleri bulmak zordur.

En iyisi: belgelendirilmiş kodlama standartları vardır - ve umarız bunları ele almayı öğrenirsiniz.

Genellikle: Orada olan belgesiz kodlama standartları - ve üzeri öğrenmek zorunda deneme ve yanılma veya demeliyim taahhüt ve _reject? Bu çoğu zaman acı verici (sizin durumunuzda olduğu gibi). Bu bazen kod kalitesi açısından tehlikelidir ve yalnızca değişken isimlendirmeyi taklit etmekle kalmayıp aynı zamanda kod tabanındaki yapıları ve desenleri iyi niyetle kopyalamak ve yapıştırmak yerine kargo kültü programlamasına yol açabilir . Böyle yapma! Mevcut değişken isimlerini bile taklit etmeyin.

Şifreyi Temizle . Bu iyi bir uygulamadır ve size savunmanız için kolay bir yol sunar. Okunabilir, test edilebilir ve bakımı yapılabilir bir kodsa, çoğunlukla herhangi bir tartışma kazandınız.

Bu da bir başka (son) tavsiyeye yol açar: İzci kuralına uyun !

Kod tabanını her zaman olduğundan daha iyi bir durumda bırakın. Çalıştığınız çevre kodu pis olsa bile, sizinkileri temizleyin; çevreyi düzeltmek için zamanınız varsa.


0

İş arkadaşlarınızın kişiliğinin çeşitli nüanslarını öğrenmek için biraz zaman ayırın. Tecrübelerime göre, iş arkadaşlarınızın tuhaflıkları etrafında çalışırsanız irrasyonel, gereksiz, tutarsız veya adil olmayan değersiz eleştirilerden kaçınabilirsiniz.

Örneğin, bazı iş arkadaşları Pazartesi günleri akşamdan kalma olabilir. Bunlar, bazı kod dallarını veya taahhütlerini reddetmek için çok huzursuz ve aşırı istekli olabilirler. Eğer böyle biriyle çalışmak zorundaysanız, pazartesi günleri kod işlemekten kaçının.

Öte yandan, bir akşamdan kalma iş arkadaşı, hata mesajlarının ayrıntılarıyla ilgilenmek için çok fazla mazeret duyuyor olabilir ... bu nedenle Pazartesi sabahı, kodunuzu almanız için mükemmel bir zaman olabilir :-p

Kişilik, ofiste ya da iş yerindeki tuhaflıklar anlamıyla sonsuzdur. Umarım kimlerden kaçınacağınızı ve ne zaman kaçınacağınızı öğrenebilirsiniz. Ayrıca kendin için fazla zor olma :-) Her zaman istifa edip başka bir iş bulabilirsin!


1
İstifa etmeden önce işi bulun, işe alınmazsanız birçok işe alım yöneticisi röportaj yapmaz.
Woot4Moo

-2

Belirli sözleşmelere uyulmadığı takdirde, kodun reddedildiği bir ortamda hiç çalışmadım. Ayakkabının içinde olsaydım, doğru kararlar alma konusunda daha fazla yetkin olduğum ve müşterinin öncelikli odak noktası olduğu yer olan iş aramak için cazip olurdum.

Temiz kod ve standartların önemli olmadığını söylemiyorum, ancak teknik personel, müşteri veya yönetici asla görmeyeceği bir şeydeki yazım hatası nedeniyle müşteri ve ürün zaman çizelgesi zarar görmemelidir.

Bununla birlikte, beklentilerin açık olmadığı bir ortamda çalışıyor olabilirsiniz veya gereklilikleri ne olursa olsun gereklilikleri tam olarak anlamadınız.

Durum ne olursa olsun, kontrolü ele almak ve açıklayıcı sorular sormak size kalmıştır. Henüz yapmadıysanız proaktif olun. Ekip üyeleriniz ve takım lideriniz, check-in kurallarını açıklığa kavuşturmak için sorular sormanız konusunda size daha fazla saygı duyacaktır. Ayrıca, sizin ve ekibinizin liderinin bunun yerine ne yapmanız gerektiğini ve nasıl yaptığınızı tartıştığı "eylem sonrası bir inceleme" isteyebilirsiniz. Belirli işlemleri ne zaman ve ne zaman yapmamanız gerektiği farkını söyleyebilir.

Yeni olduğunuz için, herhangi bir engelin üstesinden gelip gelemeyeceğinizi ve bu sorunları deneyim, iletişim ve standartları öğrenerek çözüp çözemeyeceğinizi görmek için zaman vermenizi öneririm. Bununla birlikte, birkaç ay sonra durum değişmediyse ve çevre hala belirsizlikten etkilenmişse, başka bir şirkette iş arama zamanı gelebilir.

Her organizasyon bu ejderha değildir ve kişiliğinize, tarzınıza ve iletişim gereksinimlerinize daha uygun başka çalışma ortamları bulabilirsiniz.


2
Bu "draconian" görünmüyor; tutarlılık, sürdürülebilirlikte önemli bir bileşendir, sürdürülebilirlik, kalite açısından önemli bir bileşendir ve kaliteli yazılım, zamanında ve daha düşük maliyetle, “kural kodundan” daha fazla nakliye şansına sahiptir. Yazılım şirketlerinin% 80'i gibi bir şeyin kaliteden ödün vermek ve sonuçlara katlanmak için istekli olması cesaret verici olabilir, bu nedenle "ejderha dışı" istihdam fırsatlarında herhangi bir sıkıntı yaşanmıyor gibi görünüyor. :)
weberc2 20.03.2015

1
Temel konvansiyonlar bir ortamda çalışmaları istemem değil zorlanan. Bir proje kodlama kurallarını savunmaktan vazgeçerse, uzun vadede sürdürülemez hale gelmeye mahkumdur. Özellikle değişken adlandırma küçük bir şey değildir: Belli bir matris ne kadar varolan kod olursa olsun A, Btutarlılık için başka bir matris dediğimiz bir taahhüdü asla kabul etmem . Tabii ki, OP'nin "başka yerlerde kullanılan isimleri başka yerlerde kullanılan [...] taklit etmek" tam olarak ne anlama geldiğini bilmiyorum, ancak gördüğüm bazı kodların kalitesi göz önüne alındığında, bu satırlar boyunca olabilir.
cmaster
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.