Maalesef, BT'de çalışırken kural bakımdır, çok nadiren yeni projeler olur ve insanlar projelerde düzenli olarak yeniden görevlendirilir. Ve profesyonel yaşamınızda korumanız gereken kodun kalitesi büyük ölçüde farklılık gösterse de, hiçbir zaman yeni 2-6 aylık bir proje gibi kokmazlar.

Ancak yapabileceğiniz şeyler var belki hayatınızı ve geleceğinizi biraz daha yaşanabilir hale getirmek için yapın. Mevcut projeyi zihinsel olarak modüllere ayırarak başlayıp, daha katı kodlama standartlarına uygun olarak bunları teker teker yeniden düzenlemek veya yeniden yazmak için izin istemekle başlayacaktım. Yazdığınız veya geliştirdiğiniz her şey hakkında bol miktarda test yazdığınızdan emin olun.

Bu, çalışma hayatınızın yavaş ve istikrarlı bir şekilde geliştiğini görmelidir, çünkü bu yaklaşım uygulamaya daha aşina olmanızı sağlayacak ve parçaların okunabilirliğini artıracaktır. ve böcekleri daha az yaygın hale getirir.

Bunun sahibine / lideri / patronuna nasıl satılacağı, kurumsal yapıya ve ilgili kişilere bağlı olarak büyük ölçüde değişir. Ancak bu sizin için gerçekten dayanılmazsa ve bir şeyleri iyileştirme gücünüz yoksa, o zaman farklı türde bir iş bulmak daha iyi olabilir.

Genel olarak, danışmanlar genel olarak daha fazlası üzerinde çalışacak gibi görünüyor yeni kodlar ve bir projeden diğerine geçme konusunda daha fazla esnekliğe sahipler veya öncelikle yeni (imsi) uygulamalara odaklanıyorlar.

Ancak, eski kod her zaman seçtiğiniz mesleğin bir parçası olacak, ve bununla iyi geçinmeyi öğrenmeniz ve bu gerçekle yaşamanız gerekecek.

Evet, müdürünüze işinizden zevk almadığınızı söylemeniz ve eğlenceli bir şey istemeniz mantıklı.

Bu müdürün sizden bunu ısrarla istemesi de makul. Yapılması gereken bir iş vardır ve iş her zaman eğlenceli olamaz.

İyi bir yönetici, yararlılığınızı ve onlar için çalışma isteğinizi yaktıklarını fark edecek ve yapmaya çalışacaktır. farklı projelere biraz zaman ayırmanızı ayarlayın, ancak bu garanti değildir! Bu işi yapabilen tek geliştirici sizseniz, orada sıkışıp kalabilirsiniz.

Bu eylem tarzına yardımcı olmak için, zamanınızı harcamak isteyeceğiniz bir şey hazırlamak iyi bir fikirdir: başlattığınız projeler, belki başka bir proje veya hatta becerilerinizi geliştirmek için bir kurs. Bu, bir isteği Plana dönüştürmeye yardımcı olur .

Kötü bir yönetici, "aptalca şeylerden şikayet ettiği" için size kızar, bu mantıksızdır, ancak ilk siz olmazsınız geri itme almak için.

Bunu önlemek için işi Eğlenceli Değil yapan şeylerin somut bir listesine sahip olun: aptal hatalar, tekrarlanan bildirimler, yorumlanmamış kod. Bu, bir şikayeti Geri Bildirime dönüştürür ve sorularınızın daha makul görünmesini sağlar.

Sorum: Şu anda yapmam gereken işi gerçekten sevmediğim için yöneticimden beni başka bir projeye koymasını istemek mantıklı olur mu ve bunu nasıl söylerim?

