Kişi gerçek kodlamadan önce sahte kod kullanmalı mıdır?

Sahte kod, görevleri dil destekli bir şekilde anlamamıza yardımcı olur. Geliştirme yaşam döngüsünün bir parçası olarak sahte kod oluşturmaya sahip olmak en iyi yöntem mi yoksa önerilen bir yaklaşım mı? Örneğin:

• Kodlama görevlerini tanımlayın ve bölün
• Sahte kod yaz
• Onay almasını [PL veya TL]
• Sözde kodu temel alan kodlama başlatmak

Bu önerilen bir yaklaşım mı? Endüstride uygulanmakta mıdır?

Kodlamadan önce sözde kod yazmak, plan yapmadan kodlamaktan kesinlikle daha iyidir, ancak en iyi uygulama olmaktan uzaktır. Test odaklı geliştirme bir gelişmedir.

Daha da iyisi, sorunlu alanı analiz etmek ve kullanıcı hikayeleri, kullanım senaryoları, CRC kartları, diyagram oluşturma gibi teknikleri kullanarak Cleanroom, RUP, Lean, Kanban, Agile, vb.

Sorunun doğasını ve çözümü uygulamak için kullandığınız bileşenleri iyice anlamak, en iyi uygulamaların arkasındaki ilkedir.

Yorumları, kod yazmadan önce bir çok üst düzey sahte kod olarak kullanıyorum. Tüm problemi düşünerek, hatta yüksek düzeyde bile, kodumu önemli ölçüde geliştirdiğimi düşünüyorum.

Hayır, önce sözde kodu kullanma

Bu çok fazla yük. Mantık yazma yararlarını hiçbir faydası olmadan yapıyorsun. Bunun yerine aşağıdakilerden birini öneririm:

1. Göndereceğiniz dilde prototip (AKA Birisini atmak için yazın )
2. Mimari çizimleri w / kod parçacıkları varsayımları / anahtar tasarımları test etmek için
3. Önce arayüzleri / kod yapınızı yazdığınız, ardından testlerin ardından kodu uygulayan Test Driven Development.

Bunların üçü de, sahte kodun aksine sizi doğrudan çözümünüze yönlendirir. Şahsen takım büyüklüğüne bağlı olarak 1 veya 2 tekniklerini kullanma eğilimindeyim. Küçük (örneğin 5 veya daha az kişi) ekipleri için prototip oluşturma işlemi çok iyi çalışıyor. Paralel olarak çalışan birden fazla geliştirici grubuna sahip olan daha büyük ekipler için, teknik 2'nin başlarında üretilen belgelerin iyi çalıştığını gördüm, çünkü size erken tartışmak için bir şeyler veriyor ve bileşen sınırlarını daha iyi tanımlamanıza yardımcı oluyor. TDD'nin de çok iyi çalışacağına eminim, ancak henüz bu sürece bağlı olan bir ekip üzerinde çalışmam gerekiyor.

Bence sözde kodun sadece iki geçerli amacı var:

(1) Modülerlik ve algoritma kavramlarını öğrenmesi gereken, ancak bir programlama dilinde henüz akıcı olmayan öğrencileri programlamak için.

(2) Teknik olmayan bir kişiye veya bir beyaz tahta türü toplantıda uygunluk uğruna nasıl çalışacağını bildirmek.

Sahte kod önerilen bir yaklaşım mıdır? Yeni başlayanlar için evet diyorum. Yeni programcının, bir dilin tam olarak sözdizimi hakkında endişe duymadan bir koda nasıl çevrileceğini öğrenmesine yardımcı olur. Bu düşünce sürecini şekillendirir ve faydalı alışkanlıkların kökleşmesine yardımcı olabilir (ve benim de kötü alışkanlıklar olduğunu düşünüyorum). Bu yüzden okullarda bu kadar çok kullanılıyor.

Endüstride uygulanmakta mıdır? Benim tecrübeme göre, hayır. Kimse projeyi dokümantasyon (şartnameler, şartnameler, hikaye panoları, kullanım senaryoları veya diğer her ne kullanıyorsa) ile gerçek kod arasında zorlama zamanı bulamaz. Genel olarak, yeşil ışığın kodlanmasından önce soruna yeterli düşünce getirildiği varsayılmaktadır. Bu noktada, projeyi kodlamak, bir tasarım hazırlığı daha eklemek daha önemlidir.

Sözde kodu kesinlikle tavsiye ederim. Ne yapacağınızı açıklığa kavuşturmanıza ve unutmuş olabileceğiniz eşyaları ya da olası sorunları tanımlamanıza yardımcı olur. Hala planlama aşamasındayken kodunuzu düzeltmek çok daha kolay / daha hızlıdır, daha sonra kodunun büyük kısmını kodlayana kadar bekleyin.

