logo

Thông báo

Icon
Error

Chia sẻ
Tùy chọn
Xem
Xem bài viết cuối
Offline admin  
#1 Đã gửi : 05/07/2016 lúc 04:42:43(UTC)
admin

Danh hiệu: Administration

Chức danh:

Nhóm: Administrators
Gia nhập: 23-07-2013(UTC)
Bài viết: 5,624
Man
Viet Nam
Đến từ: Vietnam

Cảm ơn: 8 lần
Được cảm ơn: 2 lần trong 2 bài viết

Một số người phản đối mọi ý tưởng về việc phân loại các lập trình viên thành các nhóm dù bất kỳ dạng nào. Nhưng lịch sử đã cho thấy rất nhiều người đã làm chính xác điều đó, với những hậu quả thú vị và đôi khi nằm ngoài ý muốn. Vào đầu năm 2004, Nikhil Kothari đã viết về 3 loại tính cách (personas) mà Microsoft đã đưa ra trong khi làm việc trên sản phẩm Visual Studio 2005.

Chúng tôi có 3 loại tính cách (personas) chính trên khắp các bộ phận phát triển: Mort, Elvis Einstein.

Mort, là kiểu lập trình viên cơ hội, thích tạo ra các giải pháp nhanh chóng cho các vấn đề ngay lập tức. Anh ta tập trung vào năng suất và học tập khi cần thiết.

Lập trình viên MortElvis, là kiểu lập trình viên thực dụng, thích tạo ra các giải pháp lâu dài để giải quyết các vấn đề chung, và học hỏi trong khi làm việc trên giải pháp đó.

Lập trình viên ElvisEinstein, thuộc kiểu lập trình viên bác học, thích tạo ra các giải pháp hiệu quả nhất cho một vấn đề nhất định, và thường tìm hiểu kỹ càng trước khi làm việc trên giải pháp đó.

Lập trình viên EinsteinNhững tính cách này giúp hướng dẫn việc thiết kế các tính năng trong suốt chu kỳ sản phẩm Visual Studio 2005.

Các mô tả ở trên chỉ là một tổng kết sơ bộ về một số đặc điểm thu thập được và ghi chép lại bởi những đồng nghiệp của chúng tôi. Trong một cuộc họp, một vị program manager của nhóm chúng tôi đã áp dụng những tính cách đó trong ngữ cảnh của các server control cũng khá hay:

  • Mort sẽ là một lập trình viên cảm thấy thoải mái và hài lòng nhất nếu control đó có thể sử dụng được như thiết kế của nó và control đó hoạt động tốt.
  • Elvis muốn có khả năng tùy biến control đó để nhận được các hành vi mong muốn thông qua các properties và code, hoặc sẵn sàng để kết nối nhiều control lại với nhau.
  • Einstein rất thích việc có khả năng hiểu một cách sâu sắc về cách thực thi của control đó, và muốn có khả năng mở rộng nó để mang lại cho control đó một hành vi (behavior) khác, hoặc đi xa hơn đó là tái thực hiện lại nó.

Những tính cách (personas) này đã gây ra tranh cãi trong nhiều năm trời; chúng đã tạo ra nhiều tranh luận nảy lửa. Rõ ràng là có một ranh giới giữa “persona (tính cách)” “stereotype (khuôn mẫu)”:

Các tính cách (personas) của các lập trình viên tại Microsoft bao gồm Mort, Elvis, và Einstein cuối cùng là một sự suy đồi về đạo đức khi mà người ta đem “nhốt chuồng” các lập trình viên phần mềm vào các thể loại quá đơn giản mà chỉ mấy tay nhân viên marketing mới cảm thấy thoải mái.

Trong khi mục đích ban đầu là để giúp phân khúc ký sinh đặc biệt này của thế giới doanh nghiệp, thì việc mô hình hóa các hành vi theo khuynh hướng tâm lý của các nhà phát triển phần mềm tại công việc của họ là một cách đơn giản không thực tế, thay vì đó nó đã biến thành một hệ thống của những hạn chế mà các lập trình viên phải bắt đầu áp đặt lên chính họ để gây tổn hại cho sự tiến bộ của thực tiễn phát triển ngành công nghiệp phần mềm. Nó dường như là một nỗ lực của các nhà phát triển để giải thoát chính họ khỏi năng lực tư duy hợp lý có lợi cho việc xác định các thương hiệu của các công ty và phần mềm nổi tiếng.

