Các kỹ năng người học lập trình cần có (1 người xem)

[ptm0412]

Rất nhiều người muốn học lập trình và muốn có thể tự viết những thủ tục hoặc thậm chí viết hẳn 1 tiện ích hoành tráng với đầy đủ chức năng như 1 phần mềm. Ngoài việc ham học hỏi, chí cầu tiến, sẵn sàng chịu tốn thời gian và tiền bạc cho việc học hỏi nghiên cứu, v.v... thì người học lập trình còn phải có những kỹ năng mà không phải ai cũng có ngay khi học xong.

Học trong sách, học trường lớp, học trên GPE, ... sẽ học được cấu trúc lệnh, các hàm, các công cụ, ... nói chung là học ngôn ngữ lập trình. Chịu khó theo dõi các bài viết của cao thủ VBA sẽ học thêm một số các thủ thuật, các giải pháp từ đơn giản đến phức tạp cho 1 va61nb đề cụ thể nào đó. Dù vậy, khi bắt tay vào việc lập trình ứng dụng cho thực tế của mình, hoặc bắt tay vào giải đáp cho thành viên, không phải ai cũng thành công nếu không có một số kỹ năng.

Những kỹ năng này phải được rèn luyện thường xuyên và cọ xát rất nhiều mới có được. Không loại trừ có những trường hợp có năng khiếu toán học và tiến bộ nhanh, và có cả những trường hợp "nghĩ mãi không ra" do khả năng bản thân kém. Tuy nhiên, việc rèn luyện sẽ nâng cao trình dộ không nhiều thì ít.

Sau đây là một vài kỹ năng cần thiết:

- Kỹ năng tư duy logic
- Kỹ năng khái quát hóa
- Kỹ năng tổ chức, quản lý tổng thể và phân công cụ thể.
- Kỹ năng phân tích
- Kỹ năng đánh giá
- Kỹ năng dự phòng
- ...

Tính nết con người cũng ảnh hưởng đến kết quả học lập trình. Người muốn lập trình giỏi phải có đức tính:

- Nhẫn nại
- Cẩn thận, tỷ mỷ
- Kiên trì
- Tính sáng tạo
- Dám chấp nhận bỏ đi làm lại từ đầu
- Biết nhận sai và tiếp thu cái đúng

Tôi xin kể một thí dụ về việc sửa xe:

Một khách hàng đem xe ra tiệm sửa yêu cầu sửa vì không đề nổ máy được, nhưng chỉ cần đạp nhẹ là nổ. Khách hàng không biết gì về xe cộ nên chỉ kể tình trạng xe như thế.

Người thợ sửa xe sẽ phải kiểm tra những gì?

- Máy móc, bugi thì ngon lành vì đạp nhẹ là nổ, nên loại trừ ra không kiểm tra
- Bình ắc quy: Còn tốt không, có giữ điện không, sạc có tích được điện vào không, cọc bình có tiếp xúc tốt không
- Bộ sạc: Còn sinh ra điện không, điện áp đủ không.
- Bộ đề: Cho điện vào có quay không, bánh răng truyền động có kéo máy không
- Tất cả dây điện có tiếp xúc tốt không, có bị đứt ở đâu đó không

Sau khi kiểm tra những cái trên, tất cả đều ngon lành, thậm chí bình ắc quy là đồ mới thay, nhưng vẫn không đề nổ máy được.

Bạn nào có thể kể ra lý do không đề nổ được không?

 

[ptm0412]

Xem ra copy và paste là cách học được một số người ưa chuộng, thậm chí copy paste mà không nhận ra rằng nguồn tra cứu đó có đáng tin hay không, đáng tin bao nhiêu %, và nếu đúng 100% thì đã thực hành được bao nhiêu.

Tôi mở topic này có chủ đề rõ ràng và viết một số vấn đề mà tôi nghĩ là cần thiết. Mọi người có thể bàn, mở rộng thêm, hoặc phản biện, hoặc chỉ ra rằng tôi sai ở điểm a, điểm b. Xin cám ơn.

Về việc sửa xe, đó là 1 thí dụ nói về khả năng phân tích. Nếu phân tích một vấn đề chưa rốt ráo, bỏ qua 1 chi tiết dù rất nhỏ cũng không giải quyết được.

 

