Chỉ có mã nguồn mới nói lên sự thật

Chỉ có mã nguồn mới nói lên sự thật

Peter Sommerlad

Tính đích thực của một chương trình được thể hiện qua mã (code) thi hành. Nếu chỉ ở dạng nhị phân (binary), code sẽ rất khó đọc! Tuy nhiên, mã nguồn (source code) cần sẵn có nếu đây là chương trình của bạn, là quá trình phát triển một phần mềm thương mại, là một dự án nguồn mở (open source), hay code trong một ngôn ngữ thông dịch động (dynamic interpreted language). Khi bạn đọc source code, ý nghĩa của chương trình cần phải toát lên một cách hiển nhiên. Muốn biết chương trình làm gì, source code là thứ sau cùng bạn cần phải đọc. Thậm chí tài liệu thu thập yêu cầu chính xác nhất cũng không thể nói lên sự thật: nó không chi tiết những gì chương trình đang thật sự thi hành, đó chỉ là ý định mức cao của người phân tích yêu cầu. Tài liệu thiết kế có thể trình bày thiết kế đã được vạch sẵn, song lại thiếu chi tiết cần thiết của công đoạn hiện thực. Các tài liệu này có thể đã không còn đồng bộ với thực tế ... hoặc có lẽ chúng đã thất lạc. Hay chưa từng được viết ra. Source code có thể là thứ duy nhất còn sót lại.

Với hiểu biết như trên, bạn hãy tự vấn xem code của bạn phải sáng tỏ đến đâu để code có thể kể cho bạn hoặc cho một lập trình viên bất kỳ về điều mà code đang làm.

Bạn có thể bảo, "Ôi chào, chú thích trong code của tôi sẽ giải thích mọi điều bạn cần." Nhưng hãy nhớ cho rằng chú thích không là code. Chúng có thể sai sót như các dạng tài liệu khác. Truyền thống mặc nhiên cho rằng chú thích là hành vi tốt, nên một số lập trình viên mù quáng chú thích thật nhiều, thậm chí còn tường thuật, giảng giải những chi tiết vụn vặt và hiển nhiên trong code. Đây là con đường sai lầm trong nỗ lực khiến code của bạn trở nên trong sáng.

Nếu bạn cần chú thích cho code, hãy xét đến khả năng tái cấu trúc (refactoring) để không cần phải chú thích nữa. Chú thích dài dòng có thể gây rối màn hình và thậm chí còn bị IDE (môi trường phát triển tích hợp) của bạn tự động che khuất. Nếu cần diễn giải về một thay đổi, hãy gửi thông điệp vào hệ thống kiểm soát phiên bản (version control system) chứ đừng chú thích trong code.

Bạn có thể làm gì để thật sự khiến code của bạn nói lên sự thật càng sáng tỏ càng tốt? Hãy gắng đặt tên cho đúng. Cấu trúc code theo tính năng cố kết, nhờ đó còn tạo điều kiện dễ dàng cho việc đặt tên. Phân rã code nhằm đạt được tính trực giao. Hãy viết mã kiểm thử tự động (automated tests) hầu giải thích hành vi dự kiến và kiểm chứng giao diện. Không ngừng refactor sau khi đã biết cách đưa ra một giải pháp đơn giản hơn và hoàn thiện hơn. Hãy biến code của bạn trở nên càng dễ đọc và dễ hiểu chừng nào, càng tốt chừng ấy.

Hãy xem code của bạn là một công trình soạn thảo, tựa một bài thơ, bài luận, blog trước công chúng, hay một điện thư (email) quan trọng. Hãy cẩn thận trau chuốt hầu biểu đạt được mục đích và trực tiếp thể hiện điều mà code đang làm; sao cho code có thể tiếp tục diễn đạt được ý định của bạn khi bạn không còn ở đó. Nhớ rằng code nào ích lợi sẽ được sử dụng lâu dài hơn ý định ban đầu. Các lập trình viên bảo trì sẽ cảm ơn bạn. Và nếu bạn là một lập trình viên bảo trì, đồng thời code bạn đang bảo trì không dễ toát lên sự thật, hãy chủ động vận dụng những hướng dẫn vừa nêu. Hãy thiết lập một tiêu chuẩn lành mạnh cho code, và duy trì sự lành mạnh của chính bạn.

Nguồn

Sommerlad P. (2010) Only the Code Tells the Truth, 97 Things Every Programmer Should Know, Henney K. (ed), O'Reilly, Sebastopol, CA.

Hãy chia sẻ kiến thức và kinh nghiệm

Hãy chia sẻ kiến thức và kinh nghiệm

Paul W. Homer

