Bir programcının kodu yazmaya başlamadan önce algoritmayı tasarlaması neden daha iyidir?

Uygun bir algoritma gerçekten bir programın kalitesini ve sonuçta verimliliğini artırmaya yardımcı olur mu?

Algoritmasız kaliteli bir program hazırlayabilir miyiz?

Modern programlamada uygun bir algoritma şart mı?

Bence bu soru tarihsel bir bakış açısı getiriyor.

"Eski günlerde" (ki şahsi tanık değilim, bu yüzden bu sadece o dönemin yeniden yapılandırılması - farklı şeyler deneyimlediyseniz beni düzeltmekten çekinmeyin) HW alanı ve performans bugünküne kıyasla sıfırdı. Bu yüzden insanların yazdığı her şey çok verimli olmak zorundaydı. Bu nedenle, işi yapmak için gerekli alan / zaman performansını elde etmek için en iyi algoritmaları icat etmek için çok düşünmeleri ve araştırma yapmaları gerekiyordu. Bunun bir başka faktörü, geliştiricilerin çoğunlukla altyapı olarak adlandırabileceğiniz şeyler üzerinde çalıştıklarıydı : işletim sistemleri, protokol yığınları, derleyiciler, aygıt sürücüleri, editörler vb. .

Günümüzde, çok çekirdekli işlemciler ve Gigabytes bellek ile inanılmaz bir HW'ye sahip olmamız bile temel bir dizüstü bilgisayarda (heck, hatta cep telefonunda) şımarık. Bu, doğal olarak, birçok durumda performansın - dolayısıyla algoritmanın - temel sorun olmaktan çıktığı anlamına gelir ve hızlı bir çözüm sunmaktan daha hızlı bir çözüm sağlamak daha önemlidir. OTOH, sorunları çözmemize ve aynı zamanda çok sayıda algoritmayı kapsüllememize yardımcı olan çok sayıda çerçeveye sahibiz . Bu yüzden algoritmalar hakkında düşünmüyor olsak bile, arka planda birçoğunu kullanıyor olabiliriz.

Ancak, hala performansın önemli olduğu alanlar var. Bu alanlarda hala kod yazmadan önce algoritmalarınız hakkında çok şey düşünmeniz gerekir. Bunun nedeni, algoritmanın tasarımın merkezi olması ve çevresindeki koddaki birçok veri yapısını ve ilişkisini belirlemesidir. Ve algoritmanızın iyi ölçeklenmediğini çok geç fark ederseniz (örneğin O (n ³ ), bu yüzden 10 öğe üzerinde test ettiğinizde güzel ve hızlı görünüyordu, ancak gerçek hayatta milyonlarca olacak), çok üretim kodunda değiştirmek zor, hata eğilimli ve zaman alıcı. Ve temel algoritma iş için uygun değilse mikro optimizasyonlar size yardımcı olmaz.

Sadece bir şeye dikkat çekmek için:

Bir algoritmanın kendisi probleminizin genel adım adım bir çözümüdür. Yani, sorunu çözdüyseniz, aslında bir algoritma kullandınız.

Buradaki en önemli nokta problemi şu ya da bu şekilde çözmek için algoritmalar kullanmanızdır. Çoğu zaman kodlamaya geçmeden önce probleminizi düşünmek daha iyidir - bu aşamaya genellikle tasarım denir. Ancak, bunu ne kadar ve hangi şekilde yapacaksınız size bağlı.

Ayrıca, algoritma kavramını akış şemalarıyla karıştırmamalısınız (bunun burada olduğundan şüpheleniyorum). Akış şemaları, bir algoritmayı göstermek için eski günlerde kullanılabilen ve kullanılabilen sadece bir grafik gösterimdir. Bugünlerde kullanımdan kaldırıldı.

DÜZENLE:

Gerçekten bir algoritmayı temsil etmenin birçok yolu vardır ve programlama dili kodunun kendisi bunlardan biridir. Bununla birlikte, çoğu zaman tüm sorunu bir kerede çözmemek çok daha iyi veya daha kolaydır, ancak sadece bir taslak ve daha sonra boşlukları doldurun.

• Benim kişisel favori burada sözde kod ve sadece söz konusu algoritmanın genel soyut taslak kapsayacak şekilde - bu detayların içine almak için saçma pseudocode en neyin gerçek kod içindir ki.

• Ancak gerçek kod anahat için kullanılabilir. Örneğin, TDD çalışanları algoritmayı kodladıkları gibi tasarlamayı severler ve hepsini bir kerede çözemedikleri için, gerçek kodda program yürütmenin bir taslağını tasarlarlar ve sahte nesneler (veya işlevler, yöntemler kullanırlar.) .) daha sonra doldurulacak boşluklar olarak.

• UML Etkinlik diyagramları , polimorfizm ve çoklu iş parçacığı gibi yeni şeyler için ek gösterim ile eski stil akış şemalarının modern bir enkarnasyonu gibi görünmektedir. Bunun ne kadar yararlı olduğunu söyleyemem, çünkü onları çok fazla kullanmadım - sadece bütünlük için bahsediyorum.

