Programlayamıyorum çünkü kullandığım kod eski kodlama stillerini kullanıyor. Bu programcılar için normal mi?


29

Programcı olarak ilk gerçek işim var ama kullanılan kodlama tarzı nedeniyle hiçbir problemi çözemiyorum. Buradaki kod:

  • Yorum yok
  • İşlevleri yok (sırayla yürütülen 50, 100, 200, 300 veya daha fazla satır)
  • ifÇok fazla yol içeren bir çok deyim kullanır
  • Hiçbir anlam değişkenleri Has (örn .: cf_cfop, CF_Natop, lnom, r_procod)
  • Eski bir dil kullanır (2002’den Visual FoxPro 8), ancak 2007’den itibaren yeni sürümler bulunmaktadır.

1970'e geri döndüğümü hissediyorum. OOP, temiz kod, tasarım kalıpları vb. Hakkında bilgi sahibi bir programcının bu eski moda şekilde kodlamada sorun yaşaması normal mi?

EDIT : Tüm cevaplar çok iyi. Umudum için, dünyada çok fazla bu tür bir kod temeli olduğu anlaşılıyor. Tüm cevaplara değinilen bir nokta, kodu yeniden yansıtmaktır. Evet, gerçekten yapmayı seviyorum. Kişisel projemde bunu hep yapıyorum, ama ... Kodu tekrar gözden geçiremiyorum. Programcıların yalnızca tasarlandıkları görevdeki dosyaları değiştirmelerine izin verilir.

Eski koddaki her değişiklik, kodda (sürüm kontrolü olarak Subversion ile bile) ve ayrıca bu değişikliğe ilişkin meta bilgileri (tarih, programcı, görev) ve bu değişiklikle ilgili meta bilgileri (tarih, programcı, 50 eski satırlar yorum yaptı). Bunun sadece bir kod problemi değil, yazılım geliştirme probleminin yönetimi olduğunu düşünüyorum.


43
Evet, elbette normal. Belli bir şekilde çalışmak için eğitildiniz ve eğitiminizin çoğu tamamen farklı bir şekilde uygulanan bir kod temeli ile karşılaştığında işe yaramaz. Bu temel ilkelerin çok değişmediğini söyledi ve ilk şoktan sonra ayarlamaya başlayacaksınız ...
yannis

12
Yorumları kullanmayarak çok eksik değilsin. Bir şey insanlar onları aşırı ise.
JohnFx

22
@JohnFx Sizinle aynı fikirde değilsiniz, ancak çok az sayıda yorumsuz eski saçmalıkla karşı karşıya kaldığımda, fazla yorum / eski yorumları hiç yorum yapmamayı tercih ederim derim.
yannis

25
Bu kötü görünecek - ama kariyerinizin başlarında böyle bir acıyı hissettiğinize sevindim, çünkü sürdürdüğünüz gibi bir kod yazmamak harika bir motivasyon olacak.
Bork Blatt

19
Bir programcı olarak geliştirebileceğiniz en önemli becerilerden biri, diğer insanların kodlarını anlayabilmek ve yeniden değerlendirebilmektir. Eğer ustalaşmazsan, asla iyi bir programcı olamazsın. Yeteneği öğrenme şansınız olduğu için şanslısınız.
Paul Tomblin

Yanıtlar:


0

Tamam, kör olacağım. Bu, çalışmak için kötü bir yer ... Böyle durumlarda bulundum ve genellikle bu kod tarafından yutulmanızla sona erer. Bir yıl kadar sonra, buna alışacaksınız ve aynı görevin daha kolay, daha sürdürülebilir bir şekilde ve aynı zamanda çalışma zamanında daha hızlı bir şekilde gerçekleştirilmesi için modern alternatiflerin nasıl kullanılabileceği konusundaki tutkuyu kaybedeceksiniz. çoğu durumda.