[siwtom]

Tôi nhắc lại cho Nghĩa:

Tôi mở topic này có chủ đề rõ ràng và viết một số vấn đề mà tôi nghĩ là cần thiết. Mọi người có thể bàn, mở rộng thêm, hoặc phản biện, hoặc chỉ ra rằng tôi sai ở điểm a, điểm b. Xin cám ơn.

Ngoài ra:
1. Tôi không nói Nghĩa copy paste không có nguồn gốc. Không có nguồn gốc lấy gì copy? Vả lại, bài của Nghĩa ban đầu chỉ ghi chú "sưu tầm", sau đó mới edit lại thêm cái link và nói rằng "tạm dịch". mặc dù tôi vẫn nghi ngờ về khả năng "tạm dịch" đó. Link này, không khác 1 dấu chấm, dấu phẩy: https://www.facebook.com/CungNhauHocLapTrinh/posts/548365215175966
2. Tôi không có ý nhồi nhét
3. Tôi không nói gì cũ hay mới

Xin làm ơn đọc, đọc, và đọc.

Cái chỗ đỏ đỏ tôi không hiểu lắm. Chả nhẽ tôi đã bỏ lỡ một sự kiện ở đâu đó?
Về cái xe thì chắc là xe máy? Vì có "đạp nhẹ" nên tôi nghĩ thế. Nếu xe máy thì tôi không biết gì. Nhưng tôi nghĩ là "đạp nhẹ" có nghĩa là "làm quay". Vậy nếu "đap nhẹ" mà nổ được máy thì chắc là: có xăng, bộ đánh lửa - chia điện hoạt động, tức ác qui có đủ điện, bugi tốt, dây không chập v...v Vậy xem bộ đề ra sao. Nhưng tôi không thạo về xe máy. Trong ô tô thì lúc đó có lẽ phải kiểm tra "điểm đánh lửa", không sớm quá mà cũng không muộn quá. Nhưng mà "đạp nhẹ" đã nổ cơ mà. Trong ô tô không có "đạp nhẹ" nên mới phải kiểm tra.
Chỗ xanh xanh thì có vị quen nói: "Đọc, đọc nữa, đọc mãi" thì phải.

 

[ptm0412]

Cái chỗ đỏ đỏ tôi không hiểu lắm. Chả nhẽ tôi đã bỏ lỡ một sự kiện ở đâu đó?
Về cái xe thì chắc là xe máy? Vì có "đạp nhẹ" nên tôi nghĩ thế. Nếu xe máy thì tôi không biết gì. Nhưng tôi nghĩ là "đạp nhẹ" có nghĩa là "làm quay". Vậy nếu "đap nhẹ" mà nổ được máy thì chắc là: có xăng, bộ đánh lửa - chia điện hoạt động, tức ác qui có đủ điện, bugi tốt, dây không chập v...v Vậy xem bộ đề ra sao. Nhưng tôi không thạo về xe máy. Trong ô tô thì lúc đó có lẽ phải kiểm tra "điểm đánh lửa", không sớm quá mà cũng không muộn quá. Nhưng mà "đạp nhẹ" đã nổ cơ mà. Trong ô tô không có "đạp nhẹ" nên mới phải kiểm tra.
Chỗ xanh xanh thì có vị quen nói: "Đọc, đọc nữa, đọc mãi" thì phải.

Xe gắn máy anh ạ. Xe gắn máy khi đạp cho nổ thì không lấy điện từ nguồn ắc quy, đạp máy tức là tác động bằng giò đạp làm cho máy quay 1 vài vòng, bộ ma nhê tô sinh ra điện kích nổ, khi nổ rồi thì máy tiếp tục quay và kích nổ tiếp.

Còn mấy bài viết dư thừa kia là để trả lời cho một số bài bị tự xóa.

Có một số bài em copy paste và dẫn nguồn, cũng nói lên kỹ năng lập trình, nhưng chủ topic dường như không hài lòng nên em xóa hết những bài đó rồi.

