X25 程式寫作員的未來(3)──想法的分享

交易的執行流程與使用的商業模組應由資深的SD來分析並依架構來設計，怎麼撰寫與如何使用也會關係到開發人員的運用程度，如果他們不懂就會做不好、做不對。若考慮專案開始時開發人員學多少東西？新進人員要多久才能獨立作業？建立執行架構與設計商業人員為他們準備了多少東西是很關鍵的因素。

身為資訊工作者，在使用別人的函式庫時都知道要看說明文件與範例程式，但是在自己建立架構或撰寫程式時卻有種種的理由敷衍地寫出根本沒用的文件。在維護時而看過幾種不同風格的程式碼，只能就不懂的部分逐一請教原來的作者；有能力足以獨當一面者嚷著不想看別人的程式的，也有人連自己以前寫的程式都不想看而叫別人先看再說的。

有許多資訊人員僅以“使用流行技術來達成客戶需求“作為成長的方向、精進自己的各項技術，卻吝於對其他人清楚地溝通或分享自己產出的成果。抱持著”我會的東西是自己花時間看來的，沒有理由讓別人不勞而獲“的想法固然沒錯，但是在一個團隊裡以這種心態相處到最後就會發現沒有人提升到能與自己討論的程度；只靠一個人的想法無法兼顧各個面向的需要，卻又沒有人能夠讓他領悟問題的所在（因為技術好的人通常會看不起技術差的人），問題一直都會是問題。

工具，有提升開發速度外還能夠呈現設定的範圍的效果，想想使用記事本與IDE撰寫程式的差異便能明白其中奧妙。工具要能存在，它編輯的對象必須是百分之百明確且固定，才能在其上設計出符合其特性的工具。可惜的是我們總喜歡用別人的方便工具，對自己的產出總是以能夠正常執行目標而難以維持規格一致，再加上工具是另外開發與系統運行完全無關的，以至大多數的人無視它的重要性。