Bir Java geliştiricisinin bir projedeki tipik görevleri

Bir Java geliştiricisinin tipik sorumlulukları nelerdir? Ne de olsa, kendinizi neyin içine soktuğunuzu ve sonunda ne yapacağınızı anlamalısınız, değil mi? Bugün bir Java geliştiricisinin gerçekleştirdiği on hayati görevden bahsetmek istiyorum. Ama önce Jira adlı aracı tanıyalım. Veya zaten aşina iseniz, hafızanızı tazeleyin. jirainsan etkileşimlerini düzenlemek için bir araçtır, ancak bazı durumlarda proje yönetimi için de kullanılır. Başka bir deyişle, bir proje bu araçta açıklanan küçük görevlere bölünmüştür. Bu görevler, uygulamalarından sorumlu olan geliştiricilere atanır. Bir görev, örneğin bazı işlevler eklemek olabilir. Bir görev gerçekleştirilirken, geliştiriciler ve diğer uzmanlar kimin neyi yaptığı ve ne kadar zaman harcadığı hakkında yorumlar ekler. Bu, zaman izleme amacıyla yapılır - hangi görevlere ne kadar zaman harcandığını bilmek. İdeal olarak, bu günde bir kez yapılır: Akşamları masanızdan ayrılmadan önce, 8 çalışma saatinizin ne kadarını çeşitli görevlere harcadığınızı belirtirsiniz. Jira'nın işlevselliği, yukarıda açıklanandan çok daha fazlasına sahiptir, ancak bu, ilk anlayış için yeterli olacaktır.

1. Yeni çözümler tasarlamak

Bir şey yaratmadan ve uygulamadan önce onu kavramsallaştırmanız gerekir, değil mi? Daha önce de söylediğim gibi, bu sadece Jira'da size verilen bir görev olabilir, bu nedenle yeni bir çözüm tasarlamak için çalışır, Jira'da ne kadar zaman harcadığınızı kaydedersiniz. Bu çalışma, bir ekip konferans görüşmesinde yapılan bir tartışma sırasında da gerçekleşebilir: herkes fikrini ifade edebilir ve en iyi olduğunu düşündüğü yaklaşımı önerebilir. Ve burada birkaç noktaya dikkat çekmek istiyorum. İlk olarak, yazılım geliştirme çok yaratıcı bir meslektir, çünkü sorunları çözmenin yeni yollarını bulmak için standart araçları kullanmanız gerekir. Bir görevin çoğu zaman birçok farklı çözümü olabilir. Buna göre, her şey geliştiricinin birikmiş bilgi ve deneyimlerinden büyük ölçüde etkilenen yaratıcılığına bağlıdır. Tüm yaratıcılığınızı ve dehanızı burada sergileyebilirsiniz. ama önemli olan aşırıya kaçmamak. Bunu yaparsanız, kod çok karmaşık ve okunamaz hale gelir. Sonuç olarak siz ayrıldıktan sonra kimse ne kodladığınızı ve nasıl çalıştığını tam olarak anlamayacaktır. Ve her şeyi sıfırdan yeniden yazmak zorunda kalacaklar. Ve seni anabilirler. Birden fazla. Ve konuşulan sıcak, nazik sözler olması pek olası değildir. Buna ihtiyacın var mı? İkinci olarak, bir geliştirici, tek bir çözüme takılıp başkalarına kapalı fikirli olmamanız gerektiği anlamında psikolojik esnekliği korumalıdır. Sanki bir şeyi tek bir şekilde yapmak zorundasın ve başka seçenek yokmuş gibi. Çeşitli nedenlerle bu tuzağa düşebilirsiniz. Örneğin, bakış açınızın doğru olduğunu kanıtlamak istediğinizi varsayalım. Veya belki de zaten kendi tanıdık çözümünüzü tasarlamış ve uygulamışsınızdır — elbette, en iyisi olmadığını kabul etmek istemezsin. Bu durumlar sizi oldukça kör edebilir. Aslında, gurur duyduğunuz ve bir haftadan uzun süredir kodladığınız işlevselliği kaldırmanız gerekse bile, hatalarınızı kabul edebilmeniz ve her zaman açık fikirli olabilmeniz gerekir. Bir iş arkadaşımın Jira'da bu zaman takibi yorumunu bırakarak herkesin gününü nasıl aydınlattığını hatırlıyorum: "Ölü doğmuş özelliğimi çıkardım. Ve yas tuttum."