Copy paste vốn không phải là xấu hay dở. Trong 1 topic "mở" để bàn luận, thì hãy nêu ra ý kiến quan điểm của mình: Đồng tình hay không đồng tình, nếu không đồng tình thì phản biện, nếu thiếu sót thì bổ sung. Trong khi phản biện có thể dẫn chứng 1 đoạn nào đó có liên quan (dĩ nhiên là phải copy paste), để chứng minh quan điểm của mình là đúng, chứ sao không?

Còn ở đây, Nghĩa copy paste 1 bài thật dài mà không có 1 tí quan điểm nào của mình, không đồng tình, cũng không phản đối, 1 câu "tôi bổ sung" cũng không có. Thật tình tôi đọc hết không hiểu Nghĩa muốn đóng góp gì cho topic, và theo nhận xét cá nhân, Nghĩa chỉ vừa search google ra để post lên thành bài chứ chưa chắc đã từng đọc để áp dụng hay không áp dụng. Đã vậy lại nói là dịch từ 1 bài tiếng Anh (có kèm link), vô lý quá.

Về câu hỏi sửa xe, liên quan đến kỹ năng phân tích và phương pháp kiểm tra lỗi:

1. Phân tích tất cả nguyên nhân có thể gây ra lỗi. Người thợ đã bỏ sót một cái gì đó, vì những cái nghĩ ra và kiểm tra đều không phải nguyên nhân.

2. Phương pháp kiểm tra:
- Nếu cái bình ắc quy là mới thay, thì khả năng gây lỗi là rất ít, phải kiểm tra sau cùng
- Kiểm tra sạc và đề: Phải tháo ra thử bên ngoài mất thời gian, nên dành để kiểm tra sau
- Kiểm tra tất cả các đường dây, mối nối: Dây đứt, mối nối tuột, sét rỉ là khả năng cao, nên phải kiểm tra đầu tiên.

3. Đáp án: người thợ chưa kiểm tra cái công tắc đề, hoặc dây dẫn từ công tắc chính đến công tắc đề. Đó có thể là nguyên nhân.

Tôi không phải thợ sửa xe, tình huống này có thể là không thật, nhưng ý tôi muốn nhấn mạnh sự quan trọng của kỹ năng phân tích và phương pháp kiểm tra. Một chi tiết nhỏ bị bỏ qua sẽ làm mất nhiều công sức vô ích. Các kỹ năng này rất cần cho người học lập trình.

 

[ptm0412]

Sự phối hợp các kỹ năng.

Mặc dù bài 1 tôi liệt kê ra một số kỹ năng cần thiết, nhưng những kỹ năng này không độc lập với nhau mà có liên quan với nhau. Nghĩa là nếu chỉ có 1 vài kỹ năng này và thiếu những kỹ năng khác thì hiệu quả không cao.

Trong bài 4 ở trên, tôi có nói về việc phân tích kỹ lưỡng kết hợp với phương pháp kiểm tra tốt sẽ tiết kiệm rất nhiều công sức. Nay tôi viết thêm về hai kỹ năng thường phối hợp với nhau, đó là kỹ năng khái quát hóa và kỹ năng dự phòng. Ở đây, tôi không biết dùng tên là dự phòng có chính xác không, nhưng đây lại chính là kỹ năng phân tích nhằm dự phòng tất cả những trường hợp có thể xảy ra.

Khi ta viết một macro để giải quyết một vấn đề cụ thể nào đó, ta không nên chỉ viết cho 1 trường hợp dữ liệu cụ thể. Ta hãy viết một cách khái quát sao cho với dữ liệu bất kỳ ở vị trí bất kỳ, code cũng hoạt động được và đúng. Kể cả khi dữ liệu thay đổi hàng ngày: thêm, bớt, sửa, xóa, ... code cũng phải hoạt động được.

Không những thế ta còn phải dự phòng khá nhiều những trường hợp có thể xảy ra do khách quan và cả cho chủ quan. Chẳng hạn như:
- Control panel setup thế nào cho định dạng ngày, code cũng xử lý được
- Control panel setup thế nào cho dấu thập phân, ta cũng xử lý được
- Người dùng nhập liệu bỏ trống dòng, cột hoặc cấu trúc dữ liệu cho phép bỏ trống ô.
- Dữ liệu mẫu toàn số nguyên, nhưng dự phòng cho cả số thập phân
- Ngày tháng không phải lúc nào cũng theo thứ tự sẵn.
- Người dùng đổi tên sheet
- Người dùng chèn thêm cột
- ...

