Etiket arşivi: anti-patterns

Hal 100:Kucağına düşen 3ncü parti ürün üzerinde bug/fix yapıp sevinir ve ardından yeni taleplerle karşılaşır.

Özellikle sahada kullanılan ürünleri olan firmaların olmassa olmaz ihtiyaçlarından birisi teknik destektir. Var olan ürünlere yapılacak yeni eklemeler veya güncellemeler haricinde, müşterilerden gelen geri bildirimler doğrultusunda acil olarak halledilmesi gereken vakalar da vardır. Bunlar her ne kadar bazı profesyonel firmalar tarafından seviyelendirilip uygun birimlere yönlendiriliyor olsa da hayat bu kadar toz pembe değildir. Doğruyu söylemek gerekirse olası pek çok vaka vardır. Bu vakalardan belki de en kötüsü bir servis sağlayıcıdan alınmış olan ürünler ile ilgilidir. 

  • Ürüne olan teknik destek, sahibi olan firma tarafından kesilmiş olabilir,
  • Ürünün sahibi teknik destek için yüksek miktarda fatura kesiyor olabilir(Vendor Lock-In anti pattern’ inin oluşma nedenidir),
  • Ürün sahibi firma kapanmış olabilir,
  • Ürün eskidir ve aslında üzerinde çalışmış geliştiriciler sahibi olan firmada artık yoktur
  • Ürünün teknik dokümantasyonu olmayabilir vb

Eğer söz konusu ürün, onu kullanan firma tarafından kolay kolay terk edilemiyorsa durum vahimdir. Ürün yeteri kadar ayrık yapıda tutulmamışsa sistemden kopartmak ve yerine başka bir alternatifi koymak her zaman güçtür. Durum böyle olunca birisinin o ürün üzerinde değişiklik yapması şarttır.

Üçüncü parti bir ürünün üzerinden değişiklik yapmak risklidir. Ancak bazı sebeplerden ötürü servis sağlayıcından habersiz olarak değişiklik yapılması çok daha risklidir.

Çünkü servis sağlayıcının yeni bir sürüm çıkartması halinde, yapılmış olan güncellemelerin bu versiyona da aktarılması gerekir. Bu, Dead End adı verilen anti-pattern’ in yolunu açar.

Eğer yukarıda sayılan sebeplerden ötürü 3ncü parti ürün üzerinde değişiklik yapılması kaçınılmazsa elden bir şey gelmez ve bir geliştiricinin bu konuya eğilmesi gerekir. Ürünün çeşidine, isteğin aciliyetine göre başına verilecek adamın kaliteli bir kumaşa sahip olması gerekebilir. Çünkü 3ncü parti ürün tam bir kod çöplüğüne benzeyebilir.

Ürünün hızla analiz edilmesi, çabucak keşfedilmesi, büyük resmin hemen fark edilmesi, içeride kullanılmış mimari kalıp veya prensiplerin anlaşılması, müdahale edilmesi gereken en uygun yerin bulunması gerekir. Bir anlamda geliştiricinin tersine mühendisliğin farkında olması ve kullanması icap edebilir.

SOA gibi üst düzey mimariler içeren, farklı platformlarda koşan ürünlerin bir arada konuştuğu sistemlerde, çıktıları kiritik olan 3ncü parti ürünler kullanılmakta olabilir.

Bu ürünlerin sistemden kolayca kopartılamadığı, üstüne bir de teknik destek alınamadığı ve bazı kanuni kurallar yüzünde acil değişikliklerin yapılması gerektiği durumlar karşısında yetkin geliştiricilerin bir mucize yapması beklenir.

Bu mucizeleri yapan geliştiriciler gerçekten de vardır.

Anahtar Kelimeler (Bunlara Bir Bakalım)

  • Dead End Anti Pattern
  • Lavaflow Anti Pattern
  • Vendor Lock-In Anti Pattern
  • Tersine Mühendislik (Reverse Engineering)

