我最近開始作爲一名開發人員工作，並在一位更高級的開發人員的幫助下工作，這位開發人員正在監督/指導我。迭代開發和重構代碼的真正含義
很多事情，他建議只是不正確。例如，他告訴我只是以程序的方式編寫我的代碼，而忽略了它的書寫或其整體設計以及如何使其工作。然後迭代地，它會隨着時間的推移而變得更好。
這讓我感到很不自在，因爲在編碼之前花時間真正正確地思考解決方案和實際問題，我覺得通過這種方式進行編碼和編碼，最終會花費更多的時間。不幸的是，我並沒有處於能夠通過第一次編寫完美代碼立即解決問題的階段。
此外，他不喜歡記錄代碼，相信它應該爲自己說話。他認爲每種方法的頂部的簡短評論就足夠了。這又似乎對我來說很直觀。
總而言之，我覺得我現在正在編寫真正的hacky代碼，以便能夠啓動並運行。他是否正確，並且這是整個行業的事情嗎？
而且，他皺起眉頭在記錄代碼， beliveing它應該 自己說話。
這幾乎是我需要閱讀的所有內容。這個人真的不知道編寫可維護代碼需要什麼。
就這樣說，這個人顯然是你的導師/主管，所以你不能只說「嘿，那很愚蠢」，你必須巧妙地去做。
但是沒有記錄代碼，因爲它「應該爲自己說話」是災難的祕訣。你一定要注意寫清楚，有效和高效的代碼。 從現在起6個月，做一些事情總比做一些你不會理解的事情更好。如果你不明白，那麼其他人也不會有機會。
我想你應該跟他們的主管談談並解釋情況。
隨着中說，有時有原因走捷徑，如果時間軸偏緊，報價傑米Jawinski，誰在Netscape中工作，
「我們要出貨 最高質量的產品，我們可以在 3月31日「
所以你必須找到平衡。但總體而言，在代碼編寫有益的意見並沒有採取更多的時間，當然不足以顯著影響項目時間表，我喜歡什麼Donald Knuth說：
...當你寫一個程序，認爲它主要是作爲文學作品的 。 你正試圖寫出一些人類將要讀的東西。不要 認爲它主要是作爲一個 計算機將要遵循。更 有效的，你是在讓你 程序可讀性強，更有效 這將是：今天 你會明白，你下週理解， 和你的繼任者誰是要 維護和修改它會明白 吧。
總之，即使時間緊迫，編寫高效，清晰和可維護的代碼也無可替代。
謝謝你，這正是我所做的，並且違背了我在大學教過的所有事情。正如你所說，這也是非常困難的，因爲他們本質上是我的主管。它也是一家小公司，所以很難超越他們的頭腦。我想唯一的方法是真正做我自己的事情，並以他們的方式編寫代碼，我認爲它應該是完美的（在課程的理由之內），雖然這會花費比他想要的東西更長的時間，所以會有一個不變的問題我花了太長時間。 – David 2010-08-08 13:05:29
以正確的方式做事情的問題在於，工具集通常不在那裏，因爲大多數事情都是以一種半開始的方式完成的，旨在讓他們先出門，或者至少秒鐘。除非你正在建造太空穿梭機或者（希望）納米機器人，否則也不會有完美的期望。所以，儘管正確的方法比一般的方法更好，但在實踐中，通常沒有足夠的人關心質量以使其具有實用性。整個unix基礎設施建立在一半以上，（着名）「更糟更好」的理念之上。 – intuited 2010-08-08 13:34:20
不，這不是真的如何通常完成的事情。但有一些考慮因素。
有一種稱爲「測試驅動開發」的開發模式。在這種模式下，您基本上只需編寫儘可能少的代碼即可通過任何測試。隨着需求的變化，您可以編寫新的測試，然後更改代碼以匹配。他可能會更加傾向於這樣的事情。在這種情況下，如果你寫得一手好足夠的測試，不要緊的原代碼是什麼樣子，如果你測試你需要，那麼代碼會永遠做你想做的，即使它是烏七八糟每一個案件。 （順便說一句，爲什麼有些人不喜歡測試驅動開發）。
關於評論的主題，當然評論很重要。但是，註釋並不能代替易於閱讀的代碼，並具有正確命名的變量和函數名稱。過度評論絕對是可能的，並使代碼更難閱讀和理解（因爲其他每行都是像// increment i這樣的評論）。此外，你有更多的評論，他們越大，他們越可能變得過時，並與實際代碼不同步。每個人都會閱讀並說「那不會發生」，但總是這樣。總是有人在「小事情」上進行改變，並且不更新評論，然後在那之後發生大約三次評論就是錯誤的。
還有一件事要考慮。想想這個人可能不會把他告訴你的東西當成一種哲學，而是他只是想幫助你。也許在寫任何東西之前，你花了太長時間來試圖正確地設計你的解決方案，他覺得如果你首先在「論文」上找到一些東西，那麼改進它會比試圖把整個解決方案放在頭上更容易。也許你已經寫了太多評，差評，或者花費太多時間在評論（或者甚至在評論格式化，我已經看到了這一點），他覺得你想通過花時間學到了更多在這個階段你代碼比做出漂亮的評論。
其100％的意見在這裏，但如果你的解決方案是精心設計的，我認爲每個方法的註釋可適量。你應該描述它的作用和原因，但不會詳細說明如何做。除非你的方法非常長（表明設計不好），否則代碼應該解釋自己，即如果你的方法看起來很複雜並且很難理解，也許你應該分解它以便更自然地閱讀。總有例外，但那是我的看法。
我在哪裏工作，代碼似乎有極少數的意見，但如果方法名是真正代表其功能，方法裏面的代碼是乾淨的，我沒有任何問題的理解吧。
可惜我不是在 階段能解決的問題立即 通過編寫代碼的完美 第一次。
有沒有這樣的事情作爲一個完美的代碼，它關於知道哪些comproises是可以接受的。
也許你的metor只是想通過說'不要擔心設計'來讓自己的生活變得簡單。或者他可能指的是紅色，綠色，重構（測試驅動開發）的實踐 - 你應該先編寫測試，然後將代碼寫入它的工作點 - 然後才能重構它。
有許多思想流派和許多不同的風格。我已經停止計數，而是嘗試使用實用的方法。
在實現代碼方面，我使用了「讓它工作」，「把它做好」，「讓它快」的原則。但是，我也使用「最簡單的事情，可能工作」（DTSTTCPW）
你寫多少意見取決於許多因素。一派思想的確提倡了好的代碼是自我記錄的論點。另外，我看到了與代碼完全不同步的無盡評論。
另一派思想認爲你需要評論。
我認爲有幾個因素會影響您的選擇。一個是你的個人喜好。然後是你的老闆。在其他情況下，你的團隊。理想情況下，你們將通過共同商定編碼標準來達成共識。最後，如果你始終有選擇：愛它，改變它，或離開它。如果你的老闆（或導師）不能確信或不願意在團隊中尋求共識，選擇1和3可能是唯一的選擇。
我對迭代開發的理解是，您可以以小增量添加功能。在任何特定的時間，您都準備好發貨，並且您的代碼儘可能精簡併且意味着您可以得到它，包括適當的註釋。
我對測試驅動開發（TDD）的理解是，您使用測試來驅動系統的設計。這不僅僅是測試優先編程。
這種方法在過去的10多年裏一直爲我工作，並與我一起工作過的很多團隊。但我相信還有很多其他的選擇，風格，偏好，方法論等同樣出色。這完全取決於！
我同意在一定程度上自我記錄代碼。你應該很好地說明你的變量和方法，而不是依賴評論。例如你更喜歡哪個？
//Get the speed of the train from the database
int value = GetValue();
int trainSpeed = GetTrainSpeedFromDatabase();
如果我決定，我想現在得到一個XML文件中的trainspeed，在第二個例子中，我更可能是很有意義的，而不是離開誤導性評論來更新它。
我要在這裏出現一個肢體，並建議你可能會誤解高級開發人員告訴你的內容。 「讓它工作」和「代碼應該爲自己說話」是相互排斥的。如果我們假設這傢伙不會真的知道自己在做什麼，讓我提供幾個替代的解釋：
很容易迷失在雜草痛苦新的開發者在正確的方式來設計軟件。這是一種分析癱瘓。他可能希望你快速地直接進入代碼，這樣你就可以寫出一些東西，並且很快發現哪些工作不好。這聽起來像是讓你早點失敗並且經常爲了學習而失敗。
許多新開發人員大肆灑出他們的代碼無用的評論。他要求你編寫自我記錄的代碼，而不是冒充和混亂的代碼。如果只允許在函數頂部使用簡短的註釋，則必須使用清晰的變量名稱和簡單明瞭的算法才能使代碼更有意義。這是一件好事。
與導師坐下來澄清他告訴你什麼是沒有錯的。你確實有有效的擔憂。不要猶豫，問他更多的信息。它顯示了自信和爲自己思考的能力。優秀的員工不是心靈麻木的機器人。
+1非常好的答案，我完全同意。 – 2010-08-08 19:52:36
我同意代碼應該爲自己說話而不需要註釋的想法，但是這僅僅是有時（大多數？）不是這種情況 - 如果您還提倡編寫草率的代碼，自己說話，確實很奇怪。但我不是專業人士。 – Phoshi 2010-08-08 12:58:21
我知道37 sig是熱衷於現在得到一些東西的倡導者，在哲學之後改進它。在我看來，這不是一個糟糕的工作方式。 至於評論，以及我的文件儘可能多我想。顯然這有點困難，因爲他是你的導師，所以我建議按照他現在想要的方式去做，直到你離開他的影子。 – studioromeo 2010-08-08 13:14:24
@尼爾：但是你有沒有遇到過（廣泛的）文檔與代碼不匹配的代碼？至少有兩次工作要理解！ – mvds 2010-08-08 13:14:58