Trở lên trên
Viết bình luận25 Bình luận
  • SamSam
    Khổng lồ thật, mà mấy thánh pro này code là tối ưu ngắn gọn lắm rồi chứ không phải rườm rà như mấy đại ca Việt Nam
    • thinker
      @SamSam bên mình chỉ code sao cho chạy được, bên nó "phú quý sinh lễ nghĩa" nên mới code sao cho dễ đọc dễ bảo trì bờ la bờ lu
    • SamSam
      @thinker Nhiều lúc Em code cái app theo xu hướng, copy paste như điên để ra thật nhanh cái app ăn theo, lúc hit được trend rồi vào nâng cấp tính năng, đọc lại code mà nản
    • thinker
      @samsam bọn firefox trâu có lẽ do nó tư làm hết từ javascript engine, render engine, UI, tính năng, v.v. Bọn khác toàn based trên webkit/blink nên đỡ. Bọn IE chắc còn to hơn Firefox (Edge thì nó xóa bớt code của IE rồi)
    • SamSam
      @thinker Làm từ đầu như thế lại ngon bác nhỉ, như ông Google Android vướng vào kiện tụng khổ sở với cái ông Oracle
    • b_y
      @thinker bác khi dễ dân ta thế
    • thinker
      @b_y em có khinh đâu, code sao cho chạy được là tốt mờ...
    • b_y
      @thinker kì, bên em làm outsource, code cùi cùi là bên công ty mẹ nó la làng liền
    • vietnamnet_ict
      @b_y Đánh giá như thế nào là code cùi nhỉ?
    • b_y
      @vietnamnet_ict generic question, trong context của em thì khó đọc, ko đúng format (comment, thụt đầu dòng, khoảng trắng các thứ..), hàm hay class quá dài, tên biến khó hiểu, dễ gây lỗi concurrent... hoặc tệ nhất là code trông có vẻ đúng nhưng review lại thì thấy logic sai
    • thinker
      @b_y một ví dụ về code cùi: toàn comment nông (là cái dòng code phía sau nó làm gì, ai chả biết còn comment), trong khi cái cần comment (mày định làm gì với cái đoạn code này) thì ko giải thích, véo hiểu đang code cái gì. Comment quá thừa mà vẫn thiếu
    • hongquan09dth5
      @samsam : công nhận nhiều khi coi lại code chóng hết cả mặt :v
    • b_y
      @thinker thì em nói chung chung thế thôi, còn làm sao để code không cùi là quá trình rèn luyện gian khổ qua bao đau thương mới rút ra được, em chưa đủ tầm đấy nên ko dám nói liều. Chỉ phản bác ý kiến là dân mình code chỉ để chạy được là ko chính xác:
      - em chưa vô công ty nào cổ xúy tư tưởng code chỉ để chạy được
      - code review rất chặt nhất là mấy công ty nc ngoài nên muốn code cùi cũng ko được.
    • Alakazam
      Những chỗ mình làm thì nếu công ty lớn sẽ có ai đó soạn ra coding standard cho từng dự án. Công ty nhỏ thì có thể cả công ty dùng chung một coding standard. Cái coding standard chia làm 2 mục nhỏ. Mục 1 là quy định về cú pháp như cách đặt tên biến, tên class, tên hằng số, format code ra sao,... Review cứ thế mà làm theo. Nếu code JAVA với eclipse có tool checkstyle chả hạn. Số lỗi thuộc dạng này đươc cho phép là 0. Mục 2 là quy định về ngữ nghĩa. Ví dụ như không cho phép khởi tạo biến trong vòng lặp này, không cho phép dùng trực tiếp hằng số (magic number) mà không khai báo qua biến này, ....Nếu code JAVA với eclipse có tool check PMD chả hạn. Số lỗi cho phép thường khoảng 5/1000 dòng code chả hạn.

      Về comment thì hồi xưa hay có yêu cầu là comment theo javadoc hoặc phpdoc chả hạn. Đầu mỗi class hay mỗi method phải có comment là cái này làm cái gì, input/output ra làm sao + ý nghĩa các tham số. Nhưng xu hướng bây giờ là bỏ, trừ những dự án phải sinh document. Nguyên tắc được ủng hộ bây giờ là phải code tốt (tên biến, tên method dễ hiểu, một logic phức tạp phải được chia thành nhiều logic nhỏ. Mỗi một logic nhỏ là một method dễ hiểu, ...) sao cho đọc code là hiểu chứ không cần comment. Chỉ nên comment giải thích ở những đoạn nào mà code phức tạp (bởi thời gian không cho phép nghĩ ra cách làm tốt hơn được hay thực hiên một thuật toán rối rắm, ...)
    • phieu
      @b_y chuẩn đấy, code muốn không cùi thì nên phải qua review bởi người khác, và qua tool để check các warning cơ bản.
  • DrVincent
    Thấy code cũng bài bản mà ta. Ghi comment đồ đầy đủ, nói chung bài bản.
  • phuocvnh
    ai code dạo đê, ai trà đá đê
  • ntmj27
    Trả lời câu hỏi: Coder 12 năm, càng ngày số code trung bình 1 ngày càng ít, hồi mới làm ngày code đc 2000-5000 dòng, đến lúc đc 10 năm kinh nghiệm thì ngày code tầm 100-150 dòng, suy nghĩ logic và tối ưu là chính, giờ chuyển hẳn sang qly ngày code tầm 50-100 luyện tay cho khỏi quên
    • thinker
      @ntmj27 thế giờ bác code 1 triệu ngày ko nghỉ mới xong cái fb, vị chi là 3000 năm, code từ thời các vua Hùng đến giờ có lẽ gần xong
    • ntmj27
      @thinker nói thật là mình ko nghĩ cái facebook nó lắm code thế Mình nghĩ tầm 2tr dòng thôi đấy
    • thinker
      @ntmj27 chắc nó đủ thứ, AI, nhận dạng, quảng cáo, phân tích, services, rồi tool/API platform cho dev, v.v. tính vào hết
    • ntmj27
      @thinker chắc chỗ đấy là tính cả lib nữa, chứ code không 61tr dòng là khủng lắm
    • b_y
      @ntmj27 2mi ít quá, dự án em đang làm cũng khoảng gần 1m
  • quanglh
    Như bạn mấy bạn ở trên nói chỉ là code đúng convention thôi. Nó chỉ là trình bày văn bản. Tất nhiên là phải có nhưng đúng convention code vẫn có thể cùi, không liên quan lắm. Có thể vẫn chỉ đang ở mức "Code chạy được" thôi.

    Một số VD về code cùi:
    1- Copy code lung tung: cùng 1 đoạn code xử lý 1 chức năng, trong cùng 1 project có thể code 1 lần, dùng lại ở 10 chỗ (nếu áp dụng đúng kế thừa, hoặc ít nhất là viết hàm tiện ích static), thì lại đem nó copy đi 10 nơi. Hậu quả là lúc có bug thì sửa 6 7 chỗ, quên mất mấy chỗ. Bị bug 10 lần thì ra 10 cái code khác nhau...

    2- Code có tính hướng đối tượng kém: VD không kế thừa khi cần, không dùng lại code như ở trên, đối tượng không có tính đóng làm logic nó không chặt, không gọn. Hậu quả là fix bug này lòi ra bug ở chỗ khác mà đáng ra không liên quan. Hay không thể mở rộng chức năng nổi. Hoặc khi cần sửa tính năng sẽ mất rất nhiều thời gian.

    3- Không có khái niệm về đa luồng. Biến static cắm lung tung tới lúc vài luồng nó sửa, nó dùng gây loạn logic. Debug rất khổ. Mà đau là bố gây ra thì không đủ trình debug, để bố không gây ra ngồi khóc .

    4- Không có khái niệm về bộ nhớ, code lăng nhăng, object không giải phóng được. Bao gồm cả 1 số cái có Garbage Collector như cả Java. VD có cái object to to, vì lý do gì đó không hủy tham chiếu của nó được, GB không giải phóng được --> module khác nó thiếu heap, nó out of memory cho. Cũng như cái 3, làm khổ ông khác. Hay mutable object, immutable object là gì cũng chả biết. String vs StringBuilder chỉ là 1 VD nhỏ của cái này. Làm số Object sinh điên cuồng, chậm phần mềm, hay gây lỗi.

    Vân vân.

    Đấy lầm chưa kể một số bố cứ copy linh tinh về mà chả hiểu mình copy gì. Trình lởm đó không nhắc tới. Còn chưa đạt "code chạy được".