büyük değişiklikler önermek / stajyer olarak yeniden yazmak [kapalı]

Bağlam:

• dahili bir proje (pek çok insanın kullandığını sanmıyorum)
• bu eski
• güncelliyoruz

Sorunlar:

1. mvc çerçevesini kötüye kullanır (model kullanımı, görünümlerde iş mantığı vb.)
2. yapmamız istendiğinde küçük, ancak düşük uyum nedeniyle iki seçeneğimiz var:
   1. bir şeyler yapmaya devam et
   2. büyük kod parçalarını hareket ettirin veya yeniden yazın

Çözümler (görüyorum):

1. onunla çalışmaya devam edin, yakında yapılması lehine en iyi uygulamaları göz ardı edin ve yeniden düzenleme / yeniden yazma yoluyla yeni hatalar getirmeme
2. refactor / yeniden yazma

Sanırım sorum şu: Bu projede büyük değişiklikler yapmak istersem, kimseye hakaret etmeden bunu nasıl önerebilirim? Yoksa bazen (mecazi) bir koli bandı anlamına gelse de akışla devam etmem daha iyi olur mu?

Tamam İşte gidiyor.

Uygulamanın kötü yapılandırılmış ve kötü yazılmış olduğunu düşünüyorsunuz.

Müşteri işi yaptığını düşünüyor.

"İç güzelliğini" iyileştirmekten başka bir nedenden ötürü yeniden yazmak istiyorsunuz.

Yani müşteriden uygulamayı şimdi tam olarak ne yaptığını yapmak için para harcamasını istiyorsunuz - sadece kullanıcının görmediği veya anlamadığı parçalar bir şekilde "daha iyi" olacaktır.

Kötü yazılmış kodlara ana itiraz, anlaşılması güçtür.

Kodun anlaşılması zordur ve yalnızca kötü yapılandırılmış bir uygulamada kolayca uygulanabilen işlevlere ve özelliklere sahiptir. Bu nedenle, bu konuda çok iyi değilseniz, yeni uygulama tam olarak geçerli uygulamanın ne yaptığını yapmayacaktır ve orijinal kodun ne yaptığını tam olarak anlamadığınızdan, muhtemelen yanlış yapacaktır.

Böylece müşteriniz, orijinal uygulamadan belirgin şekilde daha kötü bir uygulamayı elde etmek için çok para harcadı. Popüler olmayacaksınız!

Neyse ki daha deneyimli kolejleriniz sizi mizah etmeye hazırlar (muhtemelen başlangıçta aynı hatayı yaptıklarından ve hatta böyle kötü bir kaderli proje için yönetim onayı almak için talihsizliğe sahip olabilirler).

Bu yüzden tavsiyem eski kod tabanını çalışır durumda tutmak ve sessiz kalmak olacaktır. Müşteri sadece kod çirkin olduğunu düşünüyorsanız gerçekten umursamıyor çalışan bir sistem istiyor.

Değişikliklerinizi önerin. Her biri için iş durumu konusunda net olun : Teklif ettiğiniz değişiklik neden sisteme bir bütün olarak yardımcı olacak? Değilse, geri itmeyi bekleyin. Neden parayı kırılmayan bir şeyi düzeltmek için harcayalım? Sistemi daha genişletilebilir hale getirmek ve endişelerin ayrılması gibi nedenler geçerli olabilir (kiminle konuştuğunuza bağlı olarak), ancak% 99'u sadece "doğru uygulanmadı" demek sizi hiçbir yere götürmez. Projeye değer kattığınızdan ve yalnızca iş yapmayı önermediğinizden emin olun (kodu temizlese bile).

Ne yazık ki, profesyonel dünyada, bir şeylerin yanlış uygulanması, onun kırıldığı ve bu nedenle sabitlemeye gerek olmadığı anlamına gelmez. Ayrıca, bunu düzeltirken, projenin diğer alanlarını etkileyebilecek öngörülemeyen eleme sorunlarını da ortaya koyabilirsiniz.

Sorunuzu okuma, ben uygulamayı yeniden yazma buna değer aslında şüpheci. Belki de sorunuzun tam vakasını yapma zahmetine girmediniz. Ancak, eski, nadiren kullanılan bir dahili uygulama ise yeniden yazmanın yararının maliyete değer olması muhtemeldir? Yeniden yazma maliyetinin, sahip olacağı tüm güncellemelerin ve yamaların toplamından daha fazla olması muhtemeldir.

