İyi bir programlama metaforu nedir? [kapalı]

Programcı olmayanlara, programlamanın ne olduğunu açıklamaya atıfta bulunuyorum. Bu soruyu oluşturmadan önce benzer soruları aradığımdan emin oldum, ancak bulduğum birkaç soru soruyu atlatıyor gibiydi ve özellikle bazı metafor veya benzetmeleri görmek istiyorum. Kişisel olarak metafor veya analojiler kullanarak teknik bir şeyi açıklamayı daha kolay buluyorum.

Bununla ilgilenmemin nedeni, birçok insanın bir programcının çalışmasını günlük olarak karşılamasıdır, ancak ortalama bir kişiye bir programcının ne olduğunu veya ne yaptığını sorarsanız, gerçekten bilmezler. Bu, bazı yanlış anlama durumlarına yol açar (ör. "[...] ama bilgisayarlarda iyi olduğunuzu düşündüm!")

Gerçekten en iyisini bulmak istiyorum. Kariyer tercihimin ne olduğunu birisine kolayca açıklamak istiyorum. Tabii ki, en azından genel fikir.

Şahsen sağlam bir tanesine sahip değilim, ama uzun zamandır düşündüm ve genellikle bilgisayarların anladığı bir dili bildiğimiz 'dil' metaforuna yönelmiştim ve bu nedenle bilgisayarlara ne yapabileceğimizi söyleyebiliyoruz. sorunlarımızı çözmek için onlara "öğretin" veya "öğretin".

Örneğin:

Alternatif bir gerçeklikte, yapay zekaya sahip insansı robotların var olduğunu ve bazı insanların onlarla İngilizcenin bir varyasyonu olan ortak bir dille iletişim kurabildiklerini hayal edin. Robotlarla iletişim kurabilen bu insanlar, onlara kendi problemlerimizi nasıl çözeceklerini veya belirli görevlerini nasıl yapmaları gerektiğini öğretebilirler.

Bunun gibi robotlar henüz mevcut olmasa da, zamanımızın programcıları bu insanlar gibi, fakat robotlarla iletişim kurmak yerine, bilgisayarlarla iletişim kuruyorlar. Programcılar bu "ortak dili" kullanarak oluşturdukları yazılımlarla bilgisayarlara belirli görevleri nasıl gerçekleştireceklerini veya belirli sorunları nasıl çözeceklerini "öğretiyor ".

Programcılar ve bu "ortak dil" bize e-posta, web siteleri, video oyunları, kelime işlemciler, akıllı telefonlar ( basitçe söylemek gerekirse ) ve günlük olarak kullandığımız diğer birçok şey gibi şeyler veriyor.

Taht ya da başka bir şey üzerinde programlama yapmak istemiyorum, bu bulabildiğim en iyi metafor.

Birisinin bununla ilgili bir sorun bulacağına eminim, muhtemelen biraz tartışmalı, ama yine de bu yüzden soruyorum.

Bir yere nasıl sürüleceğine ilişkin adım adım ayrıntılı talimatlar yazmak zorunda olmak gibi. Ancak, genellikle 'trafik sıkışıklığı varsa ne olur' veya 'sıra şeridinde bir kamyon kırılırsa' gibi acil durum planları eklemeniz gerekir.

Bazen de daha derine dalmanız ve hangi tarafın süreceği veya kırmızı ışıkta ne yapılması gerektiği gibi yolun kurallarını açıklamanız gerekir. Ve bazen direksiyonun veya gaz pedalının nasıl çalıştığını tam olarak açıklamanız gerekir.

Ve genellikle, tüm bunları ayrıntılı olarak açıkladığınızda, müşteri "bir hovercraft kullanan biri için çalışması dışında mükemmel" diyor.

Çok, çok salak bir makine için çok, çok ayrıntılı talimatlar yazıyorum.

Büyükanne dostu olan " Örgü tarifleri yazıyoruz" metaforunu kullanıyorum .

