Karmaşık kod tabanlarında, yan etkilerin karmaşık etkileşimleri, hakkında düşünmem gereken en zor şeydir. Kişisel olarak sadece beynimin çalıştığı şekilde konuşabiliyorum. Yan etkiler, ısrarcı durumlar ve mutasyona giren girdiler ve diğerleri, her bir işlevde sadece “ne” olduğunu değil, doğrulukla ilgili şeylerin “ne zaman” ve “nerede” olduğu hakkında düşünmeme neden oluyor.
Sadece "neye" odaklanamıyorum. Arayanlar hala yanlış zamanda, yanlış iş parçacığından, yanlış işyerinde yanlış zamanda çağırarak kötüye kullanabileceğinden, yan etkilere neden olan bir işlevi iyice test ettikten sonra tamamlayamam. sipariş. Bu arada, hiçbir yan etkiye neden olmayan ve sadece bir giriş verilen (girişe dokunmadan) yeni bir çıkış döndüren bir fonksiyonun, bu şekilde yanlış kullanılması oldukça imkansızdır.
Ama ben pragmatik bir türüm, sanırım ya da en azından olmaya çalışıyorum ve kodumuzun doğruluğunu düşünmek için en az tüm yan etkileri en bariz şekilde damgalamak zorunda olduğumuzu sanmıyorum (en azından) Bunu C) gibi dillerde yapmak çok zor bulur. Doğruluk konusunda mantıklı olmanın çok zor bulduğu nokta, karmaşık kontrol akışları ve yan etkiler kombinasyonuna sahip olduğumuz zamandır.
Karmaşık kontrol akışları bana doğada grafik benzeri, genellikle özyinelemeli veya özyinelemeli (örneğin, olayları doğrudan özyinelemeli olarak aramayan ancak doğada özyinelemeli "olan), belki bazı şeyleri yapan akışlardır. gerçek bir bağlantılı grafik yapısını geçme sürecinde ya da bizi kodbazın her türlü farklı parçasına ve hepsi farklı yan etkilere neden olacak şekilde işlemek için eklektik bir olaylar karışımı içeren homojen olmayan bir olay kuyruğunu işlerken. Nihayetinde kodun sonunda çıkacağınız tüm yerleri çizmeye çalıştıysanız, karmaşık bir grafiğe benzeyebilirdi ve potansiyel olarak asla beklemeyeceğiniz grafikteki düğümlerle, o anda orada bulunmuş olacaktı ve hepsinin aynı olduğu düşünülürse yan etkilere neden olmak,
İşlevsel diller son derece karmaşık ve özyinelemeli kontrol akışlarına sahip olabilir, ancak sonuçta doğruluk açısından anlaşılması çok kolaydır çünkü süreçte her türlü eklektik yan etki yoktur. Sadece karmaşık kontrol akışları, neler olup bittiğini ve her zaman doğru olanı yapıp yapmayacağını anlamak için baştan çıkarıcı bulduğu eklektik yan etkilerle karşılaştığında.
Bu yüzden, bu davaları aldığımda, bu kodun doğruluğu konusunda kendinden emin hissetmek imkansız olmasa da, beklenmedik bir şey açmadan bu kod üzerinde değişiklikler yapabileceğim konusunda kendime güvendiğim için çok zor buluyorum. Bu yüzden benim için çözüm ya kontrol akışını basitleştirmek ya da yan etkileri en aza indirgemek / birleştirmek. (Birleştirerek, demek istediğim, iki ya da üç ya da bir değil. düzine). Simpleton beynimin var olan kodun doğruluğu ve tanıttığım değişikliklerin doğruluğu konusunda kendinden emin hissetmesini sağlamak için bu iki şeyden birine ihtiyacım var. Eğer yan etkiler kontrol akışı ile birlikte aynı ve basit ise, yan etkileri ortaya çıkaran kodun doğruluğundan emin olmak oldukça kolaydır:
for each pixel in an image:
make it red
Bu tür bir kodun doğruluğunu düşünmek oldukça kolaydır, ancak temel olarak yan etkiler çok tekdüze olduğundan ve kontrol akışı çok basit olduğu için. Ama diyelim ki böyle bir kodumuz var:
for each vertex to remove in a mesh:
start removing vertex from connected edges():
start removing connected edges from connected faces():
rebuild connected faces excluding edges to remove():
if face has less than 3 edges:
remove face
remove edge
remove vertex
O zaman bu, gülünç derecede basitleştirilmiş sahte koddur ve tipik olarak çok daha fazla fonksiyon ve iç içe döngüler ve devam etmesi gereken çok daha fazla şey içerir (çoklu doku haritalarını, kemik ağırlıklarını, seçim durumlarını vb. Güncellemek), ancak sözde kodu bile zorlaştırır. karmaşık grafik benzeri kontrol akışının etkileşimi ve devam eden yan etkiler nedeniyle doğruluk nedeni. Bu yüzden bunu basitleştirmek için bir strateji, işlemi ertelemek ve bir seferde sadece bir tür yan etkiye odaklanmaktır:
for each vertex to remove:
mark connected edges
for each marked edge:
mark connected faces
for each marked face:
remove marked edges from face
if num_edges < 3:
remove face
for each marked edge:
remove edge
for each vertex to remove:
remove vertex
... bir sadeleştirme yinelemesi olarak bu etkiye bir şey. Bu, kesinlikle bir hesaplama maliyetine neden olan veriyi defalarca ilettiğimiz anlamına gelir, ancak çoğu zaman bu sonuç kodunu daha kolay okuyabildiğimizi, artık yan etkiler ve kontrol akışlarının bu tek biçimli ve daha basit doğada gerçekleştiğini görüyoruz. Ayrıca, her ilmek bağlanmış grafiğin üzerinden geçmek ve ilerlerken yan etkilere neden olmaktan ötürü önbellek dostu hale getirilebilir (örneğin: ertelenen geçişleri sıralı sırayla yapabilmemiz için geçilmesi gerekenleri işaretlemek için paralel bir bit seti kullanın) bit maskesi ve FFS kullanarak). Fakat en önemlisi, ikinci versiyonun hatasızlık ve hatalara neden olmadan değişiklik anlamında sebep olması çok daha kolay. Böylece'
Ve sonuçta, bir noktada meydana gelmek için yan etkilere ihtiyacımız var, yoksa sadece gidecek hiçbir yerde veri çıkaran işlevlere sahip değiliz. Çoğunlukla bir şeyi bir dosyaya kaydetmemiz, bir ekrana bir şey göstermemiz, verileri bir soket üzerinden göndermemiz, bu türden bir şey ve bunların hepsi yan etkilerdir. Ancak devam eden gereksiz yan etkilerin sayısını azaltabilir ve kontrol akışları çok karmaşık olduğunda ortaya çıkan yan etkilerin sayısını azaltabiliriz ve eğer yaparsak hataları önlemenin çok daha kolay olacağını düşünüyorum.