<![CDATA[Latest posts for the topic "Như thế nào để có cách viết code tốt hơn?"]]> /hvaonline/posts/list/21.html JForum - http://www.jforum.net Như thế nào để có cách viết code tốt hơn? /hvaonline/posts/list/33821.html#207880 /hvaonline/posts/list/33821.html#207880 GMT Như thế nào để có cách viết code tốt hơn? p/s: Mình thì làm về lập trình C .]]> /hvaonline/posts/list/33821.html#207882 /hvaonline/posts/list/33821.html#207882 GMT Như thế nào để có cách viết code tốt hơn? http://conmale.blogspot.com/2007/07/craftsman-1-opening-disaster.html thấy hay hay.]]> /hvaonline/posts/list/33821.html#207894 /hvaonline/posts/list/33821.html#207894 GMT Như thế nào để có cách viết code tốt hơn?

zidole109 wrote:
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. 
Để code cho tốt hơn thì phải có điều kiện để "challenge" với những gì đã có và tất nhiên phải có điều kiện để thực hiện "challenge" đó. Nếu giữ vai trò "coding" thuần túy và không tham gia vào phần thiết kế và hình thành giải pháp ngay từ đầu thì sẽ không tìm thấy cơ hội để "gia tăng nội công" một cách trọn vẹn được. Có chăng, code có thể lên tay hơn ở khía cạnh gọn nhẹ, ít luộm thuộm hơn nhưng tính "tốt hơn" trong coding gắn liền với cái đẹp của quá trình thiết kế. Nên tìm cách tham dự vào những cuộc họp ở biên độ thiết kế và đừng ngồi yên ở biên độ coding thì sẽ thấy có những cải thiện đáng kể về coding.]]> /hvaonline/posts/list/33821.html#207896 /hvaonline/posts/list/33821.html#207896 GMT Như thế nào để có cách viết code tốt hơn? quanta: em sẽ đọc tài liệu anh gửi và ngẫm dần hi hi vì thời gian em cũng có hạn. - pisco: mình hiểu những điều bạn nói, cách làm việc khoa học rất giúp ích cho bản thân mỗi người, dù là làm ở trong lĩnh vực hay ngành nghề nào đi chăng nữa. Ở nhật chắc hẳn quy trình làm việc của họ chuẩn hơn(note: mình cũng đã làm qua vài dự án với đối tác của Nhật, thích nhất phương pháp làm việc của họ: nghiêm túc, hết mình và rất khoa học... bởi tính tập thể của họ là rất lớn. Mình lên nhiều skill cũng bởi từ khi được tham gia nhiều dự án với nước ngoài, đặc biệt ở thị trường Nhật Bản. - 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.]]> /hvaonline/posts/list/33821.html#207934 /hvaonline/posts/list/33821.html#207934 GMT Như thế nào để có cách viết code tốt hơn? /hvaonline/posts/list/33821.html#207951 /hvaonline/posts/list/33821.html#207951 GMT Như thế nào để có cách viết code tốt hơn? Trường hợp bạn zidole109 đặt ra những vấn đề mà nhiều hãng sản xuất phần mềm hay gặp, đó là Quản lý dự án và quản lý chất lượng. Tuy nhiên tui không nghĩ 1 cty "tầm cỡ" như bạn đang làm lại thiếu những điều này, có thể những dự án bạn làm đặc thù không áp dụng được, hoặc có mà bạn (và quản lý trực tiếp của bạn) không đủ thời gian và khả năng thực thi nó đúng. => 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 - Ước lượng thời gian cho dự án quá chặt hoặc vượt quá khả năng của thành viên? Điều này có thể do bị khách hàng ép, hoặc cty không đủ mạnh để thuyết phục khách hàng, hoặc "lỡ" ước lượng quá ngắn nên phải ép anh em "chạy vắt giò lên cổ". Việc ước lượng thời gian được tính toán khá chặt chẽ, thường là các PM, team leader và sau đó là lãnh đạo duyệt. Nhiều lúc bọn bạn em vẫn thường trêu đùa "tao làm bên out source cũng chẳng vất vả như mày!", em cứ nghĩ về câu nói của nó nhưng cũng chưa có câu trả lời! nguyên nhân là ở đâu? do ước lượng thời gian chưa chuẩn(như anh đã nói)? phân công không hợp lý? thiết kế, phân tích chưa tốt? con người? hay...là qui trình công ty làm việc chưa chuẩn?.... Rồi cũng nản không muốn suy nghĩ tiếp nữa(tính lười bắt đầu trỗi dậy, việc đó để lãnh đạo lo => tinh thần cống hiến có vấn đề :) ) - 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?) ]]> /hvaonline/posts/list/33821.html#207952 /hvaonline/posts/list/33821.html#207952 GMT Như thế nào để có cách viết code tốt hơn?