Hayır, makul olmaz. Bir programcı olmanın bir parçası da var olan programları, özellikleri ekleyip kaldırarak veya hataları düzelterek sürdürmektir. Sıfırdan başladığınız bazı projelerde çalıştığınız için şanslıydınız ama her projenin böyle olmasını bekleyemezsiniz. Bazen, bir süre için, işletmeler sıfırdan başlatılan yeni projelere ihtiyaç duymaz (bu, bir daha asla olmayacakları anlamına gelmez) ve sadece mevcut projeleri sürdürmeleri gerekir.

Ne yapmalısınız? mevcut projenizin sahipliğini almaktır. 6 yaşında olduğunu ve üzerinde başka 5 programcının çalıştığını unutun. Dağınıksa ve hatalarla doluysa, projeyi düzeltmek için inisiyatif kullanın. Bu proje üzerinde çalışmak zorunda kalmaktan şikayet etmek ve size farklı işler atamak yerine projeyi başarılı bir şekilde istikrarlı bir duruma getirirseniz, kesinlikle yöneticinizin gözünde daha iyi görüneceksiniz.

Her zaman sorabilirsiniz, ancak onlar da her zaman hayır diyebilirler.

Sözleşmenizde yalnızca sevdiğiniz projelerde çalışacağınızı belirtmediğiniz sürece, sizi gördükleri gibi projelere koyabilirler.

Yapmak isteyeceğiniz değişiklikleri (yeniden düzenleme, belge yazma, ...) ve daha az hatayla kazanılan zaman açısından şirket için faydaları belgeleyebilirsiniz.

Ya da daha iyi uygulamalarla ürünün yeni bir gelişimini savunabilirsiniz. Ancak, eski projenin kullanıcılara ödeme yapması gerektiği ve birilerinin bunu sürdürmesi gerektiği ve onlar da sizi Pikachu'yu seçtiği sürece.

Yaptığınız şeyi (Otobüs faktörü) daha fazla insanın yapmasını isteyebilirsiniz, böylece diğer projeler üzerinde de çalışın. Bunlar eski projeden daha önemli hale gelirse, bunlar bir çıkış haline gelebilir.

Yine de: Firmanıza ödeyen ve dolayısıyla bu proje için patronlarınıza maaş ödeyen insanlar olduğu ve firmanız olmadığı sürece. Bundan vazgeçmeye meyilliyseniz, birisinin hataları düzeltmesi gerekecek.

Son çare olarak istifa edip serbest meslek sahibi olarak çalışabilirsiniz. Orada gerçekten üzerinde çalıştığınız projeleri seçebilir, ancak ışıkları açık tutmaktan gerçekten hoşlanmadığınız bazı projeleri yapmak zorunda kalmaya hazır olun. Yalnızca en iyi ve en iyi tanınanlar yaptıklarını tam olarak seçebilir.

tl; dr: İşvereninize karşı dürüst olun. Onlara yalnızca sıfırdan projeler ile ilgilendiğinizi söyleyin. Ancak, bu kararı vermenin, muhtemelen hizmetlerinizin artık gerekli olmadığı noktaya kadar, teklif alacağınız işi önemli ölçüde sınırlayacağını unutmayın.

Profesyonel yazılım geliştirmedeki en önemli şeylerden biri, paylaşılan bir kod tabanı üzerinde işbirliğidir . Bir rock yıldızı solisti değilseniz, kod tabanının her zaman geçmiş ve şimdiki meslektaşları tarafından şekillendirilmiş bir geçmişi olacaktır - ve muhtemelen geçmişte sizin de .

Daha önce de belirttiğiniz gibi, kodu okumak onu yazmaktan çok daha zordur - işte bu yüzden bu beceri bu kadar önemlidir. Mevcut bir projenin köşelerini ve çatlaklarını öğrenmek ve anlamak çok fazla beceri ve sabır gerektirir. Her şeye yeniden başlamak, hatta muhtemelen kullanılan teknolojileri ve çerçeveleri seçmek daha kolaydır ve geliştirici için daha hoştur.

