Đào Việt Cường nói:
Dear QDuc,
----------
Theo mình thì học lập trình không phải là chỉ để biết viết code mà là học cách xây dựng các bước xử lý. Vấn đề mình nêu ở bài trên để minh hoạ cho các bạn thấy, chứ không nhất thiết phải liệt kê bài bản như thế, nó phải nằm trong đầu rồi!
Mình có một câu nói mà cảm thấy rất tâm đắc cho lập trình thế này: "Nếu bạn thường hay khát nước, hãy dự phòng cho bạn một ly nước đầy bên cạnh. Nhưng cũng đừng quên chuẩn bị một ly rỗng để phòng khi... không khát". Chúng ta phải luôn luôn đặt các giả định, tìm hiểu biến cố và sự kiện nào có thể dẫn đến một thủ tục không thể thực hiện hoặc thực hiện không thành công. Điều đó quan trọng hơn là nghĩ ngay tới việc viết mã lệnh. Lập trình cũng giống như việc mô phỏng lại cuộc sống mà thôi.
Sở dĩ mình nói những điều trên đây là vì thấy nhiều bạn quá tập trung vào vấn đề không phải cốt lõi của lập trình. Thử hình dung xem, nếu với tư duy như vậy thì phần mềm mà các bạn viết ra sẽ có bao nhiêu lỗi, bao nhiêu lần chỉnh sửa?
Dù có phải bao nhiêu năm đèn sách thì ngay từ đầu các bạn phải tư duy như thế. Và muốn có "một mảnh VBA" khai phá cho riêng mình thì các bạn càng phải cẩn thận: Always careful - Always successful
Great! :cool2:
- Trong giới lập trình có câu: "Chương trình chạy được chưa chắc đã là phần mềm tốt". Còn trong xây dựng thì mọi người đều biết người thợ xây (tương ứng trong lập trình thì đó chính là dân coder đấy) là rất quan trọng.
- Xong nếu không có bản thiết kế với các thiết kế chi tiết về các chiều (views) khác nhau như chiều điện nước, chiều theo mặt cắt ngang, chiều 3D, cùng với thiết kế nguyên vật liệu chi tiết, bản tài dự toán tài chính xây dựng,...) do những nhà kiến trúc sư tạo ra trước thì liệu kết quả của những thợ xây liệu có tốt hay không (trong IT thì tương đương với kiến trúc sư XD chính là dân phân tích thiết kế, hay còn gọi là kiến trúc sư thiết kế PM).
- Và rõ ràng một điều là những nhà làm thiết kế xây dựng muốn thiết kế cái gì thì cũng phải phụ thuộc vào khách hàng, phải phân tích được yêu cầu của khách hàng là cần xây dựng cái gì, nhà biệt thự có bể bới hay ko, v.v... và để làm được chuyện đó thì phải có người phân tích yêu cầu của dự án (tương ứng với trong giới IT thì đó là những nhà phân tích yêu cầu nghiệp vụ với kết quả là các tài liệu như Software Requirement Specification ở các mức khác nhau,...)
-Khi làm xong công trình XD, trước khi bàn giao cho đơn vị chủ quản, người chủ dự án xây dựng phải phân công cho 1 đội kiểm tra lại chất lượng của công trình trước khi bàn giao. (Trong IT thì cái này là do đội Kiểm thử - testers - chương trình thực hiện, bao gồm Unit Test, Integration Test, System Test, v.v... với các phương thức test khác nhau). Sau khi Test xong, khi bàn giao sản phẩm, đơn vị chủ quản (khách hàng) test lại theo các tài liệu yêu cầu nghiệp vụ đã thống nhất từ giai đoạn trên (khi làm hợp đồng là phải thống nhất yêu cầu nghiệp vụ dựa trên các tài liệu phụ lục hợp đồng,...)
- ....
Các phần mềm nhỏ, làm ko bài bản (thường là do chi phí rất cao) nên thường bỏ qua mọi công việc như trên vì "...mấy món đó nó nằm trong đầu tôi hết rồi, chỉ việc code ra thôi". Đây là trường hợp có 1 số thợ xây giỏi tự làm ra những cái nhà/công trình
cỡ tàm tạm mà ko cần tài liệu thiết kế gì cả (chỉ cần phải câu nói của ông chủ là phang luôn áng chừng tổng chi phí và bụp luôn, khỏi thiết kế này, tài liệu nọ...). Còn những công trình lớn (tầm cỡ nhà quốc hội, ERP, Accounting mang tính chất thương mại thực sự,...), rõ ràng là ko thể thiếu ty tỷ các thứ phải làm trước khi thi công công trình xây dựng. Đó là còn chưa xét đến tính làm việc nhóm (nhiều người cùng xây dựng).
Ý nghĩa việc phát triển SP phần mềm là rất gần gũi với công việc trong Xây dựng. Mấy ý ở trên tôi viết vẫn chưa thể hiện hết sự giống nhau đâu, vẫn còn nhiều chuyện để so sánh lắm.
Đơn cử, để viết 1 hàm delete 1 file, có ai bao giờ kiểm tra xem file đó có tồn tại hay chưa? thuộc tính là readonly hay ko? file đó có đang được mở ra bởi 1 ứng dụng khác nào đó hay không? hay là cứ viết luôn là Kill strFileName???
Vì thế, trước khi DO 1 cái gì đó, hãy thử nghĩ xem các trường hợp có thể xảy ra là gì, có trường hợp nào tương tự hay không? Còn cách nào khác để DO cho hiệu quả hơn, chạy nhanh hơn, tiết kiệm hơn,... hay ko? v.v...
Cheers! :bigok:
