[Part2] Pragmatic programmer - triết lý thực dụng (chương 1)

Part 1 - Thế nào là lập trình viên thực thụ

Tiếp nối seri về pracmatic programmer mình xin chia sẻ chương 2 của cuốn sách với tiêu đề: A pracmatic philosophy - một triết lý thực dụng.

Trong chương này, thông qua 6 câu chuyện ngắn sau, tác giả trình này cơ bản về triết lý thực dụng.

1, The cat ate my source code - con mèo đã ăn mã nguồn của tôi

Đừng đổ lỗi cho con mèo hay ai đó khi xảy ra lỗi lầm trong công việc của bạn!

Nền tảng của triết lý thực dụng là ý thức trách nhiệm đối với bản thân và hành động của bạn về sự thăng tiến trong sự nghiệp, dự án và công việc hàng ngày. Một lập trình viên thực dụng sẽ không ngại thừa nhận sự sai sót hay thiếu hiểu biết của mình. Việc sai sót hay thiếu hiểu biết về điều gì đó là việc thường xuyên xảy ra trong thế giới lập trình, ngay ở những dự án tốt nhất. Dù đã kiểm tra kỹ lưỡng, tài liệu đầy đủ nhưng vẫn có những điều rủi ro, vấn đề kỹ thuật không lường trước xảy ra, hay là giao hàng trễ.

Khi những điều này xảy ra, hãy giải quyết chúng 1 cách chuyên nghiệp nhất- có nghĩa là trung thực và trực tiếp. Chúng ta có thể tự hào về khả năng của mình nhưng cũng phải thành thật về những thiếu sót cũng như sai lầm của chính mình.

Chịu trách nhiệm

Trách nhiệm là điều bạn đã chủ động nhận lấy. Bạn phải cam kết và đảm bảo rằng điều đó phải được thực hiện đúng. Nhưng không có nghĩa là bạn phải kiểm soát trực tiếp mọi mặt của việc đó. Ngoài ra, cần phản phân tích tình hình để nhận biết những rủi ro nằm ngoài tầm kiểm soát. Bạn có quyền không chịu trách nhiệm với những tình huống bất khả thi hay rủi ro quá lớn.

Khi bạn nhận trách nhiệm về 1 kết quả, bạn phải chịu trách nhiệm cho việc đó. Khi bạn gây ra sai lầm trong hành động hay phán đoán thì thừa nhận và đưa ra phương án giải quyết. Đừng đổ lỗi cho ai hay nguỵ biện. Đừng đổ lỗi cho ngôn ngữ lập trình, các công nghệ hay đồng nghiệp. Những điều này có thể đóng một vai trò nào đó nhưng phụ thuộc vào bạn đưa ra giải pháp nào đó chứ không phải là bào chữa.

Nếu biết trước rủi ro thì cần có kế hoạch đối phó dự phòng. Giả sử ổ đĩa bị lỗi làm mất dữ liệu và mã nguồn mà bạn không có bản sao lưu dữ liệu thì đó là lỗi của bạn. Nói "con mèo đã ăn mất mã nguồn" không phải là cách giải quyết.

Tip3: Provide Options, Don’t Make Lame Excuses - Đưa ra các phương án, không viện lý do

Trước khi nói với ai đó về lý do bạn không thể hoàn thành hay làm lỗi việc gì thì hãy dừng lại và lắng nghe bản thân. Có thể dùng phương pháp nói chuyện với con vịt cao su (phương pháp Rubber Duck Debugging) và đánh giá xem lời bào chữa hợp lý hay ngu ngốc? Liệu có nên nói những lời đó cho sếp của bạn hay không?

Qua cuộc tự trò chuyện trong đầu, người khác có thể nói gì? Họ có thể sẽ hỏi bạn: đã thử cái này chưa? có hiểu cái đó chứ? Bạn sẽ trả lời thế nào? Trước khi bạn đi và nó với họ về tin xấu, bạn có thử tự nhìn lại vấn đề và đưa ra một vài đáp án trước. Bạn có thể biết trước họ sẽ nói gì và đừng chỉ đưa cho họ vấn đề.

