JavaScript'i Yeniden Düzenleme: Eski Kodla Çalışırken Teknik Borçtan Nasıl Kaçınılır

Yeniden düzenleme yapmaktan kaçındığınız eski bir JavaScript kod tabanınız var mı? WordPress'te de öyle. Son zamanlarda WordPress çekirdeğine dikkat ediyorsanız, JavaScript ve yeni özellikler eklerken eski JavaScript'in nasıl yeniden yapılandırılacağı hakkında tartışmalarda bir artış olduğunu fark etmiş olabilirsiniz. #core Slack kanalında zaten birkaç JavaScript toplantısı yapıldı. İlk günler, ancak WordPress, JavaScript bölümünde büyük bir revizyona girmeye hazırlanıyor. Gutenberg başlıklı yeni editör projesi, Özelleştirici güncellemeleri ve REST API destekli wp-admin, gelecekteki sürümler için planlanan üç büyük odak alanıdır.

Bu odak alanları, özellikle Gutenberg projesi ve REST API uygulaması etrafındaki tartışmalar, daha büyük bir JavaScript kod tabanını yeniden düzenleme sorununu akla getirdi. WordPress gibi devasa bir JavaScript kod tabanında yeni özellikler ve çerçeveler eklemeye nereden başlıyorsunuz? Bu makalede, bu tür yeniden düzenlemeyi yönetmeye yönelik bazı yaklaşımlardan bahsedeceğiz, JavaScript'i yeniden düzenlerken belirli seçeneklerin bazılarını gözden geçireceğiz ve aynı zamanda şu anda kod tabanınızda yapılabilecek bazı güncellemeleri gözden geçireceğiz. Bu devasa main.js dosyasını modernize etmeye hazır mısınız? Hadi hadi bakalım!