zidole109 wrote:
- 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. 
---> Việc đưa ra câu hỏi với mong muốn nâng cao và phát triển là việc quan trọng và cần thiết. Tất nhiên khi đã trăn trở đến điểm này thì bồ đã ít nhiều hình thành những lý do và những điểm cần nâng cao + phát triển. Điều quan trọng nhất là phải sắp xếp chúng lại cho có lớp lang và chuẩn bị những lý do cho hữu lý và thuyết phục. ----> Đối với môi trường "corporate" hoặc một ban ngành có kích thước nào đó, việc đề đạt cho sự thay đổi nào đó là việc không đơn giản tí nào. Nó luôn luôn gắn liền với giá trị kinh tế (được quy đổi bằng cách nào đó). Bởi thế, việc đề bạt ý kiến nếu không cụ thể và tỉnh táo mà mang nặng cảm tính hoặc không có những lập luận bảo vệ và trực tiếp liên quan đến giá trị kinh tế thì khó mà tiến hành được. Giá trị kinh tế trườu tượng nhất đối với đám kỹ thuật là: cắt ngắn thời gian nhưng hiệu quả công việc vẫn không thay đổi (hoặc cải thiện hơn thì càng tốt). ----> Đây là kỹ năng giao tiếp và thuyết phục. Có những cách nói làm cho người đối diện cảm thấy không bị khó chịu (như dạng bị "dạy đời") khiến cho họ vẫn vui vẻ tiếp nhận. Điều quan trọng cho những người làm việc trong môi trường kỹ thuật là phải chính xác và trực tiếp vào vấn đề. Tuy vậy, điều chỉnh lại vài ngôn từ cho "êm tai" hơn thì vẫn có giá trị thuyết phục hơn. Ví dụ: "em thấy anh làm như thế này là sai" ---> hơi khó nghe và khó được tiếp nhận (ngoại trừ đối tượng rất tự tin và cởi mở). Thay vào đó, "em thấy có vài điều chúng ta có thể bàn sâu hơn để cải thiện" thì dễ chịu hơn vì "chúng ta" là cùng phe nhau. Những kỹ năng này phải đi xuyên qua giao tiếp và đụng chạm lâu dài thì mới rèn luyện mà có được.]]> /hvaonline/posts/list/33821.html#207960 /hvaonline/posts/list/33821.html#207960 GMT Như thế nào để có cách viết code tốt hơn? => 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.  ==> Theo những ý bạn đề cập bên dưới thì tuy rằng nhìn vào thấy có qui trình nhưng rõ ràng mang nhiều tính hình thức, nó không được thực thi đúng mức và nghiêm túc. Điều này dần sẽ dẫn đến nhiều hiệu ứng tiêu cực, về phía khách hàng sẽ nhận ra cty bạn đang làm kiểu chụp giựt và không có gì đảm bảo chất lượng, hình ảnh cty sẽ giảm theo thời gian. Về mặt con người, nhân viên sẽ dần mệt mỏi và ra đi là lẽ đương nhiên.
- 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. 
==> Trách nhiệm có vẻ rõ ràng, nhưng có kế hoạch xử lý những trường hợp như member không tuân thủ lời leader/PM, viết code không đúng thiết kế, viết không hiệu quả hoặc không logic.. hay không? Ai sẽ chịu trách nhiệm chính và xử lý thế nào?
- 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! 
==> Điều này là nghiêm trọng, làm việc nhóm mà ko có tiếng nói chung rõ ràng thì sớm muộn sẽ loạn. Review có ra nhiều vấn đề nhưng có giải quyết chúng không? Có kiểm soát việc thực thi đúng hay sai?
- 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" 
==> Vậy project hiện bạn đang gặp vấn đề, khách hàng không đề cập đến chất lượng sản phẩm?
- 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! 
==> Kiểm tra thiết kế và mã nguồn là việc cực kì quan trọng. Khách hàng cũng là 1 nhân tố chính tham gia vào phát triển dự án, nếu bỏ qua yếu tố này thì chất lượng chỉ phụ thuộc phía nhà sản xuất.
- 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 
==> Tester đóng vai trò cực kì quan trọng cho chất lượng sản phẩm nên họ phải có trách nhiệm đảm bảo sản phẩm chạy đúng và ổn định cho mọi tình huố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). 
==> Nhân viên có quyền hỏi "sếp" rằng những việc cần làm trước là việc gì và có quyền đưa ra ý kiến của mình. Con người là tài nguyên quan trọng của một tổ chức và họ có quyền lên tiếng.
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. 
==> Mỗi thành viên dù ở vị trí nào cũng cần liên tục tích lũy và phát triển kĩ năng bản thân. Quản lý dự án thì bên cạnh kĩ thuật, học cách quản lý thời gian và con người tốt sẽ dễ thành công hơn. Lập trình viên nâng cao kĩ năng để sao cho cũng trong khoảng thời gian ngắn của dự án mà tự viết mã tốt hơn.
" 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?)  
Ai cũng có hoàn cảnh, gia đình và nhiều yếu tố cá nhân khác. Tuy nhiên cần phân định rõ công việc và cá nhân. Có lẽ bạn thử tìm đọc quyển "How to influence people and make friends" (sách tiếng Việt là Đắc Nhân Tâm) xem những kinh nghiệm khi làm việc với con người :)]]> /hvaonline/posts/list/33821.html#207966 /hvaonline/posts/list/33821.html#207966 GMT Như thế nào để có cách viết code tốt hơn? Bác conmale Việc đưa ra câu hỏi với mong muốn nâng cao và phát triển là việc quan trọng và cần thiết. Tất nhiên khi đã trăn trở đến điểm này thì bồ đã ít nhiều hình thành những lý do và những điểm cần nâng cao + phát triển. Điều quan trọng nhất là phải sắp xếp chúng lại cho có lớp lang và chuẩn bị những lý do cho hữu lý và thuyết phục. => Cháu xin tiếp thu ý kiến này, về việc chuẩn bị để làm điều này cháu cũng đã nghĩ và cho ra kế hoạch để thực hiện mong muốn của mình. Đối với môi trường "corporate" hoặc một ban ngành có kích thước nào đó, việc đề đạt cho sự thay đổi nào đó là việc không đơn giản tí nào. Nó luôn luôn gắn liền với giá trị kinh tế (được quy đổi bằng cách nào đó). Bởi thế, việc đề bạt ý kiến nếu không cụ thể và tỉnh táo mà mang nặng cảm tính hoặc không có những lập luận bảo vệ và trực tiếp liên quan đến giá trị kinh tế thì khó mà tiến hành được. Giá trị kinh tế trườu tượng nhất đối với đám kỹ thuật là: cắt ngắn thời gian nhưng hiệu quả công việc vẫn không thay đổi (hoặc cải thiện hơn thì càng tốt). => Cháu cần đưa ra được những "con số" nếu muốn bảo vệ được chính kiến của mình, đúng là lãnh đạo nào cũng muốn phải có con số cụ thể chứ không theo kiểu "cảm tính" đưa vào được. Đây là kỹ năng giao tiếp và thuyết phục. Có những cách nói làm cho người đối diện cảm thấy không bị khó chịu (như dạng bị "dạy đời") khiến cho họ vẫn vui vẻ tiếp nhận. Điều quan trọng cho những người làm việc trong môi trường kỹ thuật là phải chính xác và trực tiếp vào vấn đề. Tuy vậy, điều chỉnh lại vài ngôn từ cho "êm tai" hơn thì vẫn có giá trị thuyết phục hơn. Ví dụ: "em thấy anh làm như thế này là sai" ---> hơi khó nghe và khó được tiếp nhận (ngoại trừ đối tượng rất tự tin và cởi mở). Thay vào đó, "em thấy có vài điều chúng ta có thể bàn sâu hơn để cải thiện" thì dễ chịu hơn vì "chúng ta" là cùng phe nhau. Những kỹ năng này phải đi xuyên qua giao tiếp và đụng chạm lâu dài thì mới rèn luyện mà có được. => Giao tiếp rất quan trọng, cháu cũng hiểu nhưng cháu cần có thời gian, có lẽ "vấp" càng nhiều thì mới có được điều này. Cảm ơn bác đã đưa ra những phân tích, ý kiến này, thật sự rất logic :) Anh Z0rr0 Em cám ơn anh đã chỉ ra rạch ròi các vấn đề mà công ty/em/nhóm em đang gặp phải, quả đúng là những vấn đề anh đưa ra trùng khớp với nhưng gì đang xảy ra ở hiện tại. Em chưa nghĩ hết được các khả năng, những câu hỏi như anh đã trình bày ở trên để mà tìm câu trả lời. Sự giảm sút về dự án là 1 minh chứng nhất cho tình hình của công ty, nhưng 1 mình em xem ra khó mà "cải cách" được anh nhỉ, cần có đồng minh hỗ trợ và tin tưởng. Hi em lập ra cái title rõ ràng là chỉ đề cập tới vấn đề code thế mà cuối cùng viết sang cả vấn đề này, các bác/anh/chị/em thông cảm cho em với nhé. Em biết HVA từ 2003, tức là năm nhất của đại học, nhưng hồi đó cũng chỉ biết đến đó là 1 diễn đàn hacker có tiếng tăm của việt nam mình, có tạo 1 tài khoản nhưng sau đó thì do học hành ở trường rồi cũng chưa tưởng tượng được những khái niệm "hacker", "mũ đen", "mũ trắng",... nên cũng ít khi vào diễn đàn. Diễn đàn đã có sự thay đổi rất lớn thì phải, cấu trúc được thay đổi, bố trí hợp lý, gọn gàng và khoa học hơn nhiều. Nhưng các bài viết thì đã giảm chất lượng thì phải,? cái này chắc là cũng có nhiều nguyên do của nó, dù sao em cũng hy vọng HVA ngày càng tốt đẹp hơn. Từ bây giờ em sẽ sinh hoạt đều đặn hơn trên HVA hì hi, mong các anh chị chỉ bảo cho em nhé. Thân ]]> /hvaonline/posts/list/33821.html#208047 /hvaonline/posts/list/33821.html#208047 GMT Như thế nào để có cách viết code tốt hơn? /hvaonline/posts/list/33821.html#211026 /hvaonline/posts/list/33821.html#211026 GMT Như thế nào để có cách viết code tốt hơn?

