Cứ chạy được là được

#1

Nó là một tiêu chí mà gần như bất cứ ai cũng đã nghe và thực hiện.
Mọi thứ tiêu chuẩn khác : OOP, design pattern, performance, flexible, maintain, clean code vv vv…. nó đều đứng sau và nhiều khi nó mông lung hoặc chưa từng tồn tại.
Nó giống như xây một công trình mà không hề có thiết kế. Nó được viết một cách ngẫu nhiên tùy sở thích hoặc tầm hiểu của người triển khai. Nó thường xuyên phải đập đi xây lại khi thêm một yêu cầu và cấu trúc hiện tại không còn phù hợp.

Có thể suy nghĩ của tôi đã không còn hợp thời hoặc do đã cổ hủ hay bảo thủ. Nhưng tôi không cảm thấy dễ chịu khi làm sản phẩm với tiêu chí như trên.
Còn các anh em và team của các anh em thì sao ?

6 Likes
#2

Thực tế qua quá trình học hỏi là làm việc, hà mã tím đáng yêu nhận ra code chỉ là một bức tranh nhỏ, bức tranh lớn hơn là phải biết thiết kế (thiết kế phần mềm - không phải designer). Khi đã ngộ được thiết kế thì hầu như không cần quan tâm đến việc code bằng ngôn ngữ gì, framework nào, team có bao nhiêu người, senior hay junior,… chỉ cần biết nên chọn cách nào để hiện thực thiết kế.

Với một phần mềm cá nhân thì cứ chạy là được là ok, vì mình làm ra nó, mình biết nên nhấn nút A một lần, chờ 5 giây và nhận kết quả B.

Tại sao các quy tắc phát triển là quan trọng:

  1. Khi xuất bản ứng dụng tới người dùng đại trà, họ sẽ không đọc hướng dẫn sử dụng. Mà họ chỉ biết dùng theo cách của họ, có thể bạn để nút A nhưng họ không bấm một lần, họ bấm 3 lần chẳng hạn,… Đó là về thao tác, chưa kể tới số lượng thiết bị, tình trạng mạng, sự kiện có cuộc gọi tới, sự kiện máy trung cộng thiếu một số thư viện chính thống,…

  2. Khi làm việc với team, thiếu design pattern sẽ khiến conflict diễn ra thường xuyên. Code không clean nặng thì phải training lại, team mất lòng nhau,… nhẹ thì hiệu suất chậm, hiểu lầm vấn đề dẫn tới bugs…

  3. Khi cần maintain thêm chức năng mới, code thiếu clean thì lâu ngày nhìn lại code mình viết không hiểu gì, sửa 1 value phải sửa 100 trăm dòng codes (tức là phải review 100 files). Code thiếu design pattern bị dính chặt như keo 502 không biết nên bắt đầu thêm code mới từ đâu. Nặng hơn là phải đụng vô code cũ trước đó đã stable, khiến hỏng luôn tính ổn định của code cũ.

Những điều hà mã tím đáng yêu nói không phải là lý thuyết mà đã có kiểm chúng thực tế qua quá trình làm việc, đây là 1 case trong đó: Nguyên lí thứ 3 của S.O.L.I.D code qua kiểm chứng thực tế

6 Likes
#3

Cảm ơn bạn đã chia sẻ.
Quả thật những điều bạn đưa ra mình thấy đúng.
Nhất là đối với những dự án vừa và lớn mà thiếu các tiêu chuẩn thì chết luôn.

4 Likes
#4

Theo tôi căn cứ tùy trình độ member trong team và độ lớn dự án mà sẽ có những thứ tự ưu tiên khác nhau, nhưng yêu cầu chạy được & phải chạy đúng luôn là điều kiện tiên quyết của bất cứ đoạn code nào.
Nhưng nó chỉ là đk cần không phải điều kiện đủ.
code đẹp, dễ bảo trì, mở rộng nhưng output ra sai thì cũng false. :slight_smile:

4 Likes
#5

Tất nhiên output vẫn phải đúng.
Dự án có thể đến hàng trăm, hàng nghìn giờ phát triển. Những dự án nhỏ tầm vài chục giờ trở xuống và chỉ để giải quyết vấn đề tức thời không tính.

2 Likes
#6

Như tôi nói ở trên đó, code cứ chạy đc là đk cần chứ chưa đủ. Tùy vào dự án mà có những rule khác nhau và độ ưu tiên khác nhau. Và việc tối ưu code đến mức nào phụ thuộc trình của member trong team nữa và nó sẽ tiến bộ từng ngày. Ai cũng muốn tối ưu nhưng trình độ non trẻ mà lực bất tòng tâm. Như hồi cta code những bài tập đầu tiên, hồi đó ta tự hào lắm, nhưng giờ cho đọc lại thì chỉ muốn chửi thề.
Nếu ai đó nói k cần code đẹp, hãy đấm cho nó trận và nghỉ chơi luôn, nhưng thằng mà chưa thể code đẹp, hãy chỉ bảo nó :smiley:

3 Likes
#7

Mình đang bàn luận về vấn đề này.
Tức là không có tiêu chuẩn gì mà chỉ cần bằng cách nào đó nó output ra kết quả. Có thể chỉ cần đúng trong một số điều kiện.

Một ví dụ dễ thấy là bao toàn bộ code trong một try-catch và trong catch chỉ return hoặc throw exception.

1 Like
#8

