Người ta thường nói rằng người luôn nói thật là những đứa trẻ và kẻ điên. Và quả thật developer đôi khi như có vẻ đang lên cơn điên và họ cũng có tính trẻ con như bao người khác, nhưng điều đó không có nghĩa là họ sẽ luôn nói sự thật. Developer thường sử dụng một ngôn ngữ khác nhằm để che giấu đi những điều mà họ không muốn bạn biết.

Để giúp bạn không bị qua mặt bởi những developer tinh quái này, tôi sẽ giải thích một số thuật ngữ mà họ thường sử dụng trong các cuộc họp nhóm.

‘Không tiêu chuẩn – Non-standard‘

Khi các nhà phát triển gọi một sáng kiến hoặc tool là “không chuẩn”, họ có thể nói sự thật. Rằng nó thật sự chỉ đơn giản là một mẹo/cách thức của riêng họ để giải quyết vấn đề. Tuy vậy, nó có thể sẽ dễ dẫn tới việc ảnh hưởng tới chất lượng của project, đặc biệt là về lâu dài nếu như trình độ của developer không vững cũng như phương pháp không khả thi, chỉ mang tính tạm thời. Do đó, hãy thử hỏi rõ cũng như lắng nghe ý kiến của họ trước khi thật sự chấp thuận.

‘Tiêu chuẩn mới’

Đây là câu yêu thích của họ bằng cách nói rằng đó là “tiêu chuẩn mới” hoặc “nó sẽ nhanh chóng trở thành tiêu chuẩn mới.” nhằm tăng tính thuyết phục lập luận của mình cũng như khiến bạn dễ đồng ý hơn.

Tuy vậy, mới không có nghĩ là nó sẽ luôn tốt hơn hoặc phù hợp hơn. Mặt khác, các “tiêu chuẩn” không phải trở thành tiêu chuẩn chỉ trong một sớm một chiều. Nếu có cái gì đó “mới” thì vẫn còn quá sớm để biết liệu đám đông có thật sự ủng hộ nó hay không. Developer khi dùng “tiêu chuẩn mới” có thể sẽ thổi bùng lên và nói quá sự thật nhằm gây ấn tượng.

Điều đó không có nghĩa là các developer không có ý định tốt khi họ nói với bạn rằng đó là một “tiêu chuẩn mới” mà họ đang nóng lòng để được áp dụng. Điều này thường có nghĩa là họ quan tâm đến việc từ bỏ hoặc phản đối một số cách tiếp cận cũ. Tuy nhiên, bạn vẫn phải thận trọng đối với cái mới khi được các developer đề xuất.

‘Một tuần’

Khi developer nói rằng tính năng hoặc sửa lỗi đó sẽ rất dễ để làm, họ thường nói đúng sự thật. Bởi vì họ thực sự hy vọng nó sẽ được hoàn thành nhanh chóng. Chỉ có điều là có quá nhiều sai sót có thể xảy ra với máy tính. Đôi khi đó là mạng, đôi khi lại liên quan tới cơ sở dữ liệHoặc cũng có thể nó đến từ sự lạc quan ngu ngốc của chính các Developer. Trong mọi trường hợp, “một tuần” thường thực sự có nghĩa là “một tháng”. Hoặc thậm chí có thể là “sáu tuần”.

‘Một tháng’

Đây là một đơn vị ước lượng chuẩn hơn mà bạn có thể tin tưởng được nhưng cũng giống như “một tuần”, nó hoàn toàn không chính xác theo đúng nghĩa đen. Mức độ sai lệch có lẽ tương tự như “trong một tuần” và việc kéo dài thành 4-6 tháng sẽ không phải là điều hiếm hoi.

‘Một năm’

Khi developer nói điều gì đó sẽ mất một năm, họ không nói về thời gian nữa. Họ chỉ nói rằng họ không muốn làm điều đó. Có lẽ nó liên quan đến chương trình hoặc ngôn ngữ mà họ không thích. Có lẽ nó sẽ có nghĩa là phải làm việc với cá nhân/team mà họ ghét.

Nhưng developer cũng không thể tuyên bố là nó không thể thực hiện điện. Ít ra là cái tôi của họ không cho phép như vậy. Do đó mà họ thường nghĩ rằng sẽ tốt hơn là chôn vùi nó bằng cách tuyên bố rằng điều đó là không khả thi hoặc không thực tế.

Tất nhiên, hành vi này khá là phổ biến trong tất cả các thành phần của một công ty. Và đơn giản là làn này nó được sử dụng bởi các developer.

‘Phong cách – Style’

Có người đã từng nói rằng tranh luận không hề tồn tại – hoặc bạn có hoặc bạn không. Developer cũng tương tư như vậy. Họ có quan điểm cá nhân của mình ​​về cách đẹp nhất để viết code giống như các designer quan tâm đến các chuẩn mực trong thiết kế vậy.

Vấn đề đến từ việc họ cố gắng buộc những người khác phải theo đúng ý muốn của mình. Thậm chí nhiều con sẵn sàng gây “war” với nhau về cách viết code tốt nhất. Tuy vậy nó vô cùng bất lợi trong một tập thể khi có những cá nhân như vậy. Do đó mà bất cứ điều gì họ nói sau khi nhấn mạnh về “phong cách” của mình thì bạn có thể bỏ qua một bên. Chỉ khi nó thật sự có một vấn đề kỹ thuật đòi hỏi sự thay đổi “phong cách” thì hãy tiếp thu ý kiến từ họ một cách nghiêm túc.

‘DevOps’

