Re: [討論] 寫程式的追求？
※ 引述《aass5576843 (信長)》之銘言：
: 寫程式不知不覺也一年半了
: 看著公司龐大的老舊程式
: 前人寫的實在雜亂
: 造成了維護上有一定難度
: 最近有心想要嘗試從簡單的地方開始試著重構
: 讓後人可以更好的閱讀程式
: 但想想，整理這個不知道有沒有意義
: 以目前能力重構效能會不會變得更好都是未知數
: 而且還要花大量時間進行測試
: 最終效果可能就是變得 模組化 、好維護、易讀
: 不知道各位前輩 對於程式要求是什麼
: 維護能動就好？
: 偏好clean code的原則？
: 不管環境、工具、寫法如何 只要能快速端出需求就行？
Fred Brooks(1975)
"Show me your flowcharts and conceal your tables, and I shall continue to be
mystified. Show me your tables, and I won't usually need your flowcharts;
they'll be obvious."
Linus Torvalds
"Bad programmers worry about the code. Good programmers worry about data
structures and their relationships."
然後Peter Naur最經典的"Programming as Theory Building"
https://gist.github.com/onlurking/fc5c81d18cfce9ff81bc968a7f342fb1
這篇真的是寶藏，你看懂了，你可以少花很多時間在重構上。
我太晚才了解這道理了，clean code不是不好，但那不是很重要。
最重要的是你需要了解"Theory"，你才能快速修改程式。但我們誤以為clean code可以讓我們快速修改程式。
有"Theory"的程式就會有clean code。有clean code但沒有"theory"還是一團混亂。
--
蛤
有空來讀一下
未看先感謝推薦，晚點丟 GPT 看中文摘要
我怎麼覺得這跟clean code說的是同一件事
所以理論是啥 連gpt都能brief的比這篇更好
團隊不理解才是主因吧？最早原PO的問題是不知道自己處在
什麼環境，自以為的想導入正確的架構，說實話根本不是寫程
式的問題
就是要知道knowhow Y
Peter Naur's 理論是code+doc是無法解釋intent和design。
元po不了解原來的程式，所以他認為龐大，老舊，雜亂。但他
認為他整理的就會容易理解。答案是並不會，因為後續接的人
也不懂元po的intent和design。如果我們不了解這個問題，不
管我們自認為如何clean code，後面接的人如果不了解theory
還是會認為我們寫的code+doc是雜亂，難以維護。
我懂你意思了，thx
邪魔外道
推-domain knowhow
另外，論文我還是習慣
有方程式的
軟工這邊好辛苦
這篇確實有點亂 引用前兩個論點差不多 最後的比較泛
化 個人認為運作機制才是最重要的 怎麼運作決定它數
據結構應該是什麼 由運作反推結構修正結構更好
人更適合看一個面而不是一個點 光有波動與粒子二象性
考慮的是面微小細節無法顧及 考慮的是點各點統合gg
個人認為由面入手更好
推 謝謝推薦文章 覺得有道理
獨立思考果然好重要
元po有個錯誤觀念。認為從code下手，就可以，模組化，好
維修，易讀。但"There is no silver bullet"，Fred Brooks
告誡我們多少年了，可惜我們還是都要犯同樣的錯誤。
32
首Po寫程式不知不覺也一年半了 看著公司龐大的老舊程式 前人寫的實在雜亂 造成了維護上有一定難度 最近有心想要嘗試從簡單的地方開始試著重構4
程式人最重要的追求 應該是創造良好就業環境 本來一個人的工作 變成三個人做 三個人的工作要一個部門做![Re: [討論] 寫程式的追求？](https://i.imgur.com/JAcuIOSb.jpeg "Re: [討論] 寫程式的追求？")
這幾年AI流行 只要你訂好條件，清楚流程，然後約束修改窗口──你清楚你在做什麼 AI幾乎能產出100%正確的程式碼 並且功能清晰，命名合理，還加上一堆註釋 工作流程幾乎就是讓AI生成程式碼，閱讀程式碼，對一些細節做修改4
: : 這幾年AI流行 : 只要你訂好條件，清楚流程，然後約束修改窗口──你清楚你在做什麼 : AI幾乎能產出100%正確的程式碼 : 並且功能清晰，命名合理，還加上一堆註釋11
OK，你說得很有道理，AI 會產測試。 假設你要實作的邏輯不複雜，不罕見， 因此 AI 可以讓你用少少的口語產出字數更多的程式碼及測試好了， 那我就想問，是什麼樣的測試程式？ 姑且不論常常被忽略的非用途面驗證好了，光是用途面的驗證就有很多種。3
你會這樣想只有幾種可能 1.過太爽 2.年輕人認為可以學的到東西 3.單身 基本上重構對公司是沒產值的 不知道你有沒有看過一張圖3
純粹對工作上來說 好抽換，好接手(易閱讀)，好維護(包含升級，測試) 工作，這樣就很夠了阿，大家一起輕輕鬆鬆，工作之餘聚餐風花雪月。 回家，陪老婆，陪女兒不好嗎? 工作又不是人生的全部![Re: [討論] 寫程式的追求？](https://i.imgur.com/KDk3kmpb.jpeg "Re: [討論] 寫程式的追求？")
4
嗯，這三點很因人、因時、因事、因心情而異。 就像李白好還是杜甫好? 金庸好還是古龍好? Chaos 好? --39
好接手，易閱讀… 我想到一個故事 幾年前有個同事，號稱國中時期就開始接案寫代碼 clean code,DDD滾瓜爛熟,對coding極度潔癖 印象比較深的是入職時說了句：我看到不規範的代碼會非常生氣6
我應該也算軟體工程師吧 在電子廠專門用LabVIEW幫實驗室寫自動測試程式。連續寫了十六年。 體驗所謂人生三階段。 看山是山，看山不是山，看山還是山。 第一階段，只追程式會動，能用就好。就算有問題，硬解。遇到什麼不會，就去學什麼。
![Re: [討論] 寫程式的追求？](https://avatars.githubusercontent.com/u/8318854?v=4?s=400 "Re: [討論] 寫程式的追求？")
31
Re: [心得] AmazingTalker/台灣樂天市場 面試心得AmazingTalker CTO 回覆面試心得 (此為 AmazingTalker 人資部門代為轉發) 感謝版友分享在AmazingTalker的面試心得，也感謝各位大大的關心。 在招募過程中，我們一直檢討，並作出相應調整和改善。 當天面試過程不著墨太多。37
[心得] 機械轉軟體工程師經驗分享# 前言 想分享一下當初從進公司幾乎不會寫程式 到現在負責做軟體的porting to Linux的經歷 如果你想轉軟體工程師，最好先進到願意讓你寫程式的公司 但是這不一定辦得到，我底下分享一些自己做的功課![[心得] 機械轉軟體工程師經驗分享](https://cdn.sstatic.net/Sites/stackoverflow/Img/apple-touch-icon@2.png?v=73d79a89bded "[心得] 機械轉軟體工程師經驗分享")
21
Fw: [心得] 機械轉軟體工程師經驗分享作者: wulouise (在線上!=在電腦前) 看板: Tech_Job 標題: [心得] 機械轉軟體工程師經驗分享 時間: Thu Jan 21 20:45:46 2021 # 前言 想分享一下當初從進公司幾乎不會寫程式17
Re: [討論] 重構之前要寫測試 不然不要重構這就是TAD, 一般做法是假設以前人做的是對的 拿以前的output當測資 避免以後的output跟預期結果不同 技術面的錯誤→沒有防呆/沒有釋放資源/overflow/沒有check 這應該不在討論範圍內, 也有客觀標準 行為與邏輯的部分才是有爭議的, 要嘛根本沒規格只有口傳14
[請益] 如何在履歷表達軟體工程的程度? (C語言)最近在思考，如何在履歷中精準描述C語言的程度，並隨手寫了下列幾句 1. Object-oriented programming in C 2. Clean code 3. Modular programming 4. Follow SOLID principle16
Re: [問卦] 寫爛 code 會有自覺嗎大概入行一年到三年時會阿 覺得前人寫的都是糞，自己不能跟他們一樣廢 看一堆design pattern / clean code的書 覺得自己超強，要有理想 然後寫個七八年十年7
Re: [討論]有可能不學coding就可以取得前後端工作?先不用談那些面試會遇到的問題，因為基本上目前的LLM能夠作到的能力是boosting 跟teaching而boosting的基礎使用者要會寫code，而teaching的的結果是使用者會 寫code 不可能無中生有，因為這違反了目前LLM的基本邏輯：文字接龍。所謂的文字接龍 ，前半段提示詞的好壞，決定後半段生成內容的品質，當用戶連怎麼正確描述自己5
Re: [請益] 請問程式架構和資料結構的差異安,小弟最近在複習資料結構 剛好看到了魔術方陣這題練習題 附上c#原始程式碼 你可以學我用物件導向的方式2
[問卦] 看Clean code前要注意什麼？如題 Clean code全名為《Clean Code: A Handbook of Agile Software Craftsmanship》 中文名為《無瑕的程式碼：敏捷軟體開發技巧守則》 因為小弟覺得自己寫的扣像屎一樣，連自己都不想看 所以打算來看看Clean code，來增進程式內功![[問卦] 看Clean code前要注意什麼？](https://i.imgur.com/IZ4hdswb.jpg "[問卦] 看Clean code前要注意什麼？")
![Re: [心得] AmazingTalker/台灣樂天市場 面試心得](https://lh4.googleusercontent.com/tM7r9m2aWuaCBYPLM-y3xCN-n2M0E3SJD5UVxw2aooO0RHNL60y-uBXLH3JavmjNcbY=w1200-h630-p "Re: [心得] AmazingTalker/台灣樂天市場 面試心得")