• Ayrıca, algoritmanızı durumlar arasında geçiş yapmaya dayandırıyorsanız, bir durum diyagramı oldukça yararlıdır.

• Genel olarak, fikri belirli bir algoritmanın arkasına çizmeniz gereken herhangi bir yol gitmek için iyi bir yoldur.

İyi bir benzetme, pişirmeye başlamadan önce bir tarif bilmeniz gerektiğidir. Tamam, gittikçe ince ayar yapabilirsiniz, ancak başlamadan önce ne yapmak istediğinizi bilmeniz gerekir. Bir kuzu yahnisi yapmak istersem, bir somun ekmek yapmaktan çok farklı şeyler yapacağım.

Kod algoritmaları uygular. Algoritmayı tasarlamadan kod yazmaya çalışmak, duvarlar inşa edilmeden önce bir evi boyamaya çalışmak gibidir. Algoritmalar, programlamanın başlangıcından bu yana bir "ZORUNLULUK" olmuştur.

Dilinizde akıcı olmak, kaliteyi ve verimliliği artırmaya yardımcı olur. Ve küçük algoritmik problemleri çözmek, aynı MVC şeylerini 100 kez tekrar etmekten çok daha yararlıdır.
Rağmen akıcılık elde etmek için başka yollar var.

Modern programlama alanında algoritma bir zorunluluk haline gelecek mi?
Bazı 'php ninja' yazma 'serin codez' sürece zaten bir 'zorunluluk'. Tüm 'en iyi' şirketler (Google, Amazon, vb.) Röportajda algoritmik deneyiminizi test ediyor ve hiçbir sebepten ötürü yapmayacaklarını hayal ediyorum.

Ancak orijinal noktaya dönersek, geliştirmek istiyorsanız sürekli kendinize meydan okumalısınız. Ve normal işler (diğer adıyla "şimdi 100 daha fazla nesne için CRUD yöneticileri yazın") her zaman iyi bir zorluk sağlamaz, algoritmalar bunu telafi eder.

Kodlamaya başlamadan önce en azından bir algoritma fikrine ihtiyacınız olduğunu söyleyebilirim. Veri yapılarına dayalı kodlama yaparken muhtemelen fikrinizi gözden geçireceksiniz.

Daha sonra, profil oluşturma o alanda bir performans sorunu olduğunu düşündürüyorsa kodu yeniden gözden geçirebilirsiniz.

Bunun nedeni, yanlış kodu yazmadan önce hataları düzeltmenin daha hızlı olmasıdır.

Daha açık bir şekilde, farklı programcılar arasında rutin olarak ölçülen 10 ila 1 verimlilik farklılıkları vardır. 10 kat verimlilik düzeyinde olan programcılara baktığınızda, zamanlarının en küçük kısmını gerçekten kodlayarak geçirirler . Kod yazma zamanı darboğaz olmamalıdır. Bunun yerine, gereksinimlerinin düz, planlama, test vb. Olduğundan emin olmak için zamanlarının büyük bir kısmını harcarlar.

Tersine, bir duraklama olmadan kodlamaya dalış yapan programcılara baktığınızda, kaçınılmaz olarak, tamamen öngörülebilir sorunlarla karşılaştıklarından kodu tekrar tekrar yazmak zorunda kalırlar ve nihai sonuç daha az bakım yapılabilir ve daha hatalıdır. (Bu arada yazılım geliştirme için harcanan paranın ortalama% 80'inin bakım aşamasında olduğunu biliyor muydunuz?

Genellikle algoritmalar ve veri yapıları önce kodlanır, sonra kodlanır. Ancak, programlama alanına çok bağlıdır. Bir çok uygulamalı matematik türü şeyler yapıyordum ve o zamanlar yaygın olan şelale modeline gerçekten baktım. Bunun nedeni düşük ila orta seviye algoritmaların nadiren alınabilmesidir. Yazılmamış alt sistemlerin varlığı etrafında büyük bir yapı tasarlayın, daha sonra oyunun sonlarında bu önemli alt sistemlerden birinin matematiğinin işe yaramadığını (kararsız ya da her neyse) keşfedin. Bu yüzden her zaman önce en zorlu alt sistemleri düşünmüştüm ve şüphe için herhangi bir neden varsa, bunları önce yazdım ve birim test ettim. Ancak, bazı sorunlu alanlar için çok fazla planlama yapmadan ilerleyebilirsiniz.

Bölümler halinde bir algoritma tasarlayın, ardından bu bölümleri bölün ve her birini ayrı ayrı kodlayın. Bu şekilde her iki bakış açısını da karıştırabilirsiniz:

1. Algorthm'ü çalıştırmak için dil yeteneklerinizi kullanın
2. Koddan önce düşünmeye çalışın, böylece fikriniz dil ile birleşmez (bir gün algoritmanızı başka bir dile taşımanız gerekir ve spagetthi'de bitirirsiniz)

Benim için hemen hemen tüm kod. Bence bu en verimli programcılar için geçerli. Metin yazdığım kadar kolay kod yazabilirim.

Mümkün olduğunca yürütülebilir gereksinimleri (kod) gibi gereksinimleri yakalamaya çalışın. Tasarım sadece üst düzey kodlamadır. Tasarımı hedef dilde yakalamak, başka bir biçimde yakalamak ve sonra çevirmekten daha hızlı ve daha hassastır.

Çoğu kullanıcının metin gereksinimlerini etkili bir şekilde gözden geçiremediğini tespit ettim. Sıralı kullanım durumlarında sorun çıkarmazlar, ancak kullanım durumları kullanıcı arayüzünün her yönünü yakalayamaz. Şimdiye kadar en iyisi, uygulamada bir ilk kesim yapmak, kullanıcıların denemesine, yorumlarını almasına ve kodu buna göre değiştirmesine izin vermektir.

Oturup kodlamaya başladığınızda, "tasarlanmış" olsun ya da olmasın, bir algoritmanız var demektir.

Oturup tam bir algoritma olmadan kodlamaya başlarsanız, aşağıdakilerden birini yaparsınız:

1) tuşları rastgele ezme. Bu muhtemelen bir derleyici hatası üretecektir

2) muhtemelen yapmak istediğiniz şey dışında bir şey yapan derlenebilir kod yazma

