From ptt Tech_job
by darkkiwi
-- 久而久之
有些人養成一種只求快求有的習慣
所有寫法只針對當下的問題去做特殊解
也不去探究到底是為何會引發這樣的問題-- 一堆自以為了不起的"防呆條件式"
在我看來根本就是在補自己之前捅出來的簍子
by shter
-- 對 USER 和 BOSS 來說
USER : 程式執行效率要好 不要有 bug
BOSS : 程式能越快寫出來越好 bug 越少越好
by richliu
-- 你改完的 Code 有經過 Test Team(QA) 驗證嗎
還是自己改完 hi 完了
覺得很好 Bug free
Test Team (QA) 要為你自 hi 的行為再下去測試嗎
-- 等到有一天碰到那種 ASAP 的 Project
連續玩個一年 你就知道什麼叫做有 Code 就好
-- Manager 有沒有定時做 Code Review 的習慣
-- 合理的 Schedule 是 2
RD 希望的 Schedule 是 4實際上的 Schedule 是 1
-- RD 個人的素養.
大家學習的起點都不一樣
對於 Language 的認知也不一樣
-- 你的 code 替公司產生多大產值呢
寫得好好的 code
可能不比那些 sucks 的好到那邊去
by bluezero
-- 畢竟 code 長大到某個程度之後
架構的東西不是說改就可以改的
-- 第一個是 project 初期要由資深工程師及主管討論架構
畫好流程圖後 才開始做 function
第二個是公司有明定寫程式的規範
嚴格要求工程師遵守完成的程式碼起碼要有人 review & prove 才可以上
並要留下修改記錄
-- 以上是理想狀況
實際上很多公司是不吃這套的
-- 工作幾年後
你就會知道怎樣跟會動的垃圾一起生活了
by guest0079
-- 要寫 code 很簡單
要看得懂別人的 code 很難
-- 我覺得 code 是一部歷史
裡面有很多歷史因素藏著前人的心酸你知道你維護的 code
在兩年前發生過必須在三天內調整架講的窘境嗎
-- 怎麼證明自已的程式比較 robust
user 能使用的功能就那幾種
測試過就過了這種程式兜得出來 寫得快比較重要
客戶只知道趕趕趕 證明給誰看
-- 你寫的是綁 device 的程式
這種程式永遠也不會活得比 device 還久
-- 你以為現實世界的程式都像教科書一樣漂亮嗎想跨入更高的境界
你能征服的了真實世界的爛程式嗎
by egnaro123
-- 並非沒法子做
實是做太好沒必要 可以 work 即可-- 公司並不會因為程式 code 寫得很 clear
robust (通常 bug 是很難 reproduce 的)機率低
而馬上將老工程師升副總
by Dungeon
-- 現在的 CODE 已經有八年歷史了
會有很多奇怪的地方 東牆補西牆但希望我進去以後不要亂改
-- 把整個 CODE 重寫
結果出了 BUG 抓不到
而舊人已經走了
也問不到當初為什麼這地方要這樣寫
by jily
-- 咦
這邊怎麼有個 Sleep(0)順手拿掉好了
-- 結果跑出一堆 bug
by ijeCorp
-- 改動本來就是一個耗費成本的工作
沒人願意隨意改變他
by hippopus
-- code review 這件事
本來就是要去做-- 自己說自己寫的程式好太主觀
大家說這 code 寫的好才客觀
-- 但是
現實就是一大堆有的沒的理由不去做 code review