Gerekçe:

• Örme, basit bir şekilde mekanik bir işlemdir ve temelde herhangi bir şeyi almak için ayrıntılı talimatları izlemeniz gerekir.
• Örme talimatlarının çoğu çoklu boyutlar içindir. Bu size - ififadeler ve matematik ve döngüler verir.
• Öfkeli anneannelerin ordusu onların arabası kazak ile geldiğinde tarifinde hatayı bulmak!

Çok iyi bir benzetme değil ama insanlar makinelerini tamir etmemi söylediğinde "Ben arabaları tasarlayan adamım. Ben tamirci değilim!" Derim.

Çocukken, programlamanın gerçekten güzel bir tarifini okudum: bir robota okula gitmeyi nasıl yapmak, sıradan bir iş yapılacağını söylemek gibi. Yani "Okula git!" E söyleyebilirsin, ama nasıl olduğunu bilmiyor. Yani “dışarı çık, sola dön, okula gelene kadar yürümeye devam et, sola dön, gir ve otur” demişti. Ama yolunda bir yol var! Bu yüzden, “ortada durun, trafik olmadığını kontrol edin, yolun karşısına geçin ve yürümenin devam etmesini” söylemeniz gerekir. Peki ya kapılar? Yani "okul kapısının açık olup olmadığını kontrol edin. Açık değilse açın." Orada. Sonunda, robotunuza okula nasıl gidileceğini anlatan bir programınız var.

Bu, logoya çok düzgün bir şekilde gider ve burada kaplumbağaya karmaşık şekillerin oluşturulması için tam olarak bu şekilde talimat verirsiniz.

Programlama bir kutu çikolata gibidir . Bazen aradığınızı hemen bulursunuz, ancak çoğu zaman çok fazla deneme yanılma gerektirir. Bazen hindistancevizi alırsın.

Trafik ışıkları . Arabalar hareket ediyor ya da duruyor. Bir trafik ışığı kurmayı hayal etmek kolaydır, ancak başka bir tane eklerseniz ne olur? Üçüncü nasıl? Peki ya bütün şehir? Bir geçiş sistemi, her biri kendi başına basit olan binlerce stop lambasından oluşur, ancak bir bütün olarak alındığında, karmaşık bir sistem haline gelir. Bu trafik ışıklarından biri arızalanırsa veya sadece birkaç saniye kapalı kalırsa, tüm sistemi kaosa atar. Her şey senkronize ise, sürüşün tadını çıkarmanız yeterlidir.

Bir motivasyonel konuşmacı insanların motivasyonları, rüyalar ve fikirlerin bulmaca kilidini anahtarları bulur. Her durum, her insan farklıdır. Geçmişte çalıştı ne şimdi uygun olmayabilir. Bazen bir anahtar tekrar kullanılabilir, ancak bireye adapte edilmesi gerekir. Diğer zamanlarda, anahtar yeniden biçimlendirilmelidir. En ödüllendirici olan şey, insanın kilidinin açılması ve onları dışarı çıkıp dünyayı fethetmesidir. En yıkıcı, kendinizi yakın hissettiğiniz zamandır, ancak potansiyelin kilidini açamazsınız.

Dedektifin yavaşça ipuçlarını arayarak ve kanıtları toplayarak vakasını oluşturduğu bir dedektif öyküsü . Metodik, akıllı ve doğru günü kazanır. Özensiz, cahil ve tembel olayı mahvedecek. Sonunda, çalışma bir meslektaş jürisinin önünde duracak veya düşecek.

Bir slot makinesidir . Tüm paralarını koy ve kolu çek. Bazen büyük kazanıyorsunuz, bazen saatlerce orada oturuyorsunuz ve hiçbir şey olmuyor. Bazen başka biri sadece rahatça yürür, kolu bir kez çeker ve ikramiye kazanır.