Ngoài ra, nếu một đoạn code dùng để thực thi 1 việc cụ thể nào đó được dùng nhiều lần, ta nên viết thành 1 thủ tục con riêng, để các thủ tục khác khi cần thì gọi ra. Như vậy tức là ta đang dùng kỹ năng tổ chức và quản lý. Để tổ chức và quản lý tốt hơn, ngay từ tên của thủ tục ta cũng đặt sao cho có hình tượng để dễ dùng. Các thủ tục cùng loại, ta lưu trong cùng 1 module, và module đó cũng đặt tên theo sự phân loại này.

Khái quát hơn nữa, nếu các thủ tục tương tự nhau nhưng không giống nhau 100% nên không dùng chung 1 cách máy móc được, ta hãy tìm cách biến thành 1 thủ tục có tham số. Với việc truyền tham số vào thủ tục cho chạy, ta có thể dùng 1 thủ tục cho những vùng dữ liệu khác nhau, cho những yêu cầu khác nhau, ...

Thí dụ như thủ tục advanced filter cho (1): 1 vùng dữ liệu với (2): 1 vùng điều kiện và (3): 1 vùng đích để copy ra. Cho 3 cái này trở thành tham số cho cho 1 thủ tục duy nhất, ta có thể gọi thủ tục ra để thực hiện cho việc advanced filter bao nhiêu lần cho bao nhiêu sheet cũng được.

 

[thanhlanh]

Mặc dù bài 1 tôi liệt kê ra một số kỹ năng cần thiết, nhưng những kỹ năng này không độc lập với nhau mà có liên quan với nhau. Nghĩa là nếu chỉ có 1 vài kỹ năng này và thiếu những kỹ năng khác thì hiệu quả không cao.

Trong bài 4 ở trên, tôi có nói về việc phân tích kỹ lưỡng kết hợp với phương pháp kiểm tra tốt sẽ tiết kiệm rất nhiều công sức. Nay tôi viết thêm về hai kỹ năng thường phối hợp với nhau, đó là kỹ năng khái quát hóa và kỹ năng dự phòng. Ở đây, tôi không biết dùng tên là dự phòng có chính xác không, nhưng đây lại chính là kỹ năng phân tích nhằm dự phòng tất cả những trường hợp có thể xảy ra.

Khi ta viết một macro để giải quyết một vấn đề cụ thể nào đó, ta không nên chỉ viết cho 1 trường hợp dữ liệu cụ thể. Ta hãy viết một cách khái quát sao cho với dữ liệu bất kỳ ở vị trí bất kỳ, code cũng hoạt động được và đúng. Kể cả khi dữ liệu thay đổi hàng ngày: thêm, bớt, sửa, xóa, ... code cũng phải hoạt động được.

Không những thế ta còn phải dự phòng khá nhiều những trường hợp có thể xảy ra do khách quan và cả cho chủ quan. Chẳng hạn như:
- Control panel setup thế nào cho định dạng ngày, code cũng xử lý được
- Control panel setup thế nào cho dấu thập phân, ta cũng xử lý được
- Người dùng nhập liệu bỏ trống dòng, cột hoặc cấu trúc dữ liệu cho phép bỏ trống ô.
- Người dùng đổi tên sheet
- Người dùng chèn thêm cột

Ngoài ra, nếu một đoạn code dùng để thực thi 1 việc cụ thể nào đó được dùng nhiều lần, ta nên viết thành 1 thủ tục con riêng, để các thủ tục khác khi cần thì gọi ra. Như vậy tức là ta đang dùng kỹ năng tổ chức và quản lý. Để tổ chức và quản lý tốt hơn, ngay từ tên của thủ tục ta cũng đặt sao cho có hình tượng để dễ dùng. Các thủ tục cùng loại, ta lưu trong cùng 1 module, và module đó cũng đặt tên theo sự phân loại này.