Thay vì bào chữa cho lỗi lầm thì hãy đưa ra các phương án. Đừng nói rằng không thể thực hiện được mà trình bày những gì có thể thực hiện để cứu vãn tình hình. Nếu bạn cần tài nguyên, đừng ngại hỏi hay thừa nhận rằng mình cần sự giúp đỡ.

2, Software entropy.

Entropy là 1 khái niệm vật lý để chỉ độ hỗn loạn trong hệ thống. Trong ngành phần mềm, khi sự hỗn loạn gia tăng thì lập trình viên gọi đó là phần mềm thối hay code thối.

Có nhiều nguyên nhân gây lên code thối. Việc này thường do tâm lý và văn hoá trong dự án. Vấn đề này rất tế nhị. Một dự án có kế hoạch tốt vẫn có thể bị huỷ hoại trong quá trình thực thi.
Chúng ta cùng tham khảo câu chuyện về cái cửa sổ vỡ: trong 1 thành phố sạch đẹp, một cửa sổ bị vỡ và không được sửa chữa trong suốt một thời gian. Người dân sống trong toà nhà cảm thấy không được ban quản lý quan tâm vì vấn đề trên. Và rồi, một cánh cửa khác lại bị vỡ. Mọi người bắt đầu xả rác lung tung khắp nơi. Trong một thời gian ngắn, toà nhà bị hư hỏng tới mức chủ toà nhà không muốn hoặc không thể sửa chữa nữa. Cảm giác bị rỏ rơi ban đầu trở thành sự thật.

Lý thuyết cửa sổ vỡ đã truyền cảm hứng cho sở cảnh sát NewYork truy quét những thứ nhỏ nhất để ngăn chặn những thứ lớn hơn. Họ hoạt động theo nguyên tắc: bảo vệ, sửa chữa những cửa sổ vỡ, xoá các hình vẽ grafiti và chặn các hành vi vi phạm nhỏ. Điều nàylàm giảm mức độ tội phạm nghiêm trọng

Tip4: Don't live with broken windows

Vậy bài học ở đây là, không để các cửa sổ vỡ (lỗi thiết kế, quyết định sai, code kém) ở trạng thái không được sửa chữa. Hãy sửa chữa từng thứ một sớm nhất có thể khi phát hiện. Nếu không đủ thời gian sửa chữa thì hãy ghi lại. Nếu có thể comment những dòng code vi phạm. Thực hiện một số hành động để ngăn chặn thiệt hại và thực thi giải pháp.

Các hệ thống sạch, tốt sẽ xuống cấp nhanh sau khi có cửa sổ hỏng. Sự lơ là sẽ đẩy nhanh sự mục nát hơn bất kỳ yếu tốt nào khác. Nếu bạn nghĩ không ai có thời gian để đi dọn dẹp tất cả các mảnh kính vỡ của 1 công trình thì tốt nhất bạn nên chuyển đi nơi khác. Đừng để entropy chiến thắng.

Dập lửa

Có một ngôi nhà với nhiều đồ cổ bắt đầu bốc cháy. Đội cứu hoả đang tiến hành phun nước dập lửa thì phát hiện một tấm thảm quý giá. Họ ngừng phun nước vì sợ làm hỏng tấm thảm đó. Ngọn lửa hoành hành và thiêu rụi những đồ quý giá hơn

Câu chuyện tương tự cũng xảy ra trong thế giới lập trình. Một cửa sổ vỡ - 1 đoạn code được thiết kế kém hay một quyết định quản lý kém tồn tại lâu dài là những gì cần để bắt đầu sự đi xuống của dự án. Tương tự, nếu bạn ở trong một dự án tốt với code đẹp - rõ ràng, thiết kế tốt, tuân thủ coding convention - bạn cần đặc biệt cẩn thận để không làm code rối lên.

