Clean Coder – Chương 12 – Cộng Tác

Phần lớn phần mềm được tạo ra bởi các nhóm làm việc. Nhóm làm việc hiệu quả nhất khi các thành viên trong nhóm đó cộng tác với nhau một cách chuyên nghiệp. Thật thiếu chuyên nghiệp khi là một kẻ cô đơn hoặc một kẻ xa lánh trong nhóm.

Vào năm 1974, khi đó tôi 22 tuổi. Đám cưới của tôi với người vợ tuyệt vời của tôi, Ann Marie, khi đó mới được 6 tháng. Ngày sinh của đứa con đầu lòng của tôi, Angela, vẫn còn một năm nữa mới tới. Và tôi đang làm việc cho một chi nhánh của Teradyne được biết với cái tên Chicago Laser Systems.

Làm việc ngay cạnh tôi là cậu bạn thời trung học của tôi, Tim Conrad. Tim và tôi đã làm được một vài thứ khá kỳ diệu trong thời đại của chúng tôi. Chúng tôi đã cùng nhau dựng ra những chiếc máy vi tính trong tầng hầm nhà anh ấy. Chúng tôi đã xây những chiếc thang của Jacob trong nhà tôi. Chúng tôi đã dạy nhau cách để lập trình những chiếc máy PDP-8 và cách để nối các mạch tích hợp với các transistor vào các máy tính chức năng.

Chúng tôi là những lập trình viên đang làm việc trong một hệ thống dùng tia laser để cắt các bộ phận điện tử như điện trở và tụ điện với độ chính xác cực kỳ cao. Lấy ví dụ, chúng tôi đã cắt tinh thể cho chiếc đồng hồ kỹ thuật số đầu tiên, Motorola Pulsar.

Chiếc máy vi tính chúng tôi lập trình là chiếc M365, một bản sao chiếc PDP-8 của Teradyne. Chúng tôi đã viết bằng ngôn ngữ assembly, và source code của chúng tôi được lưu giữ trên các cuộn băng từ. Mặc dù chúng tôi có thể sửa chữa code trên màn hình, nhưng quy trình đó khá rắc rối, vì vậy chúng tôi đã dùng các danh sách in cho phần lớn code của chúng tôi để đọc và sửa sơ bộ.

Chúng tôi không có phương tiện nào để tìm kiếm trên toàn bộ code base. Không có cách nào để tìm tất cả những nơi mà một function đã được gọi hoặc một hằng số đã được dùng. Như bạn có thể tưởng tượng, điều này gây khá nhiều trở ngại.

Vì vậy vào một ngày Tim và tôi quyết định là chúng tôi sẽ viết một chương trình tạo tham khảo chéo (cross-reference generator). Chương trình này sẽ đọc các cuộn băng mã nguồn của chúng tôi và in ra một danh sách của tất cả các ký hiệu, kèm với file và số dòng nơi mà ký hiệu đó được dùng.

Chương trình này ban đầu khá đơn giản để viết. Nó đơn giản là chỉ đọc trong các cuộn băng mã nguồn, phân tích cú pháp ngôn ngữ assembly, tạo ra một bảng ký hiệu, và thêm các tham chiếu vào các đầu nhập. Nó hoạt động tuyệt vời nhưng lại chậm kinh khủng. Nó phải mất hơn một giờ để xử lý Chương Trình Vận Hành Chủ (Master Operating Program – MOP) của chúng tôi.

Nguyên nhân nó chậm như vậy là do chúng tôi để bảng ký hiệu đang lớn dần trong một vùng nhớ đệm đơn. Bất cứ khi nào chúng tôi tìm thấy một tham chiếu mới, chúng tôi lại chèn nó vào trong bộ đệm đó, di chuyển phần còn lại của bộ đệm xuống vài byte để tạo không gian.

Tim và tôi không phải là những chuyên gia về cấu trúc dữ liệu và thuật toán. Khi đó chúng tôi chưa bao giờ nghe về các hash table[1] hay binary search[2]. Chúng tôi không có manh mối gì để tìm ra được một thuật toán nhanh hơn. Chúng tôi chỉ biết rằng thứ mà chúng tôi đang làm quá chậm.

Vì vậy chúng tôi đã thử hết cách này đến cách khác. Chúng tôi đã cố gắng đặt các tham chiếu vào trong các linked list[3]. Chúng tôi thử để những khoảng trống trong dãy dữ liệu và chỉ mở rộng vùng đệm khi những khoảng trống này đã đầy. Chúng tôi thử tạo ra những linked list của khoảng trống. Chúng tôi thử tất cả các loại ý tưởng điên rồ.