Müzik . Bir not yeterince basit, ancak bir ölçü daha karmaşık. Tam bir şarkı, birçok nota içeren birçok önlem içermektedir. Bir not kapalıysa, tüm performansı bozabilir. Her nota mükemmel bir şekilde iletilirse, performans arka plana kaybolur ve sadece müzik vardır.

Bir şey için en iyi metafor kendisidir. Farklı olan herhangi bir şey biraz doğruluk kaybedecektir. Bu nedenle, en iyi metaforu seçmek, özellikle programlama hakkında yakalamak istediğiniz şeye bağlıdır. Burada kodlama metaforları hakkında verilen birçok cevap olacağı için, bir bütün olarak gelişim süreci için klasik metaforla cevap vereceğim:

Bina inşaatı

Bu metaforun en yaygın yönü, fiziksel bir mimarın bir yazılım mimarına benzemesidir. İşte birkaç diğer paralellikler:

• Değişiklikler daha ucuz ve daha erken yaptıklarında daha ucuzdur. Yani, şu anda kağıda bir satır veya daha sonra 10 ton çimentoya taşıyabilirsiniz.
• Uygun bir planı olmayan bir bina yıkılma eğiliminde olacaktır
• İnşaatçılar, müşterinin istediğini uygulamaya çalışır. Müşteri binanın neye benzemesini istediğini doğru bir şekilde tanımlamazsa (veya iletişimde başka bir başarısızlık varsa), değişmesi pahalı olacaktır.
• Bükülemeyen belli fizik yasaları var. 100 feet genişliğindeki 1. kat üzerine üç yüz ayak genişliğinde bir 2. hikaye inşa edilemediği gibi, X özelliği de sağlam bir alt sistem olmadan inşa edilemez.

Elbette, herhangi bir metafor gibi, sınırlamaları vardır. Bununla ilgili bazı kusurlar:

• Binalar tek kullanımlıktır; bir yere inşa edersin ve orada kalır. Sıfır artan maliyetle, milyonlarca farklı ihtiyacı olan milyonlarca farklı kullanıcı için milyonlarca kez kopyalayamazsınız.
• Binalar yazılımdan çok daha değişkendir.
• Yapı malzemesi maliyetine açık bir benzetme yoktur. Bir kod satırı hiçbir ücrete tabi değildir - yalnızca üretmek için harcadığı zaman paraya mal olur.
• Yazılımla (kime sorduğunuza bağlı olarak) mümkün olan artımlı mimari, bir kez tasarladığınız, sonra derlediğiniz yapı ile mümkün değildir.

Yani, herhangi bir benzetme gibi, açıklamaya çalıştığınız şeye bağlıdır. Herhangi bir metafora güvenmekten çekinmeyin, yoksa müşteriniz yeni bordro sistemindeki emlak vergilerinin ne olacağını merak etmeye başlayacaktır.

Chris McMahon'un Yazılım geliştirme analojisini müziğin, özellikle de caz müziğinin yaratılması gibi bir ifadesiyle seviyorum .

Bu Ella Fitzgerald ve Kont Basie, One O'Clock Jump adlı şarkıyı yapıyor. Şarkı bir UI ile bir veritabanı uygulamasının caz eşdeğeri olan on iki çubuk blues. Demek istediğim: her programcının bir kullanıcı arayüzü ile bir veritabanı uygulaması geliştirmesi gibi, her Amerikalı müzisyen on iki bar blues çaldı. Kont Basie'den Jimi Hendrix'e ve Ramones'e kadar birçok şarkının asıldığı bir çerçeve.

Bu video, çevik uygulamalara harika bir örnektir. Sesin ve piyanonun birbirlerini nasıl etkilediğini dinleyin. Bu, çift programlamaya çok benzer ve TDD'ye çok benzer: ses bir şey yapar; piyano cevap verir; piyano bir şey yapar; ses cevap verir. Ve göz temasından haberdar olun. Bu insanlar anında anında neler olduğuna dair yoğun bir şekilde farkındalar. Nota müziği yok (BDUF). İyi bir yazılım geliştirme gibi yoğun bir konsantrasyon ve beceri gerektiren bir faaliyete katılıyorlar. Ayrıca, bir izleyici kitlesinin varlığından açıkça haberdarlar; tıpkı iyi bir yazılım geliştirmenin faturaları ödeyenlerin ihtiyaçlarını bilmesi gerektiği gibi.

