乙個假期都在和教務系統在一起。這其中的滋味就像是五味瓶。鹹/酸／苦／辣／甜為什麼這麼說呢，聽我一一道來
鹹的開始：第一次接觸教務系統，我是負責教師工作量計算這一部分。一旦涉及到計算必不可少的就是邏輯上很複雜的數**算之類的東西。雖然我們還是在校的學生，但說實話對於教務上的東西我還真的不是很了解。因為不了解，也就意味著對需求的一無所知。
系統剛開始著手，我們的原則很簡單，根據自己對教務系統的了解來擬定需求。快速建模，然後讓我們的專案經理審核。第一次初步建模通過，心中暗喜自己分析的需求竟然通過，誰知.....
酸的難耐：雖然第一次快速建模通過，但心裡隱隱約約的感覺自己對需求的理解有很大偏差。為了不浪費人力資源，我向六期的師兄師姐討了點經。這時候才發現自己理解的需求和學校的真正需求相比差距很大。和師兄交流的過程中，師兄說了很經典的幾句話：要做就做好，不要去湊合。可以集中的把某一部分做好，但絕不能任何一部分作的都很湊合。解釋一下我師兄說這些話的原因，因為我做的那部分是沒有可參考的需求（資料）所以都是憑空自己想的。而且在剛接觸教務系統的時候，有人說我們做的系統是在練手，根本不讓執行。這樣的話多少給自己新增了幾分「想湊合」的想法，不應該啊。。。。
苦的繼續：需求的重新分析模型重建，讓我看到了一點點欣慰。接下來是資料庫的設計。資料庫的設計可以說我沒有參與。都是我們組長全權負責，三正規化/外來鍵關聯/表與表之間的關係等等我都沒有通過這次實踐來驗證。都怪自己不爭氣。。。資料庫設計出來後，我們的資料持久層也伴隨誕生。dal層我們是用ea直接生成的。只需要在向框架裡新增點內容就可以了。工作量是巨大的，技術含量是沒有的，這時候體現出了我們的工作本質（**工）同時也體現出了專案組長的才能（框架設計），通過單元測試我們的dal層一一暫時通過。由於需求的不明確，dal層還有很大的改動空間。
辣的刺激：dal完成後，我們邁向了bll層。到了業務邏輯層，我們組每個人都沒有精力在管彼此的模組了，剩下的只有埋頭苦幹。有了模型，對業務的分析也就有了思路。這時候才發現自己負責的教師工作量的業務很複雜（偶認為）。同時dal層寫的方法也都被推翻重寫了。教師工作量這裡的業務大部分涉及計算和「檢視」，通過對檢視的不斷摸索，現在自己可以熟練建造不同資料庫下的檢視，對檢視的使用也是有了深刻的認識。一句話「檢視是個好東西呀」。標註：因為這裡的業務很複雜，自己在**實現的時候對三層的界限設計的不是很好。
甜的快樂：業務是自己分析的，對系統的認識就更深了一步。到頁面整合的時候（我們的教務系統由原來的c/s公升級到b/s）也就更加順手。一步一步地往前走，最後發現我負責的教師工作量基本功能實現了。但並不是很完善。回想剛開始接手這一模組時的那種恐懼，真的是耐人尋味。也許自己並沒有想象中的那麼差，是自己總在和最優秀的人進行比較，結果你懂得~
總結：通過教務系統的實踐，學會了，第一：自己如何解決問題，不再像原來那樣一旦遇到問題，第一想到的就是找別人幫助。雖然現在偶爾也會需要別人的幫助，但自己的進步還是自己知道的。第二：對業務的認識，感覺業務是需求的細化。需求的明確/模型符合需求，業務也就相對來說很好理解了。不知道這樣說是否正確。一句話，這個暑假，這個教務，讓我學到了很多....
python 爬蟲登陸學校教務系統
好像很多人寫爬蟲，都是從登陸學校教務系統開始的。為什麼？學校教務系統渣啊，都是明文傳輸的，而且是200x年寫的，沒有用到很多現在的技術，所以相對來說容易些。感覺很多學校都是用的清元優軟的這個，我們學校還有驗證碼，稍微高階了一點。整體思路 1 對用firefox httpfox進行抓包，發現驗證碼是在...
爬取學校教務系統學生課表
爬取課表在指令碼的完成下顯得十分簡單 一 在開啟南郵研究生教務 是登入一下，並開啟chrome的審查元素的network發現 登入時請求的url和所提交表單的資料email和assword 二 在開啟課表查詢的頁面是我們發現 有乙個儲存為excel檔案的button，我點開發現 瀏覽器向這個url發...
系統開發 系統規劃
一 系統規劃五個階段 1 專案目標和動機 2 立項價值判斷 3 專案選擇和確定 4 初步調查 5 可行性研究 包括經濟可行性，技術可行性，法律可行性，使用者使用可行性 二 可行性分析八個階段 1 複查系統目標和規模 2 分析現在系統 3 匯出新系統的高層邏輯模型 4 使用者複查 5 提出並評價解決方...