Chúng tôi đứng trước bảng trong văn phòng của chúng tôi và vẽ vài sơ đồ mô tả cấu trúc dữ liệu và thực hiện tính toán để dự đoán hiệu năng. Chúng tôi tới văn phòng mỗi ngày với một ý tưởng mới khác. Chúng tôi đã cộng tác với nhau giống như những người bạn.

Một vài thứ mà chúng tôi thử cũng giúp tăng hiệu năng. Một số thì còn làm chậm đi. Điều đó thật đáng buồn. Đây là lần đầu tiên tôi phát hiện ra việc tối ưu phần mềm khó như thế nào, và quy trình này không trực quan tý nào.

Cuối cùng thì chúng tôi cũng làm cho thời gian chạy giảm xuống dưới 15 phút, nó rất gần với khoảng thời gian cần để đọc một cuộn băng mã nguồn. Vì vậy chúng tôi khá hài lòng.

Lập trình viên Vs Mọi người

Chúng tôi không trở thành các lập trình viên bởi vì chúng tôi thích làm việc với con người. Như là một quy luật, chúng tôi thấy mối quan hệ giữa con người với nhau rất lộn xộn và khó đoán. Chúng tôi thích hoạt động gọn gàng và đoán biết trước được của những cỗ máy mà chúng tôi lập trình. Chúng tôi là những người hạnh phúc nhất khi chúng tôi ở một mình trong phòng nhiều giờ, tập trung cao độ vào một vài vấn đề thực sự thú vị.

OK, đó là một sự tổng quát hóa quá lớn và có vô số các trường hợp ngoại lệ. Có rất nhiều những lập trình viên giỏi trong việc làm việc với mọi người và thích thú với thử thách đó. Nhưng nhóm trung bình vẫn có khuynh hướng như tôi đã đề cập. Chúng tôi, những lập trình viên, thích được cảm giác yên lặng và chui mình vào trong tổ kén của sự tập trung.

Lập trình viên Vs Ông chủ

Trong những thập niên 70 và 80, khi đang làm việc lập trình ở Teradyne, tôi đã rèn luyện để trở thành thực sự giỏi việc debug. Tôi yêu thử thách này và sẽ dấn thân vào những vấn đề bằng tất cả đam mê và nhiệt tình. Không bug nào có thể trốn lâu dài được đối với tôi!

Khi tôi giải quyết được một bug, nó có cảm giác giống như giành được một chiến thắng, hay như tiêu diệt được Jabberwock[4]! Tôi sẽ tới gặp sếp tôi, Ken Finder, với lưỡi dao Vorpa[5] trên tay, và mô tả hăng say với ông ấy bug đó thú vị như thế nào. Một ngày nọ, Ken cuối cùng cũng đã bộc bạch trong thất vọng của tôi: “Các bug chẳng thú vị gì hết. Bug chỉ cần được sửa mà thôi!”

Tôi đã học được vài điều từ ngày hôm đó. Việc đam mê về những thứ chúng ta làm cũng là điều tốt. Nhưng bạn cũng cần để ý tới mục tiêu của những người trả tiền cho bạn.

Trách nhiệm đầu tiên của lập trình viên chuyên nghiệp là đáp ứng được yêu cầu của ông chủ. Điều đó có nghĩa là hãy cộng tác với những người quản lý, những người phân tích nghiệp vụ, những người kiểm tra, và những thành viên khác trong nhóm để hiểu sâu sắc về mục tiêu của công ty. Điều này không có nghĩa bạn phải trở thành một người am hiểu về kinh doanh. Nó có nghĩa là bạn cần hiểu tại sao bạn đang viết code, và cái công ty đã thuê bạn đó sẽ được lợi ích gì từ nó.

Điều tệ nhất mà một lập trình viên có thể làm là chôn vùi anh ta sung sướng trong một hầm mộ công nghệ trong khi mà công ty của anh ta thì đang lao đao và sắp bốc cháy rừng rực ngay bên cạnh. Công việc của bạn là phải giữ cho công ty đó không bị chết chìm!

Vì vậy, những lập trình viên chuyên nghiệp sẽ dành thời gian để hiểu về công ty của mình. Họ nói chuyện với người dùng về phần mềm mà họ đang sử dụng. Họ nói chuyện với nhân viên bán hàng và marketing về những vấn đề mà họ đang gặp phải. Họ nói chuyện với quản lý của họ để hiểu về các mục tiêu ngắn và dài hạn của nhóm.