3, Stone Soup and Boiled Frogs

Câu chuyện nồi súp đá

Có 3 người lính trở về làng sau khi cuộc chiến kết thúc. Khi họ nhìn thấy ngôi làng, họ cảm thấy rất sung sướng vì tin rằng dân làng sẽ chào đón bằng một bữa ăn ngon. Nhưng khi họ đến thì thấy thấy một ai, các cánh cửa đóng kín. Sau chiến tranh, dân làng thiếu ăn và không có nhiều đồ tích trữ. Không nản lòng, các chiến sỹ đun một nồi nước và đặt 3 viên đá vào đó. Một vài dân làng nhìn thấy và kinh ngạc.

Những người lính giải thích: "Đó là súp đá?"

Dân làng hỏi: "Đó là tất cả những gì trong đó sao?"

"Đúng vậy nhưng sẽ ngon hơn nếu có cà rốt".

Có 1 người dân làng trở về và lấy vài củ cà rốt mình đã tích trữ ra. Có người khác lại hỏi: "Vậy là được rồi chứ?"

"Chà, vài củ khoai tây sẽ tốt cho cơ thể" - Thế là lại có người về và mang tới vài củ khoai tây.

Câu chuyện tiếp diễn trong vài giờ sau thì nồi súp trở nên thơm ngon với nhiều thành phần: thịt bò, tỏi tây, muối, rau thơm... Cuối cùng họ có một nồi súp thơm ngon. 3 người lính bỏ 3 hòn đá ra và cùng dân làng thưởng thức nồi súp đó. Đây là bữa ăn ngon nhất trong nhiều tháng gần đây của họ.

Chúng ta có thể thấy những người lính đã lợi dụng sự tò mò của dân làng để lừa họ quyên góp những thực phẩm riêng của mình.

Quan trọng hơn, những người lính như chúc xúc tác, kéo dân làng lại với nhau và cùng tạo ra một thứ mà họ không thể làm một mình - một kết quả tổng hợp. Cuối cùng thì mọi người cùng thắng.

Trong thực tế, nhiều tính huống bạn cần đóng vai trò như những người lính để có thể tập tợp đủ tài nguyên cần thiết từ nhiều cá nhân, bộ phận. Mọi người sẽ bảo vệ tài nguyên của chính họ. Đó là lúc bạn đưa những viên đá ra - đó có thể một điều tưởng như vô lý nhưng để họ quan tâm và tham gia cùng. Chỉ cho họ thấy sự đóng góp của họ giúp mục đích đến gần hơn từng chút một. Cho họ nhìn thấy tương lai và họ sẽ tập hợp quanh bạn

Tip5: Be a catalyst for change - hãy là chất xúc tác cho sự thay đổi

Phía dân làng

Câu chuyện nồi canh đá còn nói về sự lừa dối nhẹ nhàng một cách từ từ. Dân làng chỉ tập trung vào viên đá mà quên đi những thứ khác. Họ tỏ ra yêu thích và quan tâm chúng mỗi ngày.

Các dự án chậm chạp, không ổn định, mất kiểm soát đều bắt đầu từ những sai lầm nhỏ, khó thể nhận thấy được. Chúng diễn ra hàng ngày. Các hệ thống thay đổi các thông số kỹ thuật cũng như yêu cầu liên tục cho các tính năng. Các bản vá lỗi được thêm vào cho đến khi không còn nhận ra sản phẩm ban đầu. Các lỗi nhỏ khó nhận biết được tích luỹ lâu dài sẽ thành một vấn đề lớn và làm mất tinh thần cả đội. Nó tương tự như câu chuyện nếu thả con cóc  vào nồi nước nóng thì nó nhảy ra ngay. Nhưng nếu thả vào trong nồi nước lạnh rồi đun từ từ thì nó sẽ ở trong đó tới khi bị luộc chín