Personas (cá tính), tự bản thân nó thì không có gì là xấu cả. Trước đây tôi đã viết về tầm quan trọng của khả năng sử dụng API, và personas cho bạn một lợi thế về tính dễ sử dụng (usability) bằng cách xem xét những đối tượng người dùng khác nhau sẽ sử dụng code của bạn.

Nhưng tôi có thể thấu hiểu điều này. Trong một thời gian dài là một lập trình viên sử dụng Visual Basic và VB.NET, tôi thực sự cảm thấy khá bực bội khi bị gộp vào nhóm người kiểu như Mort. Tôi không phải là một tay lập trình viên kiểu “tà tà kiếm cơm” – tôi thực sự quan tâm về nghề nghiệp phát triển phần mềm. Vì vậy điều gì sẽ xảy ra nếu tôi viết code trong một ngôn ngữ mà không được hỗ trợ về phân biệt chữ hoa chữ thường và cả cặp dấu ngoặc xoắn? Việc lựa chọn ngôn ngữ của tôi cuối cùng chẳng có ý nghĩa nhiều hơn giữa việc lựa chọn nước giải khát CocaCola và Pepsi, vì vậy không có nhiều sự khác biệt ở đây.

Paul Vick làm việc tại nhóm tạo ra ngôn ngữ VB tại Microsoft và ông ta có phản hồi về một vài mối quan tâm của tôi:

Sai lầm cơ bản mà tôi nghĩ rằng hầu hết mọi người đều làm với các personas đó là họ nhìn thấy chúng loại trừ lẫn nhau chứ không phải là các điểm nằm trong cùng một dải kinh nghiệm. Khi tôi đang làm việc để tạo ra VB compiler, thì tôi chắc chắn là một Einstein, luôn suy nghĩ ở mức rất cao. Khi tôi đang làm việc trên các thứ kiểu như VBParser sample, thì tôi thường là một Elvis, tư duy ở một cấp độ thấp hơn một chút. Và khi tôi đang viết một batch scripts hoặc các công cụ phân tích dữ liệu ad-hoc, tôi chắc chắn là một Mort, vọc vậy tìm kiếm xung quanh để tìm ra cách làm những gì mà tôi đang cố gắng để làm.

Quan điểm thực sự đó là hầu hết mọi người thường là Mort, Elvis, và Einstein tất cả cùng một lúc, tùy thuộc vào những gì họ đang làm. Và bằng cách xây dựng các công cụ sẽ tập trung vào kiểu người này hay người kia, chúng ta đang cố tình phân chia công việc của mọi người vào trong những “cái xô” riêng lẻ mà không thực sự phản ánh đúng công việc hàng ngày của họ. (Tôi cũng đã tranh luận về việc một số phiên bản Visual Studio được phát hành trước đây đã quá nhấn mạnh những personas hơn những yếu tố khác). Hãy tìm một cách tốt hơn để phục vụ mọi người khi họ trôi theo dòng chảy công việc hàng ngày, và một cái gì đó cần sự chú ý nghiêm túc hơn.

Tôi nghĩ rằng giải pháp ở đây là bỏ thái độ gia trưởng và coi thường khi nghĩ về Mort, mà thay vào đó là yêu cầu Mort phải làm việc tốt hơn. Nếu khả năng của những lập trình viên trung bình thật sự chỉ làng nhàng như hiện có, chúng ta không nên chỉ chấp nhận điều đó, mà phải làm việc để nâng cao chất lượng của các lập trình viên loại trung bình. “Lập trình viên loại trung bình” nên phải ở một cấp độ năng lực có thể chấp nhận được.