Bunun doğru olmadığını düşünüyorsanız, bunun için burada olduğundan daha fazla dava açmanız gerekecektir.

Uygulamayı geliştirmeye gelince, güncellemelerinizde doğal olarak gerçekleşen biraz yeniden düzenleme için biraz şansınız olabilir.

Sen stajyersin. Muhtemelen, sen yenisin. Muhtemelen bir aptal için şüpheleniyorlar.

Böylece öneri yapmaya devam ederken hafifçe bas . Mütevazi ve alçakgönüllü olun. Diğer üyelerin kod tabanı ve hangi baskı altında olabilecekleri hakkında kendi fikirlerini tartışmalarına izin verirken fikirlerinizin etkileşimli olarak akmasına izin verin (bir şeyleri temizlemek için çaba gösterilmemesinin çok iyi bir nedeni olabilir).

Onların güvenini kazanmak istiyorsun. Bunu, verilen görevler için iyi kod yazarak yaparsınız. Temiz bir şekilde yazın, uygulandığını görmek istediğiniz en iyi uygulamaları kullanın, ancak yalnızca ne yapmak istediğinize. Bunlar muhtemelen küçük şeyler olacak, takımın geri kalanının muhtemelen düşündüğü şeyler önemsiz. Bunları iyi yapın. Bulunduğunuz köşeyi aydınlatın ve ekip kodunuzu olumlu bir şekilde gözden geçirmeye başladıkça, fikirleriniz de sonuçta büyüyecektir.

Sonunda , yetkinliğinizi ve bilginizi gösterdikçe, bir veya iki öneri çekebilirsiniz.

Bu öneriyi tamamen yapardım, ancak sadece diğer bir geliştiriciye . Yönetimin sınırların üstesinden gelmenin bir türü olarak göreceğini hayal edebileceğim gibi, yönetimle gündeme getirmezdim.

Birlikte çalıştığınız bir geliştiriciye öneride bulunduktan sonra, muhtemelen kod tabanının neden böyle olduğuna dair bazı iyi nedenleri olacaktır. Sebepleri "hayır, aslında kod iyi, sadece MVC (ve bu yüzden bir stajyer) anlamıyorsunuz" den "harika bir fikir, yeni uygulamayı birlikte tasarlayalım!"

Bu uygulamayı yeniden düzenlemenin cevabının muhtemelen daha fazla olmayacağını unutmayın; Bir stajyerin dahili bir uygulamanın yeniden yazılmasını devralmasını asla istemem (staj tamamlandığında ve yeniden yazma işlemi sadece yarı bitmişse ne olur?) Ayrıca, muhtemelen dahili bir uygulamanın etrafında dolaşmaktan daha önemli şeyler olabilir .

Ama akranlarınıza sormak asla acıtmaz ve eğer yaparsanız, bir şeyler öğreneceksiniz. Ve bu, 7983879342, bir stajın ne olduğudur.

Ne olursa olsun, umarım aşağıdaki mesajı alıp götürürsün. Yukarıdaki yanıtlardan bazıları bazen bir kodun yeniden yazıldığına işaret ettiğinden, en iyi teknik nedenlerden dolayı bazen işletme / maliyet nedenleriyle mümkün değildir. Çok fazla programcı teknik çözümde yaşıyor ve teknik zarafet / okunabilirlik / en iyi uygulama arayışlarının, işlerin yapılması gereken şeylerle dengelenmesi gerektiğini düşünmeyi reddediyor. Kişisel deneyimlerime göre bu dengeye (her iki yönden) çarpmayan adam genellikle takım içinde bir sorumluluk olarak görülür.

Bazı şeyleri geri alsanız bile, öğrenme ve büyüme şeklimizi sorgulamaktan vazgeçmeyin.

Diğer yanıtlar durumunuzun politikası hakkında çok konuşuldu ve ben de aynı fikirdeyim. Zorlayıcı bir iş vakası sunmadığınız sürece, yeniden yazma muhtemelen kartlarda değildir.

Ancak, bu İzci Kuralını unutmanız gerektiği anlamına gelmez :

Kamp alanını her zaman bulduğunuzdan daha temiz bırakın.