İşte tartışıldığı blog yazısı için link: http://chrismcmahonsblog.blogspot.com/2007/05/example-of-analogy-monks-vs-music.html

Bazen programlamadan akılsız zombileri kontrol etmek olarak bahsediyorum . Blog yayınımı bunun hakkında özetliyor :

• Zombiler gibi, birlikte çalıştığımız bilgisayarlar çok aptal. Talimatlar ayrıntılı olmadığı sürece, bir şey yapmalarını söylemesi zor.
• Zombiler saldırgandır ve talimatlardaki küçük ayrıntıları kaçırırsak, yaratığı işlenmeden bırakır, etrafındaki her şeyi ezebilir. Bilgisayarlarda da aynı: talimatlardaki detayların eksikliği programınızın çökmesine neden olabilir ve verilerinizi tahrip edebilir.
• Bir zombi kontrol etmek istiyorsan sihir bilmelisin. Programlama ile aynı.
• Beyni olan insanlar ne kadar çok yerde toplanırsa, bilgisayarları o kadar fazla olacaktır. Beyinlerin bilgisayarları çektiği görülüyor - zombileri aynı şekilde çekiyorlar.

Programlama Lego ile bir şeyler inşa etmek gibidir :

• Daha büyük şeyler yapmak için bir sürü küçük parçayı birbirine yapıştırıyorsunuz
• Küçük uçlar sınırlı sayıda şekil ve boyutta gelir
• Küçük şeyler ancak belirli şekillerde birbirine uyabilir
• Bu şeyle oynamak çok eğlenceli olabilir

Bilgisayar programlamak çocuk büyütmek gibidir ...

• Herkes doğru şekilde yapmak için aynı fikirde değil
• Geceleri seni ayakta tutar
• Asla söylediğin şeyi yapmaz.
• Konuyla ilgili ne kadar kitap okursanız olun, ne zaman yapmaya başladığınızda, ne yaptığınız hakkında hiçbir fikriniz yokmuş gibi hissedersiniz.
• Bir süre sonra tembelleşmeye eğilimlisin
• Gelecekte büyük kazançlar elde etmesini bekliyorsunuz ancak yaşamın sonuna kadar sürdürmek zorunda kalacaksınız.
• Asla istediğin kadar temiz, akıllı ya da güvenli değil.
• Daha sonra tekrar baktığınızda, ne düşündüğünüzü merak ediyorsunuz.
• Size neden olan tüm strese rağmen, yine de onu seviyorsunuz.

Asıl fark, birisi kaynak kodumuzu çalarsa üzülmemizdir, ancak çoğu zaman birisinin çocuklarımızı elimizden almasından memnuniyet duyarız.

Programlama bir fabrika veya montaj hattı inşa etmek gibidir.

Yazılımı, bilgisayarın içinde bulunan bir makine veya montaj hattı olarak düşünün. Bazı hammaddeler ve bileşenler makineye beslenir ve bunları nihai ürün olarak işlemek için bir dizi prosedür izler. Prosedürler, belirli bir sırada belirli bir parametre setine (örneğin zaman, sıcaklık, mesafe vb.) Bazı hammadde veya bileşen üzerinde belirli bir işlemi gerçekleştirmek üzere ayarlanmıştır. Gerçekleştirilecek işlemin detayları yanlışsa veya makinenin sensörleri doğru şekilde kalibre edilmemişse veya bazı hammaddeler veya bileşenler beklenen kalite standartlarında değilse, işlemin sonucunu değiştirebilir ve ürün ortaya çıkmaz beklenildiği gibi.