Teknik Borç (veya neden kodunuzun bir kısmı 1997'den gelmiş gibi görünüyor)

Çoğu geliştirici gibiyseniz, muhtemelen birkaç yıl(!) önce yazılmış eski bir kod tabanıyla çalışmak zorunda kalmışsınızdır. JavaScript dünyasında birkaç yıl, birkaç yüzyıl gibidir, bu nedenle çoğu zaman bu eski koda dokunmaktan kaçınmaya çalışır ve karışıklığı bozmadan dikkatlice yeni özellikler eklersiniz.

Bu yaklaşımdan doğabilecek sorunları anlamak için aşağıdakileri hayal edelim. Patronunuz size geliyor ve “Bir an önce feature-x eklememiz gerekiyor!” diyor. Yani bu yeni özelliği kullanmaya başlayın ve kendinize “Gerçekten Angular 4 ve TypeScript'i denemek isterim, belki onları bu yeni özellik için kullanırım” diye düşünüyorsunuz. Böylece 100 yıllık jQuery çorbasını olduğu gibi bırakırsınız (eski hatalarla birlikte) ve Angular 4 ve Webpack ile yeni modüller oluşturmaya başlarsınız. Geleceğin dalgası!

Çok hızlı değil.

Artık teknik borç denen bir şeyi artırdınız. Bu, yazılım geliştirmede oldukça yaygın bir şeydir – temelde, her kod satırının ileriye dönük olarak korunması ve gözden geçirilmesi gerektiğini ve yeni özellikler veya işlevlerle ilerlerken sorunları veya hataları daha sonra bırakmanın bu teknik borcu büyük ölçüde artırdığını anlamaktır. Eski kod ve hatalar, gelecekte kod tabanında daha fazla değişiklik yapılması gerektiğinde ödenmesi gereken borç haline gelir. Öyleyse patronunuz bir ay sonra geri gelip size eski bir bileşeni güncellemenizi istediğini söylediğinde ne yaparsınız? Eski bileşeni yeniden düzenleyin ve Angular 4'e mi taşıyın, yoksa maymun yamalayın mı?

Elbette orijinal çerçevelerinize veya süreçlerinize bağlı kalarak bile teknik borç yaratabilirsiniz, ancak yeni bir çerçeveye veya sürece geçtiğinizde katlanarak artabilir. Yeniden düzenleme ve genel kod kalite standartlarına yakından bağlıdır.

Teknik borçtan kurtulmanın tek yolu herhangi bir kod yazmamaktır!

WordPress çekirdek geliştirme şu anda bu zorlukların çoğuyla karşı karşıya. İleriye dönük UI etkileşimleri için hangi çerçevenin seçileceğine ve ayrıca eski ve yeni kod için yaklaşımın ne olması gerektiğine dair kararlar alınmaktadır.

WordPress Örneği

Belki de internette kullanımda olan daha büyük JavaScript kod tabanlarından biri ile WordPress, gelecekteki özellikleri ve sürümleri planlamada bir zorlukla karşı karşıyadır. Yeni sürüm programıyla, özellikler her ana sürümün merkezinde yer alır ve önemli yeni özellikler eklerken hızlı bir şekilde yayınlama baskısı vardır.

WordPress çekirdeği tarafından kullanılan mevcut JavaScript'in stokunu almaya girişirseniz, biraz bunalmış olabilirsiniz. Adam Silverstein tarafından yakın zamanda yapılan bir ankette , 16'sı Backbone.js kitaplığını kullanan toplam 95 JS dosyası olmak üzere 38.191 satır listelenmiştir.

WordPress, teknik borcu dengeleme ve yeni özelliklerin uygulanmasıyla yeniden düzenlemeye karşı bağışık değildir. Günlüğe kaydedilen çok fazla JavaScript hatası olmadığından, teknik borcun WordPress için daha az sorun olduğu veya en azından iyi bir şekilde ele alındığı söylenebilir. Ancak borç, eski mantığı yeni modele uyacak şekilde yeniden düzenlemezken yeni çerçeveler ve kitaplıklar eklemekten kaynaklanır.

Çerçeve parçalanmasına yeni bir örnek Project Gutenberg'dir. Bu, WordPress düzenleyicisini "yeni bir sayfa oluştur ve oluşturma deneyimi gönder" için güncelleme projesidir. Amaç, kısa kodları ve özel HTML'yi "bloklar" ve daha esnek bir düzenleyici arayüzü ile değiştirmek.

Gutenberg ekibi, React çerçevesine dayanan bir prototip oluşturdu. React şu anda çekirdekte kullanılmamaktadır, bu nedenle ek bir çerçeve eklemek anlamına gelir. Ayrıca React, şu anda WordPress çekirdeğinde kullanılan iki çerçeve olan Backbone veya jQuery'den temelde farklı bir çerçevedir.

Bu yeni O'Reilly kitabı için çok heyecanlıyım pic.twitter.com/PnhQuG3257

— Wes Bos (@wesbos) 12 Mayıs 2015

React kullanma kararı, özelliklerin tutarlılığa ve ek bir çerçevenin ek ağırlığına öncelik verilmesi sorununun altını çiziyor. Hacker Noon'daki ilginç bir gönderi, bağımlılıkları en aza indirmenin 'yalın' kalmanın ve hızlı hareket etme yeteneğini korumanın önemli bir bileşeni olduğunu vurguluyor.

Projenize bir kitaplık eklediğinizde, o kitaplığın tamamını ve onu kullanımınız için kira ödüyorsunuz. Bu nedenle, her kütüphane, her eklenti için iyi bir durum oluşturmanız gerekir. Küçücük olanlar bile. Hızlı bir şekilde toplanırlar. Ve aşırı hafif, disiplinli bir yaklaşımı benimserseniz, ne kadar hızlı hareket edebildiğinize şaşıracaksınız.

WordPress çekirdeğine önemli bir refactor olmadan başka bir çerçeve ekleyerek, eklenen karmaşıklığın ve borcun yeni özelliklerin değerinden daha yüksek olduğunu iddia ediyorum. Büyük bir yeniden düzenleme yerine, farklı JavaScript bileşenlerini birbirine bağlamak için en azından standart bir API tanımlamak mantıklı olacaktır.

Ayrıca, WordPress çekirdeğinde JavaScript'in geleceğini tartışmak açısından henüz erken olduğunu da belirtmeliyim, ancak görünüşe göre bazı görüşler ve yönler oluşmaya başlıyor.

Gutenberg'in React'e sadık kalıp kalmayacağını ve çekirdekte birleşip bütünleşmeyeceğini zaman gösterecek, ancak eski JavaScript projelerini yeniden düzenlemek için denenmiş ve doğrulanmış bazı yöntemler var. Kendi eski JavaScript'imizle neler yapılabileceğini görelim.

JavaScript Yeniden Düzenleme Seçenekleri

Böylece, WordPress çekirdeğinin bile teknik borçtan ve JavaScript kod tabanının önemli kısımlarını yeniden düzenlemenin mahkumiyetinden muzdarip olduğunu gördük. Ancak modern JavaScript kitaplıklarından ve çerçevelerinden yararlanmak için ne yapılabilir ? Sağlam bir kodlama standartları ve testleri seti ile başlar. Birkaç seçeneğe bakalım.

JavaScript Kodlama Standartları

Teknik borcu en aza indirmenin ve yeniden düzenleme maliyetini düşürmeye başlamanın ilk adımı bir kodlama standardına sahip olmaktır. JavaScript için varsayılan değerlere sahip çok sayıda proje vardır, ancak bu gerçekten ekibiniz ve projeniz için neyin işe yaradığına bağlıdır. ESLint gibi araçlar bu standartların uygulanmasına yardımcı olabilir ve kodun tutarlı bir biçimlendirme düzeyini korumasını sağlamak için git ön taahhüt kancasına kurulabilir. Kod formatı ve tutarlılığı, tüm kodlar aynı stile bağlı olduğundan, okumayı ve incelemeyi kolaylaştırdığından geliştirme hızına yardımcı olur.

Kod incelemeleri yapıyorsunuz değil mi?

Sağlam bir kodlama standartlarına sahip olmanın diğer avantajı, eski kodun yeniden düzenlenmesi de dahil olmak üzere koddaki tüm güncellemelerin kodlama standartlarına uyması gerektiğidir. Bu, eski kodu yavaş yavaş modernleştirmeye ve yeni kodun kalitesine ve tutarlılığına getirmeye yardımcı olur.

React ile Birim Testleri

Bu makalede React hakkında konuştuğumuz için, fiili React test kitaplığı Jest ile birim testlerinin nasıl kurulacağını gözden geçireceğiz. Jest, kurulumu oldukça basit bir araçtır ve React ile hızlı bir şekilde çalışmaya başlamak istiyorsanız, Create React App ile birlikte gelir.

Bu, Create React App ile önceden yapılandırılmış olarak gelen basit testtir.

 import React from 'react'; import ReactDOM from 'react-dom'; import App from './App'; import { shallow } from 'enzyme'; import Header from './Header'; it('renders without crashing', () => { const div = document.createElement('div'); ReactDOM.render(<App />, div); }); it('renders header with props', () => { const header = shallow(<Header title={'What\'s up doc?'} />); expect(header.contains('What\'s up doc?')).toEqual(true); });

Açıkçası, çalıştırılabilecek daha karmaşık testler var, ancak birim testi ile kurulum yapmak için ne kadar ek çaba gerektiğini gösteriyor. Çok değil! Jest kitaplığını kullanmanın yararı, Vanilla JavaScript için de testler yazmanıza izin vermesidir. Hem yeni hem de eski kod için testler yazarak yeniden düzenleme riski azalır. Test kapsamının amacı, yol boyunca herhangi bir gerileme veya kırılmayı ele almaktır.

Kısmi Yeniden Düzenleme

Kısmi yeniden düzenleme veya "gittikçe temizleme", birçok projenin yeniden düzenleme için seçtiği bir seçenektir (Delicious Brains Inc. dahil!). Bu, yeni özellikler ve kod eklerken eski kodu güncellemeyi içerir. Örneğin, WordPress gibi, görünüm katmanınızı React'e geçirmek istediğinizi varsayalım. Ayrıca şunun gibi bir sürü eski jQuery ve AJAX çağrınız olduğunu varsayalım:

 $( function() { $( ".my-form" ).on( 'submit', function( e ) { var repo = $( '.repo' ).val(); var endpoint = 'https://api.github.com/repos/' + repo + '/issues'; $.get( endpoint, function( data ) { if ( !data.length ) { $( '.message' ).html( 'No issues for: ' + repo ); return; } $( '.issue-wrap' ).empty(); $( '.message' ).empty(); $( '.repo-name' ).html( repo ); var details = data; for ( var i = 0; i < details.length; i++ ) { var formatted_body = details[ i ].body.split( '\n' ).join( '<br>' ); console.log( formatted_body ); $( '.issue-wrap' ).append( ' <div class="issue-info"><div>' + '<h3><a href=' + details[ i ].html_url + ' target="_blank">' + details[ i ].title + '</a></h3>' + '<p><small>reported by - <a href=' + details[ i ].user.html_url + ' target="_blank">' + details[ i ].user.login + '</a></small></p>' + formatted_body + '</div></div>' ) } } ).fail( function( jqXHR, textStatus, errorThrown ) { console.log( errorThrown, jqXHR.status, textStatus ); $( '.message' ).html( errorThrown + " " + jqXHR.status + " " + textStatus ) } ) e.preventDefault(); } ); } ); 

CodePen'de Peter (@tasker82) tarafından kaleme alınan Pen jQuery Github Sorunları listesine bakın.

Tanıdık görünmek? Bana da olmuyor.

Görünüm katmanımızı React'e dönüştürerek artımlı bir yaklaşım benimsemek istiyorsak, dize biçimlendirme parçalarından bazılarını React bileşenlerine taşımaya başlayabiliriz.

 class IssueInfo extends React.Component { render() { const details = this.props.details; return ( <div className="issue-info"> <h3><a href={details.html_url} target="_blank">{details.title}</a></h3> <p> <small>reported by - <a href={details.user.html_url} target="_blank">{details.user.login}</a> </small> </p> <div> {details.body.split( '\n' ).map( ( item, key ) => { return <span key={key}>{item}<br /></span>; } )} </div> </div> ); } }

Ve verilerimizi sahne ve durum verileri olarak ayarlayın.

 <div className="issues-box"> { Object.keys( this.state.data ).map( key => <IssueInfo key={key} index={key} details={this.state.data[ key ]} /> ) } </div>

Ve eğer gerçekten jQuery'den uzaklaşmaya başlamak istiyorsak, yerel fetch() yöntemini kullanmak için AJAX çağrılarımızı değiştirebiliriz. Aşağıda, React'te tamamen yeniden düzenlenmiş bir sürüm bulunmaktadır.

CodePen'de Peter (@tasker82) tarafından kaleme alınan Pen React Github Sorunları Listesine bakın.

Bu basit örnekte görebileceğiniz gibi, JavaScript kodunuzun parçalarını yeni bir süreç veya çerçeveyle kısmen değiştirmek çok zor değil. Bu yaklaşımın dezavantajı, bir süre için, yetişmek için iki veya daha fazla JavaScript çerçevesine sahip olmanızdır. Bazı projeler için bu kabul edilebilir bir orta yol ve WordPress çekirdeğinin alacağı yaklaşımın bu olduğuna dair bir his var.

tek kullanımlık iş

Aksi halde yeniden düzenleme gerektiren daha büyük kod tabanlarında yardımcı olabilecek başka bir yöntem de 'kullan at' çalışması kavramıdır. Bunlar, temel olarak gelecekteki potansiyel özellikler için prototip görevi gören projelerdir. Esasen, hızlı hareket etme kararı verirsiniz, kod incelemesi ve tutarlılık gibi şeyleri atlarsınız ve derin uçlara inersiniz, gerekli her şekilde prototipi tamamlarsınız. Geliştiricilerin, aksi takdirde söz konusu olmayacak çerçeveleri veya platformları seçmelerine olanak tanır. Prototip başarılıysa ve tüm gereksinimleri karşılıyorsa, olduğu gibi kullanılması, değiştirilmesi veya çöpe atılması konusunda kararlar alınabilir.

Bu şekilde prototipleme, bir konseptin uygulanabilir olduğunu gösterir ve potansiyel olarak seçilen yaklaşımın avantajlarını veya dezavantajlarını vurgular. Geçmişte bu yaklaşımı bir evcil hayvan projesi oluşturmak ve yöneticime bir fikrin uygulanabilir olduğunu kanıtlamak için kullandım. Bu aynı zamanda Gutenberg projesiyle yaptıkları gibi görünüyor ve eğer çekirdeğe kabul edilirse süper pompalanırdım.

Ancak bunun gibi prototip oluşturmanın riskleri vardır. Kodu üretime geçirmeden önce "temizlemek" için bir taahhütte bulunulması gerekir. Bu adım atlanırsa, daha fazla teknik borç oluşturmaya geri dönersiniz.

Yukarıdakilerin hiçbiri

Elbette diğer seçenek, parlak yeni bir çerçeve kullanarak tüm kod tabanınızı yeniden yazmaktır. Bunu bir seçenek olarak sunanlar için el gösterisi? …😏

Tüm ciddiyetle, büyük bir kod tabanını, özellikle JavaScript'i yeniden düzenlemek çok büyük bir iştir. Bu makaledeki amacım, yararlı bulduğum bazı seçenekleri ele almaktı. Ancak gerçekte, eski JavaScript sorununu çözmenin ve yeni çerçevelere ve özelliklere uymanın birçok farklı yolu vardır. WordPress çekirdeğinin hangi yolu izlediğini görmek ilginç olacak ve insanların aldığı diğer yaklaşımları duymakla yakından ilgileniyorum.

Bir JavaScript yeniden düzenleyicisi aldınız mı? Nasıl bir yaklaşım sergilediniz? Yorumlarda bize bildirin!