2. Yeni işlevler yazmak

Bu adım - yeni işlevlerin uygulanması - mantıksal olarak bir öncekinden sonra gelir. Bir projede yer alan tüm işler, Jira'da görevlere bölünür ve bunlar daha sonra iş yüklerine göre geliştiricilere dağıtılır. Bu sürece yönelik "metodolojiler" olarak bilinen ve CodeGym'deki bu makalede hakkında daha ayrıntılı olarak okuyabileceğiniz farklı yaklaşımlar vardır . Kural olarak, görevlerin bir tahmini vardır, bunları tamamlamak için gereken tahmini süre. Görevi aldığınızda geliştirici olarak siz veya ekip lideri tarafından veya planlama sırasında toplu olarak geliştirme ekibi tarafından belirlenir. Yazılım geliştirmeyi pek çok farklı faktör etkilediğinden, bu seferki tahmin çok nadiren doğrudur. Örneğin, bir programcının ilgili teknolojiye aşina olup olmadığı, genel deneyimi, öngörülemeyen çeşitli tuzaklar vb. Bunlar sadece genel tahminlerdir. Bununla birlikte, tüm projeler için zaman tahmini gerekmez. Şahsen, onsuz yaşamayı çok daha kolay buluyorum, özellikle de Başbakan beni günde birkaç kez "zaman tahminleriniz nerede?" Yani, bir görev alırsın,İncelemeye hazır " Jira'da ve kod değişikliklerinizin yorumlarla birlikte revizyon için iade edilmemesi için dua edin.

3. Yazma testleri

Gözden geçiren, yani kodunuzu kontrol eden kişi, uyguladığınız işlevselliği beğendi, ancak size bir sorusu var: ilgili testler nerede? Böylece görevi gözden geçirmeniz için size geri gönderir. Testler, herhangi bir Java uygulamasının önemli bir parçasıdır. Testleri çalıştırarak, uygulamanın düzgün çalışmadığı yerleri hemen belirleyebilirsiniz. Örneğin, bir geliştirici sistemin bir bölümünde bazı değişiklikler yapar ve bunun sonucunda başka bir bölümde davranış değişiklikleri olur, ancak bunu kodlama sırasında fark etmemiştir. Testleri çalıştırarak, bazı testlerin başarısız olduğunu, yani beklenen sonuçları vermediklerini görebilecek. Bu ona sistemde başka bir yerde bir şeylerin bozulduğunu söyler. Bunu bildiğinden, sunucudaki son değişiklikleri gerçekleştirmez ve bunun yerine kodunda hata ayıklama üzerinde çalışmaya devam eder. Evet, çok az sayıda geliştirici test yazmayı sever, ancak yazılım geliştirmeye sağladıkları faydalar inkar edilemez. Müşterilerin kendileri genellikle sürdürmek istedikleri test kapsamı düzeyini belirtirler (örneğin, %80). Bu, bilmeniz gerektiği anlamına gelirçeşitli test türleri ve bunları yazabilme. Java geliştiricileri temel olarak birim testleri ve entegrasyon testleri yazarken, daha kapsamlı (uçtan uca) testler QA ve test otomasyon uzmanları tarafından gerçekleştirilir.

4. Hataları bulma ve düzeltme