Ta học hỏi được rất nhiều từ cả kinh nghiệm thành công lẫn thất bại. Trong một nền công nghiệp non trẻ như phát triển phần mềm, phổ biến kinh nghiệm và tri thức đóng vai trò sống còn hầu hỗ trợ tiến trình phát triển vững bền. Bài học của một nhóm ở nơi khỉ ho cò gáy vẫn có thể tác động đến toàn thế giới.

Thật sự mà nói, kiến thức cơ bản của ta về phát triển phần mềm, tức những tri thức đúng tuyệt đối về mặt lý thuyết, còn nhỏ nhoi so với yêu cầu phát triển thành công dự án. Để bù đắp, chúng ta buộc phải phỏng đoán dựa trên đánh giá trực quan, hoặc thậm chí làm bừa. Bằng cách đó, các dự án phát triển quan trọng có thể cung cấp bằng chứng thực nghiệm về thành công cũng như thất bại. Ta từng bước thử nghiệm qua nhiều trường hợp, để rồi tái áp dụng vào nền công nghiệp trên qui mô tổng thể.

Ở mức độ cá thể, ai cũng gắng tiến bộ để học được cách xây dựng hệ thống ngày càng lớn. Con đường nghề nghiệp sẽ đưa ta đến những thử thách ngày càng cao, vì vậy mà ta muốn kinh nghiệm quá khứ có thể hướng dẫn chúng ta. Muốn là một chuyện, song để học được từ kinh nghiệm, ta thường phải hợp lý hóa nó. Cách hay nhất và dễ nhất là gắng diễn giải kinh nghiệm cho một người khác.

Thảo luận luôn giúp chỉ ra thiếu sót. Bạn chưa thật sự hiểu nếu bạn chưa giải thích được một cách lưu loát. Chính nhờ nỗ lực trình bày và thảo luận mà ta có thể biến kinh nghiệm thành tri thức.

Mặt khác, tuy có thể đã trải qua nhiều kinh nghiệm cụ thể, suy luận rút ra từ đó có thể chưa thật chính xác trong bối cảnh chung. Có thể ta chưa thành công hoặc tài trí như mong muốn. Tất nhiên việc thử nghiệm kiến thức của bạn trước bàn dân thiên hạ sẽ thật đáng sợ, đặc biệt là lúc bạn nhận ra điều mà bạn trân quý chỉ là hoang tưởng, sai lầm, hay chẳng bao giờ là chân lý; thật khó chấp nhận khi mình sai.

Suy cho cùng, không phải mọi điều trong tâm trí con người chúng ta đều đúng; không phải mọi thứ mình nghĩ cũng đều hợp lý. Chỉ khi nào biết thừa nhận sai lầm thì ta mới có cơ may tiến bộ. Ngạn ngữ "thất bại là mẹ thành công" là chân lý. Nếu ý tưởng và niềm tin của ta không trụ vững khi tranh luận, tốt hơn là biết được ngay, để sau này khỏi phải xây dựng trên đó.

Ta thật sự mong muốn chia sẻ tri thức và kinh nghiệm để ngành công nghiệp tiến bộ; đồng thời nhận thức rằng điều này sẽ giúp mình hiểu biết và sửa sai. Trước hiện trạng phát triển phần mềm, ta cần tận dụng mọi cơ hội hầu chia sẻ điều mình biết, điều ta nghĩ rằng ta biết, và những gì ta đã chứng kiến. Nếu hỗ trợ đồng nghiệp xung quanh tiến bộ, họ sẽ giúp ta phát huy được hết tiềm năng của mình.

Nguồn

Homer P.W. (2009) Share your knowledge and experiences, 97 Things Every Software Architect Should Know, Monson-Haefel R. (ed), O'Reilly, Sebastopol, CA.

Điều lệ Hướng đạo

Điều lệ Hướng đạo

Robert C. Martin

Hướng đạo có một điều lệ: "Luôn thu dọn nơi cắm trại sạch đẹp hơn lúc bạn đến." Nếu nơi nào bừa bộn, hãy dọn sạch nơi đó mà không cần biết ai đã gây ra. Bạn có ý cải thiện môi trường cho đoàn cắm trại tiếp theo. (Thật ra, nguyên bản của điều lệ này, do Robert Stephenson Smyth Baden-Powell, nhà sáng lập phong trào hướng đạo, viết ra như sau, "Hãy gắng để lại thế giới này tốt hơn một tí so với thời điểm bạn phát hiện ra nó.")

Điều gì sẽ đến nếu ta áp dụng điều lệ này cho mã (code) của ta: "Luôn làm cho mã (module) gọn gàng hơn so với lúc bạn tiếp nhận nó"? Không màng đến ai là tác giả đầu tiên, điều gì sẽ diễn ra nếu ta luôn nỗ lực cải thiện module, dù chỉ là nỗ lực nhỏ nhoi? Kết quả sẽ ra sao?