Hal 98:Mimari tanımlanmadan önce, teknoloji seçimi yapılması gerektiğine inanır.

Bir yazılım projesi geliştirilmeye karar verildiğinde ekibin sahip olduğu yetenek ve kabiliyetler önem arz eden konuların başında gelir. Ekibin daha önceki başarıları, hataları ve ürettikleri bir sonrakisi için katma değer niteliği taşıyan unsurlardır.

Ne varki pek çok ekip sahip olunan bilgi ve deneyimi o kadar çok benimser ki diğer bütün problemleri de aynı yollarla çözümlemeye çalışır. Bir nevi Golden Hammer ve biraz da Cargo Cult Programming Anti-Pattern’ lerinin sıklıkla yaşandığı haldir.

Oysaki bir ürünün çözüm gerektiren mimarisi tasarlanmaya başlanmadan önce sorgusuz kabul gören teknikler, pratikler, disiplinler ve teknolojik araçlar ürünün gelişimine olmusuz etkide bulunabilir. Süreler uzayabilir, ortaya OverEngineering anti-pattern’ i çıkabilir ve aslında aile için tasarlanmış sedan otomobilin içine 340 km hızla gidebilmesini sağlayacak motor konulmuş olabilir.

Birden fazla ekibe sahip olan firmalarda ekipler arası teknoloji transferi ve bilgi aktarımı yeni nesil ürünlerin geliştirilmesinde seçilecek enstrümanları belirleme açısından önemli bir konudur.

Dolayısıyla mimari tasarımların oluşturulmasında şekillenmeye başlayan teknolojileri göz önüne almak çok daha doğru bir yaklaşımdır. Pek tabi seçim yaparken sıkıntıya düşülebilecek bir husus vardır ki o da bu teknolojik bilgiyi kimin bu kadar iyi bileceğidir. Ekip içi görevlendirmeler ile gelişmelerden haberdar olunması, uygun görev ve sorumluluk atamaları ile sürekli güncel kalınması sağlanabilir.

Teknoloji, pratik, prensip gibi enstrümanların seçiminde çözüm/yazılım mimarlarına büyük sorumluluk düşer.

Mimari tasarımdan önce kullanılacak teknolojinin seçilmesi ürün gelişimi açısından sorun teşkil edebilirken bazı hallerde de kullanılabilecek teknoloji sadece bir tanedir. Böyle haller istisnai olarak kabul edilebilir tabi.

Anahtar Kelimeler (Bunlara Bir Bakalım)

  • Golden Hammer,
  • Cargo Cult Programming,
  • OverEngineering

Hal 95:O anda geçici çözüm olarak kullandığı try…catch bloğunu kodun orasında ebediyen unutabilir.

Yazılım geliştiriciler de aslında birer insandır. Bu yüzden çok doğal olarak gün içerisinde sıkıldıkları, bunaldıkları anlar olur. Bu tip anlarda iş verimliliği düşer ve hatalı kodların oluşması söz konusu olur. Tedbir almak kolaydır.

  • Ekip olarak çalışılması halinde iç iletişimi ön plana çıkartarak ilerlemek,
  • Kodları çift kişi olarak geliştirmek(Biri bakar diğer yazar sonra roller değişir),
  • Kod gözden geçirmelerde bulunmak,
  • Test odaklı geliştirme gibi yaklaşımları kullanmak
  • Çeşitli kod kalite araçlarından faydalanmak

vb….

Ancak bazı hallerde geliştiriciler Lone Wolf Developer modunda takılırlar. Bu gibi bir halde kişinin kendi disiplinindeki kaçakların doğuracağı olumsuz sonuçlar vardır. İçi boş bir try…catch bloğu bunlardan birisidir. Bir anlık dikkatsizliğin veya o andaki vakadan bir an önce kurtulmanın ya da çabucak kodun kalan kısımlarını işletebilme isteğinin bir sonucu olabilir.

