在學校裏，通常需要對流水線上寫下的小程序進行流水線處理。有沒有人實際使用流程圖的螺母和螺栓代碼了？
由於圖片的大小，這些流程圖趨向於非常大，並且往往繁瑣繪製。
總是這樣的細節，你本質上是寫代碼。
我使用流程圖/ UML風格的技術來開發更高層次的東西，但是當它到達實際循環時，它看起來像是過度殺傷了什麼。
我經常僞代碼更詳細的算法，但仍然不是超細粒度的點。
這僅僅是在學校的東西如此之小以至於沒有別的什麼東西來流動圖表，所以他們有使用做細節？
真實代碼ifs和whiles的流程圖從未（在30年內）發現有用。
作爲一個討論援助的要求......所以當我們在這裏時，會發生什麼？ ......你如何決定......如果95％以上，你會怎麼做......會有所幫助。用戶的某個親屬在白板上發現這樣的圖表容易談論。
流程圖，否 - Sequence diagrams，是的。我試圖讓他們保持高水平，以便快速將這個想法傳達給某個人。我不會試圖詳細介紹每一個細節。如果它看起來很重要，我可以用另一張圖來補充說明一個邊緣案例。
這是偉大的溝通作爲草圖 - 我認爲這是不對的規範（但會是一個很好的介紹仔細的部分）
+1對於粗略的順序圖。他們非常好，他們有一些直覺，即使是非技術人員也可以理解。爲了獲得更詳細的信息，你可以改爲編寫代碼。 – 2010-06-28 09:24:18
是的，我同意。重點是讓你瞭解流程圖，而不是暗示你應該使用它們來逐行代碼覆蓋。
我不知道爲什麼你甚至會浪費時間用僞代碼，除了演示，老實說，除非它是一些真正的低級編程。
我在流程圖中找不到非常有用的細節。我在一張紙上使用UML風格的技術。在組設置中使用白板。中級的類圖和順序圖對於組織你的想法和傳達你的設計意圖非常有幫助。
有時在白板上描述一個過程，但從不在實際的設計或文檔中。我更多地將它們描述爲「流程圖式」，因爲我並不總是特別關注這些形狀。
說實話，我非常高興我需要陪同流程圖的任務。他們讓我在結構上思考，我缺乏一些東西（也許在某種程度上還缺乏）。
所以，不要急於跳上「我正在玩大鋼琴」的流行，流程圖確實有效。
我從來沒有發現自己處於一種不平凡的邏輯中。在將流程圖中的邏輯放在一張紙上（需要幾分鐘）之後，這一切都不可避免地變得清晰。
我自己不使用它們。但是一個同事每隔一段時間只進行一次節目的同事就會這樣做。對他來說，這是一個非常方便的方式，可以記住他一年前編寫的那個程序的基本功能。他沒有做太多的編程，所以學習序列圖和類似的東西是不值得的。
這也是其他pple幾乎沒有編程將能夠輕鬆讀取圖的類型。在他的位置是一個加號。
我們有一個內部應用程序，它有一些相當複雜的工作流程。流程圖是這部分系統規範的重要組成部分。所以是的，流程圖是用於指定系統的有用工具。他們通常也可以被非技術人員所理解，如果他們是用戶需求的一部分，那麼他們是有用的。不，我通常不會在很低的水平上使用它們，也不會期望系統的一部分只能通過流程圖進行規定或記錄。
TDD是堅果和螺栓代碼的一個很好的選擇，如果你是如此傾向於，並且它帶來很多其他好處。
我們有一個很大的有機增長的應用程序，它只有很少的文檔，所以使用流程圖來記錄應用程序中的組件對於操作的業務方面已經證明非常有用，因爲即使他們不瞭解每件事物是如何組合在一起的。
它們並不是一致的行，而是覆蓋了業務邏輯的所有分支以及隨後的處理和輸出（雖然沒有遵循嚴格的流程圖規則 - 某些塊描述多個進程）。
我真的不是流程圖，除非是向別人解釋一些東西。它很少幫助我的思考過程，但也許我只是很奇怪:) – Thorarin 2009-07-10 20:41:50