Tôi nghĩ rằng nếu tất cả chúng ta đều tuân thủ điều lệ đơn giản đó, ta sẽ thấy hồi kết của hiện tượng các hệ thống phần mềm suy thoái không ngừng. Thay vào đó, hệ thống của ta sẽ tốt dần lên theo sự tăng trưởng. Ta cũng sẽ thấy cả tập thể cùng quan tâm chăm sóc hệ thống chung, thay vì từng cá nhân chăm chút cho riêng mình.

Tôi không nghĩ rằng điều lệ này quá đáng. Bạn không buộc phải hoàn thiện mọi module trước khi chuyển giao. Bạn chỉ cần làm sao cho nó tốt hơn một tí so với lúc bạn tiếp nhận nó. Dĩ nhiên, bất kỳ code nào mà bạn thêm vào module đều phải gọn gàng. Bạn cũng cần dọn dẹp ít ra là một điều gì khác trước khi bạn chuyển giao. Có thể bạn chỉ đặt lại tên một biến (variable) cho tốt hơn, hoặc phân chia một chức năng (function) dài thành hai functions nhỏ hơn. Bạn có thể phá vỡ một chu trình phụ thuộc (circular dependency), hay bổ sung một giao diện (interface) nhằm tách bạch một điều khoản (policy) ra khỏi chi tiết.

Thật lòng, đối với tôi đây có vẻ như phép xử thế thông thường – giống như hành động rửa tay sau khi đi vệ sinh, hay bỏ rác vào thùng thay vì xả ra đường. Hành động code cẩu thả cần bị xã hội lên án giống như hành vi xả rác. Hành động đó cần bị gán cho là chưa hoàn thành nhiệm vụ.

Song không thể dừng lại ở đó. Chăm sóc code của chính mình là một nhẽ. Chăm sóc code cho tập thể lại là chuyện khác. Tập thể cần hỗ trợ nhau dọn dẹp hết chỗ này đến chỗ kia. Tập thể cùng tuân theo điều lệ Hướng đạo bởi vì điều đó tốt cho mọi người, không phải chỉ có lợi cho bản thân họ.

Nguồn

Martin R. C. (2010) The Boy Scout Rule, 97 Things Every Programmer Should Know, Henney K. (ed), O'Reilly, Sebastopol, CA.

Vẻ đẹp nằm ở sự giản dị

Vẻ đẹp nằm ở sự giản dị

Jørn Ølmheim

MỘT PHÁT BIỂU của Plato mà tôi cho rằng mọi lập trình viên cần phải nằm lòng:

Vẻ đẹp của phong cách, của nét hài hòa, của tính thanh lịch và nhịp độ, đều tùy thuộc vào sự giản dị.

Một câu thôi, đã tổng kết được mọi giá trị mà lập trình viên chúng ta cần phải hướng tới.

Ta phấn đấu để mã (code) được

• Dễ hiểu
• Dễ bảo trì
• Dễ phát triển
• Đẹp

Plato bảo rằng có một nhân tố ảnh hưởng đến tất cả những phẩm chất trên, đó là sự giản dị.

Code thế nào là đẹp? Đây là câu hỏi hết sức chủ quan. Nhận thức về vẻ đẹp phụ thuộc rất nhiều vào cá tính, cũng như vào nhận thức của chúng ta về vạn vật. Nghệ nhân nhận thức (hay ít ra là tiếp cận) vẻ đẹp khác với khoa học gia. Nghệ nhân có khuynh hướng so sánh vẻ đẹp phần mềm (software) với vẻ đẹp của các công trình nghệ thuật, trong khi đó, khoa học gia lại bàn về sự cân đối và hoàng kim tỉ lệ (golden ratio), gắng qui mọi thứ về công thức. Theo kinh nghiệm của tôi, giản dị là nền tảng của hầu hết những lập luận từ cả hai phía.

Hãy tư duy trên code mà bạn đã từng tìm hiểu. Nếu chưa dành thời gian nghiên cứu code của người khác, bạn nên dừng đọc ngay đây để tìm hiểu một đoạn mã nguồn mở (open source code). Tôi nói nghiêm túc đấy! Hãy tìm trên Web một đoạn code do chuyên gia nổi tiếng viết bằng ngôn ngữ mà bạn ưa thích.

Xong rồi à? Tốt lắm. Ta đã bàn đến đâu nhỉ? À, đúng rồi... Tôi thấy rằng code đó cộng hưởng với tôi, đồng thời vẻ đẹp có một số nét chung. Trên hết là sự giản dị. Tôi nhận ra rằng cho dù toàn bộ ứng dụng hay hệ thống có phức tạp đến đâu, từng bộ phận đơn lẻ đều phải duy trì được tính giản dị: các đối tượng (objects) đơn giản có trách nhiệm duy nhất, chứa những phương thức (methods) vừa giản tiện vừa tập trung, vừa có tên gọi dễ hiểu. Một số cho rằng việc tạo ra các methods từ 5 đến 10 dòng code là cực đoan, và một vài ngôn ngữ rất khó thể hiện được điều này, song tôi cho rằng giản dị là một mục tiêu cần thiết.