Sözde kod, dili bilmiyorsanız veya zihinsel bağlamı değiştirmeniz gerekirse faydalı olabilir. Nadiren sözde kod yazdığımda kağıt üzerinde. Bazen sadece klavyenizden ellerinizi çekmek ve kağıda yazı yazmak zihinsel bir blok etrafında dolaşmanıza yardımcı olabilir.

Fakat gelişme sürecinin resmi bir parçası olarak? Olmaz. Bireyler için ara sıra faydalı bir araçtır. "Yazmadan önce ne yazdığınızı bilmek" için daha iyi yollar vardır.

1. Başlamadan önce yöntemin sözleşmesini (öncesi / sonrası / değişmeyen koşullar) tanımlama
2. TDD
3. 1 ve 2 birlikte

Ayrıca, kod yazmaya başlamadan önce herhangi bir onay almanın, değerinden çok daha fazla sıkıntıya neden olabileceğini öneriyorum. Tasarım incelemeleri (uygulama öncesi) faydalı olabilir, ancak bireysel algoritmalardan daha yüksek seviyede olmaları gerekir.

Önceki cevaplara katılmayacağım ve hayır diyeceğim, ancak bir ihtirasla: psuedocode kodundan kurtulabilirsiniz, ancak titizlikle ortaya çıkan sorunları ele almak için kodunuzu yeniden düzenlemeye kararlıysanız. Psuedocode, özünde, kodunuzu tanımlamadan önce kodunuzu tanımlamanın bir yoludur; bu, birçok durumda gereksiz bir soyutlamadır ve kodunuz ilk kez mükemmel olamayacağından (ve muhtemelen, psuedocode'un tasarımını tamamlamaya devam etmeyeceğinden), bana gereksiz geliyor.

COBOL veya C yazıyorsanız, sözde kod yararlı olabilir çünkü gerçek kodun yazılması çok daha uzun sürer ve algoritma / gereksinimlerinizi sözde koddan doğrulayabilirseniz, biraz zaman kazanabilirsiniz.

Daha modern dillerde, sözde kod pek mantıklı gelmiyor. Daha iyi sonuç verebilecek olan şey, yöntem saplamalarını yazmak, en üst düzey mantığı ve algoritmayı ve gereklilikleri doğrulamak için gereken her şeyi gerçek kodda doldurmaktır. Daha sonra bu kodu onay için Ekip Liderine gösterebilir ve gerçek kodunuzun daha önce başlatılmasını sağlayabilirsiniz.

Sözde kodu son 10 yılda kullandığım tek zamanlar, bir beyaz tahta üzerinde çalıştığımız ve belirli bir dilin önemli olmadığı durumlarda röportaj.

Bir işlem / algoritma aracılığıyla gevşek terimlerle sözdizimine bağlı kalmadan konuşmak için kesinlikle faydalıdır. Örneğin, sadece noktayı göstermek için C # özelliklerine sahip bir C ++ sınıfı yazmak.

Onun yeri vardır, ancak ihtiyaç duyulan yerlerde kullanılmalıdır (atmanız gereken iş) ve üzerinde ısrar eden ISO tipi standartlara sahip olmadığınız sürece, kesinlikle resmi bir sürecin parçası değildir.

Kendim ve son birkaç yıldır birlikte çalıştığım insanlar için sözde kod, tam anlamıyla mükemmel bir gerçek kod haline gelmedi. Aynı anda birçok dilde çalışmadığınız sürece, çoğu insan ana dilinin genel düzeninde düşünmeye başlıyor gibi görünmektedir. Bir süredir .net mağazalarında çalıştım, bu yüzden çoğu insanın ofisinin etrafındaki beyaz tahta karalamalar, noktalama işaretlerinin bir kısmı eksikken vb veya c # gibi gözüküyor.

Alıştırma seçenekleri ve bunun gibi şeyleri tartışırken hala değerlidir, ancak dilde agnostik bit, birkaç dilde daha fazla zaman harcadığınızda uzaklaşma eğilimindedir.

Daha da fazlası, sözde kod UML gibi araçlarla grafiksel olarak yazılmıştır. Örneğin, yUML'yi deneyin .

basit UML diyagramları oluşturmak ve yayınlamak için çevrimiçi bir araç. Bu sizin için gerçekten kolay:

• UML diyagramlarını bloglara, e-postalara ve wikilere gömün.
• Forumlarda UML diyagramları ve blog yorumları gönderin.
• Doğrudan web tabanlı hata izleme aracınızın içinde kullanın.
• UML diyagramlarını kopyalayıp MS Word dokümanlarına ve Powerpoint sunumlarına yapıştırın ...

... yUML size zaman kazandırır. Küçük UML diyagramları ve eskizleri oluşturmak isteyenler için tasarlanmıştır.

YUML olmadan, bir UML diyagramı oluşturmak, bir UML aracını yüklemek, bir diyagram oluşturmak, bir ad vermek, mizanpaja girmek, onu bitmap'e dışa aktarmak ve çevrimiçi bir yere yüklemek olabilir. yUML bunların hiçbirini yapmaz ...

Harika iş. İyi bir tartışma başlattın. Benden, çeşitli döngüler ve algoritmaları anlamak için programlama öğrenirken sahte kodlar yazıyordum. Bu bir buçuk yıl önceydi. O günler, programlama dilleri bile çok güçlü değildi ... ve olaya dayalı programlama geleceğe aitti. Şimdi 4GL ve 5GL'lerle, dilin kendisinde sade İngilizcede olduğunu düşünüyoruz. Bir problem düşündüğümüzde, nesneler ve işlemler açısından düşünüyoruz. Ve karmaşık bir algo olana kadar sahte kodlar yazmak (veya PSEU-DO Kodları, sadece şaka yapmak) bir anlam ifade etmiyor. Daha da iyisi, çözümü grafiksel bir şekilde temsil edin.

Kullanılan dile ve bu konudaki bilginize bağlıdır.

Python veya Java gibi pek çok modern dil, zaten bazı sahte sahte kodu yazmanın israf olduğunu gösteren IMHO'nun sahte koduna zaten çok yakın. Sadece izleyici mermi yaklaşımını kullanarak hemen yap .

Biraz düşük seviyeli, metal şeylere yakın veya kullanmakta olduğunuz dil konusunda rahat hissetmiyorsanız, bu farklı bir fırsat. Sonra sözde kod kesinlikle yararlı olabilir.

Yaptığım çalışmada sözde kodun bozulma eğiliminde olduğu, programlamanın bir araç olarak ya da “ve şimdi çözüyoruz” projenin ortasında doldurma eğiliminde olduğu akademi'deki birkaç durum vardır:

1. Kod, sözde kodun olacağından ne olacağı ile ilgili gerçek bir anlayışa karşı daha üretken olacağı zaman. Örneğin SAS, bazı temel programlama görevlerini yerine getirdiğinde beyaz tahtanın yarısını kaplayacaktır. Diğer bazı posterlerin tartıştığı C'ye de bakın.
2. Çok fazla veri analizi ve istatistik kodlamasıyla, sonuçlar üretilirken kodla çok fazla ilişki kurma eğilimi vardır. Sahte kod, "tanılama planı doğru görünmüyorsa, X'i deneyin" için ileri geri ileri bir işlemden bahsediyor.
3. Öğrenciler çok sayıda farklı programlama dili öğrenirler. Örneğin, tanıdığım insanlar arasında SAS, R veya Stata'da bir istatistik problemi analiz edilebilir. Geleneksel programlamaya daha yakın bir şey gerektiren bir şey R, Matlab, C, C ++, Java, Python'da yapılabilir ... bu gerçekten hangi öğrencinin programı uyguladığına ve hangi amaç için olduğuna bağlıdır. Ancak Java halkı ve Python insanı ve Matlab halkı için diğerlerinin ne yaptığı ve kodun kendisinden ziyade yaklaşımın nasıl çalıştığı hakkında ortak bir fikir edinmeleri hâlâ yararlı .

Bu evet / hayır sorusu değil. Aksine, kişi sahte kodu ne zaman kullanacağını merak etmelidir . Bir çözüm tasarlamadan önce sorunu anlamak önemlidir ve uygulamadan önce çözümü açık bir şekilde görmek önemlidir. Sözde kod aşağıdaki adımlardan herhangi birinde kullanılabilir:

1. Sorunu tanımlarken, bazen eylem dizileri kullanarak kullanım durumlarını yazmak yaygındır.
2. Bir çözüm tasarlarken. Sınıf diyagramları güzeldir, ancak yalnızca "statik" kısmı, yani verileri açıklarlar. Dinamik kısım için, bir döngü ve önemsiz veriyle başa çıkmanız gerektiğinde, en iyi yöntem olarak sahte kodu buluyorum. Grafiksel alternatifler arasında durum makineleri (az veri içeren karmaşık kontrol akışı için iyi) ve veri akış şemaları (karmaşık veri içeren basit akışlar için iyi) bulunur.
3. Çözümü uygularken (veya hemen önce). Bazı programlama dillerini okumak zor (düşünmek, montaj). Alternatif bir temsil bu durumda değerli olabilir. Dilleri bilmiyorsanız, yapmaya da değer.

Yüksek seviye bir dilde aslında uygun kod olan sözde kod da kullanılır, genellikle prototipleme olarak adlandırılır.

Anlamaya ulaşmanın yanı sıra, sözde kod iletişim için de iyidir.

Düzenli olarak sahte kod kullanmanız gerekip gerekmediğini merak ediyorsanız, şahsen her türlü katı kurallara karşıyım. Takımdaki herkesin anladığı önemsiz problemler için kullanıldığında, bu kolayca sıkıcı bir zaman israfına dönüşebilir. Projenin ömrü boyunca sürdürdüğünüz özellikler için sözde kod kullanmak da maliyetli olabilir ve çok az değer sunar.