O anda yetiştirilmesi gereken iş için çalışma zamanı hatasının gerçektende bir önemi olmayabilir. Aslında oluşan istisnai durum daha sonradan değerlendirilecek ve gerekli tedbirler alınacak şekilde ilerlenebiliyorsa boş bir catch bloğu gerçekten işe yarar. Ne var ki çalışma zamanı hatalarının Exception mekanizması içerisinde yer almasının bazı dezavantajları da vardır. Herşeyden önce çalışma zamanına ek yük getirir. Belki de oluşan hatalar Exception Handling’ e başvurulmadan önlenebilir.

Bir dosyanın yerinde olup olmadığını kontrol ederken, “catch bloğuna düşüyor ve hatta FileNotFoundException alıyorsak dosyanın yerinde olmadığından emin olabiliriz” düşüncesiyle hareket etmek doğru bir yaklaşım değildir.

Aslında önlenebilecek bir takım hataların try…catch bloklarına başvurulmadan çözülmesi mümkün olabilir.  Kötü olansa geçici olarak uygulanan try…catch bloğunun kodun o kısmında ebediyen unutulabilmesidir. Bunun bilinen sonuçlarından birisi Boat Anchor isimli anti-pattern’ dir. Diğer yandan Error Hiding isimli anti-pattern için de bir gerekçe olarak düşünülebilir. Hatta AR-GE amaçlı başlayıp ürün haline gelmiş pek çok projede Lavaflow Anti-Pattern’ i oluşurken bu şekilde kullanılıp unutulan kod parçaları veya geçici çözümlere rastlamak son derece olasıdır.

Anahtar Kelimeler (Bunlara Bir Bakalım)

  • Anti-Patterns
  • Boat Anchor
  • Error Hiding
  • Lavaflow
  • Exception Handling
  • Test Güdümlü Programlama (Test Driven Development)
  • Pair Programming
  • eXtreme Programming
  • Code Review

Hal 89:Bir fikir bulduğunda,Open Source dünyasında benzerleri var mıdır/yazılmış mıdır diye pek araştırmaz.

Bu aslında yazılım dünyasında ekip ve birey bazında Reinventing the Square Wheel isimli Anti-Pattern’e de yol açabilecek ihtimallerden birisidir. Bazen geliştirici çözüm arayışı içerisine girdiğinde, problemin daha önce karşılaşılmamış kadar özgün olduğunu düşünebilir. Bunun sonucu olarak tekerliği yeniden keşfetmeye çalışabilir. Ne var ki yazılım dünyasında var olan problemlerin çoğu bir şekilde çözülmüş olup asıl maharet içlerinden uygun olanını seçebilme becerisidir.

Bir AR-GE projesi olmadığı sürece tekerliği yeniden keşfetmeye çalışmanın çok fazla artısı olmayabilir elbette ama herşeyi körü körüne kabullenip nasıl çalıştığını bilmeden uyarlamak da doğru değildir ve Cargo Cult Programming adı verilen Anti-Pattern’ in oluşmasına sebebiyet verebilir.

Problemin büyüklüğüne göre uygulanması gereken çözüm farklılık gösterebilir ama mutlaka birilerinin denemiş olabileceğini düşünmek gerekir. Hatta problemin çözümü ile ilişkili vaka çalışmaları varsa okumak ve olasılıkları yakalamak mühimdir.

Günümüz yazılım dünyası pek çok ihtiyacın karşılanmasında kullanılabilecek sayısız açık kaynak çözüm içerir. Zor olan seçim yapabilmektir.

Açık kaynak çözümler sadece kullanılma aşamasında değil, geliştiricinin kendisini ileriye götürme noktasında da önem arz eder. Uygun olan çözümün tespit edilmesi ardından onu incelemek, hangi disiplinlerin uygulandığını anlamaya çalışmak hem öğretici hem de yaşanmış deneyimleri ileride kullanabilme anlamında faydalıdır. Tabi burada önem arz eden bir başka husus vardır. “Nasıl Karar Vereceğiz?”