Chốt lại: code đẹp là code giản dị. Từng thành phần đơn lẻ được duy trì sao cho giản tiện, trách nhiệm đơn sơ, và có quan hệ đơn giản với các bộ phận khác trong hệ thống. Đây là cách duy trì khả năng bảo trì hệ thống theo thời gian, thông qua code gọn, đơn giản, dễ kiểm thử, đảm bảo tốc độ phát triển nhanh trong toàn thời gian tồn tại của hệ thống.

Vẻ đẹp được tạo tác và được khám phá từ sự giản dị.

Nguồn

Ølmheim S. (2010) Beauty Is in Simplicity, in 97 Things Every Programmer Should Know, Henney K. (ed.), O'Reilly, Sebastopol, CA.

Hãy lập trình với tinh thần phải bảo trì cho đến chết

Hãy lập trình với tinh thần phải bảo trì cho đến chết

Yuriy Zubarev

Khi hỏi 97 người rằng mọi lập trình viên phải học những gì và cần làm gì, bạn có thể nhận được 97 lời khuyên khác nhau. Kết quả này có thể khiến bạn cảm thấy quá sức và lo sợ. Lời khuyên nào cũng hay, nguyên tắc nào cũng hợp lý, và câu chuyện nào cũng đầy thuyết phục, song phải bắt đầu từ đâu? Quan trọng hơn, một khi đã bắt đầu, làm thế nào duy trì được tất cả các thực hành tốt mà bạn đã học, và làm thế nào tích hợp được chúng vào kỹ năng lập trình của mình?

Tôi nghĩ rằng câu trả lời nằm trong tâm, cụ thể hơn là ở thái độ của bạn. Chẳng hạn, nếu chẳng màng đến đồng nghiệp lập trình, kiểm thử, quản lý, bán hàng, tiếp thị, và người sử dụng, bạn sẽ không bị thôi thúc áp dụng phương pháp phát triển phần mềm dựa trên kiểm thử (test-driven development), hoặc không muốn chú thích rõ ràng trong chương trình. Tôi nghĩ rằng có một cách đơn giản để điều chỉnh thái độ của bạn và luôn thôi thúc bạn xuất xưởng những sản phẩm có chất lượng tuyệt hảo, đó là

Hãy lập trình với tinh thần phải bảo trì cho đến chết

Chỉ vậy thôi. Nếu bạn thừa nhận quan điểm này, nhiều điều kỳ diệu sẽ xảy đến. Nếu phải chấp nhận để nhà tuyển dụng trong quá khứ hay ở hiện tại có quyền nửa đêm dựng bạn dậy, yêu cầu giải thích vì sao bạn lại viết phương thức (method) fooBar như thế, bạn sẽ cải thiện từng bước để trở thành một chuyên gia lập trình. Tự nhiên bạn muốn đặt tên biến và tên method cho tốt hơn. Bạn sẽ tránh xa những khối lệnh chứa hàng trăm dòng. Bạn sẽ tìm học và áp dụng các công thức thiết kế (design patterns). Bạn sẽ chú thích, kiểm thử, và liên tục tái cấu trúc (refactor) chương trình. Tinh thần bảo trì mã (code) do bạn viết ra cho đến chết còn là một nỗ lực hoàn thiện. Qua đó bạn chẳng còn chọn lựa nào khác ngoài việc trở nên tốt hơn, chín chắn hơn, và hiệu quả hơn.

Nếu suy niệm sâu sắc, bạn nhận thấy rằng chương trình do mình viết ra nhiều năm trước vẫn tiếp tục tác động đến nghề nghiệp, bất chấp mình có thích điều đó hay không. Bạn sẽ để lại di tích về kiến thức, thái độ, lòng kiên trì, tính chuyên nghiệp, tinh thần tận tụy, và cảm hứng của mình trong từng method, lớp (class), và bộ phận (module) mà bạn đã thiết kế và thi công. Người khác sẽ đánh giá bạn qua code của bạn. Nếu những đánh giá đó thường xuyên là tiêu cực, bạn sẽ thu nhận từ nghề nghiệp ít hơn điều mà mình mong ước. Hãy chăm sóc nghề nghiệp, khách hàng, và người sử dụng qua từng dòng code – hãy lập trình với tinh thần phải bảo trì cho đến chết.

Nguồn

Zubarev Y. (2010) Write Code As If You Had to Support It for the Rest of Your Life, 97 Things Every Programmer Should Know, Henney K. (ed), O'Reilly, Sebastopol, CA.

"Hai đánh một, không chột cũng què"

"Hai đánh một, không chột cũng què"

Adrian Wible