Khái quát hơn nữa, nếu các thủ tục tương tự nhau nhưng không giống nhau 100% nên không dùng chung 1 cách máy móc được, ta hãy tìm cách biến thành 1 thủ tục có tham số. Với việc truyền tham số vào thủ tục cho chạy, ta có thể dùng 1 thủ tục cho những vùng dữ liệu khác nhau, cho những yêu cầu khác nhau, ...

Thí dụ như thủ tục advanced filter cho (1): 1 vùng dữ liệu với (2): 1 vùng điều kiện và (3): 1 vùng đích để copy ra. Cho 3 cái này trở thành tham số cho cho 1 thủ tục duy nhất, ta có thể gọi thủ tục ra để thực hiện cho việc advanced filter bao nhiêu lần cho bao nhiêu sheet cũng được.

Trong các tình huống dự phòng mà anh đã liệt kê thì trường hợp người dùng chèn thêm cột là "đau đầu" nhất.

 

[SA_DQ]

Viết như thầy Mỹ ở #5 mình thấy cầu toàn quá trong VBA

Trong ngôn ngữ khác, như VB,. . . thì mình đồng í;
Còn trong VBA mà
[Thongbao]
(1) Control panel setup thế nào cho định dạng ngày, code cũng xử lý được
(2) Control panel setup thế nào cho dấu thập phân, ta cũng xử lý được
(3) Người dùng nhập liệu bỏ trống dòng, cột hoặc cấu trúc dữ liệu cho phép bỏ trống ô.
(4) Dữ liệu mẫu toàn số nguyên, nhưng dự phòng cho cả số thập phân
(5) Người dùng đổi tên sheet
(6) Người dùng chèn thêm cột
(7) ...[/thongbao]

(3) Trường hợp này thì mình lại iêu cầu người sử dụng fải biết tối thiểu về câu trúc CSDL

(1), (2), (4) Nêu bẫy lỗi để nhắc người nhập liệu làm đúng theo iêu cầu nào đó tối thiểu; Chắc thầy Mỹ hay chiều học viên lắm nhỉ, Có khi thương quá mà bỏ qua nguyên tắc nào đó đó thầy!

(5) & (6) Nếu ưu ái thì Thầy có thể viết cho hiện hộp thoại cảnh báo bằng Việt ngữ là OK rồi!

Vài lời xen ngang & xin chúc mừng xuân mới!

 

[nhan833767]

bài viết rất hay xin cảm ơn các anh đã chỉ bảo

 

[Lê Duy Thương]

bài viết rất hay xin cảm ơn các anh đã chỉ bảo

sao dạo này em mất hết các kỹ năng học lập trình rồi vậy thầy.

 

[ndu96081631]

- Máy móc, bugi thì ngon lành vì đạp nhẹ là nổ, nên loại trừ ra không kiểm tra
- Bình ắc quy: Còn tốt không, có giữ điện không, sạc có tích được điện vào không, cọc bình có tiếp xúc tốt không
- Bộ sạc: Còn sinh ra điện không, điện áp đủ không.
- Bộ đề: Cho điện vào có quay không, bánh răng truyền động có kéo máy không
- Tất cả dây điện có tiếp xúc tốt không, có bị đứt ở đâu đó không

Sau khi kiểm tra những cái trên, tất cả đều ngon lành, thậm chí bình ắc quy là đồ mới thay, nhưng vẫn không đề nổ máy được.

Bạn nào có thể kể ra lý do không đề nổ được không?

Còn mỗi cái "núm đề", chẳng thấy ai ngó ngàng gì đến hén
???

 

[anhdepjai]

Theo tôi thiếu mất việc kiểm tra cái nút đề nó có tiếp điện hay không nữa. Dây dẫn còn OK hay chuột gặm thì cũng không đề được

 

[siwtom]

Theo tôi thiếu mất việc kiểm tra cái nút đề nó có tiếp điện hay không nữa. Dây dẫn còn OK hay chuột gặm thì cũng không đề được

Nói đến bộ đề thì nên hiểu là toàn bộ một mạch kín nào đó gồm có dây, công tắc, và "cục gì đó" chứ không chỉ đơn thuần là mỗi "cục gì đó".

 

[nghiaphuc]

Trong các tình huống dự phòng mà anh đã liệt kê thì trường hợp người dùng chèn thêm cột là "đau đầu" nhất.