zidole109 wrote:
" 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?)  
Một thầy giáo của mình cũng nói tuổi nghề của coder chỉ đến 30 thôi, sau 30 thì không đọ được với lớp trẻ đâu, còn nếu theo phần cứng thì có thể đến 40 tuổi (nhưng cũng hiếm), sau tuổi đó mà không lên quản lý hay gì thì chấp nhận đổi nghề. Còn lý giải vì sao nước ngoài ngũ tuần vẫn code ầm ầm. Đam mê là một chuyện nhưng theo mình còn là do cái vấn đề về cái cách tư duy lập trình nữa, có thể họ được đào tạo bài bản từng bước từ đầu. Ở việt nam mình đào tạo về lập trình cảm thấy vẫn rất là lung tung theo đúng kiểu là bảo gì biết thế, gần như chả có đâu đào tạo một cách bài bản kỹ năng và cách tư duy lập trình cả. 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 :(. ]]> /hvaonline/posts/list/33821.html#211143 /hvaonline/posts/list/33821.html#211143 GMT Như thế nào để có cách viết code tốt hơn? /hvaonline/posts/list/33821.html#211145 /hvaonline/posts/list/33821.html#211145 GMT Như thế nào để có cách viết code tốt hơn?

faithhw wrote:
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 :(.  
Anh không nhớ anh đã từng nói "muốn code tốt hơn thì nên học cả thiết kế hướng đối tượng" :P. Thông hiểu về OO là chuyện nên làm vì các ngôn ngữ lập trình hiện đại ngày nay đều ít nhiều áp dụng và vận dụng OO. Tuy nhiên, OO không phải là chìa khoá để lập trình tốt hơn. OO chỉ là phương tiện giúp lập trình viên có cái nhìn tổng quát và liên đới đến những đối tượng được dùng trong khi lập trình. 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".]]> /hvaonline/posts/list/33821.html#211161 /hvaonline/posts/list/33821.html#211161 GMT Như thế nào để có cách viết code tốt hơn? code cho nó chạy trước được cái đã đa số gặp phải mà gần như đâu cũng thấy, bản thân em cũng bị cái này mãi không sửa được vì thế nên trình code vẫn cứ lẹt đẹt thôi :(. Và quan trọng là thiếu cái tư duy tổng quan ngay từ đầu rồi. Ở việt nam phần lớn các dự án đều theo kiểu lập trình xong rồi mới có thiết kế chứ ít khi theo tư duy thiết kế rõ ràng ngày từ đầu (trừ các project out source có sẵn thiết kế của nước ngoài thì không nói làm gì) Kết một cái muốn code tốt hơn, khi đã có định hướng rồi thì vấn đề là kiên nhẫn và đam mê thôi. Thanks a conmale nhiều.]]> /hvaonline/posts/list/33821.html#211200 /hvaonline/posts/list/33821.html#211200 GMT Như thế nào để có cách viết code tốt hơn?

conmale wrote:
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".  
=> Khi học lập trình thường có bước vẽ lưu đồ thuật giải cho chương trình sau đó mới viết code, nhưng khi học thì thấy đa số giảng viên và học viên bỏ qua phần này :(. => Điều này làm em liên tưởng đến câu nói vui sau:"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" - Ky0 - ]]> /hvaonline/posts/list/33821.html#211301 /hvaonline/posts/list/33821.html#211301 GMT Như thế nào để có cách viết code tốt hơn?