Lập trình cần nghĩ sâu, mà nghĩ sâu lại cần nơi tĩnh mịch. Điều này tạo nên phong cách của lập trình viên.

Lập trình theo kiểu "sói đơn độc" như vậy đã đưa đến một phong cách mang tính hợp tác cao hơn, và tôi cho rằng cách đó sẽ cải thiện chất lượng, năng suất, đồng thời đem lại cho lập trình viên niềm thỏa mãn công việc. Theo tiếp cận này, các lập trình viên gắn bó với nhau nhiều hơn, cũng như với những thành viên khác, đó là chuyên viên phân tích kinh doanh, phân tích hệ thống, chuyên viên đảm bảo chất lượng, và người dùng.

Điều này có nghĩa lý gì đối với các lập trình viên? Thành một chuyên gia công nghệ hiện nay là không đủ. Bạn phải làm việc hiệu quả với nhiều người khác.

Hợp tác không phải là hỏi đáp hay ngồi họp. Hợp tác là cùng xắn tay áo với ai đó để giải quyết công việc.

Tôi là một cổ động viên nhiệt thành cho phong cách lập trình đôi (pair programming). Bạn có thể gọi đó là "hợp tác cực đoan". Là lập trình viên, kỹ năng sẽ tăng tiến khi tôi có đệ nhị thân (bạn bắt cặp với mình). Nếu kém cỏi hơn đệ nhị thân về chuyên ngành hoặc công nghệ, tôi chắc chắn học được kinh nghiệm của người ấy. Khi giỏi hơn một phương diện nào đó, tôi sẽ học được nhiều hơn về cái tôi đã biết cũng như chưa biết, vì mình phải làm công việc giảng giải. Dù gì đi nữa thì cả hai đều có thể chia sẻ và học hỏi lẫn nhau.

Khi bắt cặp, mỗi thành viên cùng đóng góp kinh nghiệm – trong chuyên môn cũng như kỹ thuật – để giải quyết vấn đề đặt ra, đồng thời đem hiểu biết và kinh nghiệm để phát triển phần mềm hiệu quả. Ngay cả trong trường hợp mất cân đối nghiêm trọng về chuyên môn cũng như kỹ thuật, thành viên nhiều kinh nghiệm hơn vẫn học được điều gì đó từ đệ nhị thân – có thể là một tổ hợp phím tắt (keyboard shortcut) mới, hoặc làm quen với một công cụ hay thư viện mới. Đối với thành viên non kinh nghiệm, đây là cơ hội vô cùng tốt để có thể theo kịp.

Lập trình đôi rất thông dụng, tuy không dành riêng, trong cộng đồng phái phát triển phần mềm linh hoạt (agile software development). Người phản bác sẽ cật vấn, "Tại sao phải trả công cho hai để làm công việc của một người?" Phản ứng của tôi thật sự là không nên trả hai để được một. Tôi lập luận rằng lập trình đôi sẽ gia tăng chất lượng, nâng cao hiểu biết về chuyên môn cũng như công nghệ, kỹ năng (chẳng hạn các thủ thuật trong IDE), và giảm bớt tác động của rủi ro xổ số (tức một trong những chuyên gia của bạn trúng số rồi bỏ việc vào ngày hôm sau).

Đâu là giá trị lâu dài của việc học một tổ hợp phím tắt mới? Làm thế nào đo được khả năng cải thiện chất lượng tổng thể của sản phẩm qua lập trình đôi? Làm sao đo được tác động của đệ nhị thân trong việc ngăn bạn không đi vào ngõ cụt khi phải giải quyết vấn đề hóc búa? Một nghiên cứu cho thấy tính hiệu quả và tốc độ sẽ tăng 40%. Đâu là giá trị của việc giảm nhẹ "rủi ro xổ số"? Mối lợi này không dễ đo.

Ai nên là đệ nhị thân của ai? Nếu là thành viên mới, bạn phải tìm người có nhiều kiến thức. Quan trọng không kém, hãy tìm người có khả năng giao tiếp và có kỹ năng huấn luyện. Nếu không có nhiều kinh nghiệm chuyên môn, bạn hãy bắt cặp với một chuyên gia trong lĩnh vực đó.

Nếu bạn chưa được thuyết phục, hãy thử nghiệm bằng cách hợp tác với đồng nghiệp. Lập trình đôi là một điều thú vị nhưng khó nhai. Hãy cảm nhận nó. Hãy thử một đôi lần.

Nguồn

Wible A. (2010) Two Heads Are Often Better Than One, 97 Things Every Programmer Should Know, Henney K. (ed), O'Reilly, Sebastopol, CA.

Hãy học ngoại ngữ

Hãy học ngoại ngữ

Klaus Marquardt

Lập trình viên cần giao tiếp rất nhiều.

