Em đã đi làm trong 1 công ty lớn, có tầm cỡ và nhiều khách hàng được hơn 2 năm rồi, dự án lớn nhỏ đều có tham gia. Nhưng trong quá trình làm hầu như mọi người chỉ chăm chăm vào việc là "làm sao dự án không bị deadline, chạy được là ổn rồi". Điều đó khiến cho moi người hâu như chỉ quan tâm vào có việc là "làm xong dự án" mà ít khi chú ý đến quá trình làm việc của mình(đặc biệt là việc viết code), khi viết code mỗi người đưa vào 1 "kiểu viết" khiến cho người mệt nhất sau này là người bảo trì hệ thống, mất thời gian nữa. Thế nên 2 năm rồi em chưa thấy mình tiến triển lên 1 mức nào cả (có lẽ mọi người trong team cũng thế), tuy là có tester rồi quy trình kiểm tra, kiểm thử đầy đủ cả.

Em thiết nghĩ ngay cả ở 1 công ty lớn, có uy tín, thương hiệu như mình đang làm việc đây còn như thế thì thử hỏi ở các công ty khác sẽ như thế nào? họ có như vậy không? nếu cũng như vậy thì thật đáng buồn cho dân coder

Nhưng câu hỏi của em không bàn nhiều tới vấn đề đó vì đó là vấn đề của công ty, như câu hỏi của em ở trên mọi người cùng góp ý và đưa ra định hướng để giúp em nói riêng và giúp những người thực sự đam mê trong việc lập trình, để có định hướng tốt hơn trong khi đã/đang/sắp đi làm. 

- bác conmale: Hiện tại cháu đang tham gia chiến theo hướng bác nói, cháu đang tạm là team leader, nhóm cháu khoảng 7 người, khối lượng công việc cũng rất lớn. Ở công ty cháu cũng có đội ngũ thiết kế riêng, đội tester riêng, đội code riêng. Cháu là dân code nhưng công việc của cháu cũng nặng hơn về thiết kế, lên plan, quản lý time cho đồng đội trong nhóm. Cháu gần như ôm cả từ việc thiết kế đến, code, rồi đến kế hoạch triển khai, tuy nhiên cháu cũng thích code nhất hi hi(cái này do đam mê mà). Qua những lần xong dự án nào đó, cháu đều có bản tổng kết dành cho nhóm, ai làm như thế nào được được ghi chép lại cẩn thận và ngay cả bản thân cũng vậy. Cháu đưa ra câu hỏi trên để "mong muốn" mình có thể thay đổi được cách làm việc của mọi người trong nhóm nói riêng và ...lớn hơn là group nữa. Nhiều lần đề bạt ý kiến cho lãnh đạo về việc xem lại "quy trình" của công ty từ A->Z nhưng hình như chưa được ai quan tâm tới, đặc biệt các lãnh đạo. Hơn nữa trong nhóm cháu có nhiều anh tuổi cũng cao(cao hơn cháu) nên đôi khi nói "anh viết thế này, hay viết thế kia" thì quả là.....hơi khó cho cháu vì nhiều lý do hi hi => (cháu không chê họ về cách viết)có lẽ đây cũng là 1 điểm yếu cho người việt mình chăng? Tất cả cháu cũng chỉ muốn mọi người mà chí ít là những người trong nhóm sẽ phát triển hơn, ngay cả bản thân cháu cũng muốn xông pha nhiều hơn nữa.

Theo mọi người thì em nên làm thế nào ở trường hợp này?

Cháu đang phân vân, có khi chuyển công tác qua nơi khác... lại nghĩ mình đang lùi bước chăng? nhiều câu hỏi quá mà chưa trả lời được. 

=> Anh nói cũng đúng vì đôi khi có dự án đúng là không theo qui trình đã đưa ra do: thời gian, rồi thúc ép từ khách hàng,..., nhưng đa phần là tuân theo đúng qui trình, mặc dù em chưa có tìm hiểu gì nhiều về qui trình nào cả: "quản lý dự án", "phát triển phần mềm","...." (=> điều này khá nguy hiểm, vì thực ra em mới vào được 1 thời gian mà suốt ngày chỉ cắm đầu vào mà làm thôi). Thực trạng này em nghĩ không chỉ riêng công ty em mà còn nhiều công ty khác cũng rơi vào cùng tình trạng. 