Ky0 wrote:
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 -  
Haha nhắc đến câu này lại nhớ đến mấy thầy giáo dạy mình, một thầy dạy môn thuật toán và hệ điều hành thì lúc nào cũng bảo là chương trình phải tối ưu, sử dụng ít biến, và tốc độ chạy phải nhanh, tốn ít bộ nhớ. Thầy dạy môn phần mềm thì bảo: cứ code cho chạy ngon, chương trình thân thiện người dùng, còn đâu tối ưu hay tiết kiệm bộ nhớ thì quan trọng gì , máy tính bây giờ đủ mạnh rồi, ram toàn vài GB thì lo gì thiếu bộ nhớ nọ kia, có phải máy tính đời cổ đâu mà phải quan tâm chuyện đó. Thực ra theo mình nghĩ, cái vấn đề quan tâm đến chương trình chạy đúng hay chạy nhanh, nó phụ thuộc vào việc chương trình phục vụ mục đích gì. Tức là phải xác định xem trước đối tượng mà chương trình này phục vụ là ai và công việc nó phải làm là gì. Ví dụ chương trình phục vụ cho đối tượng bình thường, cho các công ty tổ chức nhỏ v.v. thì việc ưu tiên phần chạy đúng và giao diện. Còn nếu chương trình phục vụ việc tính toán với khối lượng dữ liệu lớn, dùng cho tổ chức lớn thì phải tính đến việc tối ưu thuật toán sao cho nó chạy nhanh nữa. Chốt một câu là phải biết mình làm cái gì.]]> /hvaonline/posts/list/33821.html#211305 /hvaonline/posts/list/33821.html#211305 GMT Như thế nào để có cách viết code tốt hơn? /hvaonline/posts/list/33821.html#211373 /hvaonline/posts/list/33821.html#211373 GMT Như thế nào để có cách viết code tốt hơn? 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  ]]> /hvaonline/posts/list/33821.html#211865 /hvaonline/posts/list/33821.html#211865 GMT Như thế nào để có cách viết code tốt hơn?