Trong đời lập trình viên, có những lúc phần lớn giao tiếp dường như chỉ là với máy tính – chính xác hơn là với các chương trình thi hành trên máy tính đó. Kiểu giao tiếp này là khả năng biểu đạt để máy tính hiểu được ý tưởng của mình. Hiện tượng này thật kỳ thú: chương trình là sự hiện thực của ý tưởng mà dường như không có vật chất tham dự vào đó.

Lập trình viên cần lưu loát về ngôn ngữ máy, dẫu đó là thực hay ảo, cần thành thạo với những khái quát liên quan đến ngôn ngữ thông qua công cụ phát triển. Biết nhiều cách khái quát khác nhau là điều quan trọng, bằng không sẽ gặp vướng mắc khi diễn đạt ý tưởng. Lập trình viên giỏi cần có khả năng đứng ngoài công việc thường nhật, có ý thức trong việc dùng các ngôn ngữ khác nhau để biểu đạt mục đích khác nhau. Thành quả ắt đến với họ.

Ngoài giao tiếp với máy, lập trình viên cần giao tiếp với đồng nghiệp. Các dự án lớn hiện nay đòi hỏi nhiều nỗ lực giao tiếp xã hội hơn là đơn thuần ứng dụng nghệ thuật lập trình. Khả năng hiểu và diễn đạt được những điều vượt quá khả năng lĩnh hội của máy là rất quan trọng. Hầu hết các lập trình viên kỳ tài đều dùng lưu loát ngôn ngữ mẹ đẻ, ngoại ngữ cũng vậy. Đây không đơn thuần là sự truyền thông qua lại: Sử dụng tốt một ngôn ngữ còn đưa đến tư duy trong sáng, phẩm chất không thể thiếu khi khái quát vấn đề. Mà khả năng khái quát lại là linh hồn của lập trình.

Ngoài giao tế với máy, với bản thân, và với đồng nghiệp, một dự án còn có nhiều người liên quan, phần lớn trong số họ không có hoặc có nền tảng kỹ thuật khác biệt. Họ sống trong lĩnh vực kiểm thử, quản lý chất lượng, và cài đặt; trong lĩnh vực tiếp thị và bán hàng; họ là người dùng bình thường, làm việc ở cơ quan hay tại nhà. Bạn cần hiểu họ cũng như những mối quan tâm của họ. Điều này là bất khả nếu bạn không nói được ngôn ngữ của họ – ngôn ngữ trong thế giới của họ, ở lĩnh vực chuyên môn của họ. Trong lúc bạn tưởng rằng cuộc đối thoại với họ đã diễn ra tốt đẹp, thì có thể họ không nghĩ như vậy.

Khi trò chuyện với kế toán viên, bạn cần có kiến thức cơ bản về kế toán trung tâm chi phí (cost-center), vốn ràng buộc (tied capital), vốn sử dụng (capital employed), v.v... Nếu bạn trao đổi với nhân viên tiếp thị hay luật sư, bạn phải quen thuộc với một số biệt ngữ (tức tư duy) của họ. Thành viên trong đội ngũ thực hiện dự án, tốt nhất là lập trình viên, cần làm chủ được tất cả những ngôn ngữ chuyên ngành này. Lập trình viên là người chịu trách nhiệm cuối cùng trong việc đưa ý tưởng đi vào cuộc sống thông qua công cụ máy tính.

Và dĩ nhiên, cuộc đời không đơn thuần là những dự án phần mềm. Theo Charlemagne, biết thêm một ngôn ngữ là có thêm một tâm hồn. Khi giao tế vượt khỏi biên giới công nghiệp phần mềm, bạn sẽ hiểu rõ giá trị của việc học ngoại ngữ. Để biết khi nào cần phải im lặng lắng nghe. Để hiểu rằng ngôn ngữ cao cả nhất chính là không lời.

Nơi nào người không thể lên tiếng, nơi ấy người phải im lặng.

– Ludwig Wittgenstein

Nguồn

Marquardt K. (2010) Learn Foreign Languages, 97 Things Every Programmer Should Know, Henney K. (ed), O'Reilly, Sebastopol, CA.

Hãy tu luyện thật nhiều

Thiết kế chương trình hướng đối tượng

Center of Excellence, SaigonTech

Bài đọc thêm

Hãy tu luyện thật nhiều

Jon Jagger

Tu luyện không đơn thuần là thực hiện một nhiệm vụ. Nếu bạn tự hỏi, "Tại sao mình lại làm công việc này?" và nếu bạn trả lời, "Để hoàn thành nhiệm vụ," thì đó không phải là tu luyện.