Chúng ta phải nhận ra rằng Mort phải chịu trách nhiệm cho rất nhiều hệ thống quan trọng. Các hệ thống mà có ảnh hưởng đến phần đông dân số. Khi tôi nghe về các vụ trộm cắp tài khoản gần đây tại Choicepoint, đặc biệt nguyên nhân bởi sự lỏng lẻo trong việc bảo mật như là sử dụng các mật khẩu mặc định cho cơ sở dữ liêu, tôi nghĩ về Mort. Khi tôi đọc thấy rằng $250 triệu đô-la tiền thuế của dân đã được đầu tư vào việc đại tu hệ thống Case File của FBI, và hệ thống đó đã bị loại bỏ, tôi nghĩ về Mort.

Đưa ra nhiều trách nhiệm như vậy, chúng ta nên mong chờ nhiều hơn từ Mort. Vì vậy Mort ơi, tôi rất ghét phải nói ra với bạn điều này, nhưng phát triển phần mềm không giống như là đang làm việc tại quầy thu ngân của tiệm bánh McDonalds, nơi mà bạn chỉ việc đến có mặt từ 9 giờ sáng đến 5 giờ chiều là đủ. Mặc dù chúng ta cần cân bằng giữa công việc và cuộc sống, nhưng bạn phải hiểu một điều rằng, phát triển phần mềm là một lĩnh vực vô cùng thách thức, đòi hỏi phải tập trung cao độ và có một năng lực tinh thần mạnh mẽ. Đây là thời điểm bạn nên tham dự một vài buổi hội thảo để cải thiện những kỹ năng của mình. Đây là lúc để bạn nên đăng ký đọc một số blog lập trình và đọc một thêm một số cuốn sách. Nhưng hãy đọc những cuốn sách sâu sắc chứ đừng đọc mấy cuốn sách loại 3 xu rẻ tiền như “Làm thế nào để lập trình VCR trong 21 ngày”. Ví dụ, hãy đọc một cuốn sách về Design Patterns hoặc Refactoring. Mort ơi, tôi e rằng đây là lúc bạn nên rời bỏ lối mòn cũ. Đã đến lúc bạn nên bước lên một nấc thang mới trong nghề lập trình.

Tôi tin chắc rằng đó là công việc của chúng ta để giúp nghề phát triển phần mềm trở nên tốt hơn so với khi chúng ta mới bước chân vào nó. Nếu bạn có bất cứ điều gì giống như tôi, bạn đã viết code tồi khủng khiếp khi bạn mới bắt đầu như là một lập trình viên non trẻ. Nhưng thông qua sự phối hợp giữa nỗ lực và thực hành, tôi đã cố gắng để viết code bớt tệ hơn một chút sau mỗi năm. Tôi sẽ thừa nhận rằng điều này là khá đau khổ, bởi vì các lập trình viên chúng ta không biết chính xác về các kỹ năng trong bản thân mình. Nhưng chúng ta có bổn phận với nghề của mình – và cả với chính chúng ta nữa – để tiếp cận và giúp đỡ những lập trình viên đồng nghiệp khác, ít ra là theo một cách nhỏ nào đó.

Việc trở thành một lập trình viên chuyên nghiệp thì không chỉ đơn thuần là ngồi viết ra thật nhiều code tuyệt vời. Mà trở thành một lập trình viên chuyên nghiệp nghĩa là phải giúp đỡ những lập trình viên khác cũng trở nên chuyên nghiệp. Nào tất cả chúng ta hãy cùng góp sức. Dù chúng ta không thể tiếp cận tới tất cả mọi người. Nhưng ít ra là sẽ vươn tới được một số lập trình viên loại 80% đó.

Ai đang xem chủ đề này?
OceanSpiders 2.0
Di chuyển  
Bạn không thể tạo chủ đề mới trong diễn đàn này.
Bạn không thể trả lời chủ đề trong diễn đàn này.
Bạn không thể xóa bài của bạn trong diễn đàn này.
Bạn không thể sửa bài của bạn trong diễn đàn này.
Bạn không thể tạo bình chọn trong diễn đàn này.
Bạn không thể bỏ phiếu bình chọn trong diễn đàn này.

Powered by YAF.NET 2.2.3 | YAF.NET © 2003-2018, Yet Another Forum.NET
Thời gian xử lý trang này hết 0.367 giây.