3) sorunun küçük bölümlerini çözmek için kod yazmak ve toplayıcı bir şekilde ilerlerken üzerine inşa etmek, ama gerçekten ileriyi düşünmemek - sonuçta sorun çözüldü - ancak kod çok verimli bir şekilde değil ve yol boyunca geri gitme ve zaman kaybetme olasılığı

Bu yüzden insanlar genellikle kafalarında bir algoritma ile program yaparlar. Kağıt üzerinde veya başka bir ortamda etli veya mantıksal olabilir.

Özellikle programcı olarak ilk günlerinizde, klavyeden uzak bir soruna yönelik saldırınızı düşünmek iyi bir disiplin olabilir. Diğer cevapların da belirttiği gibi, daha deneyimli hale geldikçe, "anında" daha yönetilebilir problem yığınlarını kodlamada daha iyi olabilirsiniz. Bununla birlikte, zor veya büyük problemler için, klavyeden uzakta düşünmek ve tasarlamak yararlıdır: kodla uğraşırken, dilin yapıları ve en yakın görevdeki sorun. Bir kalem ve kağıtla ilgili sorunu düşünürken, sizi kodun dil yönünden daha fazla serbest bırakır ve daha soyut bir düzeyde düşünmenizi sağlar.

Yazılım yapımına temelde değerli başka bir şeyin yapımından bakmayı bırakmalısınız. O değil. Yani, her şey gibi, her ne kadar özlü olsa da, iyi düşünülmüş bir plan veya tasarıma her zaman ihtiyaç vardır.

Uygun bir algoritma gerçekten bir programın kalitesini ve sonuçta verimliliğini artırmaya yardımcı olur mu?

Uygun bir bina planı / şemaları kaliteli bir evin verimli bir şekilde inşa edilmesine yardımcı olur mu?

Algoritmasız kaliteli bir program hazırlayabilir miyiz?

Uygun bir bina planı olmadan verimli bir şekilde kaliteli bir ev inşa edebilir misiniz? Gereğince Sonsuz Maymun Teoremi , olasılıksal, sonsuza rastgele yazarak evet (sadece bir milyondan olarak maymunlar sonunda Shakespeare'in bütün eserlerini yazacaktır.

Modern programlamada uygun bir algoritma şart mı?

Bir kod maymun olmak istemiyorsanız ve bok gibi görünen ve çalışan bir yazılım sunmadığınızdan emin olmak istiyorsanız, evet, bu bir zorunluluktur. Kurtarmak zorunda olduğum her proje (kod umatainable bok gibi göründüğü için) değişmez bir şekilde bu soruya olumsuz bir cevapla başladı.

Aslında, modern programlama kovboy programlama yazılım mühendisi uzak bir hareket oldu nerede bir tür planlama gerekirse.

Emrinizde bir algoritma ve veri yapıları kütüphanesi olsa bile (.ie. C ++ veya Java koleksiyon kütüphanesinde artırın), bu öğelerin onu uygun şekilde kullanmak ve makul, daha yüksek seviye algoritmaları.

Daha iyi değil. Hiçbir şeyi "tasarlamamak" daha iyidir. Bu program yazmayan insanlar içindir. Bilirsiniz, sorunun gerçek deneyimi olan insanlar elinizin altında. Eğer bir matematikçi, mühendis veya bir lojistikçiyseniz, tamam, başka bir yerde süreç üzerinde çalışmanız gerekir. Ancak bu 'programlama' değildir.

Önce bir tür test ve kıyaslama yapın.

Sonra bir şey, herhangi bir şey yazın. Refactor-rewrite -loop'u, zamanınız bitene veya artık düzelmeyene kadar yapın.

Birçoğu, bir bilgisayarda bir şey yapmadan bir insanın bilgisayarla bir şeyler yapabileceğini düşünüyor olsa da, bunun en yaygın efsanelerden biri olduğunu düşünüyorum. Mimarlık astronotizmleri.

Ayrıca, yazılmadan önce algo'yu optimize edemezsin.

IOW, "metale yakın dur".