Bu aynı zamanda Java geliştiricileri için çok yaygın ve sık yapılan bir görevdir. KG ve test otomasyonu uzmanlarının asıl işi hataları yakalamaktır. Yani programın hatalı davrandığı yerleri arıyorlar, sonra Jira'da görevler oluşturup birilerine veriyorlar. Örneğin, iş yüklerine ve sistemin ilgili bölümlerine aşinalıklarına bağlı olarak onları hangi geliştiricilere atayacağına karar veren bir ekip liderine. Bundan sonra, atanan geliştirici, bir hata ayıklayıcıda saatler harcayarak hatanın temel nedenini bulmaya çalışır., hatanın oluştuğu koşulları yeniden oluşturmak için QA uzmanları tarafından sağlanan hata açıklamasını kullanarak. Geliştirici hatayı bulup düzelttikten sonra düzeltmeyi incelenmek üzere gönderir. Bazen geliştirici hatayı yeniden üretemez, bu nedenle görevi açıklayıcı bir yorumla birlikte QA uzmanına geri gönderir. Bir hatayı bulup düzeltmek çok uzun sürmemeli gibi görünüyor, ancak bazı nüanslar var. Her şey esas olarak geliştiricinin kodun bu bölümünü ne kadar iyi tanıdığına, deneyimine ve teorik bilgisine bağlıdır. Bazen bir bug 20 dakikada bulunup düzeltilebiliyor, bazen ise üç gün sürebiliyor. Bu, geliştirici açıklamayı okuduktan sonra hatanın ne, nerede ve nasıl olduğunu hemen anlamadığı sürece, bu tür bir görevin önceden tahmin edilmesinin özellikle zor olduğu anlamına gelir. Bu durumda,

5. Kod incelemesi

Yukarıda bahsedildiği gibi, bir görevi tamamladığınız anda incelemeye gönderilmelidir. İncelemeyi geçerse, ana şubeye gider. Değilse, ele alınması gereken yorumlarla birlikte geliştiriciye iade edilir. Elbette, kodunuzun bazı yüksek güçler tarafından değil, diğer geliştiriciler tarafından kontrol edildiğini anlıyorsunuz. Bununla birlikte, herkesin kod incelemesi yapmasına izin verilmez - yalnızca iyi kod ile kötü kod arasındaki farkı anlayabilen, gerçek dünya uygulamalarıyla güçlendirilmiş en deneyimli geliştiriciler. Kod incelemeleri genellikle Crucible gibi bir yardımcı araç kullanılarak gerçekleştirilir.. Gözden geçirenler kodu gözden geçirir ve gerekirse belirli satırlar hakkında yorum bırakır. Çeşit çeşit yorum olabilir. Örneğin, bazıları kritiktir. Ele alınmazsa, gözden geçiren kişi kodun işlenmesine izin vermez. Diğer yorumlar, diyelim ki, sadece seçilen yaklaşımla ilgili açıklamalardır. Geliştirici bunları dinleyebilir, not alabilir veya göz ardı edebilir. Bir ekip, kod incelemeleri için kendi kurallarını ve prosedürlerini oluşturabilir, neyin dikkat etmeye değer olup neyin olmadığı, bir kod incelemesini tamamlamak için hangi zaman çerçevesinin ayrılması gerektiği vb. konusunda anlaşabilir. İnceleme yapmak için yalnızca deneyim yeterli değildir: teknik becerilerinizde çok gelişmeniz ve çeşitli kitaplar okumanız gerekir (örneğin, "Kod Temizliği").

6. Kod analizi

Farklı düşünen birkaç kişi aynı anda proje için kod yazdıklarından, kodları ve yaklaşımları farklı olacaktır. Ve zamanla, her şey yavaş yavaş bir karmaşaya dönüşür. Kodu iyileştirmek için bazen, örneğin belirli bir modülü veya tüm uygulamayı analiz etmek, eksiklikleri bulup not almak ve daha sonra bu analize dayalı olarak bir yeniden düzenleme görevi oluşturmak için görevler oluşturulur. Bu tür bir analiz, geliştirme başladığında ekibin daha basit, daha özlü çözümler göremediği, ancak bunları şimdi gördüğü durumlarda da yardımcı olur. Örneğin, bazı yöntemlerde mantık genellikle kopyalanır. Buna göre, daha sonra birçok kez yeniden kullanılabilen ayrı bir yönteme çıkarılabilir. Ya da belki bir sınıf çok şişkin hale geldi ya da bazı kodların bakımı zorlaştı ya da güncelliğini yitirdi ya da... Analiz görevleri, kodun ve uygulamanın kalitesini artırmaya yardımcı olur. Bununla birlikte, benim için büyük miktarda kodu analiz etmek sıkıcı olabilir.