Về vấn đề này thì chính em cũng đang "điên đầu" (chứ không chỉ đơn giản là "đau đầu") vì cái vụ chèn thêm một cột đây. Lúc bắt tay vào xây dựng chương trình, em đã không tính đến việc xuất hiện của một cột thông tin, và trong quá trình sử dụng thì mới thấy việc có cột thông tin này là cần thiết. Vậy thì bây giờ phải làm thế nào? Thêm cột này vào tận cùng bên phải của bảng đã có hay chèn vào vị trí giữa bảng?! Hướng thứ nhất thì dễ nhưng "ngố" quá vì thông tin này có liên quan trực tiếp đến một thông tin đã có trong bảng ban đầu, nếu để "anh ở đầu sông, em cuối sông" thì kỳ cục quá. Còn hướng thứ hai thì hợp lý hơn nhưng chấp nhận đi theo hướng này đồng nghĩa với việc em phải rà soát, thậm chí xây dựng lại "một rừng code" đã viết trong thời gian khoảng nửa năm!

Chỉ một ví dụ đơn giản đó cũng đủ để cho thấy tầm quan trọng của việc phân tích bài toán trước khi bắt tay vào việc đưa ra lời giải chi tiết cho nó. Nó cũng giống như Quy tắc 80/20 đã được đề cập trong loạt bài Những "tuyệt chiêu" trong Excel, và em thấy trong các kỹ năng được thầy Mỹ đưa ra ở đầu topic thì các kỹ năng phân tích và dự phòng là hết sức quan trọng mà không phải ai cũng có được.

 

[be_09]

Trong ví dụ về việc sửa xe có 1 chi tiết nhỏ mà chưa ai đề cập đến là 2 cục than trong bộ đề, nếu nó mòn quá thì sức đề sẽ kém vì vậy dù cho bộ đề có hoạt động tốt nhưng tia lửa điện phóng ra yếu và không đều đặn dẫn đến đề không nổ máy được.

Liên quan đến vấn đề lập trình VBA, đó là Comment trong Code, không có nó thì Code vẫn chạy bình thường, nhưng về sau này khi bị lỗi ta muốn đọc và kiểm tra lại Code để sửa thì đôi khi mất rất nhiều thời gian và công sức, để khắc phục vấn đề này thì mỗi đoạn Code ta cho nó 1 Comment để giải thích tác dụng của đoạn Code đó thì sẽ thuận tiện rất nhiều những vấn đề sau này.

 

[SA_DQ]

Một CSDL không thể là bất di bất dịch, nó sẽ f át triển. . . .

Nhớ khi xưa mình xây dựng CSDL về nhân sự cho CQ; Khi chưa có BHXH & BHYT thì CSDL đương nhiên sẽ là:

[thongbao]
[STT], [MaNV], [HoDem], [GTính], [NgaySinh]
Rồi sau đó tiếp đến fần dùng để tính lương, như [NgayVô], [HSL], [Mức lương], [BacLuong]
Cuối sẽ là [Trình độ học vấn], [TĐChínhTrị], [NgàyĐảng], [Ngày Đoàn] . . . [/thongbao]

Đùng 1 cái, ông NNc ra sắc lệnh về BHXH, BHYT

Vậy nếu thêm vô sau cùng thì hơi vô duyên, nên fải tính cách xen ngang.

Nhưng để xen ngang được thì khi xây dựng CSDL ta xài tên trường 1 cách mạch lạc là chuyện tất iếu, Khi viết code cũng rành mạch với fương châm là nhìn vô code sẽ đoán ngay là mình viết (chứ không ai khác) & có thể là viết lúc nào, ở đâu nữa kia.

Đã vậy thì sửa lại cấu trúc CSDL cũng không đến nổi nào cam go!
Fương châm là đừng tự huyễn hoặc mình sau này!

Vài lời từ kinh nghiệm bản thân, mong các bạn xem như là 1 tham khảo lúc rỗi!

 

[ptm0412]

Cái núm đề của ndu, cái nút đề của anhdepjai chính là cái công tắc đề mà tôi nhắc đến trong bài 4.