Ticari yazılım her zaman iş amacına hizmet eder. Bu, yalnızca yeni başlayanlar veya pazarlama ile çalışmadığınız sürece, yazılımın makul bir yaşam beklentisine sahip olması gerektiği anlamına gelir. Mevcut çözümleri ve özellikle mevcut ticari çıkarları tanımak için fazladan çaba sarf eden geliştiriciler, kendilerini değerli kılan ve genellikle değiştirilmeleri zor olan geliştiricilerdir.

Sizin gibi Eski kodla çalışmak her zaman (hiç mi?) kolay, hatasız veya temiz değildir. Düşünmenizi önereceğim şey, işleri tersine çevirmektir: Her imkansız spagetti kopya-makarna parçacığı, birim testleri ile harika bir yeniden düzenleme için bir fırsattır ; her hata raporu, işletmeyi ve son kullanıcıları kusursuz müşteri hizmetleri ile etkilemek için bir şanstır.

Ekibim şu anda, şirketimiz orijinal geliştiricileri satın aldığında şirketimize ait olan iki ürünün bakımını yapıyor. Bu satın alımların mümkün olmasının nedeni, diğer şirketlerin finansal olarak iyi performans göstermemesidir.

İki üründen sadece biri üzerinde çalışıyorum. Önceleri, yol katliamında çalışan tahnitçi olmak gibiydi. Orijinal kodlama ekibinin bir daha asla bilgisayarlara dokunmasına izin verilmemelidir. Amirim diğer üründen sorumludur ve bu aynı zamanda bir felakettir.

Bu çöplük yangınları üzerinde çalışmanın başlıca yararı, bunun nasıl yapılmadığı konusunda sağlam dersler almamızdır. bir şeyler yapmak için ve hatta sektörde üç yıl geçirmiş olsanız bile, üzerinde çalıştığınız ürünlerden böyle bir şey öğreniyorsunuz.

Durumunuza, uğraşmak zorunda kalmamanız gereken bir şey olarak bakmayı bırakın ve bunun yerine şirketinizin ürününü eskisinden daha iyi hale nasıl getireceğinize bakın.

Kolay bir ilk adım olarak, bir kod parçasının ne yaptığını anlamak zorunda olduğunuz her seferinde, kodun ne yaptığını tam olarak açıklayan kod. Bana çok yardımcı olduğunu görmeme rağmen, size yardımcı olmayabilir, ancak koda bakacak bir sonraki kişinin onu çözmesi gerekmeyecek.

Şimdiden pek çok harika yanıt var, ancak buna 0,02 sterlinimi ekledim.

Eski yazılımı korumak, yeni bir şey oluşturmaktan daha zordur, aynı zamanda başlı başına değerli bir beceridir.

Yapabilmek Yıllardır var olan, kötü dokümantasyonlu veya hiç dokümantasyonsuz ve üzerinde çalışan birçok geliştiriciden birçok farklı kodlama stilini içeren bir kod tabanına atlamak, özellikle kurumsal dünyada birçok işverenin aktif olarak aradığı bir şeydir.

Belge yoksa, bazılarını yazın. Otomatikleştirilmiş test yoksa, test edilebilir olması için kodu yeniden düzenlemeye çalışın ve bazı testler yazın. Kodlama stilleri her yerde bulunuyorsa, dil veya çerçeve için önerilen stilleri araştırın ve kod tabanını önerilen kodlama stiliyle eşleşecek şekilde yeniden düzenleme üzerinde çalışın.

Mutlu olan biri olarak itibar kazanmak eski kodla çalışmak ve bunu kimin iyi yaptığı, kariyeriniz için yeni ve parlak çerçevelerle sıfırdan projelerde çalışmak kadar iyi olabilir.

Zaman geçtikçe, üretimdeki eski kod miktarı artar. yalnızca artacak ve bununla ilgilenebilecek, hataları düzeltebilecek ve yeni özellikler ekleyebilecek geliştiricilere olan talep, bununla birlikte artacak, çünkü bu uygulamaları yeni teknolojiyle yeniden yazmak genellikle birçok kişi için kötü bir fikir olarak kabul ediliyor. iyi nedenler.