Anahtar Kelimeler (Bunlara Bir Bakalım)

  • Anti-Patterns
  • Cargo Cult Programming
  • Reinvent the Square Wheel
  • Codeplex
  • Sourceforge
  • GitHub
  • Case Studies

Hal 83:Guru’ larca hoş görülmeyen buton arkası çözümlerin bazen milyarlar kurtarabileceğini hiç düşünmez.

  • En iyi yazılımı geliştirmek? Nasıl olmalı?
  • Mimari ne kadar önemli?
  • Çözüm için en uygun teknolojiler hangisi?
  • Tasarım kalıplarından hangileri tercih edilmeli?
  • SOA olmassa olmaz mı?
  • En iyisi her zaman en pahalı olanı mı?
  • RDBMS’si yürüyemez miyiz?
  • Fark yaratması nasıl sağlanabilir ki?

Bu gibi sorular hemen her ekibin başına gelen veya yazılım işine yeni yeni girenlerin karşılaştıkları arasında yer alır. Hep en iyisini en güzelini yapmak ister yazılımcı.

Adamın biri zamanında Sedan tipinden bir aile arabasına onun saatte 340 km ile gidebilmesini sağlayacak bir motor yerleştirmiş.

İşin kötü tarafı aracı kullanacak ailelerin saatte 90 km’yi geçmeleri pek de olsaı değilmiş. Gereksiz yere üstün teknoloji ürünleri kullanılmış, üretim maliyetleri ve süreleri artmış. Sonunda bu maliyetleri düşürecek yollar aranmaya başlanmış ve yeni mühendislik çözümleri getirilmiş.

Sonuçta iş OverEngineering isimli bir Anti-Pattern olmuş.

Bazı hallerde, özellikle acil durumlarda ileriyi düşünmeden hareket edip şirketin önemli bir sorununu ortadan kaldırmak adına bodoslama çözümler uygulamak gerekebilir. Bu her ne kadar buton arkası bir durum olarak yorumlansa ve hatta bazen ürünü Magic PushButton’a(arayüz tabanlı iş mantıkları söz konusu olduğunda) götürse de zaman zaman hayat kurtarabilir.

Buton arkası tabir edilecek ve şık sayılmayacak bir kaç hareketle bir bankanın yıl sonunda hayatını kurtardığınızı ve kredi kartı satabilir hale getirdiğinizi düşünün. Bu anda uygulanan çözümün hiç bir pratikle bağdaşmadığını savunabilir misiniz? Gerçek hayat vakaları bazen çok şaşırtıcı olabilir.

Anahtar Kelimeler (Bunlara Bir Bakalım)

  • Anti-Patterns
  • OverEngineering
  • Magic PushButton

Hal 81:Katıldığı projelerde elbette başarısızlıkla sonuçlananlar olabileceği ihtimalini kabullenmek istemez

Yazılım geliştiriciler bazen kendi aralarında toplanır ve birbirlerine başarıyla tamamladıkları projeleri anlatır. Hata onlara göre sadece ve sadece başarı ile tamamlanmış projeler konuşulmalıdır. Bu son derece doğal bir psikolojidir. Nitekim başarısızlıkla sonuçlanan projelerin maliyetleri herkes için fazladır.  Bu yüzden başarısızlık hem korkulan hem de gizlenmesi gereken bir olgu gibi görünür. Bir projeyi başarısız olarak saymanın pek çok kriteri vardır,

  • Zamanında bitmemiş olması,
  • Zamanında bitmesi için bir noktadan sonra ek kaynak kullanılmış olması,
  • Zamanında bitmiş olsa da ilk başta planlanandan çok daha farklı bir ürünün ortaya çıkmış olması,
  • Bir takım anti-pattern’ leri içermesi nedeniyle ürünleşme sonrasındaki zaman diliminde başkalarının başına dert açacak olması,

vb

Elbette bir projede başarısız olunmasını kimse istemez. Ürün sahibi başta olmak üzere herkes iş bitiminde bir parti ile kutlama yapmak ister.