7. Yeniden düzenleme kodu

Kod analizinin bir sonraki kısmı yeniden düzenlemedir. Kod eski, eskimiş, kötü yazılmış, okunması zor vb. olabilir. Her zaman mükemmellik (mevcut olmamasına rağmen) ve güncel kod için çabalamalısınız, gereksiz olan her şeyi kaldırmalısınız, çünkü gereksiz olan sadece kafa karışıklığına yol açar ve kodun ne yaptığını görme yeteneğini engeller. Bu görevleri bir projenin başlangıcında görmenizin pek olası olmadığını söylemeye gerek yok: geliştirmenin sonraki aşamalarında, uygulama cilalanırken ve mükemmelleştirilirken bunlarla karşılaşırsınız. Burada iş arkadaşlarına ne yapacaklarını ve ne gibi tuzaklar gördüklerini danışmak uygun olabilir. Özünde, bu tür görevler yeni işlevsellik geliştirmeye benzer. Örneğin, davranışını değiştirmeden bazı işlevleri düzenlemek için bir görev aldığınızı varsayalım. Bunu yapmak için eski kodu silin, kendinizinkini yazın ve testleri kontrol edin. Her şeyi doğru yaptıysanız, testlerde herhangi bir değişiklik yapmadan hepsi eskisi gibi geçmelidir. Koddaki her şey olması gerektiği gibi olduktan sonra incelemeye gönderiyoruz ve kahvemizi yudumluyoruz :)

8. Belge yazmak

Uzun vadeli bir yazılım geliştirme projesinde yeni bir geliştirici olduğunuzu hayal edin. Kendinizi kod tabanına alıştırmanız veya belirli bir görevi gerçekleştirmeniz, örneğin bir hatayı teşhis etmeniz gerekir. Projede nasıl gezineceksiniz? Takım arkadaşlarınızı her beş dakikada bir rahatsız mı ediyorsunuz? Peki ya meşgullerse ya da hafta sonuysa, o zaman ne olacak? İşte tam da bu nedenle belgelere sahibiz - böylece koda aşina olmayan bir kişi gelebilir, ilgili sayfayı bulabilir ve uygulamanın onu ilgilendiren bölümünde neler olup bittiğini hızlı bir şekilde anlayabilir. Ama birisinin belgeleri oluşturması gerekiyor, haha. Bir proje, geliştiricilerin desteklemesi gereken belgelere sahipse, yeni işlevsellik uyguladıklarında, bunu açıklar ve herhangi bir kod değişikliği veya yeniden düzenleme ile birlikte belgeleri günceller. Belgeleri yazmak, sürdürmek ve denetlemek için ayrı bir çalışanın (teknik bir yazar) işe alındığı durumlar da olabilir. Böyle bir uzman varsa, sıradan geliştiricilerin hayatı biraz daha kolaylaşır.

9. Çeşitli toplantılar

Geliştiricilerin zamanının çoğu çeşitli toplantılar, müzakereler ve planlamalar için harcanır. En basit örnek, dün yaptıklarınızı ve bugün yapacaklarınızı raporlamanız gereken günlük stand-up toplantılarıdır. Ek olarak, bir hatayı yeniden oluşturmanın nüanslarını gösterebilmeleri/açıklayabilmeleri veya bir iş analistiyle incelikleri ve gereksinimleri tartışabilmeleri veya organizasyonel sorunlar hakkında konuşabilmeleri için örneğin test uzmanlarıyla bire bir telefon görüşmeleri yapmanız gerekecektir. PM ile. Bu, bir geliştiricinin yalnızlığı tercih eden içe dönük biri olmasına rağmen, diğer insanlarla (en azından biraz) ortak bir zemin bulması gerektiği anlamına gelir. Bir geliştiricinin rütbesi ne kadar yüksekse, iletişim için o kadar fazla, kod yazmaya ise o kadar az zaman ayırması gerekir. Bir geliştirici lideri, iş gününün yarısını veya daha fazlasını tek başına konuşmalar ve toplantılar için harcayabilir ve daha seyrek kod yazabilir (muhtemelen kodlama becerisini biraz kaybetmesine neden olur). Ancak konuşmayı seviyorsanız, bir ekip lideri olarak yönetime geçebilir ve kod yazmayı tamamen unutabilirsiniz, bunun yerine tüm gününüzü çeşitli ekipler, müşteriler ve diğer yöneticilerle iletişim kurarak geçirebilirsiniz.