Bạn tu luyện nhằm cải thiện năng lực hoàn thành nhiệm vụ của mình. Đó là vấn đề cải thiện kỹ năng và kỹ thuật. Tu luyện nghĩa là làm đi làm lại, thực hiện công việc với mục tiêu gia tăng khả năng làm chủ một hay nhiều phương diện của công việc đó. Chậm rãi, làm đi làm lại, cho đến khi đạt được trình độ tinh thông mà mình khát khao. Bạn tu luyện nhằm làm chủ công việc, chứ không phải để hoàn thành nhiệm vụ.

Mục đích chính của hoạt động phát triển để được trả thù lao là nhằm hoàn thành một sản phẩm, trong khi mục tiêu chủ yếu của tu luyện là để cải thiện hiệu suất bản thân. Chúng không giống nhau. Hãy tự hỏi, bạn mất bao lâu để phát triển sản phẩm cho một ai đó? Mất bao lâu để hoàn thiện bản thân?

Cần tu luyện bao lâu để đạt đến trình độ tinh thông?

• Peter Norvig cho rằng "có thể 10.000 giờ...là một con số thần diệu."
• Trong Lãnh đạo phát triển phần mềm tinh gọn (nhà xuất bản Addison-Wesley Professional), Mary Poppendieck cho rằng "các thành viên ưu tú phải mất 10.000 giờ tập trung tu luyện để có thể trở thành chuyên gia."

Trình độ tinh thông đến dần theo thời gian – chứ không đến ngay vào giờ thứ 10.000! Tuy nhiên, 10.000 giờ là nhiều lắm: vào tầm 20 giờ mỗi tuần và liên tục trong 10 năm. Với quyết tâm này, có thể bạn vẫn còn lo là mình không có tố chất để trở thành một chuyên gia. Thật sự là bạn có đấy. Sự vĩ đại chủ yếu là từ ý thức quyết tâm của bạn. Kết quả nghiên cứu trong hơn hai thập niên vừa qua cho thấy nhân tố chính để đạt đến trình độ tinh thông là thời gian tu luyện. Khả năng bẩm sinh không phải là yếu tố chủ đạo. Theo Mary Poppendieck:

Đông đảo các nhà nghiên cứu về vấn đề hiệu suất tinh thông đều nhất trí cho rằng khả năng bẩm sinh chẳng qua là điểm bắt đầu; bạn phải có khả năng tự nhiên tối thiểu để khởi đầu một môn thể thao hay một nghề nghiệp. Sau đó, bạn có tiến bộ vượt bậc hay không là nhờ làm việc chăm chỉ.

Sẽ chẳng nghĩa lý gì lắm nếu bạn tu luyện cái điều mà bạn đã tinh thông. Tu luyện tức là luyện tập điều gì mà bạn chưa giỏi. Peter Norvig giải thích:

Vấn đề then chốt [để đạt đến trình độ tinh thông] là tu luyện: không những làm đi làm lại, mà còn thách thức bản thân trước một nhiệm vụ vượt quá khả năng hiện tại của mình, gắng làm cho được, phân tích hiệu suất trong lúc làm và sau khi làm, đồng thời sửa chữa sai sót.

Và Mary Poppendieck viết:

Tu luyện không có nghĩa là làm cái điều mà bạn đã giỏi; tu luyện tức là thách thức bản thân, làm điều gì mà mình còn kém. Vì vậy tu luyện không nhất thiết phải là điều gì đó thú vị.

Tu luyện là học hỏi – học để thay đổi bản thân, học để thay đổi hành vi của mình. Chúc bạn may mắn.

Nguồn

Jagger J. (2010) Do Lots of Deliberate Practice, 97 Things Every Programmer Should Know, Henney K. (ed), O'Reilly, Sebastopol, CA.

Đừng phát triển theo lối đập chuột

Thiết kế chương trình hướng đối tượng

Center of Excellence, SaigonTech

Bài đọc thêm

Đừng phát triển theo lối đập chuột

Venkat Subramaniam

Các nhà quản lý dự án luôn phải đối diện với áp lực xuất xưởng thật nhanh. Thời gian là yếu tố cốt lõi. Làm thế nào để bạn có thể nhanh chóng hoàn thành công việc?

Hãy hình dung tổ của bạn có hai lập trình viên (programmers), Bernie và Rob. Cả hai đều có khả năng, có kiến thức nghiệp vụ ngang nhau, và có cùng kỹ năng ngôn ngữ. Trong quá trình phát triển, bạn nhận ra rằng Bernie hoàn thành phần thi công (implementation) nhanh hơn Rob nhiều.

Trong lúc Bernie tập trung kết thúc nhanh phần viết mã (code), Rob lại dành thời gian viết rồi tiếp tục tái cấu trúc (refactor) mã. Anh đặt lại tên biến (variables) và tên phương thức (methods) cho tốt hơn. Khi chương trình chạy ổn, anh tổ chức code thành những đơn vị nhỏ hơn. Rồi anh kiểm thử (test) để đoan chắc rằng từng đơn vị code phải thực hiện đúng điều anh muốn đơn vị đó làm. Khi đã khá hài lòng, anh mới tuyên bố nhiệm vụ thi công đã hoàn tất.