- Dự án bạn làm có tuân thủ đầy thủ qui trình phát triển phần mềm không? Ai triển khai, thực thi và giám sát?
=> Câu trả lời đã có ở ý trả lời trên, em bổ sung thêm là: người triển khai là PM(project manager) và thực thi tất nhiên là các Team rồi, còn giám sát: PM + team leader. 

- Dự án có đề ra và tuân thủ coding standard và convention hay không? Ai là người chịu trách nhiệm review code,...?
=> Chưa chấp hành, đôi khi vì kịp dự án nên chấp nhận bỏ qua điều đó(đây không phải là ý kiến của em), review thì do mọi người trong team! 

- Khách hàng có đặt cụ thể yêu cầu chất lượng sản phẩm, ví dụ performance (tốc độ, khả năng xử lý nhiều dữ liệu...), platform independence, blah blah hay không?
=> Có và cũng không, tuỳ theo loại khách hàng, đối với bên Nhật hay 1 số thị trường nữa(em chưa làm với thì trường khác ngoài Nhật) em thấy cái này được kiểm duyệt gắt gao, có thể nói là "đưa code lên bàn cân để cân" 

- Khách hàng có kiểm tra thiết kế và mã nguồn hay không?
=> Thường là không? chỉ có 2 lần tham gia dự án của Nhật thì em thấy có bàn đến. Còn ở trong nước thì không thấy! 

- Tester có kiểm tra những yêu cầu về chất lượng như trên không?
=> Có khi có yêu cầu / ngược lại thì Không 

- Khi hoàn tất dự án, đã rút ra những bài học và đề bạt lên cấp trên nhưng tại sao họ phớt lờ? Nếu cấp trên không nghe thì hẳn phải có 1 kênh đề xuất khác, lên giám đốc chẳng hạn. Những bài học kinh nghiệm luôn đáng giá cho những dự án tiếp theo.
=> Nhiều việc cần làm trước đã(câu này được nghe vài lần, thôi thì em biết vậy, em nghĩ chắc sếp cũng có kế hoạch cả rồi). 

Bài toán theo kiểu "tui làm cho nó chạy còn chưa xong thời gian đâu mà nghĩ đến việc viết code cho đẹp, chạy được là tốt lắm rồi"
=> Chính suy nghĩ như thế này đã ghóp phần làm xảy ra tình trạng như hiện nay, em nghĩ mỗi thành viên trong nhóm hay trong công ty cần có tinh thần trách nhiệm hơn với công việc của mình. 

" chuyện tuổi tác của thành viên dự án không quá quan trọng "
Các "anh ấy" đã có vợ con, họ phải lo cho gia đình của họ rất nhiều thứ, không lẽ em lại đưa ra những chính kiến của mình rồi bất đồng(mà chắc gì em đã đúng anh nhỉ?), rồi sếp làm khó cho em hoặc các anh ấy thì .... em và các anh ấy sẽ ra sao?(hi hi em thì không sao rồi, nhưng .... tính em hơi lo bò trắng răng) => hơi khó để em đưa ý kiến lên sếp! Nhiều khi em nghĩ code thì cũng chỉ đến ngưỡng 30 tuổi (đối với coder việt nam, đây là ý kiến chủ quan của em), chứ >= 30 "phải đang ở vị trí quản lý" rồi mấy ai còn code nữa. Hi hi vì thực sự cuộc sống em thấy sau khi ra trường trở thành "thực dụng" mất rồi . Tất cả là vì cơm áo gạo tiền, chứ em thấy bên nước ngoài ngũ tuần vẫn code ầm ầm(có chăng họ đủ ăn, đủ mặc? hay đam mê theo đúng nghĩa?)
 

" chuyện tuổi tác của thành viên dự án không quá quan trọng "