Tip6: Remember the big picture - nhớ về bức tranh lớn, cái toàn cảnh

4, Good- enough software

Chúng ta luôn cố gắng kiểm soát chất lượng nhưng  thực tế không nhiều thứ có thể hoàn hảo, đặc biệt là phần mềm không lỗi. Thời gian, công nghệ, con người đều chống lại điều đó. Tuy nhiên bạn có thể tạo ra phần mềm đủ tốt - đủ tốt cho người dùng, đủ tốt cho người bảo trì trong tương lai để bạn yên tâm hơn. Bạn sẽ thấy mình làm việc hiệu quả hơn và người dùng hạnh phúc hơn. Và bạn cũng thấy sản phẩm của mình tốt hơn trong thời gian phát triển ngắn hơn.

Cụm từ "đủ tốt" không nghĩa là được phép cẩu thả hoặc viết code kém chất lượng. Hệ thống phải đáp ứng yêu cầu người dùng. Điểm mấu chốt là tạo cơ hội để người dùng tham gia vào quá trình quyết định sản phẩm của bạn là đủ tốt ( nhận phản hồi của người dùng về kết quả làm ra một cách thường xuyên).

Thu hút người dùng tham gia thường xuyên

Chúng ta thường nhận yêu cầu từ người khác và viết phần mềm cho họ. Nhưng bạn có thường hỏi họ muốn sản phẩm tốt đến mức nào? Đôi khi không có lựa chọn. Nếu làm những dự án đòi hỏi độ chính xác cao như máy điều hoà nhịp tim, tàu con thoi... thì các yêu cầu sẽ nghiêm ngặt và sự lựa chọn cũng bị hạn chế. Nhưng khi bạn hát triển một sản phẩm mới thì có thể sẽ có nhiều lựa chọn hơn. Công ty hứa chuyển giao sản phẩm tới người dùng cuối đúng hẹn với nguồn tiền ít ỏi. Bạn không thể bỏ qua các yêu cầu mới nhưng cũng không thể tăng thời gian phát triển hay bỏ qua những quy trình kỹ thuật để rút ngắn thời gian.

Phạm vi và chất lượng hệ thống phải được chỉ định như một yêu cầu hệ thống.

Tip7: Make Quality a Requirements Issue - tiêu chuẩn chất lượng cho yêu cầu cần làm

Bạn thường xuyên ở trong tình huống phải đánh đổi. Phần mềm tuyệt vời hôm nay được ưa chuộng hơn là phần mềm hoàn hảo vào ngày mai. Nếu người dùng được sử dụng sản phẩm sớm thì phản hồi của họ sẽ dẫn bạn tới những giải pháp tốt hơn.

Biết thời điểm dừng

Ở góc độ nào đó, lập trình giống như vẽ tranh. Bạn bắt đầu với giấy và các nguyên liệu thô. Bạn kết hợp khoa học nghệ thuật và thủ công để quyết định làm gì với chúng. Bạn phác thảo, vẽ lớp nền rồi tới những chi tiết. Bạn liên tục lùi lại với con mắt phê phán để xem mình đã làm được những gì. Thỉnh thoảng bạn sẽ vứt bỏ bức tranh và bắt đầu lại.

Các nghệ sỹ nói rằng tất cả các công việc khó khăn sẽ bị phá hoại nếu không biết khi nào nên dừng lại. Nếu bạn đè thêm 1 lớp màu, chi tiết này đè lên chi tiết khác thì bức tranh sẽ biến mất trong lớp sơn đó.  Đừng làm hỏng một chương trình hoàn toàn tốt bằng cải tiến quá mức. Hãy tiếp tục và để code của bạn đúng vị trí của nó trong 1 thời gian. Nó có thể không hoàn hảo. Đừng lo lắng: nó không bao giờ có thể hoàn hảo.

<Updating...>
TO DO:
5, Your Knowledge Portfolio

6, Communicate!