Böyle bir işyerinden ayrıldım, çünkü bir ay sonra eski bir skool koduna sürüklendiğimi hissettim. Gitmeye çalıştım ama gitmemeye karar verdim. Temiz kod kullanamadım ve günlük pratik yapmadığım için becerilerimi yitirmeye başladım. Herhangi bir modern yaklaşımın, hiçbir zaman olmamış olan 3 geliştirici katmanı tarafından onaylanması gerekiyordu, çünkü fikir, modern yaklaşımlar kullanıldığında her şeyin kırılabileceği fikriydi. Ve modern yaklaşımları kullanmadığınızda ortaya çıkan kodun kırılgan doğası oldukça korkutucu.

Beni yanlış anlamayın, insanların çözümleri çok fazla geliştirdiği durumlar var ve hepsine karşıyım. Ancak, uzun süre boyunca 80 kodlama sözleşmesine ve tarzına sürüklenmeniz, ilerlemenizi durduracak ve aynı zamanda kariyer fırsatlarını da durduracak.

Sonra tekrar, para kazanmak zorundasın, bazen de tam olarak sevmediğin bir şeyi yapmak zorundasın. Tükenmişlik semptomlarına dikkat edin ve bu durumlarda kodlamayı sıradan bir iş haline getirin.


1
Onun çalışmak için kötü bir yer olduğunu nasıl söylersin? Eski satır içi kodunda yanlış bir şey yok. Eski kodun, bu dünyada eski kod olmadan bir yeri vardır, günlük kullandığımız uygulamalarda yeni faydalar elde ederiz.
Ramhound

1
@Ramhound: Çünkü böyle yerlerde ilk elden deneyimim var. Etkili kaplar kullanmanıza izin verilmeyecek, güvenli yapılar kullanamayacaksınız, mimariye sıfır girdi sağlayacaksınız. Değişimin korkusu ana nedendir. Ve bir yıldan daha uzun bir süre böyle bir yerde kalırsanız, bunun içine sürükleneceksiniz. Modern kod, tasarımlarınızı daha basit, daha hızlı ve SAFER yapar! Bir yerde ham bellek twiddling, SQL sorgu inşaat anında büyük olasılıkla bile parametrized, vb. İle dolu olduğundan eminim.
Kodlayıcı

1
@Ramhound Eski kod tamam. Bugün eski kodu yazmak tamam değil.
Renato Dinhani

@Coder, bu, işin mükemmel bir açıklamasıydı ve sizin gibi, bir ay ve birkaç gün sonra işten ayrıldım. Yaptığım en iyi şey ve şimdi boş zamanlarımda birçok yararlı şey öğreniyorum.
Renato Dinhani

6 yıl sonra güncelleme: Bu şirketi gönderdikten ve geriye dönüp baktıktan birkaç gün sonra o şirketten ayrıldım, verdiğim en iyi karardı. Diğer şirketlerdeki pek çok başka projede çalışma fırsatı buldum ve hiçbiri bu ilk işte bulduğum aynı kötü uygulamalara ya da kaliteye sahip olmadı. Evde kalmak, iş piyasasının mevcut durumunu öğrenmek, daha ilginç projeler ve daha iyi şirketler üzerinde çalışmamı sağladı.
Renato Dinhani

35

Bu kodlama stili (hatta herhangi bir stile çağırmak istiyorsanız ) kötü kodlama tarzıdır.

Bir çoğu modern dilde tanımlayıcı değişken isimleri ve aklı başında akış kontrolü ile kısa fonksiyonlar yazabilir (Visual FoxPro moderndir, evet).

Karşılaştığınız problemler kötü bir kod tabanına sahip, daha fazla değil, daha az değil.

Bu tür kod tabanları var ve birçoğu - onlarla sorun yaşıyor olmanızın ne kadar kötü olabileceğini (ve iyi bir eğitime sahip olduğunuzu) kanıtlıyorlar.

Deneyebileceğiniz ve yapabileceğiniz şey, yapabileceğiniz şeyleri geliştirmek - değişkenleri yeniden adlandırmak, ortaklıkları ayıklamak ve büyük işlevleri küçük parçalara bölmek vb. ... Legacy Code ile Etkili Çalışmanın bir kopyasını alın ...

Çok kötü bir yapıya sahip bir C # projesindeyim. Sadece 12 ayrı fonksiyon (belirgin kopyala-yapıştır) ile tek bir parametre alır .


