Bence çok iyi bir yazı. Özellikle böyle 'rakamlar' içeren materyaller çok değerli. Yazdığımız kodun, kullandığımız teknoloji yığınının ne tür ek yükler getirdiğine dair 'kabaca da olsa bir sezgisi olan' geliştiricileri görmenin kolay olmadığı bir dönemdeyiz; keyifle okudum.
Benzetme yerinde görünüyor. Benim projem de fiilen yalnızca iki şeyden oluşuyor: insanın intent’i ve Snapshot.
Sonuçta, insanın niyetini (ör. klavye girişi, fare tıklaması) nasıl hesaplayıp ona nasıl bir anlam kazandıracağımızın, projemin ilerlemesi gereken yön olduğunu düşünüyordum.
Fikir çekici ama deneyimlerime göre böyle idealist denemelerin pek başarılı olduğu olmadı..
Şimdilik Feedly, yapay zeka özellikleriyle de en iyi ve en sorunsuz seçenek gibi görünüyor.
Kent Beck’in Extreme Programming’i, Jeff Sutherland’ın Scrum’u vb. çoğu çevik yöntem kitabında temelde yer alan içerik budur. User story’lere de bakabilirsiniz. Çoğu insan, çevikliğin temelinin müşteri gereksinimlerine hızlı uyum sağlamak için kısa sprintler ve demolar olduğunu pek bilmiyor.
Evet, belirttiğiniz görüşe katılıyorum.
Kodla ikame edilemeyecek kısımlar olduğu kesin.
Bu anlamda biraz farklı açıklamak gerekirse, anlatmak istediğim şey okunabilirliği yüksek kodun belge üretme ihtiyacını azaltacak şekilde yazılmasıydı.
Yazılım uzun soluklu hale geldikçe biriken belgeler de geliştiriciye bilişsel yük getiriyor. Asıl mesele, kod ile belge arasında gidip gelme işini azaltmak.
Tamamen yalnızca kod bırakmanın mümkün olduğunu düşünmüyorum.
Bunun bağlama ve içinde bulunulan duruma göre değişebileceğini düşünüyorum.
Yorumunuz için teşekkür ederim.
Karşı argümanı temkinli biçimde iletmek gerekirse, bence kod dokümantasyonun yerini tutamaz. Programlama dilleri hâlâ doğal dilin zengin ifade gücüne ve aktarım kabiliyetine sahip değil; pratikte de o kadar kodun tamamını ne zaman okuyacağız ki?
Dokümantasyonun yerini alabilecek bir koda sahip olmak bir umut ve temenni, ama çıkılamayacak bir Babil Kulesi gibi.
Açıkçası OOAD üzerine ciddi şekilde çalışmak bana daha iyi görünüyor.
specin kendisini çevik şekilde yazmak tam olarak ne demek?
speci kabaca yazarız.
speci müşterinin söylediği gibi yazarız.
Müşteri gereksinimleri değişirse, speci hızlıca değiştirebilmek için araçların gücünden yararlanıp bakımını yaparız.
speci çevik şekilde yazarız.
Asıl meselenin, o yazının da özünde söylediği gibi, çevikliğin ne olduğunun bilinmemesi olduğunu düşünüyorum. Çevik için böyle özellikleri var, şöyle böyle yapılmalı diye çok konuşuldu ama bunun gerçekten çevik metodolojiyle geliştirilmiş bir üründür diye örnek gösteren bir yazı şimdiye kadar görmedim. Manifestoya bakınca da pek net gelmemişti. Bir kez gösterebilir misiniz?
Neden metodolojilere kutsal metin muamelesi yapıldığını anlamıyorum. Bence asıl yazar da sadece yönü farklıydı; dogmatiklik açısından aynı derecede sorunluydu.
SQLite’ı prodüksiyon sunucusu için seçtiğiniz andan itibaren, ne zaman başka bir şeye geçmeniz gerektiğini sürekli düşünmek zorunda kalırsınız.
Eskiden veritabanının kendisinin maliyeti (sunucu satın alma, IDC, lisans maliyetleri vb.) yüksek olduğu için bunu düşünmeye değerdi,
ancak bugünlerde sözde tek tıkla kurulum yapılabiliyorken gerçekten bunu dert etmeye gerek var mı?
Dikey karar alma yapısını yıkmak ve kısa döngülerle tekrarlı iyileştirme bile, bize büyük bir mesaj bırakıyor (elbette proje yönetimi teknikleri/araçları da aynı şekilde).
'Agile'ın kendisinin yeni bir içgörü sunamadığı ve Agile'ı savunan herkesin körü körüne Agile fanatiği olarak çarpıtıldığı' sonucunun fazla sert olduğunu düşünüyorum
Bence çok iyi bir yazı. Özellikle böyle 'rakamlar' içeren materyaller çok değerli. Yazdığımız kodun, kullandığımız teknoloji yığınının ne tür ek yükler getirdiğine dair 'kabaca da olsa bir sezgisi olan' geliştiricileri görmenin kolay olmadığı bir dönemdeyiz; keyifle okudum.
Benzetme yerinde görünüyor. Benim projem de fiilen yalnızca iki şeyden oluşuyor: insanın intent’i ve Snapshot.
Sonuçta, insanın niyetini (ör. klavye girişi, fare tıklaması) nasıl hesaplayıp ona nasıl bir anlam kazandıracağımızın, projemin ilerlemesi gereken yön olduğunu düşünüyordum.
Yayınlandığını görüp yazı yazmaya gelecektim ama siz zaten çoktan yazmışsınız.
Performansının ne kadar iyi olacağını merak ediyorum.
Mevcut kod kaldığı için bunun nasıl bir uygulama olduğunu doğrudan kendiniz kontrol edebilirsiniz.
https://gitlab.com/sebuls/libhwp
Fikir çekici ama deneyimlerime göre böyle idealist denemelerin pek başarılı olduğu olmadı..
Şimdilik Feedly, yapay zeka özellikleriyle de en iyi ve en sorunsuz seçenek gibi görünüyor.
rip
Kent Beck’in Extreme Programming’i, Jeff Sutherland’ın Scrum’u vb. çoğu çevik yöntem kitabında temelde yer alan içerik budur. User story’lere de bakabilirsiniz. Çoğu insan, çevikliğin temelinin müşteri gereksinimlerine hızlı uyum sağlamak için kısa sprintler ve demolar olduğunu pek bilmiyor.
Evet, belirttiğiniz görüşe katılıyorum.
Kodla ikame edilemeyecek kısımlar olduğu kesin.
Bu anlamda biraz farklı açıklamak gerekirse, anlatmak istediğim şey okunabilirliği yüksek kodun belge üretme ihtiyacını azaltacak şekilde yazılmasıydı.
Yazılım uzun soluklu hale geldikçe biriken belgeler de geliştiriciye bilişsel yük getiriyor. Asıl mesele, kod ile belge arasında gidip gelme işini azaltmak.
Tamamen yalnızca kod bırakmanın mümkün olduğunu düşünmüyorum.
Bunun bağlama ve içinde bulunulan duruma göre değişebileceğini düşünüyorum.
Yorumunuz için teşekkür ederim.
Bence sadece bir bakış açısı değişikliği gibi okunuyor ama herkes çok hassas davranıyor.
Ben de bir denemeliyim sanırım
İyi bilgi için teşekkürler.
Karşı argümanı temkinli biçimde iletmek gerekirse, bence kod dokümantasyonun yerini tutamaz. Programlama dilleri hâlâ doğal dilin zengin ifade gücüne ve aktarım kabiliyetine sahip değil; pratikte de o kadar kodun tamamını ne zaman okuyacağız ki?
Dokümantasyonun yerini alabilecek bir koda sahip olmak bir umut ve temenni, ama çıkılamayacak bir Babil Kulesi gibi.
Açıkçası OOAD üzerine ciddi şekilde çalışmak bana daha iyi görünüyor.
specin kendisini çevik şekilde yazmak tam olarak ne demek?speci kabaca yazarız.speci müşterinin söylediği gibi yazarız.speci hızlıca değiştirebilmek için araçların gücünden yararlanıp bakımını yaparız.speci çevik şekilde yazarız.Asıl meselenin, o yazının da özünde söylediği gibi, çevikliğin ne olduğunun bilinmemesi olduğunu düşünüyorum. Çevik için böyle özellikleri var, şöyle böyle yapılmalı diye çok konuşuldu ama bunun gerçekten çevik metodolojiyle geliştirilmiş bir üründür diye örnek gösteren bir yazı şimdiye kadar görmedim. Manifestoya bakınca da pek net gelmemişti. Bir kez gösterebilir misiniz?
BckHWP. Excel VBA otomasyonu
https://m.blog.naver.com/husky81/222045248589
gemini cli sadece düzgün çalışsa bari, sürekli çöküyor
Son zamanlarda bu tür durumları daha sık görüyorum.
Tam olarak anladığımı söyleyemem ama kabaca nasıl bir his verdiğini anlıyorum gibi.
Teşekkürler.
Neden metodolojilere kutsal metin muamelesi yapıldığını anlamıyorum. Bence asıl yazar da sadece yönü farklıydı; dogmatiklik açısından aynı derecede sorunluydu.
SQLite’ı prodüksiyon sunucusu için seçtiğiniz andan itibaren, ne zaman başka bir şeye geçmeniz gerektiğini sürekli düşünmek zorunda kalırsınız.
Eskiden veritabanının kendisinin maliyeti (sunucu satın alma, IDC, lisans maliyetleri vb.) yüksek olduğu için bunu düşünmeye değerdi,
ancak bugünlerde sözde tek tıkla kurulum yapılabiliyorken gerçekten bunu dert etmeye gerek var mı?
Bu yazının kendisi bile çevik değil!
Katılıyorum
Dikey karar alma yapısını yıkmak ve kısa döngülerle tekrarlı iyileştirme bile, bize büyük bir mesaj bırakıyor (elbette proje yönetimi teknikleri/araçları da aynı şekilde).
'Agile'ın kendisinin yeni bir içgörü sunamadığı ve Agile'ı savunan herkesin körü körüne Agile fanatiği olarak çarpıtıldığı' sonucunun fazla sert olduğunu düşünüyorum