Böyle bir makine işleminde ve kabul edilebilir girdilerde çok katıdır. Makineler tasarımcıların zekasını ve mevcut çalışma ortamını sorgulamıyor. Yönettiği sürece prosedürleri takip etmeye devam edecektir. Hammaddelerde veya bileşenlerde yapılan bir değişiklik, sonraki işlemlerde olanları üzerinde ciddi bir etkiye sahip olsa bile, makine yine de işlemlerini yerine getirir. İstenen sonucu telafi etmek ve üretmek için prosedürlerde hangi değişikliklerin yapılması gerektiğini görmek için sürecin gözden geçirilmesi gerekir. Ürünün tasarımında veya yapılandırmasında yapılan bir değişiklik, gerçekleştirilen işlemlerde veya siparişlerinde önemli bir değişiklik gerektirebilir. Üretimden sorumlu olanlar, bunlar arasındaki istenmeyen etkileri azaltmak için izolasyon işlemlerinin mümkün olduğunca çabuk önemini öğrenmiş olsalar da, Bileşenlerin işlemden geçirildiği haliyle şartların bir sürü varsayımı yapılır; nihai ürün kullanıcının bazı farklı çalışma ortamlarında bulunmadığı sürece tespit edilemeyecek varsayımlar.

Hızlı bir aptalın yazılı bir deneme gerektiren bir matematik dersinden geçmesine yardım etmek.

Bilgisayar programlama, tahtanın büyüklüğü, oyundaki parçaların miktarı ve bu taşları yöneten kuralların oyun ilerledikçe boyut ve karmaşıklık içinde büyüdüğü bir satranç oyunu oynamak gibidir.

Yazma Yazılımı Gibi ... Yazma! ^^

CS / Programming sınıflarına yeni gelen öğrenciler, pratik olarak, programlama yapmayan kullanıcılar gibidir. Robot örneği iyi.

80'lerde, kullanıcının programlamayı öğrendiği, bilgisayarda bir robot gibi izlemenin, bir daktilo ile televizyon setinin kullanılmasını sağladığı Logo, Karel (veya benzeri programlama ortamları) kullanarak çok yardımcı oldu. Yaygın olarak ortaokul ve lisede kullanılan araçlar.

Bu pratik programlama, öğrencilere bilgisayarla ilgili olmasalar bile, problem çözme becerilerini kazanmalarında yardımcı oldu !!!

Veya, öğrenciler programcı olmasa bile.

Bazı Meslektaşlar ve Üniversiteler bu araçları ilk yıl derslerinde de uyguladılar.

Acaba neden birçok lise Logo ve Karel'e ders veriyor?

Mythical Man-Month'dan Fred Brooks'un benzetmesini seviyorum, bu programlama sihir yapmak gibi.

() Program programı şairin sözlerinden farklı olarak, yapının kendisinden ayrı bir görünür çıktı üreten, hareket ettiği ve çalıştığı anlamında gerçektir. Sonuçları basar, resim çizer, ses çıkarır, silah taşır. Efsanenin ve efsanenin büyüsü zamanımızda gerçekleşti. Biri klavyede doğru bir şekilde büyüyor ve hiçbir zaman olamayacak şeyleri gösteren bir ekran ortaya çıkıyor. ...

(Bir) doğru şekilde yapılmalıdır. Bilgisayar da bu açıdan mit ve efsanenin sihrini andırıyor. Bir karakter, tutkunun bir duraklaması kesinlikle uygun biçimde değilse, sihir işe yaramaz. İnsanoğlu kusursuz olmaya alışkın değildir ve birkaç insan faaliyet alanı bunu talep eder. Mükemmelliğe olan gereksinime uyum sağlamak, programlamayı öğrenmenin en zor kısmı olduğunu düşünüyorum.

“[...] ama bilgisayarlarda iyi olduğunu düşünmüştüm!”