Nói ngắn gọn, họ quan tâm tới con thuyền mà họ đang chèo trên đó.

Chỉ có một lần tôi bị đuổi việc khỏi công việc lập trình là vào năm 1976. Vào thời điểm đó, tôi đang làm việc cho tập đoàn Outboard Marine Corp. Tôi có nhiệm vụ viết một hệ thống tự động hóa nhà máy bằng các hệ thống máy tính IBM System/7 để theo dõi hàng tá những máy đúc nhôm trong nhà xưởng.

Về mặt kỹ thuật thì đây là một công việc thử thách và đáng làm. Kiến trúc của hệ thống System/7 thật hấp dẫn, và hệ thống tự động hóa nhà máy bản thân nó đã thực sự rất thú vị rồi.

Chúng tôi cũng có một nhóm thật tuyệt. Trưởng nhóm, John, là một người có trình độ và nhiệt tình. Hai đồng đội lập trình của tôi cũng là những người dễ thương và sẵn lòng giúp đỡ. Chúng tôi có một phòng thí nghiệm được dành riêng cho dự án, và tất cả chúng tôi đều làm việc trong phòng thí nghiệm đó. Đối tác kinh doanh của công ty cũng tham gia vào và làm việc trong phòng thí nghiệm đó với chúng tôi. Người quản lý chúng tôi, Ralph, là một người giỏi chuyên môn, tập trung, và chịu trách nhiệm.

Mọi thứ lẽ ra phải rất tuyệt vời. Vấn đề ở đây là tôi. Tôi có đủ đam mê về dự án này, và về công nghệ, nhưng ở tuổi 24 tôi đơn giản là không có chút quan tâm nào tới công ty và về cấu trúc chính trị nội bộ của nó.

Sai lầm đầu tiên của tôi là vào ngày đầu tiên đi làm. Tôi đã ra mắt mà không đeo cà-vạt. Tôi đã đeo khi đi phỏng vấn, và tôi đã thấy mọi người khác đều đeo cà-vạt, nhưng tôi đã không kết nối được với việc đó. Vì vậy vào ngày đầu tiên đi làm, Ralph đã gặp tôi và nói rõ rằng “Ở đây chúng ta phải đeo cà-vạt.”

Tôi không thể nói với bạn tôi bực tức về điều đó như thế nào. Nó làm tôi bực mình tới tận óc. Sau đó hằng ngày tôi đều đeo cà-vạt, và tôi ghét nó. Nhưng tại sao? Tôi biết tôi đang làm việc ở đâu. Tôi biết quy tắc họ đặt ra. Tại sao tôi lại bực mình nhỉ? Bởi vì tôi là một kẻ ti tiện đáng khinh nhỏ bé, chỉ yêu bản thân và ích kỷ.

Tôi không hoàn thành công việc đúng hạn. Và tôi nghĩ như vậy cũng chẳng sao. Sau cùng thì tôi cũng đang làm “tốt công việc”. Và đó là sự thực, tôi làm rất tốt công việc viết chương trình của tôi. Tôi dễ dàng trở thành lập trình viên kỹ thuật tốt nhất trong nhóm. Tôi có thể viết code nhanh hơn và tốt hơn bất cứ ai khác. Tôi có thể chẩn đoán và giải quyết các vấn đề nhanh hơn. Tôi biết là tôi rất có giá trị. Vì vậy thời gian và ngày tháng không quan trọng nhiều lắm đối với tôi.

Quyết định sa thải được đưa ra một ngày sau khi tôi không hoàn thành đúng thời hạn một cột mốc của dự án. John đã nói rõ với tất cả chúng tôi là anh ấy cần một bản demo của các chức năng đang hoạt động vào thứ Hai tới. Tôi chắc chắn là tôi biết về điều này, nhưng ngày tháng và thời gian đơn giản là không quan trọng đối với tôi.

Chúng tôi tích cực phát triển. Hệ thống vẫn chưa đưa vào hoạt động thực tế. Không có lý do gì để hệ thống chạy khi mà không có ai ở trong phòng thí nghiệm. Tôi lại là người cuối cùng rời khỏi đó vào thứ Sáu, và tôi rõ ràng đã để hệ thống đó ở trạng thái không hoạt động. Thực tế thì việc thứ Hai là một ngày quan trọng không hề nằm trong đầu tôi.