33
İyi programcılar her türlü korku hikayesini kaldırabilir. Eğlenceli olmayacak, ama bu yüzden sana yapman için para ödüyorlar. İşin eğlenceli ve oyun olması gerekmiyor.
tp1

9
@ tp1 - Evet, fakat karşılaştığınız ilk kod tabanının sistem için bir şok olabileceğini kabul etmelisiniz.
Oded

10
@Renato: tüm programcılar yeni kod yazmaktan / tasarlamaktan çok daha fazla kod tutmaya çalışırlar. Ve sürekli olarak değiştirilen tüm kodlar, bunu önlemek için çok çaba harcamadıkça zamanla daha da kötüye gider. İyi programcılar aynı zamanda kötü kod tabanlarıyla başa çıkmakta daha iyi, ister ister ister istemese de, yöneticiler genellikle bu tür görevler vereceklerdir ve çok az kişi bu tür görevlerden tamamen kaçınabilecek durumdadır. Aslında, bir programcının kötü kodlarla (bazılarının kendisi de olabilir) başa çıkma konusunda bir tecrübesi olmadığı sürece, gerçekten iyi olduğunu iddia edemeyeceğini iddia ediyorum.
Michael Borgwardt

13
@ RenatoDinhaniConceição, bakımında zamanını yapmayan özgün bir tasarım yapmak için bir geliştiriciyi işe almayı asla düşünmem, bu deneyimi yaşamadan iyi bir tasarımcı olamazsınız. benim deneyimim). İyi bir programcı olamazsınız ve bakımda kötü olamazsınız. Hoşuna gitmeyebilir, ama nasıl iyi dizayn edileceğini anlamak gerekir. Ve zorlayıcı bir terfi işi yapabilme yeteneği de iyi bir programcının özelliğidir. Kolay olsaydı bize ihtiyaçları olmazdı.
HLGEM

8
@ tp1 Çalışmanın eğlenceli ve oyun olması gerekiyor, aksi halde yanlış yapıyorsunuz.
Kevin McCormick

18

Bu (şimdiki gibi) iyi tasarım uygulamalarının her zaman popüler olmadığı durumlar dışında, aslında "eski moda" değildir. Bu sadece kötü kod. Kötü kod herkesi yavaşlatır. Sonunda buna alışırsınız, ancak bunun nedeni belirli sisteminizdeki belirli tuhaflıklara alışmanızdır. Yeni bir proje verildiğinde hatalı kod yazmanın tamamen yeni yollarını bulabilirsiniz . İşin güzel yanı, bu kod kokularını nasıl tanımlayacağınızı bilmenizdir.

Yapabileceğiniz en büyük şey , sorunu yaymak değil . Ekibiniz olmadığı sürece bu kötü uygulamaları kongre olarak kabul etmeyin. Yeni kodu, bir refactoru zorlamayan şekillerde temiz tutun. Eğer o kadar kötüyse ve zamanınız varsa, büyük bir refactor düşünün ... ama pratikte nadiren bu lükse sahipsiniz.

İşleri çözerken yorum eklemeyi düşünün ve küçük parçaları ve parçaları pratik olarak değiştirin. Yalnız kodlamadığınız sürece bunu ekibinizle birlikte yapmanız gerekir; Herhangi bir sözleşme yoksa, onlarla karşılaşmak için biraz zaman ayırmalısınız ve yine de düzenli olarak sürdürüyorsanız, kod tabanını yavaşça iyileştirmeyi taahhüt etmeniz gerekir.

Kötü değişken isimleri ile tamamen izole edilmiş bir işlev bulursanız ve yine de düzeltirseniz, değişken isimlerini faydalı bir şey yapabilir, iflas'ı yeniden düzenleyebilirsiniz. Bunun büyük bir bölümünü yeniden düzenleyecekseniz ortak özelliklerde değişiklik yapmayın.


4
“İyi tasarım uygulamaları her zaman olduğu kadar popüler değildi” Mutlaka popülerlik ile ilgili değil. İyi tasarım veya en iyi uygulama olarak kabul edilen şey zamanla gelişir. Eski koda bakarken akılda tutulması gereken bir şey.
Burhan Ali,