Nói đến bộ đề thì nên hiểu là toàn bộ một mạch kín nào đó gồm có dây, công tắc, và "cục gì đó" chứ không chỉ đơn thuần là mỗi "cục gì đó".

Bài 1 tôi có nói kiểm tra bộ đề, thực sự tôi chỉ nói đến cục đề thôi anh ạ, có lẽ tôi nói chưa đủ chính xác, tôi xin lỗi. Vì cái công tắc đề cũng nằm trong "mạch kín" của bộ đề, nhưng nó lại nằm trên tay lái, nhấn như nhấn nút commandbutton, nên tôi tách ra. Kiểm tra "bộ đề" (chỉ là cái cục đề), nên chỉ kiểm tra có quay không, có truyền động được vào máy không.

Xin nói thêm, đây chỉ là 1 thí dụ về kỹ năng phân tích chứ không phải đơn thuần là sửa xe. Mọi người bàn ở đây chắc cũng bàn về kỹ năng phân tích và thử tự phân tích vào cái thí dụ, chứ không phải học sửa xe hoặc biết sửa xe; không như 1 kẻ kia, không biết gì mà phát ngôn bửa bãi.

 

[ptm0412]

Còn hướng thứ hai thì hợp lý hơn nhưng chấp nhận đi theo hướng này đồng nghĩa với việc em phải rà soát, thậm chí xây dựng lại "một rừng code" đã viết trong thời gian khoảng nửa năm!

Chính vì để code thành 1 đám rừng, nên mới gây khó khăn sau này. Đây là lúc ta cần đến kỹ năng tổ chức và quản lý. Những thủ tục chia nhỏ ra, lưu trữ theo loại, tên thủ tục tượng hình tượng thanh, ... Và biết đâu, những thủ tục có tham số lại là hữu ích trong trường hợp (lỡ viết mà không dự phòng) này.

Ở bài trên, chị HYen17 có nói nên nhắc nhở khi người dùng tự ý thay đổi cấu trúc dữ liệu trong đó có việc chèn cột. Theo tôi, sẽ có vài biện pháp:
- Yêu cầu người dùng không thay đổi tên trường dữ liệu, và dùng tên trường là 1 phần của việc định vị. Nếu code dùng ADO thì thậm chí chèn cũng chẳng sao. Chỉ quan tâm đến số thứ tự cột khi dùng mảng và xử lý trên mảng mà thôi.
- Tên trường có thể gắn với 1 chỉ số và chỉ số này có thể tìm ra dù cho chèn cột hay đảo thứ tự cột cách nào đi nữa.

Nhắc đến bài #7 của HYen, về việc set định dạng ngày và dấu thập phân trong control panel, chỉ cần quan tâm đến nó khi làm việc trên form. Làm việc trên sheet và đưa vào mảng hay xử lý bằng cách khác thì số cứ là số, ngày cứ là ngày, VBA hiểu tuốt. Làm việc trên form thì đôi khi phải định dạng trên textbox cho thành số theo con mắt người dùng, có khi ngược với control panel. Mà định dạng textbox thì nó cứ là text, chứ chẳng phải số hay ngày tháng gì, dùng hàm chuyển đổi không khéo sẽ bị hỏng.

Do đó, nếu là ngày tháng trên form, nên dùng control calendar hoặc Date Picker, nếu là số trên textbox, nên viết 1 hàm chuyển đổi dựa vào việc dấu thập phân của hệ thống là gì.

Trong ví dụ về việc sửa xe có 1 chi tiết nhỏ mà chưa ai đề cập đến là 2 cục than trong bộ đề, nếu nó mòn quá thì sức đề sẽ kém vì vậy dù cho bộ đề có hoạt động tốt nhưng tia lửa điện phóng ra yếu và không đều đặn dẫn đến đề không nổ máy được.

2 cục than mòn thì cục đề không quay hoặc quay yếu không đủ sức kéo máy (đã kiểm tra vụ truyền dộng có kéo máy hay không). Than mòn, đề quay yếu thì không kết luận cục đề tốt được.
Còn tia lửa yếu hay mạnh nằm trong ổ máy, trong đó có cục ma nhê tô, hễ quay là sinh điện đánh lửa cho bugi. Nhưng giả định là lửa tốt, bu gi tốt, máy nổ bình thường.