İyi şanslar!

Eski bakım, geliştiricinin iyi uygulama arzusunu oluşturur

Yalnızca bir lider geliştiricinin bakış açısını eklemek istiyorum, çünkü bir geliştirici olarak eski kodu korumak istememeyi değil, bir lider geliştirici olarak katılıyorum Hiçbir geliştiricinin bundan kaçınmasını savunmuyorum.

Durumumu ortaya koymak için pratik bir örnek kullanacağım. Bir danışman olarak, genellikle kod kalitesi sorunları olan bir şirkete / projeye gönderilirim, burada işim işleri doğru yapmaktır. Tahmin edebileceğiniz gibi, kötü kod çok sayıda eski bakıma yol açar.

Kötü kod yazan geliştiricilerin iki kamptan birinde olması benim en önemli deneyimimdi:

• Daha iyisini bilmeyenler
• Doğru şeyi yaptıklarını düşünenler

Eski grubun üstesinden gelmek kolaydır, çünkü hemen gelişecekler onlara iyi bir uygulama gösterdiğinde. Bununla birlikte, ikinci grubu ikna etmek çok daha zordur, çünkü kısa vadede genellikle daha fazla çaba gerektiren iyi uygulamanın faydasını görmezler. Uzun vadede kâr payını geri ödüyor, ancak ikinci grup genellikle bu noktayı gözden kaçırıyor.

İkinci kampta bulunan ilgilendiğim hemen hemen her geliştirici, projeden projeye atlamayı başaran geliştiricilerdi kendi kodlarının bakımını atlamak . Kusurlu tasarım kararlarının sonuçlarıyla hiçbir zaman karşılaşmadıkları için, bu sorunların, uygulama ilk geliştirilirken ortaya çıkmadan önce ortaya çıkmasını engellemeye asla teşvik edilmediler.

Çözüm basit: geliştiriciler sahipliği almalıdır . Hatalı kod yazarsanız, ortaya çıkan hatalarla ilgilenirsiniz. Zamanınızı hataları düzeltmek için harcamak istemiyorsanız, o zaman onları üretmeyen kod yazmak size kalmıştır.
Bu, geliştiricilerin ona karşı zorlanmak yerine kendilerini geliştirmeleri için çok basit bir teşvik oluşturur. iradeleri ve neden daha iyi bir yaklaşım olduğunu anlamadıkları için.

Bundan çıkarmanızı istediğim şey, geliştiricilerin neden iyi uygulamaya ihtiyaç duyduklarını hatırlamaları için eski bakımın şart olduğudur .
Bir benzetme olarak, siperde olan bir general adamları, ülkenin diğer tarafındaki bir sarayda rahatça oturan bir generalden daha iyi kararlar alacaklardır (askerler için). Bir geliştiricinin, genel olduklarında (= yeni uygulamayı oluştururken) tasarım kararlarının etkisini bilmeleri için ellerini kirletmesi gerekir.

Başkalarının peşinden gitmek

Bununla birlikte, kendi böceklerinizle değil, sizden önce gelen insanlarla karşı karşıyasınız. Şu anda aynı gemideyim ve bunun savunulabilir bir durum olmadığı konusunda sizinle aynı fikirdeyim.
Hiç kimse eski bakımı sevmiyor ve görünüşe göre yöneticiniz yalnızca eski bakımı nasıl yaptığınızı dikkate almadı hem de moralinizi ve kişisel kariyer gelişiminizi etkiler.

3 yılımı eski bakım için harcadım, ancak evden çok gevşek bir çalışma ile rahat bir işti. İş / yaşam dengesi kötü olmasa da, sektöre ilişkin güncel bilgiler kazanmadığım için kariyerimin durduğunu anlamam biraz zaman aldı. Bu işten 5 yıl sonra kovulmuş olsaydım, becerilerim diğer şirketler için o kadar eski olurdu ki, kaybedilen zamanı telafi etmek için uğraşmam gerekirdi.