Một hậu quả là rất hay phải đập đi xây lại và member không thể support nhau do không có tiêu chuẩn chung.

3 Likes
#9

tui nghĩ 1 team thường có việc review code chứ nhỉ? tùy vào tình hình dự án mà code như thế nào thui chứ bạn. deadline đến rồi, code chạy được là mừng rơi nước mắt rùi. Nộp cho sếp đã, tính tới việc sửa chữa, nâng cấp sau :smiley:

1 Like
#10

Khi deadline thì đành chịu.
Mà ngay từ đầu dự án đã không đề cao các tiêu chuẩn ?

2 Likes
#11

tui nói nó là đk cần mà, có phải đk đủ đâu. ông nào cứ cãi ngang k cần thì đấm cho trận.
còn như thế nào là đẹp, tối ưu thì căn cứ do người có trình độ cao hơn (thường sẽ đưa ra được những tool hoặc lý lẽ khiến ng khác phải nghe). Đơn giản hơn, sếp nói sao thì nghe vậy, sếp k yc thì thôi, người khác mình kệ, để tester bắt bug, tự mình code đẹp phần của mình, vì nó liên quan đến thói quen, tương lai của mình nữa, mất thời gian hơn tí nhưng mình có thể đi xa. (chỉ sợ lực bất tòng tâm :v )

1 Like
#12

Mình không có võ :smile:

3 Likes
#13

đã từng trải nghiệm, k phải sếp k muốn mà member k đủ trình độ để sếp áp chuẩn nên thôi, code chạy là được. Nhưng dự án đó tui khá buồn vì trình độ mình tăng k nhiều, k được như kỳ vọng.

Bạn có là sếp k? Có thì đấm đi.
Không thì đừng care việc của Xếp :V
sếp giao cho bạn review code thì feedback lại. fb rồi mà bạn đó k sửa thì báo sếp hoặc đưa cả team. k được thì thôi, khỏi review. code xong đưa qua tester tìm bug :V

1 Like
#14

Mình lửng lơ. Mà chỗ mình team nhỏ nên không cod khái niệm dev, coder, tester…
All in one ::))
Nên có thể có trường hợp bạn đưa tiêu chuẩn nhưng không được áp dụng và bạn là thằng sẽ ăn hành từ việc đó.

2 Likes
#15

team nhỏ nên áp dụng chuẩn khó lắm, trình độ team chưa đá[ ứng được. Như trường hợp của team tôi trước, sếp muốn áp chuẩn nhưng phải bó tay. 1 ng a đã nói vs tôi: “cái gì lợi hơn thì làm” Lợi cho team, lợi cho dự án, lợi cho bản thân mình.

Tôi thì k nghĩ vậy, code chuẩn nó thành thói quen rồi. Như bạn sẽ k mất quá nhiều thời gian cho việc đó, nên k nghĩ rằng đó là ăn hành. Bạn k ở với team đó lâu. Mình đúng thì ở đâu cũng đúng, còn mình sai thì chỉ đúng ở team mà coi cái sai là đúng (thiểu số)

Đã đưa ra nhưng k ai muốn theo thì thôi. Đừng áp đặt yc của bạn cho người khác. Bạn tự làm theo cái chuẩn bạn tin rằng nó đúng. (Hãy chắc chắn rằng chuẩn đó hợp thời đại :v )
Bạn người giỏi, tôi nghĩ bạn chỉ đưa ra nhằm giảm stress, tìm người đồng cảm. Nhưng nếu team bạn k chấp nhận nó thì cứ cười đi. Bạn cần đi đường dài chứ k phải chỉ ở team hiện giờ ^^
Nếu quá hãy bơi đi tìm team khác

2 Likes
#16

Mình không tìm người đồng cảm. Đó chỉ là vấn đề mình đang gặp phải.
Và cũng muốn các anh em chia sẻ với nhau.
Để mình xem có phải mình đã quá cứng nhắc hoặc bảo thủ quan điểm hay không.

1 Like
#17
  1. Viết code chỉ ưu tiên chạy đc thì 1 là có hại cho chính người viết code vì sẽ ko học thêm đc cái gì mới, đồng thời hại cho những người đến sau vì chả biết thằng cha trước đây đang viết cái gì.
  2. Code review là 1 phần quan trọng để các ae trong team có thể học hỏi lẫn nhau, nhưng mà thấy ông nào ô nấy đều ngại, lười
    Làm team cứ thấy kiểu thằng nào cũng ưu tiên code chạy đc, nhà bao việc !
    Muốn nâng cao trình độ chắc làm pet project lại hiệu quả hơn.
5 Likes
#18

Mình và team đang gặp đúng cả 2 cái.
Bởi vì không có tiêu chuẩn hoặc thiết kế nên không lường trước được yêu cầu có thể xảy ra. Luôn trong trạng thái có thể phải làm lại vì cấu trúc dữ liệu, dự án không phù hợp ở step sau.

Phần code review thì đúng là không có.

2 Likes
#19

sau 3 tiếng ngâm nước, hà mã tím đáng yêu đã ngoi lên mà thread vẫn chưa kết thúc
:crazy_face::crazy_face::crazy_face::crazy_face::crazy_face:
surprised!!!
image

3 Likes
#20

Chuẩn luôn thứ tôi đang nghĩ.
Tôi có 1 câu có lẽ bạn cần “phương án tốt nhất là phương án phù hợp nhất”.

1 Like
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?