Tecrübe arttıkça hata yapma olasılığı azalır. Aslında az hata yapmaya başlamak tecrübenin arttığının bir göstergesidir.

Yazılımcıların hata yapmaktan korkmaması ancak bunu alışkanlık haline de getirmemesi gerekir. Hata yapmayı azaltmak için bir kaç konuya dikkat edilmesi yeterlidir.

  • Sürekli pratik yapmak,
  • Öğrenilenleri unutmamak adına tekrarlarda bulunmak,
  • Anlık olarak ihtiyaç duyulan bilgilere doğru yollardan ve en hızlı şekilde ulaşabilmeyi sağlayacak yolları keşfetmek,
  • Bol bol farklı çözümleri okumak ve bunları irdelemek,
  • Sık sık daha tecrübeli insanlarla bir araya gelip onları sadece dinlemek,
  • Sorgulayıcı yaklaşmak ama bunu fazla abartmamak,
  • Öğrenilenleri tartışabileceği kişilere anlatmak ve onlardan fikir almak

vb

Elbette hata yapmanın da sınırları olmalıdır. Öğrencilik yıllarında yapılan yazılımsal hatalar, fark edildiği sürece kıymetlidir. Hatta öğrencilik yıllarında mümkün olduğunca fazla hata yapılması bir yazılımın olası hatalarını öngörme ve baştan tedbir alma yeteneklerini de arttırıcı bir etkendir.

Bazen büyük başarısızlıkların başka fırsatların kapısını açabileceği gerçeği de unutulmamalıdır.

Anahtar Kelimeler(Bunlara Bir Bakalım)

  • Başarılı Proje Kriterleri
  • Anti-Patterns,
  • Best Practices,
  • Case Studies,
  • Whitepapters

Hal 45: Bir dilin veya ürünün fanatiği olunur ve diğerlerine ömür boyu tu kaka denilir.

Fanatiklik her zaman için olumsuz etkilere neden olabilecek bir davranış biçimidir. Pek çok insan gibi yazılımcıların da sorgulamadan savundukları konular vardır. Ancak bir yazılımcının ürün odaklı fanatikliği diğer fanatikliklere pek benzemez. Çünkü bir programlama diline veya yazılım ürününe aşırı derecede bağlanmak, onu her platformada savunmaya çalışmak getiriden çok götürüye sebebiyet verebilir.

Ürün fanatizmi yazılımcıları Anti-Pattern oluşumuna götüren sebeplerin en önemlisidir.

Aslında bir ürüne bu kadar çok bağlı olmak bir takım Anti-Pattern’ lerin de oluşmasına neden olur. Cargo Cult Programming, Vendor Lock-In, Golder Hammer, Over Engineering, Design by Commitment gibi karşıt desenlerin oluşmasında önemli bir faktör olarak düşünülebilir. Bu da aslında kritik bir kaç sonucun doğmasına neden olur.

  • Ürünün zamanında yetişmemesi,
  • İstenen ürünün ortaya çıkmaması,
  • Beklenenden fazla zaman harcanması,
  • Proje maliyetinin artması,
  • Kişisel güvenin kaybolması vb

Zaten yazılımsal bir ürünün geliştirilmesi noktasında sahip olunan bilgiler ile harekete geçmek çoğu zaman yeterli olmaz. Geliştirilmesi istenen/düşünülen ürünün hangi teknolojiler ile ele alınması gerektiğine karar vermek yolun başında yapılması gerekenler arasında yer almaktadır.

Kimi programlama dili çok az kullanılsa da o ürün veya ihtiyaç için biçilmiş kaftan olabilir. Kimi platform her yerde kullanılıyor olsa da istenen ihtiyaç için fazla gelebilir. Bu nedenle fanatik olmak yerine farklı ürünleri de göz önüne almak, özellikle bir ürünün hangi pratiklerde uygun olabileceğinin farkında olmak önemlidir.