Tôi đã đi muộn một giờ vào ngày thứ Hai đó và nhìn mọi người tập trung ủ rũ xung quanh một hệ thống không hoạt động. John hỏi tôi, “Tại sao hôm nay hệ thống này không hoạt động, Bob?”. Câu trả lời của tôi: “Tôi không biết.” Và tôi ngồi xuống để debug nó. Tôi vẫn không hề suy nghĩ về buổi demo thứ Hai, nhưng tôi có thể biết có điều gì đó không ổn bằng ngôn ngữ cơ thể của những người khác xung quanh. Sau đó John tiến lại và thì thầm vào tai tôi, “Điều gì sẽ xảy ra nếu Stenberg quyết định ghé thăm nơi đây?” Sau đó ông ấy đi ra ngoài trong sự chán ghét.

Stenberg là VP[6] phụ trách tự động hóa. Ngày nay chúng ta gọi ông ấy là CIO[7]. Câu hỏi đó không có ý nghĩa gì đối với tôi cả. “Vậy thì sao chứ?” Tôi đã nghĩ. “Hệ thống này chưa đưa vào hoạt động, làm gì mà ghê gớm vậy?”

Tôi nhận được lá thư cảnh cáo đầu tiên vào ngày hôm sau. Bức thư viết rằng tôi phải thay đổi thái độ làm việc của tôi ngay lập tức hoặc “kết quả sẽ là việc chấm dứt hợp đồng nhanh chóng.” Tôi đã bị choáng váng!

Tôi dành một chút thời gian để phân tích cách hành xử của mình và bắt đầu nhận ra điều mà tôi đã làm sai. Tôi nói chuyện với John và Ralph về điều đó. Tôi quyết tâm thay đổi bản thân và công việc của mình.

Và tôi đã làm được! Tôi thôi không đi muộn. Tôi bắt đầu chú ý tới chính trị nội bộ. Tôi bắt đầu hiểu tại sao John rất lo lắng về Stenberg. Tôi bắt đầu hình dung ra tình huống xấu mà tôi đã đặt ông ấy vào khi không làm cho hệ thống hoạt động được vào ngày thứ Hai.

Nhưng những thứ đó là quá nhỏ bé, quá trễ rồi. Khuôn đã đúc xong. Tôi nhận một lá thứ cảnh cáo thứ hai một tháng sau đó vì một lỗi vặt mà tôi đã phạm phải. Tôi đã nhận ra rằng tại thời điểm đó, lá thư này chỉ mang tính thủ tục và quyết định chấm dứt hợp đồng với tôi đã được soạn sẵn. Nhưng tôi vẫn quyết tâm cứu vãn tình thế. Vì vậy tôi thậm chí đã làm việc chăm chỉ hơn.

Buổi họp chấm dứt hợp đồng diễn ra vài tuần sau đó.

Tôi đi về nhà ngày hôm đó với người vợ 22 tuổi đang bầu và phải nói với cô ấy rằng tôi đã bị đuổi việc. Đó là một trải nghiệm mà tôi không bao giờ muốn lặp lại lần nào nữa.

Lập trình viên Vs Lập trình viên

Các lập trình viên thường khó làm việc gần gũi với các lập trình viên khác. Điều này dẫn tới một số vấn đề thực sự kinh khủng.

Sở hữu code

Một trong những biểu hiện tệ nhất của một nhóm bất thường là khi mỗi lập trình viên xây một bức tường quanh code của anh ta và từ chối để những lập trình viên khác đụng vào nó. Tôi đã từng ở những nơi mà các lập trình viên thậm chí còn không cho lập trình viên khác xem code của họ. Đây là một công thức cho thảm họa.

Một lần tôi đã tư vấn cho một công ty mà nó đang phát triển các loại máy in cao cấp. Những chiếc máy này có nhiều bộ phận khác nhau như bộ cấp, bộ in, bộ xếp, bộ ghim, bộ cắt.v.v. Công ty này định giá mỗi thiết bị này khác nhau. Bộ cấp quan trọng hơn bộ xếp, và không gì quan trọng hơn bộ in.

Mỗi lập trình viên làm việc trên thiết bị của anh ta. Một tay viết code cho bộ cấp, một tay khác viết code cho bộ ghim. Mỗi người bọn họ nắm giữ công nghệ của họ và ngăn cho những người khác đụng vào code của họ. Ảnh hưởng chính trị mà những lập trình viên này nắm giữ thậm chí có ảnh hưởng trực tiếp tới việc công ty này định giá thiết bị mà họ phụ trách. Cậu lập trình viên làm việc với bộ in là bất khả xâm phạm.