Bu kod tabanında bir şey uygularken, tasarımın veya uygulamanın bazı yönlerini temizlemek için bir yol çalıştırabilirsiniz, o zaman bu dikkate almanız gereken bir şeydir. MVC modelini daha iyi kullanmak için muhtemelen tüm uygulamayı yeniden yazmanıza gerek yoktur ve belirli bir görünüm için yeni bir iş mantığı uyguluyorsanız, mantığı eski görünümden modele taşımayı düşünebilirsiniz. ve yeni mantığınızı buna ekleyin.

Diğerlerinin de belirttiği gibi, uygulamanın nasıl / neden olduğunu anlayabilmeniz için başka bir geliştiriciden (bu uygulamaya aşina olan) hızlı bir adım atmasını isteyin. Teknolojik yönleri anlayabildiğiniz halde, noktaları iş gereksinimlerine bağlayabileceğinizi açıklayın (iş gereksinimleri hepsini koyar).

Bu bilgileri edindikten sonra değerlendirmenizi yapabilirsiniz. Şahsen bunun yeniden yazılması gerektiğini düşünüyorsanız, ancak başkalarının bunu iyi bir zaman kullanımı olarak göreceğini düşünmüyorsanız, bunu kişisel bir proje olarak kabul edin. Kesinti süresi olduğunda burada / orada bir saat olsa bile, uygulamayı "doğru" yapın. Bitirdiğinizde, diğer geliştiricilere "hey, bunun biraz temizlik yapabileceğini hissettim, bu yüzden kesinti sürem boyunca bazı yan işler yaptım. Ne düşünüyorsunuz?" Onlara değişikliğe basmayın - sadece onlara "hey, siz böyle misiniz?" ve oradan gidin.

Çoğu değişiklik genel bir kural olarak aşamalı olarak gerçekleşir.

Akılda tutulması gereken birkaç şey;

• Uygulamanın geçmişi nedir?
• Bugün neden çirkin?
• Mimari değişikliklerin yararı nedir?

İyi bir strateji, küçük şeyler üzerinde çalışmak ve şeyler hakkında bir sürü soru sormaktır (Google'dan veya kaynaktan öğrenemediğiniz sorular, insanların zamanını boşa harcamayın). Kod tabanı ve geliştiricilerle rahat hissettikten sonra, kodun neden olduğu konusunda iyi bir fikir sahibi olmalısınız. Bazen, sadece, "Evet, birlikte bir şeyleri kesmek ve kapıdan çıkarmak zorunda kaldık". Sistemin normal işlerinize devam ederken meydana gelen küçük parçalarına hafif değişiklikler önerebilirseniz, bu radikal yeniden yazma işlemlerinden daha fazla çekiş sağlar.

Eğer güzel bir şekilde sormak ve mantıklı bir durum yapmak (sadece bir önsezi ya da bunu yapmak için daha iyi bir yol değil) yeniden yazma önermek hiçbir zararı yoktur. Düşük kullanımlı bir uygulamayı yeniden yazma olasılığının düşürülmesi olasılığı yüksektir ve sistemi ilk yazan kimsenin hala etrafta (ve hiyerarşide sizden daha yüksek) olma ve eleştiriye karşı nazik davranmama ihtimali yüksektir.

Bu yüzden "Temel MVC ilkelerini ihlal eden bu korkunç tasarımlı sistemi yeniden yazmamız gerekiyor" demeyin, bunu uygun üst seviyelere (doğrudan üstünüzdeki insanlar) açık bir soru olarak sorun. "Sistemin MVC modelinde yeniden yazılmasının uzun vadede çok fazla zaman kazanıp kazanmayacağını merak ediyorum gibi bir şey. MVC modelini, TDD, vb. Yanıt, bunun gerektirdiğini düşünmüyoruz - zaman tahminlerinize katılmıyorum ve yeni sistemin uygun bir yedek olma olasılığı var. Ya da yanıt şu olabilir, iyi gidin, ama yeni sisteminizin t İnsanların sizi suçlamasını önerdiğiniz zaman diliminde yeni sistemden daha iyi / daha iyi çalışmak. Ve sistem az kullanılmış olsa bile; yeniden yazma döneminde küçük düzeltmelerle güncellemeyi durdurmak kabul edilemeyebilir.