@BurhanAli, abosiolutely, uygulamamızın orijinal olarak tasarlandığı 2000 yılında iyi bir uygulama olan şey şu anda mutlaka iyi bir uygulama değildir. Genç geliştiriciler çoğu zaman, kodun yazıldığı sırada en iyi uygulamaların mevcut olamayabileceği veya yazılımın kullandığı eski dille çalışmayabileceği için ne öğretildiklerine dair hiçbir fikre sahip değildir.
HLGEM

2
Ben 500-satır fonksiyonlarının "iyi" olarak kabul edildiğini sanmıyorum ... 80'lerde arka arkaya montajı öğrendiğim ilk kitap, baştan sona dallanmayacak kadar büyük olduklarında belki alt yordamları kırmanız gerektiğini belirtti. başlangıcına. Bu işlemcide (6502) 40-120 satır arasında bir yere geliyor.
mjfgates

11
  • yorum yok - öğrendikçe düzeltin
  • işlev yok (sırayla yürütülen 50, 100, 200, 300 veya daha fazla satır)

Bu muhtemelen kodun önceki bir yinelemesinden kaynaklanmaktadır. Bu noktada, "özellik" haline gelen benzer görünen kod blokları arasındaki ince farklardan sakının. Ancak bu tür bir yapının ne kadar kötü olduğuna bakılmaksızın, anlaşılması oldukça basittir ... bu yüzden nerede sorun yaşayacağınızdan emin değilim.

  • çok fazla yolu olan if ifadeleri kullanıyor - burada ne demek istediğinizi tam olarak bilmiyorum
  • anlamlı olmayan değişkenleri var (örneğin: cf_cfop, CF_Natop, lnom, r_procod) -

'Değişkenleri yeniden adlandırmak' bitiyle ilgili uyarıları vurgularım. Henüz sadece lingoyu anlamadığınız bir şans var ve değişken isimleri bir süre orada kaldıktan sonra çok daha anlamlı olacak. Sorunlu değişken isimlerinin de olamayacağını söylememek değil, ancak örnekleriniz sitenizdeki ortak kısaltmalar ne olduğunu biliyorsanız, onlara bir mantık var gibi görünüyor. Açıkçası, 1 kişilik bir ekip olmanız önemli değil.

  • Bilmediğim bir dil kullanıyor (2002’den Visual FoxPro 8) - Kodunuz değil

7
+1: Bu senin sorunun, kodun değil :)
aleroot

Son noktası dilbilgisi yanlıştı; Özgün anlamını anlayamadım. Tahmin etmiştim ve yanlış tahmin etmiş olabilirim, bu yüzden Visual FoxPro ile aşina olmadığı anlamına gelmeyebilirdi.
Myrddin Emrys

