Kitapta belirttiğim bir nokta var, ancak o zamandan beri insanlara birkaç kez dikkat çekmek zorunda kaldım ve bu yüzden onu biraz daha vurgulamak istedim.
Kodu temizlediğinizde, daima ürünün hizmetinde yaparsınız. Refactoring aslında bir örgütsel süreç (“bir işle uğraşmak zorunda olmak” anlamına gelen “örgütsel” tanımı değil, “işleri sıraya koymakla uğraşmak anlamına gelir” anlamına gelir). Yani, sırayla koyuyorsun ki yap şey.
Yeniden yapılanma uğruna yeniden başlamaya başladığınızda, yeniden yapılanma kötü bir ad alır. İnsanlar zamanınızı boşa harcadığınızı, güvenilirliğini yitirdiğinizi düşünmeye başlar ve yöneticiniz veya meslektaşlarınız işinize devam etmenizi engeller.
“Yalnız yeniden yapılanma uğruna refactoring” derken, demek istediğim bir kod parçasına bakmak. hiçbir şey değil üzerinde çalıştığınız şeyi yapmak, “Bunun tasarlanma şeklini sevmiyorum” diyerek ve tasarımın parçalarını sistemin işlevselliğini etkilemeden hareket ettirmek. Bu, eviniz yanarken çimleri sulamak gibi. Kod tabanınız gördüğüm kod tabanlarının çoğuna benziyorsa, “eviniz yanıyor” muhtemelen uygun bir benzetmedir. Öyle olsa bile, işler o kadar da kötü değilse, mesele, odaklanması gerekmeyen bir şeye odaklandığınızdır. Kodu yeniden düzenlemek için harika bir iş çıkarıyormuş gibi hissedebilirsiniz, ve muhtemelen puan Çimleri sulamak güzel bir çimlere sahip olmak. evin önünde. Yeniden düzenlemenizin mevcut ürünle hiçbir ilgisi yoksa veya sisteminizin özellik hedeflerine sahipse, hiç kimsenin kullanmadığı, ilgilendiği veya umursadığı bir şeyi yeniden sipariş etmekten başka bir şey gerçekleştiremezsiniz.
Peki yapmak istediğin nedir? Genelde, yapmak istediğin şey, uygulamak istediğin bir özelliği seçmek ve bunu hayata geçirmeyi kolaylaştıracak şeyleri yeniden düzenleyebileceğini bulmak. Ya da sıklıkla üzerinde çalışılmakta olan kodun bir alanını buluyorsunuz ve bu alanda bazı düzenlemeler yapıyorsunuz. Bu insanları yapacak anlamak işin. Bu sadece bununla ilgili değil – gerçekten takdir edecekleri gerçeğiyle ilgili çünkü siz bir şeyler yapıyorsunuz etkili. Ancak, yaptığınız iş için takdir veya (en azından kibar bir onay formu) devam etmenizi teşvik edebilir, diğer kişilerin işinize önem vermeye başladığını gösterebilir ve umarım iyi gelişim uygulamalarının yaygınlaştırılmasına yardımcı olabilir. şirketin.
Hiç bir şeyi olmayan bir yeniden düzenleme projesini ele alacağınız bir zaman oldu mu? direkt olarak Yapmanız gereken işi yapmak için mi? Bazen yapmak zorunda olduğun bir şeyi yeniden düzenlersin dolaylı olarak Sahip olduğun amaç için. Kimi zaman özellikle karmaşık bir soruna bakmaya başladığınızda, en alttaki kumlara inmek için sahilde kayaları toplamaya çalışmak gibi bir şey olur. Bir taşı hareket ettirmeye çalışın ve ilk önce başka bir taşı hareket ettirmeniz gerektiğini anlayın. O zaman, o kayanın büyük bir kayaya karşı olduğunu keşfettin ve her yerde kayalar var. o taşınmasını engelleyen kaya, vb.
Bu nedenle, sizi yeniden yönlendirme yapmaktan alıkoyan sorunları ele almalısınız. Bu problemler yeterince büyüyerse, bu problemleri çözme görevi olan özel bir mühendise, özellikle de kendini yeniden düzenlemeyi engelleyen problemlere ihtiyacınız olacaktır. (Örneğin, kodunuzun veya yapı sisteminizin bağımlılıkları o kadar karmaşıktır ki hiç kimse herhangi bir kodu herhangi bir yere taşıyamaz ve eğer bu kadar büyük bir sorun varsa, bir kişi için aylarca çalışabilirsiniz.) Tabii ki, ideal olarak siz ' Asla sorunlarınızın çok büyük olduğu, normal işini yapan bir kişi tarafından taşınamayacağı bir duruma girmeyin. Bunu başarma şekliniz, artımlı gelişim ve tasarım ilkelerini izleyerek ve sistemi her zaman olduğu gibi göstererek yapmak, şu anda yaptığı işi yapmak üzere tasarlanmıştır.
Ancak, dünyadaki çoğu yazılım projesine benziyorsunuz. vermedi Bunu yapın, şimdi kötü bir durumdasınız ve sisteminizin altında gömülü olduğu kaya yığınından çıkarılmanız gerekiyor. Bu konuda kendimi kötü hissetmeyecektim, çünkü bu konuda kendimi kötü hissetmek gerçekten bir şeyi başarmıyor. Kendini kötü hissetmek ya da kafasını karıştırmak yerine, yapmanız gereken şey soruna artımlı olarak saldırmanıza ve bulunduğunuz yerden daha iyi bir duruma gelmenize izin verecek bir sisteme sahip olmaktır. Bu, sistemi ilerledikçe iyi tasarlanmış tutmaktan çok daha karmaşık, ancak yapılabilir.
Karmaşık bir kod temeli temizlemenin temel prensibi, bir özelliğin hizmetinde daima yeniden yönlendirici olmaktır.
Görüyorsunuz, sorun şu ki bu "kaya" dağına sahip olmanız. Yanan bir ev gibi bir şeyiniz var, ancak evin birkaç dağın büyüklüğü olması ve her zaman yanması gibi. Şu anda gerçekten ihtiyaç duyduğunuz “dağ” veya “evin” hangi kısmını bulmanız ve bunu bir dizi küçük adımda “kullanılabilecek” şekilde biçimlendirmeniz gerekir. Yangın mükemmel, tehlikeli ve hayati tehlike oluşturduğu için bu mükemmel bir benzetme değildir. Ayrıca, onları temizleyebildiğinizden daha hızlı bir şekilde yok eder. Ancak bazen bir kod temeli aslında bu durumdadır – daha iyi hale geldiğinden daha hızlı bir şekilde daha kötüye gidiyor. Bu başka bir ilke:
İlk hedefiniz, sistemi daha da kötüye gitmek yerine zaman içinde daha iyi hale geldiği bir yere sokmak.
Bunlar pratikte aynı prensibi, tamamen farklı gelmelerine rağmen. Nasıl olabilir? Çünkü daha da kötüye gitmek yerine kod tabanını zamanla daha iyi hale getirmenin yolu, insanların özellikleri eklemeden hemen önce yeni özellikler eklemek üzere oldukları kodu yeniden düzenlemelerini sağlamaktır.
Bir kod parçasına bakıyorsun. Diyelim ki, şirketinizde çalışan adlarının bir listesini oluşturan kodun bir parçası. Listeyi işe alındıkları tarihe göre sıralamak için yeni bir özellik eklemeniz gerekir. Kodu okuyorsunuz ve değişken isimlerinin ne anlama geldiğini bulamıyorsunuz. Bu yüzden, yapabileceğiniz ilk şey, yeni özelliği eklemeden önce, ayrı, değişken adlarını iyileştiren bağımsız değişiklik. Bunu yaptıktan sonra, kodu hala anlayamazsınız, çünkü hepsi 1000 satır kod içeren tek bir işlevdedir. Böylece onu birkaç işleve ayırıyorsunuz. Belki şimdi yeterince iyidir ve yeni sıralama özelliğini eklemenin oldukça basit olacağını düşünüyorsunuz. Belki de nesneye yönelik bir dilde iseniz, devam etmeden önce bu işlevleri iyi tasarlanmış nesnelere dönüştürmek istersiniz. Her şey size kalmış; temel nokta, bir şeyler yapmanız gerektiğidir. daha iyi ve daha da kötüye gitmekten daha hızlı olmaları gerekir. Ne kadar ileri gittiğine dair bir yargılama noktası. Kendini dengelemek zorundasın. yap özellik hedeflerinizde ilerleme kaydetmeniz ve yalnızca kodunuzu sonsuza dek düzeltemeyeceğiniz konusunda ilerleme kaydedilmesi gerekiyor.
Genel olarak, kodumun etrafına bazı sınırlar koydum, “Bu özelliği gerçekleştirmek için projem dışında hiçbir şeyi yeniden düzenlemeyeceğim” veya “Daha önce programlama dilinde bir değişiklik beklemeyeceğim. Bu özelliği bırakabilirim. ”Fakat sınırlarım dahilinde iyi bir iş yapmaya çalışıyorum. Ve özelliği gerçekten geliştiremeyeceğim bir duruma girmeden sınırı olabildiğince geniş tutmaya çalışıyorum. Genellikle bu bir zaman sınırı olduğu gibi “kod tabanının kapsamı” (örneğin kod tabanımın ne kadar dışında) sınırı — zaman bölümü genellikle en önemlisidir, “Üç aylık bir proje yapmayacağım. iki günlük bir özellik geliştirin. ”Ancak bununla bile, yeniden yapılanmaya zaman ayırmanın yanında bazı şeyleri dengeliyorum, özellikle bunu ilk önce bir kod tabanında yapmaya başladığımda ve bu yeni bir şey ve her şey çok dağınık.
Bu da bizi başka bir noktaya getiriyor – refactor için daha fazla zaman alacağınızı ve sonra özelliğini geliştireceğinizi düşünseniz bile, benim deneyimime göre genellikle daha az zaman alır veya genel olarak aynı miktarda zaman alır. “Genel” burada hata ayıklamak, sürümleri geri almak, hata düzeltmeleri göndermek, karmaşık sistemler için testler yazmak, vb. Harcayacağınız zamanları içerir. Karmaşık sisteminize yeniden yönlendirme yapmadan bir özellik yazmak daha hızlı görünebilir ve bazen , ancak çoğu zaman daha az zaman harcayacaksınız tüm Yeni bir özellik eklemeye başlamadan önce sistemi ilk önce sıraya koymak için iyi bir iş çıkarırsanız. Bu sadece teorik değil – defalarca böyle olduğunu gösterdim. Aslında takımımın projelerini bitirdim Daha hızlı Bunu yaptığımızda daha iyi araçlarla daha yeni kod tabanları üzerinde çalışan ekiplerden daha iyi. (Yani, diğer takım bizi daha fazla geliştirebilmeliydi, ancak ürünün hizmetine sürekli olarak yeniden baktık ve her zaman sürümlerimizi daha hızlı bir şekilde ortaya çıkardık ve kabaca aynı sayıdaki özellikler açısından öne çıktık. benzer özelliklerde çalışan iki projede de geliştiriciler.)
Belirli bir kod parçasını yeniden gözden geçirme işleminde “ne zaman yapıldığına” karar vermek için kullandığım başka bir nokta var; bu, başkalarının tasarladığım deseni açıkça görebileceğini ve kodu koruyacağını düşünüyorum. bu düzende o andan itibaren. Bazen, sistemin amaçlanan tasarımını tanımlayan küçük bir belge parçası yazmam gerekir, böylece insanlar onu takip eder, ancak genel olarak teorim (ve bu gerçekten sadece bir teoridir – bunun için yeterli kanıtım yok) Ancak, yeterince iyi bir kod parçası tasarlarsam, nasıl tasarlanması gerektiğini açıklayan bir belge belgesine ihtiyaç duymaması gerekir. Muhtemelen sadece nasıl tasarlandığı kodu okumaktan görülebilir olmalı ve olması gerektiği gibi olmalıdır. çok açık Bu tasarım içinde kimsenin başka türlü yapamayacağı bir özelliği nasıl eklersiniz? Açıkçası, kusursuzca bu hedefe ulaşmak imkansız olurdu, ama bu yazılım tasarımında genel bir gerçek:
Mükemmel bir tasarım yok, sadece bir daha iyi tasarımı.
Bu, “bisiklet sürdüğünüzü” bildiğinizi ya da aşırı mühendislik yaptığınızı ya da bir şeyi nasıl yeniden düzenleyeceğinizi bulmak için çok fazla zaman harcadığınızı – “mükemmel” hale getirmeye çalıştığınızı bilmenin başka bir yoludur. , ”Çünkü“ mükemmel ”yok.“ “Sahip olduğu amaç için iyi bir iş çıkarıyor” var. Yani, bir tasarım olup olmadığını gerçekten yargılayamazsınız bile. olduğu Kodun tasarlanma amacını anlamadan iyi. Bir tasarım bir amaç için iyi olur, başka bir tasarım başka bir amaç için iyi olur. Evet, genel kütüphaneler var, ama bu bile bir amaç. Ve en iyi genel kitaplıklar, özel amaçlara çok iyi hizmet ettiklerini doğrulayabileceğiniz gerçek kod tabanları ile yapılan gerçek deneylerle tasarlanmıştır. Refactoring yaparken, fikir şu anda amacına uygun olmayan bir tasarımdan tasarımı uygun bir tasarımla değiştirmek. şimdiki bu kod parçasının amacı. Yeniden yapılanma hakkında bilmeniz gereken tek şey bu değil, ancak başlamak için oldukça iyi bir temel prensip.
Dolayısıyla, kısacası, yeniden düzenleme, üretimi mümkün kılmak için gerçekleştirdiğiniz organizasyonel bir süreçtir. Yeniden ateşlenirken üretime doğru gitmiyorsanız, karşılaşacaksınız. çok farklı türden sorun. Size yanlış giden her şeyi bile söyleyemem, ama olacaklar. Öte yandan, sadece bir sistem üretmeye çalışırsanız ve asla Yeniden düzenleyin, kendinizi üretimin zor ya da imkansız olduğu bir karmaşaya sokacaksınız. Bu yüzden her ikisinin de yapılması gerekiyor – bir ürün üretmelisiniz ve sistemi ürünün hızlı, güvenilir, basit ve iyi bir şekilde üretilebileceği şekilde organize etmelisiniz. Kurum dışına çıkarsanız, istediğiniz ürünü alamazsınız ve üretimden çıkarsanız, ilk başta refactoring'i yapmak için bile hiçbir neden yoktur.
Evet, çimleri sulamak güzel, ama önce bazı yangınları söndürelim.
-Max