Đây là một thảm họa đối với công nghệ. Là một nhà tư vấn tôi có thể thấy một số lượng khổng lồ code bị lặp lại và các interface giữa các module thì hoàn toàn lệch lạc. Nhưng không một lời khuyên nào của tôi có thể thuyết phục được những lập trình viên đó (hoặc công ty đó) thay đổi cách làm việc của họ. Dù gì thì việc đánh giá tiền lương của họ cũng gắn liền với mức độ quan trọng của thiết bị mà họ phụ trách mà.

Sở hữu tập thể

Tốt hơn nhiều nếu chúng ta phá vỡ tất cả các bức tường của việc sở hữu code và để cho nhóm là đối tượng sở hữu tất cả phần code đó. Tôi thích những nhóm mà bất cứ thành viên nào trong nhóm cũng có thể lấy về bất cứ module nào và tạo ra những thay đổi mà họ nghĩ là phù hợp. Tôi muốn nhóm sở hữu code, không phải là từng cá nhân.

Những lập trình viên chuyên nghiệp không ngăn chặn người khác làm việc trong code họ viết. Họ không dựng nên những bức tường chủ sở hữu quanh code họ viết. Thay vào đó, họ cùng nhau làm việc trên hệ thống đó nhiều nhất có thể. Họ học hỏi lẫn nhau bằng cách làm việc với những người khác trong những phần khác nhau của hệ thống.

Ghép đôi

Nhiều lập trình viên không thích ý thưởng lập trình ghép đôi. Tôi thấy lạ là phần lớn các lập trình viên sẽ ghép đôi trong trường hợp khẩn cấp. Tại sao? Bởi vì rõ ràng đó là cách hiệu quả nhất để giải quyết vấn đề. Nó chỉ đơn giản là cách làm theo câu châm ngôn cổ: Hai cái đầu thì tốt hơn là một cái đầu. Nhưng nếu ghép đôi là cách hiệu quả nhất để giải quyết một vấn đề trong trường hợp khẩn cấp, thì tại sao đó không phải là cách hiệu quả nhất để giải quyết vấn đề lúc bình thường?

Tôi sẽ không trích dẫn các nghiên cứu cho bạn, mặc dù tôi có thể đưa ra một vài cái. Tôi sẽ không kể cho bạn bất cứ giai thoại nào, mặc dù tôi có thể kể nhiều câu chuyện. Tôi thậm chí sẽ không nói cho bạn rằng bạn nên ghép đôi bao lâu. Tất cả điều tôi muốn nói với bạn đó là những lập trình viên chuyên nghiệp thì sẽ ghép đôi. Tại sao? Bởi vì ít nhất đối với một vài vấn đề thì đó là cách hiệu quả nhất để giải quyết. Nhưng đó không hẳn là nguyên nhân duy nhất.

Những lập trình viên chuyên nghiệp cũng ghép đôi bởi vì đó là cách tốt nhất để chia sẻ kiến thức với người khác. Những lập trình viên chuyên nghiệp không tạo ra những hầm chứa kiến thức. Thay vào đó, họ học những phần khác nhau của hệ thống và của công ty bằng cách ghép đôi với những người khác. Họ nhận thấy rằng mặc dù tất cả các thành viên trong nhóm đều có một vị trí chơi riêng, nhưng tất các thành viên trong nhóm cũng cần có thể chơi ở những vị trí khác trên sân.

Những người chuyên nghiệp ghép đôi bởi vì đó là cách tốt nhất để soát lại code. Không hệ thống nào mà lại chứa code chưa được soát lại bởi những lập trình viên khác. Có nhiều cách để tiến hành soát lại code; phần lớn chúng đều cực kỳ không hiệu quả. Cách hiệu quả nhất để soát lại code đó là cộng tác với nhau trong khi đang viết nó.

Tiểu não

Tôi đi trên chuyến tàu tại Chicago vào một buổi sáng năm 2000 trong thời kỳ cao trào của bong bóng “dot com” bị vỡ. Khi tôi bước xuống tàu trên sân ga, đập vào mắt tôi là một bảng thông cáo khổng lồ treo ở phía trên các cổng ra. Bảng hiệu này là của một công ty phần mềm danh tiếng đang tuyển dụng lập trình viên. Nó ghi: Hãy đến sử dụng tiểu não với những người giỏi nhất.