Các "anh ấy" đã có vợ con, họ phải lo cho gia đình của họ rất nhiều thứ, không lẽ em lại đưa ra những chính kiến của mình rồi bất đồng(mà chắc gì em đã đúng anh nhỉ?), rồi sếp làm khó cho em hoặc các anh ấy thì .... em và các anh ấy sẽ ra sao?(hi hi em thì không sao rồi, nhưng .... tính em hơi lo bò trắng răng) => hơi khó để em đưa ý kiến lên sếp! Nhiều khi em nghĩ code thì cũng chỉ đến ngưỡng 30 tuổi (đối với coder việt nam, đây là ý kiến chủ quan của em), chứ >= 30 "phải đang ở vị trí quản lý" rồi mấy ai còn code nữa. Hi hi vì thực sự cuộc sống em thấy sau khi ra trường trở thành "thực dụng" mất rồi . Tất cả là vì cơm áo gạo tiền, chứ em thấy bên nước ngoài ngũ tuần vẫn code ầm ầm(có chăng họ đủ ăn, đủ mặc? hay đam mê theo đúng nghĩa?)
 

Còn làm thế nào để code tốt hơn, đúng như a comale nói có lẽ phải học cả thiết kế hướng đối tượng, mô hình UML xem như thế nào thì mới được, có tư duy thì mọi thứ nó vẫn tốt hơn. Đợt tới đang tính học món này. Thấy tiếc khi hồi xưa học OOP không chú tâm lắm .
 

Nói về mặt kỹ thuật, lập trình tốt hơn luôn luôn đòi hỏi planning (chuẩn bị và kế hoạch) mình muốn lập trình cái gì. Đi từ điểm tổng quan đến điểm chi tiết một cách có suy nghĩ. Trong quá trình planning như vậy, nó giúp mình tìm ra những điểm yếu và những điểm chưa hiệu quả trong việc coding và giúp tránh những thiếu sót hoặc những áp dụng chưa đủ sâu vô trong code của mình (dẫn tới tình trạng phải code lại sau này). Thông thường các lập trình viên có thói quen ngồi xuống là gõ và muốn thấy kết quả hiển hiện càng sớm càng tốt. Tư duy này khiến cho lập trình viên luôn luôn có thái độ "code cho chạy trước cái đã" mà bị thiếu hẳn thái độ "code làm sao cho đẹp nhất và hữu hiệu nhất, chạy là chuyện tất nhiên". Nắm vững cú pháp là chuyện cần thiết và nó tuỳ thuộc vào khả năng lĩnh hội của từng cá nhân. Tuy nhiên, sau khi nắm vững cú pháp rồi nhưng vẫn mang nặng tư duy "bạ đâu, code đấy" thì vẫn không thể nào "code tốt hơn".
 

Dân Phần mềm thì code sao cho chương trình chạy đúng trước đã sau đó mới quan tâm đến việc code cho chương trình chạy "nhanh". Dân Khoa học máy tính thì code sao cho chương trình chạy "nhanh" sau đó mới là code cho chương trình chạy đúng[/i]"

- Ky0 -
 

code: code ít nhất mà sinh ra mã bin tối ưu,đỡ tốn công mà chính xác hơn
tốc độ: tuỳ theo yêu cầu ứng dụng, mã chạy lớp nào thì có cách tối ưu của nó
chính xác: thường thì khó nói về độ chính xác, nhưng càng ít lỗi càng tốt 

nếu viết code cho chạy nhanh mà không đúng là không thành cái gì. Nói tóm lại không thể có trường hợp "code chạy nhanh sau đó mới code cho chuơng trình chạy đúng"
đây là câu nói nghe cảm tính quá mức

 

- bác conmale: . Nhiều lần đề bạt ý kiến cho lãnh đạo về việc xem lại "quy trình" của công ty từ A->Z nhưng hình như chưa được ai quan tâm tới, đặc biệt các lãnh đạo. Hơn nữa trong nhóm cháu có nhiều anh tuổi cũng cao(cao hơn cháu) nên đôi khi nói "anh viết thế này, hay viết thế kia" thì quả là.....hơi khó cho cháu vì nhiều lý do hi hi => (cháu không chê họ về cách viết)có lẽ đây cũng là 1 điểm yếu cho người việt mình chăng? Tất cả cháu cũng chỉ muốn mọi người mà chí ít là những người trong nhóm sẽ phát triển hơn, ngay cả bản thân cháu cũng muốn xông pha nhiều hơn nữa.

Theo mọi người thì em nên làm thế nào ở trường hợp này?

Cháu đang phân vân, có khi chuyển công tác qua nơi khác... lại nghĩ mình đang lùi bước chăng? nhiều câu hỏi quá mà chưa trả lời được.