Bu genellikle bir bilgisayarı tamir etmek için bir inek kandırmak için bir girişimdir (onları yanlış kanıtlamak için istekli hissediyorum?). Standart cevabım:
Ben bir programcıyım. Bu bir otomobil mühendisi gibi - muhtemelen Trab72'nizin frenlerini nasıl çözeceğinizi bilemeyecek ve bilseydi kesinlikle yapmaz. Bir tamirci bunu yapar!

Yemek pişirmek için bir tarif kavramına düşkünüm.

Programlama muazzam miktarda güç kullanmak gibidir. Bilgisayarın yapmak istediğiniz her şeyi yapmasını sağlayabilirsiniz. Yalnızca hayal gücünüz ve yatırım yapmak istediğiniz zaman miktarınızla sınırlıdır.

Programcılar bir evin yapımcıları gibidir. Yaptığımız evler hakkındaki her şeyi size söyleyebiliriz. Yine de, bize rastgele bir ev sormamızı sorarsanız, yoldan geçiyoruz, büyük olasılıkla fazla bir şey bilmiyoruz. Ancak o eve eklenmiş veya değiştirilmiş bir şeye ihtiyacınız olursa, sahibin bize izin vermesi şartıyla bunu gerçekleştirebiliriz.

Chris Crawford’ın programlama konusundaki eski makalelerinden birinde, karmaşık bir programı bürokrasiye benzetmiş, birden çok ajansı ileriye ve geriye doğru aktararak ileten bir iletişim kurmuştu. Yazılım geliştirmeyi açıklarken çok kullanışlı bir metafor olduğunu buldum.

Programlamayı genelde bir bilmeceye eşitlerim.

Yeni bir proje oluşturmak için - birkaç tanesi bu görüntüye ait olmayan tonlarca parçanız var ve bittiğinde bulmacanın nasıl göründüğünün bir önizlemesine sahip değilsiniz. Ancak, büyüklüğü ve genel renkleri bilirsiniz, bu nedenle tahminler mümkündür, ancak kesin olarak doğru değillerdir.

Halihazırda var olan bir projeyi değiştirmek için - bir kedi geldi ve bitmiş bulmacanın bir parçasını çaldı. Biraz zaman alacaktır, ancak çerçeve zaten oradadır, dolayısıyla ne kadar değiştirilmesi gerektiğine bağlı olarak çok kötü olmamalıdır.

Aynı zamanda ilerlemeyi tanımlamak için yardımcı olur. Son projelerimden biriydi, bir noktada, teknik olmayan bir insanın neden daha fazla bilmediğimi anlayabilmesi için nasıl tanımlayacağımı merak ediyordum ve şunu buldum: sınır parçaları, iç kısımların yarısından biraz daha fazlası gibi yapılır. Geri kalanların hepsi birbirinden ayrı, şimdi yapmam gereken boşlukları doldurmak.

Bu üzücü ama programlama sadece nasıl yapılacağını öğrenerek anlaşılabilecek bir iştir.

Programlamanın birkaç farklı algı düzeyi vardır ve farklı yönlerden farklıdır.

Düşük seviyede "çok, çok aptal bir makine için çok, çok ayrıntılı talimatlar yaz"

Bir sonraki aşamada karmaşıklıkla uğraşıyor. Çalışmayı kolaylaştırmak için yeni metafor oluşturmak. Daha yüksek matematik gibi.

Farklı yönlerden, sürüm kontrolü, kendini belgelenmiş kod, proje oluşturma ve test etme gibi yardımcı teknolojilerin kullanımı.

Diğer taraftan, bina "kullanıcı" arayüzü (kelimenin tam anlamıyla değil, yani API kullanıcı arayüzü anlamına gelir), olası hataları (kullanıcı, veriler tarafından veya hatta kendisi tarafından yapılır) tahmin eder ve hatalara doğru tepki verir.

Ve sonunda.

Programlamanın metaforu edebiyattır. İlk önce alfabeyi öğrenmeniz gerekir. Ancak buna bir roman yazmak bile başlamaz.