Song giả định rằng bạn không biết được các chi tiết này. Nếu bạn chỉ xét đến tốc độ hoàn thành công việc, rõ ràng là Bernie giỏi hơn, đúng không?

Vài tuần trôi qua, đến lúc bạn trình cho khách hàng những chức năng (features) mới. Như thường lệ, khách hàng thích thú với các chức năng đó, nhưng rồi họ muốn bạn thay đổi và cải thiện chúng. Bạn yêu cầu lập trình viên của mình thực hiện các thay đổi đó. Khi bạn trình chức năng mới, đã được cải tiến, cho khách hàng, họ thử dùng và hài lòng với những chức năng do Rob thực hiện.

Chẳng may, họ phát hiện ra điểm lạ trong các chức năng do Bernie thực hiện. Trong lúc Bernie lập trình để cho những chức năng mới chạy tốt, thì một vài bộ phận khác không còn hoạt động tốt như trước đây nữa. Khách hàng ghi nhận đây là khuyết điểm, nên bạn yêu cầu Bernie phải chỉnh sửa. Khách hàng kiểm tra lại. Giờ thì điều kỳ cục thậm chí còn xuất hiện nhiều hơn. Chuyện gì đang xảy ra vậy?

Nếu bạn có em nhỏ, bạn biết chắc điều gì đang diễn ra. Bernie đã tạo ra một ứng dụng Đập Chuột (Whack-A-Mole). Đập Chuột là một đồ chơi. Trẻ em dùng búa gỗ để đập các chú chuột ngẫu nhiên ngóc đầu lên. Chúng ngạc nhiên và thích thú đoán xem chú chuột tiếp theo nào sẽ chui ra. Tuy nhiên, việc sửa chữa những ứng dụng mà lỗi phát sinh tại các vị trí ngẫu nhiên thì không sao vui được. Ban đầu Bernie chạy nước rút, song lại chệch hướng.

Trong khi Rob bề ngoài có vẻ chậm chạp hơn, thật ra là anh đang tạo code chất lượng cao. Anh có tiến độ làm việc bền vững. Phẩm chất tốt của code ban đầu đã giúp anh thực hiện những thay đổi một cách nhanh chóng. Thêm vào đó, các kiểm thử (tests) ban đầu anh viết ra đã giúp anh tiếp nhận phản hồi tức thì về sự tương thích giữa code mới và các bộ phận khác bên trong ứng dụng (application).

Khi tính toán thời gian hiện thực một chức năng, đừng chỉ xem xét thời lượng phát triển ban đầu. Hãy cộng thêm thời gian nâng cấp, sửa đổi, và cải thiện code. Quá trình phát triển và kiểm thử code có chất lượng sẽ mất thời gian. Đó chỉ là tổn thất ngắn hạn. Nhưng sẽ đem lại lợi ích dài hạn.

Bạn hãy tự vấn xem mình có muốn nhanh nhanh hay muốn thưởng thức hương vị của tiến độ bền vững.

Nguồn

Subramaniam V. (2009) Avoid Whack-a-Mole Development, 97 Things Every Project Manager Should Know, Davis B. (ed), O'Reilly, Sebastopol, CA.

Làm ít

http://gettingreal.37signals.com/ch02_Build_Less.php

Hãy làm ít hơn đối phương

Người đời thường khuyên: để đánh bại đối phương bạn cần chiếm ưu thế. Nếu đối phương có bốn chức năng, bạn cần có năm (hay 15, hay 25). Nếu đối phương chi ra x đồng, bạn cần chi ra xx đồng. Nếu đối phương có 20, bạn cần có 30.

Tâm lý ưu thế như thời kỳ Chiến tranh Lạnh kiểu này chỉ đem lại bế tắc. Đây là cách tạo sản phẩm tốn kém, bị động, và hoang tưởng. Những công ty bị động và hoang tưởng không thể vượt lên trước, họ chỉ có thể ở đằng sau. Họ không dẫn đầu, họ chỉ đi theo.

Thế thì phải làm gì? Câu trả lời là làm ít. Làm ít hơn đối phương để đánh bại họ. Giải quyết chuyện đơn giản và nhường chuyện hóc búa cho người khác. Thay vì làm nhiều hơn, hãy thử làm ít hơn. Thay vì tỏ ra ưu thế, hãy thử tỏ ra yếu thế.

Ta sẽ bàn nhiều về làm ít, nhưng trước tiên, làm ít hơn nghĩa là

   Ít chức năng hơn

   Ít khả năng chọn lựa hơn

   Ít nhân sự và cấu trúc doanh nghiệp đơn giản hơn

   Ít hội họp và bớt trừu tượng

   Ít hứa hẹn hơn