Anahtar Kelimeler(Bunlara Bir Bakalım)

  • Anti-Patterns
  • Cargo-Cult Programming
  • Golden Hammer
  • Vendor Lock-In
  • Design by Commitment
  • OverEngineering

Hal 35:Bazen bulunan çözümlerin zamanla Anti Pattern haline geleceğini düşünmeden hareket etmesi.

Özellikle nesne yönelimli dünya da gezinen pek çok yazılımcı, tasarım kalıpları konusuna oldukça titiz yaklaşır.  Tasarım kalıpları standartlaşmış problemlerin standartlaşmış çözümlerinde oldukça etkilidir. Her ne kadar öğrenilmeleri ve hangi senaryoda kullanılmaları gerektiğine karar verilmeleri zor olsa da , geliştiricilerin baş tacıdır.

Acil giderilmesi gereken bug-fix’ ler ve kısa verilen proje süreleri geliştiriciyi Anti-Patterns noktasına iten önemli etkenlerdir.

Ne var ki gerçek hayat senaryolarında çoğu zaman ihmal edilebilirler. Bunun bir çok sebebi vardır. Kısa proje süreleri, bir anda kendimizi içinde bulduğumuz geçmişi olan ürünlerdeki bug-fix işleri vb… Bu gibi hallerde geliştiricilerin çoğu en kısa yoldan sorunu çözmeye çalışmak zorunda kalır ve bu durum haliyle bir süre sonra çeşitli sancılara yol açar.

  • Geliştirici spagetti kod üretiminde ustalaşır. (Spaghetti Code)
  • copy-paste programcılığı alanında ihtisas sahibi olur. (Cut and Paste Programming)
  • Yeri gelir tekerleği yeniden keşfeder. (Reinvent the Wheel)
  • Kocaman bir sınıf ile bütün sorunların üstesinde gelmeye başlar. (God Class)
  • Teknik desteği bir anda kesilen veya çok eskilerde kalan açık kaynak ürünlere bağımlı hale gelir. (Dead End)
  • İlle de bu mimari olacak bundan başkası olmaz diye diretir (Golden Hammer)
  • vb

Bu sebepten her yazılımcının aslında Anti-Patterns konusuna bakması, en azından belli başlı maddelerini incelemesi ve özümsemeye çalışması şarttır.

Anahtar Kelimeler(Bunlara Bir Bakalım)

  • Anti Patterns
  • Design Patterns
  • Nesne Yönelimli Programlama (Object Oriented Programming)

Hal 27:Kodlarını, yıllar sonra başka bir geliştiricinin yeniden kurcalayabileceğini düşünmeyerek yazması.

Yazılımcı ne kadar çok sıkışırsa, işin yetiştirilmesi için üzerinde kurulan baskı ne kadar artarsa, ortaya çıkacak işin kalitesinin azalması her zaman için bir ihtimaldir. Bu tip bir durumda yazılımcının panik olmadan, baskıyı kaldırarak, emin adımlar ile ilerleyememesi halinde uygulama kodlarının enkaz haline dönmesi de kaçınılmazdır.

27

@coderizbiz

Bir yazılım ürününün kod anlamında enkaz haline gelmesi epeyce çaba isteyen bir iştir. Ancak şartlar bunun oluşması için bazen çok uygundur!

Acele acele yazılan kodlar, ilerisi düşünülmeden entegre edilen geçici çözümler(bilhassa yıllar içinde teknik desteği azalan veya kaybolan açık kaynak kütüphaneler), var olan ürünler üzerindeki pansumlanlarda çalışan deneyimsiz yazılımcılar gibi nedenler, zamanla kodun kirlenmesine ve enkazın devleşmesine sebebiyet verecektir.

Enkaz ürünler özellikle kod ve kalite standartlarını denetleyen araçların hışmından kurtulamaz.