Tên gọi giống như sự kết hợp của “Developer” và “Operations”, nhưng nó thực sự đề cập đến quá trình giữ code chạy và các máy chủ hoạt động tốt, một quá trình phức tạp đủ để lập hẳn ra các ban phòng riêng cho nó.

Nhưng bạn thường có thể phát hiện ra một chút nhạo báng trong giọng nói của developer với đội “DevOps”. Đó là bởi các developer là người tạo ra cấu trúc dữ liệu và để lại công việc bảo đảm nó chạy tốt cho người khác. Theo một cách nào đó, “DevOps” có thể có vẻ như là bất cứ điều gì mà các developer không muốn làm nhưng cần được thực hiện.

‘API’

Các developer yêu thích các API bởi vì nó thiết lập ranh giới rõ ràng với các quy tắc để vượt qua chúng.

Nhưng khi các lập trình viên nói “API”, điều họ đang nói đến thường xuyên hơn là kiểm soát. Nhóm xây dựng API được thiết lập các quy tắc, tạo điều kiện khiếu nại các developer khác khi không làm đúng theo chuẩn của họ. Nói cách khác nó có nghĩa là họ đang lạm dụng API để giằng mặt nhau. Họ có thể thiết lập các điều khoản về dịch vụ và các quy tắc về quyền truy cập có lợi cho mình. Do đó mà rất cần thiết để nghe rõ từ hai phía cũng như bảo đảm sự công bằng cũng như vì lợi ích chung của công ty.

‘Thích hợp hơn / Công cụ phù hợp với công việc’

Đối với developer, những công cụ mà họ đang học thì thường có hiệu quả và giá trị hơn. Vì vậy, không có gì ngạc nhiên khi họ thường ủng hộ cho những gì họ biết là tốt nhất.

Khi họ nói rằng X hoặc Y là “thích hợp hơn” với task này, họ thường chỉ xác nhận rằng lựa chọn này là phù hợp với họ. Cách giải quyết tốt nhất chỉ là gật đầu, mỉm cười và đồng ý. Bởi cái họ giỏi nhất sẽ giúp bảo đảm chất lượng. Tuy vậy, hãy lưu ý rằng đôi khi những tool và công nghệ đó thật sự vẫn chưa tối ưu hoặc phù hợp cho task.

‘Phạm vi leo thang’

Các dự án bắt đầu với những ước mơ lớn – và đôi khi chúng ta quản lý chỉ để hoàn thành 50 % trong số chúng. Lựa chọn mức độ phù hợp không phải là một công việc dễ dàng. Nếu bạn quá bảo thủ, bạn không đạt được nhiều. Nhưng nếu bạn cố gắng quá mức thì bạn có nhiều khả năng bị sụp đổ và không thu được gì cả.

Cụm từ “phạm vi leo thang” mô tả quá trình mà một mục tiêu trở nên bất khả thi do cứ thêm nhiều mục tiêu khác trên quá trình đi tới nó. Nó thường được đề cập khi developer cố gắng ngăn một người quản lý muốn thêm một ý tưởng mới vào. Tuy nhiên, các nhà quản lý thường phản đối bằng các cụm từ như ” phải biết nâng cao bản thân” hoặc thậm chí tệ hơn là “Hoặc là làm nó, hoặc bị sa thải.”

‘Phù hợp với văn hoá’

Thường ám chỉ những cá nhân không nằm trong xã hội thu nhỏ của developer. Đó thường là các thành viên không có hiểu biết về IT cũng như không đủ “trình” để giao tiếp với họ bởi sự thiếu hụt về kiến thức kĩ thuật trong ngành.

‘Sắp xếp lại – Refactoring‘

Nếu một lập trình viên gọi nó là “sửa sai lầm” hoặc “xây dựng lại đúng cách”, thì có vẻ như họ đã thừa nhận bản thân không đủ năng lực. Nhưng bằng cách nào đó thì dùng từ “tái cấu trúc” nghe nó có vẻ khoa học và cao quý hơn. Tuy vậy, nó sẽ khiến bạn thắc mắc tại sao các developer lại mắc những lỗi như vậy để phải đập đi xây lại.

‘Tính năng’ vs ‘Bug’

Nếu một lập trình viên nói “tính năng”, nó có nghĩa là họ thích code đó, thường là vì bởi chính họ đã viết nó. Nếu họ sử dụng từ “bug”, tức là họ không thích code này và nó thường đơn giản bởi vì nhóm khác đã viết nó.

Mặc dù bất kỳ người dùng nào cũng hiểu được khái niệm “Bug”, nhưng thực sự khó cho các developer để nhận ra chúng. Thường thì phải chạy code mới biết được.

Do đó đừng bị sa lầy vào đống triết học của họ. Nếu người dùng không thể sử dụng, nó cần phải được sửa cho dù nó là bug hay tính năng.

‘Kludge’

Một kludge chỉ là một tiếng lóng cũ cho một biện pháp làm lại những task mà đã thực hiện trong quá khứ nhưng chưa thật sự hoàn hảo do “không có đủ thời gian”. Ví dụ như các developer có thể sẽ muốn refactor bằng cách thêm nhiều code hơn nữa. Trong tương lai, nhóm tiếp theo sẽ đề cập đến tái cấu trúc này như là một kludge và chu kỳ sẽ tiếp tục

‘Luser’

Ám chỉ phần còn lại của thế giới, những người vốn không chuyên về code hay còn gọi là “lusers”. Khi sự thành công của một nền tảng công nghệ được đo bằng số lượng người sử dụng nó thì chúng ta cũng thường ngộ nhận rằng nó sẽ là tốt nhât. Tuy vậy, Developer sẽ cần có sự hiểu biết cũng như nhận thức rõ công nghệ nào phù hợp chứ đừng theo đám đông