FoxPro hakkında sorumu değiştirildi. Bunun ayrıntılı bir dil olduğunu söyledim ve benim için bu iyi değil, ama kişisel bir görüş. Bunu anlıyorum ama sevmiyorum ve asıl mesele dilin yaşı. Şirketimde güncellenmedi, ancak yeni sürümler var (2007'den Visual FoxPro 9).
Renato Dinhani

3
@ RenatoDinhaniConceição, yükseltmeleri şu anda çalışan şeyleri kırdığı için bir veritabanı ürününü yükseltmemek yaygındır ve eski sürümü koruyorsanız gerekmeyen değişiklikler yapmak için harcayacağınız para ya da zaman yoktur. Bu bir iş seçimi.
HLGEM

1
@ renato, çoğu veritabanı uygulaması kolayca geriye dönük olarak uyumlu değildir.
HLGEM

11

Bu bana bir Fırsat gibi geliyor .

İşlerin nasıl yapıldığına ve yönetildiğine ilişkin birçok sorunu görebildiğiniz açık. Bunların hepsinin çöplük olduğundan ve hiçbir şey yapamayacağınızdan şikayet edebilirsiniz, VEYA bunu işvereninize gerçekten değerinizi göstermek için altın bir fırsat olarak kullanabilirsiniz.

Şimdi, işvereninize gidip ona her şeyin değişmesi gerektiğini söylerseniz, size yardımcı olmayacaktır. İşin püf noktası bir süre oynamak, LOTS'a soru sormak ve kod yazmanız gerektiğinde, diğer geliştiricilere sahip olmanız gerekeceğinden, tüm yorumlar vb. Hangi sistemi tercih ettiklerini kullanarak bilgi sahibi olurken, aynı zamanda sizi hiçbir şey riske atmayacak makul refactorings sunabilirsiniz. Birkaç yöntem çıkarabilirsiniz ve eğer diliniz destekliyorsa, birkaç birim testi uygulayabilirsiniz. Neden bu şekilde yaptığınız sorulduğunda veya “yanlış” bir şey yaptığınızı söyleseniz, tercih ettiğiniz kodlama stili için konumunuzun sesli sunumunu yaparken savunmacı veya tartışmacı olmaktan kaçının. Örneğin, Bob Martin'in Temiz Kodu gibi kitaplara başvurabilir veya diğer kitaplara, makalelere ve hatta Programcılar'da karşılaştığınız soru ve cevaplara bakabilirsiniz. Birlikte çalıştığınız insanların gözünde deneyiminizin ötesinde olabilecek gerçeklerle konumunuzu desteklemeye yardımcı olabilecek her şey.

Aşırı yorumlama ile ilgili olarak, değişkenler ve yöntemler için birkaç tanımlayıcı ad ekleyebilseniz, bunlardan bazıları temizlenebilir, ancak iyi bir sürüm kontrol sistemi için bir durum yaratabilir ve onu kullanabilirsiniz. Değişikliklerin ve tarihlerin vb. kaydını tutmak ve önceden seçilen VCS ile gelmemişse, kaynak dosyalarınızın farklı sürümlerini karşılaştırmak için bir araç kullanmak.

Dediğim gibi, bu, konuşma biçimini yitirmiş gibi görünen bir geliştirme ekibinin gelişimine katkıda bulunmak için bir fırsattır. Becerikli ve bilgili ve örnek olarak liderlik edebilecek biri olarak öne çıkma olanağına sahipsiniz. Bunların hepsi, kariyeriniz ilerledikçe size yardımcı olacak iyi şeylerdir.


2
İlk olarak, buradaki tüm cevaplar iyi ve bana yardımcı oldu. Bu cevap yüksek oylanmadı veya yorumlanmadı, ama gerçekten hoşuma gitti. Çok fazla soru sormanın ve savunmaya devam etmemenin çok önemli olduğunu düşünüyorum. Patronumla burada bahsettiğim bazı konular hakkında konuştum ve beklendiği gibi büyük değişiklikler yapma gücüm yok, ancak bundan sonra biraz daha iyi bir şekilde değişeceğini hissediyorum. Akıllı sözler için S. Robbins ve diğerlerine teşekkür ederim.
Renato Dinhani

1
Bunu bir kere yaptım ve başardım. Çok yorucu. Bunu bir daha asla yapmayacağım. Bu gerçekten zordur: Yenilemeden ÖNCE en uyamazsınız, kod zayıftır, bu nedenle herhangi bir anda yüzünüzde patlayabilir ve insanların çalışma alışkanlıkları nedeniyle (diğer problemler arasında) çok önemli bir dirençle karşılaşırsınız. Sadece kod kalitesini önemseyen insanlar için iş biliyorum.
deadalnix

1
@deadalnix İlk işler nadiren birlikte çalıştığınız kişileri seçme imkanı sunar. Genellikle, bir süre onlarla çalışana kadar insanların kod kalitesini ne kadar önemsemediğini bilemezsiniz. Cevabım OP'nin bunu anlamasına yardımcı oluyor. Yeniden yapılanmadan önce ünite testinde bulunamama konusundaki ifadeniz açıkça yanlıştır. Ünite testlerinden önce refactor denemek genel riski arttırır. Testler olmadan böcek kovalamak yetersiz ve yorucu. Kod kalitesini önemseyen insanlar, ağırlıklı olarak testlere ve temiz kodlama tekniğine odaklanır. Zımni itirazınızı alamıyorum, bu çevrimdışı :-) hakkında sohbet etmekten mutluyum :-)
S.Robins

@ S.Robins Test yapmadan kovalama hatası verimsiz ve yorucu ve yeniden kontrol etmeden yeniden yapılanma çok riskli (ve her ikisi de güzel bir şekilde birleşiyor). İşte bu yüzden böyle bir durum bir kabus. Büyük eski kod tabanı genellikle kararsız değildir (küresel devletlerle dolu, üretim sistemine veya diğer sistemlere kodlanmış bağımlılıklar doludur, kaygılar ayrılmaz, büyük kod tekrarları vb.). Kodu yenilmez yapmak için ilk bir refactoring kartı atmanız gerekecek. Sanırım ikimiz de sorunun kodlanması konusunda hemfikiriz ama birbirlerini yanlış anladık.
deadalnix

1
Ayrıca içerik toplamak için bir fırsat thedailywtf.com
Arkh

8

Ormana hoşgeldin !

Ne yazık ki, genellikle bir şirkette çalışmaya başlamak, bu tür durumlarla karşı karşıya gelmek anlamına gelir, eğer yapılandırılmış ve iyi organize edilmiş bir şirket için çalışmazsanız, bu durumlar oldukça olağandır ...

Benim tavsiyem:

  1. Öğrenmeye başlayın ve aşina olun: kullanılan programlama dili (Clipper / dBase) ve çevre (Visual FoxPro)

  2. Kod tabanını okuyun ve analiz edin ve yorum yapmaya başlayın

  3. Kodu düzenlemek / yeniden düzenlemek (sırayla yürütülen çok fazla satırın problemini ele almak)

Benzer bir kod temeli ile karşı karşıya kalmakta sorun yaşıyorsanız normaldir, ancak kod kalitesini iyileştirmeye çalışmak ve kod tabanını iyileştirmek için programa "dokunuşunuzu vermek" ve belki de daha iyi bir program yapmak ...


7

Sorunuzu cevaplamak için: Evet, her yerdeki insanlar / şirketler berbat kodlar üzerine kurulabilecek altyapıları kullanıyor. Kendinizi bu gibi durumlara entegre ederken baş etmek çok zor olabilir.

Geçen yaz, belirli bir bölüme bağlı KG ekibi tarafından kullanılmak üzere bir uygulama geliştiren stajyer olarak çalıştım. QA ekibi, veritabanları üzerinde testler yapmak için birçok bağımsız komut dosyası (VBScript, Perl, Bash) kullandı ve hepsini bir araya getirmek istediler. Bununla birlikte, bununla ilgili sorun, bu komutların şirketin başka bir yerinde kullanılmasıydı (bu nedenle çekirdek işlevsellik / değişken adları değiştirilemezdi) ve kod yaklaşık 10 yıl boyunca "eklenmiştir"; bir sürü saçmalık oluşmuştu.

İşte bu konuda yapabilecekleriniz:

  1. Yardım isteyin: bu yasaya bakmak zorunda kalan iş arkadaşlarınız muhtemelen kendi kendine hasretlerini biliyorlar. Geniş ve size kafa karıştırıcı olan şey, onlar için tamamen iyi. Öyleyse yardım isteyin!
  2. Mümkün olan her durumda refaktör: Bu kodu uzun bir süre boyunca bakmak / sürdürmek zorunda kalırsanız, olabildiğince tekrar kontrol edin. Değişken adında bir bul ve değiştir çalıştırıyor olsanız bile, her küçük yardımcı olur. Geçen yaz staj yaptığım firmanın crappy değişken isimlerini kullanma konusunda da benzer bir sorunu vardı. Yapabildiğim her şans kodlarını ince bir tarak, değişken isimlerini değiştirmek, mantığı optimize etmek (örneğin çeşitli fonksiyonları 1 olarak gruplamak gibi), vb. Kullanarak koştum. Fırsatınız varken aynısını yapın!

Her yerde olduğu gibi, kodun dış özellikleri düzgün çalıştığı sürece, iç kısımların nasıl çalıştığı önemli değildir.


"Yardım isteyin" için +1. Bir takımda çalışmak maliyet katıyor ama aynı zamanda fayda sağlıyor.

7

Buradaki yanıt verenlerin çoğundan farklı bazı yorumlar yapacağım. Yorumlarımın çoğu sizin için açık olabilir, ancak yine de söylemelisiniz.

  • Anlamadığınız, anlayana kadar kod değiştirme konusunda dikkatli olun.
  • Bir ekip ortamında çalışıyorsanız, ekip arkadaşlarınızın üzerinde çalıştığı kodla, değişiklikleri yapmadan önce değişikliklerinizi onlarla tartışın. Kimse içeri girmek ve başkalarının bildiği kodları değiştirmek için yalnız bir silahşörden hoşlanmaz. Bu, değişikliklerin garanti edilmediğini ya da yapılacak "doğru" şey olduğunu söylemek değildir.
  • Fikirleriniz için benimseyin. Herkesi fikirlerinizle buluşturun, ardından tüm iş yükünü kendinize yüklemekten ziyade, takımınızın becerilerini refaktör olarak kullanabilirsiniz.
  • Kazanç yönetimi girişi. Kodu alıp gitmeniz için fon tahsis edebilirler.
  • Yönetimle konuşarak kod tabanlarını yeniden faktörlendirmenin yararlarını anlarlar. Daha fazla bakım gerektirebilir kod, hataları çözmek, daha fazla özellik eklemek vb. İçin daha az zaman harcanması anlamına gelir. Daha hızlı geri dönüş süresi vb.

Ortamınızın politikasını anlamadan saf kodlama, en iyi uygulama önerileri eklemek kolaydır. Çalıştığınız insanlar, kod tabanınızı değiştirme zamanını değiştirmek veya zaman ayırmak istemeyebilir, ancak içeri girmeden ve her şeyi değiştirmeden önce (kendi başına doğabilecek riskleri olan) fikri herkese satmaya çalışın.

Bu yardımcı olur umarım.


1
Ayrıca: Test edin, yedekleme yapın, sürüm kontrolünü kullanın. Eğer yeniyseniz, kaynakta anlayamayacağınız şeyler oluyor ve zararsız bir değişime benzeyen şey, öngörmediğiniz sorunlara neden olabilir.
Scott C Wilson

Daha fazla eklerdim. Eylem gerektiren başarısız bir sınava girinceye kadar hiçbir şeyi değiştirmeyin . Test yazmaya başla. Başarısız bir test yaptığınızda, önemli olduğundan emin olun. O zaman değiştirmek için güçlü bir göreviniz var. O zaman bile sistem testlerle dolana kadar bekleyin. Her zaman sistemi bulduğunuzdan daha iyi veya daha iyi (asla daha kötü) bırakmaya çalışmayın.
emory

5

Yapışan şeylerden biri de sizin düzenlediğiniz yorumunuz.

Eski koddaki her değişiklik kodda yorumda tutulmalı, ayrıca bu değişiklikle ilgili meta bilgiler (tarih, programcı, görev) (bu bir karışıklık oldu, kullanılan 3 satırlı ve 50 eski satır yorumlu bir kod var). Bunun sadece bir kod problemi değil, yazılım geliştirme probleminin yönetimi olduğunu düşünüyorum.

Ayrıca, tarif ettiğiniz birçok konuyla ilgili eski bir FoxPro kod temelini miras aldığım bir projem var. Projeye sunduğum ilk şeylerden biri iyi bir kaynak kodu deposuydu. FoxPro SourceSafe ile entegre olabilir, ancak bu ürünün kullanımı acı vericidir.

Paul McNett'in scx aracı http://paulmcnett.com/scX.php'nin bir kopyasını aldım ve bunu geliştirme döngüme dahil ettim. İkili FoxPro kodunu daha sonra Subversion, Mercurial ve hatta git gibi bir kaynak havuzuna koymak için kullanılabilecek bir metin biçimine çıkarmak oldukça iyi bir iş yapar. (SubFox projesini http://vfpx.codeplex.com adresinde bulabilirsiniz .

Bu araçlar Geçmişi sağlar ve programcıların kodu koruma görevini üstlenmelerini sağlar. Bu araçları kullanmayı öğrenmek biraz zaman alır, ancak hepsi ücretsiz olduğu için, onlara zaman ayırmamak pek mantıklı gelmiyor. (Job projelerini bu şekilde hareket ettiremiyorsanız bile).


4

Ben korkak mantarın cevabına şiddetle katılıyorum. Eğer bir takım ortamıysanız, gelecekte iyi bir ödev almayı planlıyorsanız, başkalarının sizin refaktör olduğunuzu veya kodu yeniden düzenlediğinizi bildiğinden emin olun.

Bildiğim kişisel deneyimlerden, kodlama tarzınız olmasa da, başkalarının da değiştirdiği ve koruduğu kodu koruyorsanız, mevcut kodun tarzında kalın . Yorum ve açıklama eklemek iyi, ancak temel düzen ve kurallar kalmalı. Projedeki eski guru / silahlar, kodun yıllarca gördüklerine benzer olmasını bekliyor.

Bir müşteri bir hata hakkında çığlık attığında, yönetiminiz sorunu olabildiğince çabuk düzeltmek için eski silahlara gider. Bu eski silahlar, baskı altındayken, sizi “kodu temizledi” olarak bulurlar ve bu nedenle, artık çimdiklemesi gerektiğini bildikleri bir değişkeni nereye taşıdığınızı veya yeniden adlandırdığınızı bulmak için zaman harcamak zorunda kalırlar, şirketteki adınız “olarak değiştirilecektir” çamur".

Kriz bittiğinde, önce eski silah kritik güncellemeden yavaşça sizi suçlayacak. Daha sonra, şirkette olduğunuz sürece temizlik kodunu sakladığınızı göreceksiniz. Sonunda, yeni ilginç projeler ortaya çıktığında, yöneticileriniz projeye kimin çalışması gerektiğini irdeleyen gurulara soracaklar ve onları bir kez batırdıysanız, yeminiz sonunda atılana kadar asla yeni projeye giremezsiniz. bir son tarih buluşması için.

Üniversitede kodlamanın "doğru" yolunu öğrendiyseniz ve şimdi işgücündeyseniz, bu "doğru" yolu unutun. Bunlar kolej ödevi değildir, bu projeler sadece bir sömestr sürmezler, yıllarca yaşayabilirler ve en son CS trendine farklı seviyelerde uzmanlığa ve farklı ilgi seviyelerine sahip bir grup insan tarafından bakılmalıdır. Takım oyuncusu olmalısın.

Okuldaki en büyük çekim programı olabilirsiniz, ancak iş yerinde, ilk işinizde, sıfır sokak kredisine sahip bir yenicisiniz. Yıllardır programlama yapan insanlar, okulunuz ya da notlarınız hakkında hiçbir şey ifade etmiyorlar, başkalarıyla ne kadar iyi oynuyorsunuz ve hayatlarına ne kadar rahatsızlık veriyorsunuz.

20 yılımda, asıl programcıları kovmuş gibiyim, çünkü temel olarak işleri “doğru” şekilde yapmayı talep ediyorlar. İşe çok, çok çok özel bir şey getirmezseniz, değiştirilebilirsiniz. Sınıfının en iyisi olabilirsin, ama gelecek yıl, başka biri sınıfının en üstünde olacak ve bir iş arayacak.

İlk işiniz olarak görüyorum, siz işi değiştirmeye karar verene kadar işinizi sürdürmek. İşinizi sürdürmek için oyun alanında başkasının yaptırdığı ve parasını ödediğiniz kadar iyi oynamanız gerektiği anlamına gelir.

Kulağa olumsuz geldiğimi biliyorum ama her zaman umut vardır. Deneyim kazandıkça, başarılı olursanız, etkileneceksiniz ve olayları daha iyi bir şekilde değiştirebileceksiniz. Yeni kod yazarken veya yeni bir projede, aradığınız değişiklikleri bastırın. Eğer yeni bir kodsa, eski silahlar bıraktıkları gibi olmasını beklemiyorlar ve avantajları gördüklerinde yeni yolu öğrenip adapte edebiliyorlar.

Eski sistem değişebilir ama zaman alıyor. Bir şeyi değiştirmek risk ve iş nefreti riskini beraberinde getirir ve şirketin değişimle rahat etmesini sağlamak için zaman ve çalışmanız gerekir.

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.