panfider wrote:
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  
Thực ra ý nghĩa của cái này đó là bên khoa học máy tính ưu tiên tới việc lựa chọn giải thuật v.v. sao cho nó chạy nhanh đã rồi mới bắt đầu tính đến việc chạy đúng. chứ không nên hiểu là code chạy không đúng. Nó chỉ là câu nói just for fun thôi mà :). Chương trình làm một việc gì thì cái yêu cầu chạy đúng là yêu cầu tất yếu mà. Còn việc chạy nhanh thì tuỳ thuộc vào mục đích của chương trình thôi. ]]> /hvaonline/posts/list/33821.html#211866 /hvaonline/posts/list/33821.html#211866 GMT Như thế nào để có cách viết code tốt hơn?

zidole109 wrote:
- 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. 
Thế thì phải xem lại cái "lớn" của công ty cậu nhé, tớ cảm giác nó chỉ có nhiều nhân viên, có hạ tầng cơ sở tốt... nhưng không có quy trình làm việc, giống như người béo quá mà không có sương sống ý :| , < chết chả, chả biết phải FSOFT ko > :-) Về cơ bản thì theo ý tớ cậu lượn luôn cho nhanh... Khi cậu viết đơn xin thôi việc, các sếp sẽ ngay lập tức "ngó" tới các ý kiến của cậu và có thể cậu sẽ ở lại với 1 mức lượng + 30% chả hạn... tớ thường làm thế ]]> /hvaonline/posts/list/33821.html#213129 /hvaonline/posts/list/33821.html#213129 GMT