10. Görüşmeleri yürütmek/geçmek

Bir dış kaynak veya taşeron şirket için çalışıyorsanız, genellikle kendinizi müşteriye "satmanız" gereken (müşteri için çalışan biri sizinle görüşme yapabilir) ve ayrıca dahili görüşmelerden geçmeniz gerekir. şirket içinde rütbeleri tırmanmak isteyenler. Bunu gelişmek için iyi bir fırsat olarak adlandırırım çünkü sık sık yapılan görüşmeler sizi bilginizi keskin tutmaya zorlar: paslanıp yumuşamazsınız. Sonuçta, BT'de yumuşarsanız, alanın tamamen dışına çıkabilirsiniz. Daha deneyimli bir geliştirici olduğunuzda, kendinizi masanın diğer tarafında bulabilir, onları geçmek yerine röportajlar yürütebilirsiniz. İnanın bu açıdan baktığınızda çok şaşıracaksınız çünkü mülakat sorularını sormak, onlara cevap vermekten daha ürkütücü olabilir. Kendi görüşme stratejinize, bir soru listenize ve bir saat içinde gerekli tüm konularda soru sormak için zamana ihtiyacınız var. Ve bundan sonra, işe alma kararını ve adayın uzun zamandır beklenen bir teklif veya terfi alıp almayacağını etkileyecek geri bildirim sağlamaktan siz sorumlusunuz. Ya da açıkça zayıf bir adayın hak etmediği bir pozisyona girmesine izin verebilirsiniz ve sonra size "bu düzeyde bilgiyle onun işe alınmasına nasıl izin verirsiniz" diye sorulabilir. Bu nedenle, bir röportaj sırasında sıcak koltukta oturduğunuzda, karşınızdaki kişinin de bir zorlukla karşı karşıya olduğunu ve stresli olabileceğini unutmayın. işe alma kararını ve adayın uzun zamandır beklenen bir teklif veya terfi alıp almayacağını etkileyecek geri bildirim sağlamaktan sorumlusunuz. Ya da açıkça zayıf bir adayın hak etmediği bir pozisyona girmesine izin verebilirsiniz ve sonra size "bu düzeyde bilgiyle onun işe alınmasına nasıl izin verirsiniz" diye sorulabilir. Bu nedenle, bir röportaj sırasında sıcak koltukta oturduğunuzda, karşınızdaki kişinin de bir zorlukla karşı karşıya olduğunu ve stresli olabileceğini unutmayın. işe alma kararını ve adayın uzun zamandır beklenen bir teklif veya terfi alıp almayacağını etkileyecek geri bildirim sağlamaktan sorumlusunuz. Ya da açıkça zayıf bir adayın hak etmediği bir pozisyona girmesine izin verebilirsiniz ve sonra size "bu düzeyde bilgiyle onun işe alınmasına nasıl izin verirsiniz" diye sorulabilir. Bu nedenle, bir röportaj sırasında sıcak koltukta oturduğunuzda, karşınızdaki kişinin de bir zorlukla karşı karşıya olduğunu ve stresli olabileceğini unutmayın. Herhangi bir görüşme hem aday hem de görüşmeci için streslidir. Muhtemelen burada bitireceğiz. Bu yazıyı okuyan herkese teşekkürler. Bir beğeni bırakın ve Java öğrenmeye devam edin :)