Tôi lập tức bị ấn tượng bởi sự ngu ngốc của một bảng hiệu như thế. Những người quảng cáo thiếu hiểu biết đang cố gắng thu hút một bộ phận các lập trình viên có kiến thức, thông minh, và kỹ thuật cao. Đây là loại người chắc chưa từng trải qua sự ngu xuẩn nào. Những người quảng cáo này đang có gắng gợi lên hình ảnh của việc chia sẻ kiến thức với những người rất thông minh khác. Không may thay, họ lại ám chỉ sai phần của bộ não, tiểu não, nó xử lý các điều khiển cơ bắp, chứ không phải là trí thông minh. Vì vậy rất nhiều người mà họ đang cố gắng thu hút đã giễu cợt một lỗi ngu ngốc như vậy.

Nhưng một điều khác đã kích thích tôi về bảng hiệu này. Nó làm tôi nghĩ về một nhóm người đang cố gắng sử dụng tiểu não. Do tiểu não ở đằng sau của bộ não, nên cách tốt nhất để sử dụng tiểu não là quay mặt lại người khác. Tôi tưởng tượng một nhóm các lập trình viên trong văn phòng, mỗi người ngồi một góc, quay lưng lại với người khác, nhìn chằm chằm vào màn hình trong khi đang đeo tai nghe. Đó là cách bạn sử dụng tiểu não đấy. Đó cũng không phải là một nhóm làm việc.

Những người chuyên nghiệp làm việc cùng nhau. Bạn không thể làm việc cùng nhau trong khi bạn ngồi tại một góc đeo tai nghe. Vậy nên tôi muốn bạn ngồi quanh bàn đối diện với những người khác. Tôi muốn bạn có thể đánh hơi thấy nỗi sợ hãi của người khác. Tôi muốn bạn có thể nghe thấy những lời lẩm bẩm bực bội của người khác. Tôi muốn có những giao tiếp thường xuyên, cả bằng miệng và bằng ngôn ngữ cơ thể. Tôi muốn bạn giao tiếp như một thực thể.

Có thể bạn tin rằng bạn làm việc tốt hơn khi bạn làm việc một mình. Điều đó có thể đúng, nhưng điều đó không có nghĩa là nhóm của bạn làm việc tốt hơn khi bạn làm việc một mình. Và, trong thực tế, rất khó có khả năng là bạn làm việc tốt hơn khi bạn làm việc một mình.

Có những lúc khi làm việc một mình là điều nên làm. Có những lúc bạn cần suy nghĩ lâu và kỹ lưỡng về một vấn đề. Có những lúc công việc vặt vãnh đến nỗi sẽ là lãng phí nếu phải thêm một người khác làm việc cùng bạn. Nhưng, nói chung, tốt nhất là bạn hãy cộng tác chặt chẽ với những người khác và ghép đôi với họ trong phần lớn thời gian.

Kết luận

Có lẽ chúng ta không thích công việc lập trình phải làm việc với con người. Thật may mắn cho chúng ta. Làm lập trình thì có nghĩa là phải làm việc với con người. Chúng ta cần làm việc với khách hàng, và chúng ta cần làm việc với người khác. Tôi biết, tôi biết. Không phải thật tuyệt với ư nếu họ chỉ việc giam họ trong phòng với 6 màn hình khổng lồ, một dãy các bộ vi xử lý siêu nhanh chạy song song, RAM và ổ đĩa không giới hạn, và nguồn cung cấp vô hạn coca ăn kiêng và snack ngô cay? Lạy chúa, nó không phải như vậy. Nếu chúng ta thực sự muốn dành thời gian của chúng ta để lập trình, chúng ta sẽ phải học cách để nói chuyện với – con người.


[1] hash table: bảng băm, một loại cấu trúc dữ liệu.

[2] binary search: tìm kiếm nhị phân, một thuật toán tìm kiếm nhanh chóng.

[3] linked list: danh sách kết nối, một loại cấu trúc dữ liệu.

[4] Jabberwock: một con quái vật trong chuyện Alice ở xứ sở thần tiên.

[5] Vorpa: vũ khí của Alice trong chuyện.

[6] VP: Vice President – Phó Chủ Tịch.

[7] CIO: Chief Information Officer – Giám đốc Công nghệ thông tin.

Trả lời

Email của bạn sẽ không được hiển thị công khai.