Öte yandan, birisinin bu projeyi desteklemesi gerekiyor. Yani "ben değilim" yaklaşımını benimseyemezsiniz, çünkü her geliştirici aynı "ben değilim" yaklaşımını öne çıkarır ve ardından yönetim, kısa çöpü çekecek birini atamakla yükümlüdür (bu, başlamak için bu konum).

Sorunu ele alma

Yöneticinize yaklaşın ve ona eski projenin destek gerektirdiğini anladığınız halde, hiçbir şey yapmamanız ancak eski kodla uğraşmamanızın moral kaybı olduğunu açıklayın. Yöneticinizin sizi farklı (eski olmayan) bir yarı zamanlı projeye atamayı düşünüp düşünmediğini sorun.

Tecrübelerime göre, mantıklı yöneticilerin çoğu bunu anlayacak (muhtemelen siz bu işe atandınız çünkü hepsinden ayrılan diğer 5 geliştirici aynı noktayı tartıştılar) ve sizi korumanın faydasını görecek (zaten bilen biri eski projeyi yarı zamanlı olarak terk etmenize ve eski projeyi bilmeyen yeni bir geliştirici bulmaya ihtiyaç duymanıza karşılık, projede yarı zamanlı.

Ama aynı deneyimime göre, Çalışanların morali, daha sıkı bir "yapmanı söylediğimizi yap" yaklaşımını uyguladıkları öncelikler listesinde oldukça düşüktür.
Burada verebileceğim tek tavsiye, böylesine zehirli bir ortam bırakmaktır. İş memnuniyetinize (makul ölçüde) değer vermeyen bir şirket için nefret ettiğiniz bir işte çalışmakla kariyerinizin boşa gitmesine izin vermeyin.

Üzerinde çalıştığınız şeyden hoşlanmıyorsanız, başka bir şirkete gidin. Programcılara yüksek talep var.

Yapacağınız çalışma türlerini önceden öğrendiğinizden emin olun. Senin durumundan ayrıldığı için kimseyi eleştirmeyeceğim, kulağa korkunç geliyor. Ancak, bu tür bir proje üzerinde çalışacağınızı bilerek işe alınmış olsaydınız, bundan şikayet etmek pek zevkli olmazdı.

Günlük işlerinizi bir gün içinde değiştirmek için nadiren çok fazla alan vardır. şirket, bu şeyler uzun vadeli olma eğilimindedir ve yapmak istediğiniz bir şeyi yapan başka bir iş bulmaktan neredeyse her zaman daha düşüktür.

Şirkete göre değişir. Son işimde şirketim devlet ve bankalara BT çözümleri sunuyor. Yani her seferinde yeni bir ihale ve yeni bir proje. Teklif verme, proje tasarlama ve uygulama aşamalarında yer alan geliştirme ekibindeyim. Üretim sürümünden sonra, bakım ekibi görevi devralacak ve bizimle yalnızca başa çıkamayacakları sorunlarla iletişime geçecektir. Dolayısıyla, farklı yapıdaki bir şirket çözüm olabilir.

Ancak durumunuzu farklı bir açıdan görebilirsiniz.

Bakımını yaptığınız yazılım kötüyse düzeltin . Düzeltmenin ötesinde ise, amirinize neden böyle olduğunu açıklayın ve bir çözüm önerin.

Kötü bir durum olduğunu düşündüğünüz şey, bunun yerine amirinize neler yapabileceğinizi gösterme şansı olabilir.

Yöneticiniz sizi olumlu bir açıdan görürse, Yapmak istediğiniz projelere atanmak veya onu sizi yeniden atamaya ikna etmek için çok daha iyi bir şans.

Şu anki 2 yıllık sözleşmeli işimde, sizin gibi kötü yazılımları kullanıyorum. Orijinal satıcı çoktan gitti ve kod kalitesi kötü. Yöneticim şirket kültürü çok çekingen olduğu ve risk almaktan nefret ettiği için büyük değişikliklere isteksiz. Üzerinde çalıştığım kısmı düzeltmek için çeşitli seçeneklerin artılarını ve eksilerini sundum, çok çaba sarf ettim ama sonunda onları kazandım. Birkaç ay içinde, amirim bana kalıcı bir pozisyon teklif etmekten bahsediyor.

Bu durumdan kahramanlar yükseliyor.

Kendinizi diğer yerlere koyun Yöneticinizin takımını dinlediğini biliyor musunuz? Makul bir yönetici mi? Geliştiricilerin ihtiyaçlarını karşılamaya mı çalışıyorsunuz? İletişimsel mi? Bu çok önemli, yöneticinizin bir rolü var ... işi halletmek, sonuçları sunmak. Ve bunun için birisinin eski projeyle ilgilenmesi gerekiyor.

• Başka bir yedeği var mı?
• Tercihlerinize daha çekici gelen, size motivasyon veren başka bir projesi var mı, belki de zamanınızın% 50'si ?.
• Projenin bir bölümünü yeniden yaratmanız için size yeşil ışık yakabilir mi?

Kesin olarak bilmiyorsunuz .... bu yüzden, evet, onunla konuşmalısınız. Zorlu bir şekilde değil, işyerini seviyorsanız hayır. Ama onunla rahatsızlığınız hakkında konuşmalısınız, çünkü ayrılan çalışanlar da iyi bir sonuç değil, ... hiçbir şirket / yönetici bir geliştiricinin istifasından yararlanamaz. Ve ondan daha fazla para, daha az saat, uzaktan çalışma veya şirket politikalarını / kaynaklarını engelleyen bir şey istemiyorsunuz. Takımın tahsislerini yeniden düzenlemeye çalışmakla ilgili bir şey, daha 'yapılabilir'. Ve ona bir rahatsızlığı bildirdiğiniz için kovulmuyorsunuz. Ancak, rahatsızlığınızı gidermenize yardımcı olabilecek tek kişi, tabii ki orada kalmak istiyorsanız o kişidir.

Ondan kısa bir özel toplantı yapmasını isteyin.
Rahat olun , kızgın duygu yok, talepkar sesler yok.
Bu, bir ekip üyesiyle yapılan ve bir rahatsızlığa çözüm bulmanıza yardımcı olabilecek bir görüşmedir .

Sizin için hiçbir şey yapmasa bile hiçbir şey yapılamaz. Senin elinde değil, hareket ettirmek için elinden geleni yaptın. Çünkü hiçbir şey söylemez ve yeni bir iş bulmazsanız, ona söylediğiniz anda size söyleyeceğim ilk şey 'Ben şimdi böyle hissettiniz, bunu çözmeye çalışabiliriz' olacaktır. . Bir şirketten para için ayrıldığınızda, önce bir artış istersiniz, bu aynıdır, iş aramaya başlamadan önce, her iki menfaatin de tatmin edildiği bir çözüm bulma şansı verin. Ekibe / müşteriye değer katarken aynı zamanda motivasyon elde edeceğiniz bir şekilde düşünün

Hikayemi dinlemekten büyük bir fayda sağlayabilirsiniz.

Şirketimde belirli bir proje üzerinde çalışmak üzere işe alındım (kısmen, röportaj yaptıkları ve tanıdıkları tek kişi olduğum için elektronik, ancak bu büyük ölçüde alakasız hale geldi). Yaklaşık altı ay boyunca üzerinde çalıştıktan sonra, kod tabanı o noktada sadece bir buçuk yaşında olmasına rağmen mimarinin tam bir kayıp olduğu sonucuna vardım. O zamanlar üç yıllık bir kod tabanına baktığımı ve şirketin kötü kaynak kontrol uygulamaları geçmişi olduğunu düşünmüştüm. Aslında, kaynak kontrol kullanımları oldukça iyiydi (daha iyi hale geldi) ve ürün, büyük patlama üretimi tarafından yapıldı.

Benzer şekilde, temelin çatladığını ve zeminin dengesiz olduğunu bildirdim. Aslında tamamen yeniden yazmak gerekiyordu, ancak o zaman karşılanamadı ve bunu biliyordum. Gerektiğinde, direk olarak hizmet etmek için I-kirişlerini temelden geçireceğim konusunda analoji yoluyla anlaştık. Önümüzdeki on yıl içinde işler bozulduğunda veya sürdürülemez hale geldikçe veya profil oluşturucu sıcak noktalar bulduğunda neredeyse tüm orijinal mimariyi değiştirdim, o ana kadar sadece birkaç düzine satır kaldı. Ama şimdi I-kirişlerin kendileri çatladı ve desteklendi ve ev-skycraper yaşını gösteriyor ve yine üzerinde çalışmak zorlaşıyor ve yeni programcılara, veritabanına yeni tablolar eklemek için gereken her şeyi öğretmekten korkuyorum. örnekler kalır. İşlerin nasıl yürüdüğüne dair her açıklama artık bir tarih dersi haline geldi.

Artık ürün üzerinde fazla çalışmıyorum, ancak mimarinin kurallarını ihlal eden bir değişiklik yapılması gerektiğinde bunu yapıyorum , bunu yalnızca benim yapabildiğim için değil, aslında kafamdaki tüm kuralları bildiğim ve bu nedenle sonuçlarını sürdürmenin en kolay yolunu seçebildiğim için.

Ancak, bunu gerçekten doğru bir şekilde yapacak ve aslında yirmi yıl veya daha uzun süre sürdürülebilecek bir mimari tasarlayacak deneyime ancak şimdi sahibim. Bazı problemler orijinal mimarinin kötü kararlarıdır ve uygulamayı neredeyse aynı işle değiştirdim ve aynı kararların çoğunu alıkoydum. Sorunlardan bazıları kendi kötü kararlarım. Ve endüstri değişti ve biz fat-client mimarisini bir web mimarisiyle değiştirmek istiyoruz. Biliyor musun, şimdi tam zamanı. Bir web mimarisi için tüm becerilere sahip değilim, ancak çoğuna sahibim ve geri kalanı için nereye döneceğimi biliyorum.

Seçim gerçekten sizin olmalı, ancak Burada temelden I kirişlerini geçirecek bir yer var. Bunu yapmayı seçerseniz, öğrenecek ve güçlü olacaksınız.

Zorlayıcı bir şey yapmadan önce kendinizi bildiğinizden emin olun

Üç yıl henüz çok küçük, bu yüzden ne olduğunu bildiğinizden emin olmadan iş veya kariyer değiştirmek gibi sert bir şey yapmam hoşunuza gitmeyen eski kodu korumak hakkında. Örneğin, yeni bir araç veya teknik öğrenmeniz gerekebilir ve aslında eski kodu korumayı sevmeyi öğrenebilirsiniz. Bir akıl hocanız varsa, bu onlarla tartışmak iyi olur. Bir mentorunuz yoksa, bir tane bulmaya çalışmalısınız.

Mutsuz = zayıf performans = kariyer başarısı = değişim zamanı

Siz olmadığınıza emin olduktan sonra, iş bu, o zaman en iyi işinizi yalnızca mutluysanız veya en azından işinizden memnunsanız yapacağınızı anlayın. Aktif olarak mutsuzsanız veya işinizden nefret ediyorsanız, işinizde görünecektir. Bu, uzun vadede kariyerinize zarar verecektir. Yani, aktif olarak sizi mutsuz eden bir durumda kalmak için kendinize herhangi bir iyilik yapmıyorsunuz (bazen başka seçeneğimiz yok, ama eğer öyleyse ve çoğu zaman biz yapıyoruz, o zaman bir değişiklik yapmanız gerekir).

Ne yapmalısınız?

Patronunuza tercihlerinizi söyleyin ve makul bir süre içinde patronunuz onları onurlandıramazsa veya onurlandırmazsa, bunu yapabilecek ve niyet. Neredeyse hiçbir işin (kendi patronunuzsanız dahil) tercihlerinizi% 100 oranında karşılamayacağını unutmayın; bu sadece hayat. Ancak iyi bir uyum sizin için kabul edilebilir olan ve sevdiğiniz görevleri en azından tahammül edebileceğiniz bazı görevlerle karıştırır. Ancak kendinizi işinizden nefret ederken bulursanız, değişim zamanı gelmiştir.

Son bir şey

Uzun saatler çalışıyorsanız veya hafta sonları yeterli molalar olmadan çalışıyorsanız, o zaman tükenmişlik yaşıyor olabilirsiniz, bu da en keyifli görevlerin bile ev işleri ve sıkıcı görevler gibi hissetmesine neden olabilir. Bu nedenle, durumunuzu değerlendirmenin bir parçası, işinize yönelik nefretinizin tükenmişliğin neden olduğu stresten değil, gerçekten işinizden kaynaklandığından emin olmayı içerir. Sorunun tükenmişlik olduğu ortaya çıkarsa, işinizden hoşlanmama durumundan farklı bir şekilde ele alınması gerekir.

İşte kullanabileceğiniz bir strateji. Ancak dikkatli olun, bu sizi müdürünüzün yanında elverişsiz bir duruma sokabilir.

Onlara bazı modüllerin saçma olduğunu ve sıfırdan yeniden yazılması gerektiğini söyleyin, onlara yara bandı yapamayacağınızı söyleyin. Başka birini bulabilir veya yeniden yazmanıza izin verebilir. Yeniden yazabiliyorsanız, neredeyse yeni bir proje gibi, mutlu olmalısınız.

Bunun her iki tarafını da gördüm. Anlaması ve düzeltmesi, yeniden yazmaktan daha uzun sürecek berbat kodu yeniden yazdım. İyi ve sürdürülebilir olduğunu düşündüğüm (ve bütçemi aşan) kodları yeniden yazan insanlar gördüm.

Bunu uzun süre yaşadım. Dayanılmaz bir şey oldu.

Maalesef, iş gününüzün çoğunu tüketiyor ve çok sayıda kötü kodla karşılaşacağınızı düşünerek uyanmak çok iğrenç. Bu kötü bir duygu.

Yaratmayı ve icat etmeyi seviyorum; bu yüzden uzun zaman önce programcı oldum. Ben de bir dahi değilim, zeki ama oldukça yaratıcı.

Deneyiminiz olduğuna göre, işinizi bırakın ve bağlılığınızı daha iyi hak edecek birini arayın. Bunu 2 ay önce yaptım ve şimdi neden daha önce yapmadığımı anlayamıyorum.

Birkaç kez kod tabanından "nefret etmeye" başladığımı keşfettim, nedenini araştırmaya başladım.

Ve bunun beni sürekli rahatsız eden ve düzeltilmemiş kalan bazı dezavantajları olduğu için öğrendim. Zor olan şey bu yüzden artıyor ve ...

Bu "nefreti" ortadan kaldırmanın yolu, sizi bu kodla ilgili rahatsız eden şeyleri tespit edip düzeltmektir!

Nedir? en önemlisi, onları zaten tanıyorsunuz (çünkü sizi rahatsız ettikleri için) ancak öncelik vermek istemiyorsunuz.

Zaten birkaç ad verdiniz: "Kodun anlaşılması kolay değil, özellikle de belge yoksa." Kodu incelerken, bunların ve bu parçaların özensiz ve hataya açık olduğunu belirlemiş olmalısınız; burada ve burada test yoktur, bu nedenle kodun her durumda (hala) doğru olup olmadığını bilmenin bir yolu yoktur vb.