Unutulan bir şey varsa o da bu hale gelmiş ürün kodlarına yarın öbür gün başka bir geliştiricinin bakacak olmasıdır. Öyle ürünler vardır ki onlarca yıl belirli sektörlerce kullanılır, sürekli eklemeler ile genişler, genişler, genişler… Hatta şirketin farklı iş ihtiyaçlarını yürüten kanallara ve buradaki uygulamalara kadar etki eder. Genişleyen bu tip ürünlerin yıllara varan oluşumu sırasında kullanılan teknoloji eskiyebileceği gibi, o teknolojiyi bilen ve pansuman yapabilen yazılımcı sayısı da azalır. Bu nedenle yazılımcının daha az “Ah!” alması ileriyi düşünerek yapacağı hamlelere de bağlıdır.

Anahtar Kelimeler(Bunları Bir Araştıralım)

  • Hatasız Kodlama
  • Okunabilir Kod
  • Kod Kalite Standardları
  • Anti-Patterns
  • Desteği Bitmiş/Azalan Açık Kaynak Ürünler

Hal 8: Bir problem çözümünde akla gelen ilk çözümün en iyi çözüm olduğu yanılgısıdır.

Ne yazık ki ve malesef istek sahiplerinin vakti ilginç bir şekilde dardır. Mümkünse istekler veya sorunlar hemen halledilmelidir. Sonuçta parayı veren düdüğü çalar modeli daha geçerli olduğundan, geliştiricilerin genellikle en acilinden çözüm bulması gerekebilir. Bu, en düzgün proje yönetiminde bile söz konusudur. Geliştiriciden istenen tahmini süreler gerçekçi bile olsa, yönetim tarafından azaltılmaya çalışılabilir. Geliştiricinin Einstein gibi uzun süre düşünüp kısa bir süreyi çözüme ayırmak gibi lüksü yoktur.

Eğer dünyayı kurtarmak için bana 1 saat verilseydi, bunun 55 dakikasını problemi tanımlamak, 5 dakikasını da çözümü bulmak için kullanırdım.

Albert Einstein

Bu yaklaşım bir, iki, üç derken bir bakmışsınız ki yıllardır acele acele kod geliştiriyor, çözüm üretiyorsunuz. Herkes memnun belki. İstekler en hızlısından çabucak çözülüyor, yeni talepler en kısa sürede karşılanıyor vs…

8

@coderizbiz

Ama gözden kaçırılan bazı hususlar var. Bir bakmışsınız bulunan o ivedi çözümler birer anti-pattern haline gelmiş. Bir bakmışsınız ürün bir süre sonra müdahale edilemez veya edilmesi riskli kategoriye girmiş. Bir bakmışsınız 3 sene önce uygulanan çözüm zincirleme bir reaksiyon başlatmış ve artık bir bug-fix için harcanan süre ve uygulamada dokunulan yer çok daha fazla. En sonunda isyan eden yazılımcının kaçmasıyla süreç yaşam döngüsü de tamamlamış. Yeni gelenin vay haline!

Bu halin oluşmasını engellemek pek kolay değildir aslında. Hatanın belli bir kaç nedeni vardır;

  • Çözümler üzerinden yeterince düşünülmemesi,
  • Çevresel etkilerinin araştırılmaması,
  • Yöneticinin veya müşterinin geliştiriciyi dinlemeyişi, dinlese bile önemsemeyişi,
  • Ürünün geliştirilmesi sırasında elin adamının bin bir dert sonrasında edindiği tecrübelerden ortaya çıkarttığı metodolojilere hiç uyulmaması,

ve benzerleri. Dolayısıyla problem çözümüne daha metodolojik yaklaşılmasında yarar vardır. En azından problemi iyi tanımlayarak işe başlanabilir.

Anahtar Kelimeler(Bunları Bir Araştıralım)

  • Einstein bir problemi nasıl çözer?
  • Uygulama Geliştirme Yaşam Döngüsü – Application Life Cycle Management
  • Anti-Patterns
  • Yazılımsal problemleri çözme tenikleri