Nhái Cốm Blog

I love you just the way you are

0R8A4000_


Leave a comment

Điều gì ảnh hưởng đến hiệu quả làm việc nhóm nhất?

Tác giả: Anna Majowska
Bài gốc: What Impacts Team Productivity the Most?

Lược dịch

Nghe có vẻ hiển nhiên nhưng việc tách khỏi nhóm để làm việc thực sự là một vấn đề quan trọng. Công việc khác nhau đòi hỏi những cách tiếp cận khác nhau, và thông thường thì khối lượng công việc hoàn thành trong ngày phụ thuộc rất lớn vào kế hoạch của từng ngày một.

Nếu công việc thực sự của nhóm là làm ra một thứ gì đó (sản xuất, viết lách, lập trình, đồ họa hay thiết kế…), thứ gây phiền nhiễu nhất đến quá trình làm việc của họ chính là những cuộc họp.

Điều quan trọng là loại bỏ hoàn toàn các cuộc họp hay “nhồi nhét” chúng lại; từ nửa ngày đến 1 ngày một tuần dành cho các cuộc họp, 4 ngày còn lại hoàn toàn dành cho công việc. Qua đó, có thể giới hạn thời gian không dành cho công việc cũng loại bỏ quãng thời gian lãng phí gây ra bởi việc chuẩn bị và chờ đợi cuộc họp diễn ra. Bằng cách này, nhóm của bạn có thể tập trung hoàn toàn vào công việc, hoàn thành nhiều thứ hơn trong khoảng thời gian ít hơn.

Như chúng ta thường nghe, ai cũng cần nghỉ ngơi thường xuyên.

Cảm xúc

Chúng ta là con người. Cho dù bạn là chuyên gia và có khả năng tự kiểm soát hay không thì cảm xúc cũng chi phối công việc và cách chúng ta hoàn thành công việc.

Vì vậy, nếu người quản lý không quan tâm đến cảm xúc và lý do đằng sau cảm xúc đang được biểu hiện trong nhóm, kết quả làm việc nhóm có thể sẽ không được như mong đợi. Vai trò của người quản lý nhóm là dẫn dắt, chỉnh sửa và làm mọi việc trở nên đơn giản hơn. Để cảm xúc tác động đến những gì chúng ta làm sẽ tạo ra những tác động lớn.

Ví dụ, khi bạn thể hiện sự tức giận sau một dự án thất bại, nhóm dự án sẽ ghi nhớ điều này, qua đó tạo ra những thay đổi trong cách cư xử ở dự án kế tiếp. Tất nhiên, điều này không có nghĩa họ sẽ làm việc chăm chỉ hơn.

Tôi không có ý nói rằng không được để cảm xúc xen vào quá trình quản lý. Nhưng biết thể hiện cảm xúc ở thời điểm nào có thể giúp cải thiện tình hình là cực kỳ quan trọng.

Người khó ưa

Mọi nhóm đều có một vài người như thế này. Đó có thể là một gã luôn vùi dập ý kiến của bạn để làm nổi bật tầm quan trọng của mình. Đó cũng có thể là một cô gái điệu đà luôn làm phiền bạn bằng những vấn đề cá nhân của riêng cô ta trong khi bạn đơn giản chỉ là không muốn nghe cô ta nói. Hoặc cũng có thể là một người bi quan luôn cho rằng chẳng gì có thể hoàn thành đúng hạn, luôn đưa ra những lý do tại sao không nên thực hiện một công việc thay vì giải pháp để thực hiện công việc đó.

Tránh đối đầu trực tiếp với những người như thế này này có thể là một giải pháp hay. Hãy giữ khoảng cách với họ, thông qua trao đổi thư điện tử (email), messenger hoặc công cụ quản lý nhiệm vụ để tạo không gian cho việc đánh giá, nhận xét từng vấn đề cụ thể.

Bằng cách giữ khoảng cách với họ, bạn có thể tập trung vào việc trao đổi thay vì những vấn đề cá nhân hay cách tiếp cận. Lấy dữ liệu và xử lý mà không để bị ảnh hưởng bởi mớ bòng bong do họ tạo ra.

Bằng cách tôn trọng cái tôi của họ (bằng cách giữ khoảng cách), bạn sẽ thu về lợi ích từ công việc thực sự của họ. Tình huống này dường như là lợi cả đôi bên.

Và cũng đừng lo lắng. Sẽ luôn có một ai đó coi bạn như người khó ưa và cần được quản lý. Điều này là rất hiển nhiên.

Không gian và thời gian

Bởi vì mọi người không ai giống ai, rất khó có trường hợp cả nhóm đều cảm thấy thoải mái và hạnh phúc khi làm việc trong cùng loại văn phòng, phòng làm việc hay khung giờ làm việc.

Đó là lý do tại sao không gian làm việc nên có khả năng điều chỉnh như sắp xếp chỗ làm việc khác kiểu hay bàn ghế khác loại…

Thêm vào đó, một số công ty mới cho phép nhóm có thể thiết lập giờ làm việc của riêng họ. Hãy ghi nhớ rằng sẽ có khoảng thời gian chung trong thời gian biểu của các thành viên. Vậy tại sao không để những người dậy sớm đi làm lúc rạng sáng và những người ngủ nướng đi làm vào buổi trưa?

Những điều trên có có thể giúp nhóm đạt được hiệu quả công việc cao nhất, qua đó kết quả làm việc nhóm nói chung và sản phẩm cuối cùng nói riêng sẽ được hưởng lợi.

Chắc chắn rằng, có rất nhiều yếu tố khác ảnh hưởng đến hiệu quả làm việc nhóm. Nhưng nếu bạn nghiêm túc lưu ý đến những điều ở trên, cơ hội thành công của nhóm bạn sẽ tăng hơn.

0R8A4000_


Leave a comment

Vài yếu tố liên quan đến hiệu năng

Tác giả: Rico Mariani
Bài gốc: Performance Tidbits

Lược dịch

Delegate

Bạn có sử dụng delegate khi bạn có thể thay thế bằng tính đa hình? Delegate cho phép bạn gọi bất kì phương thức trên bất kì đối tượng nào. Chỉ với một interface hoặc một phương thức ảo (virtual method), bạn cũng có thể có một hàm xác định trên mọi đối tượng và điều này thông thường là đủ. Delegate cần tài nguyên cho từng đối tượng trong bộ nhớ trong khi các các phương thức ảo chỉ sử dụng tài nguyên đối với từng class.

Virtual Method (phương thức ảo)

Bạn có sử dụng phương thức ảo khi bạn hoàn toàn có thể sử dụng một lời gọi trực tiếp đến phương thức? Rất nhiều trường hợp lập trình viên sử dụng phương thức ảo nhằm tăng khả năng mở rộng trong tương lai. Đây là một điều tốt nhưng cái gì cũng có giá của nó. Vì vậy bạn cần chắc chắn rằng việc sử dụng phương thức ảo là bắt buộc để giúp bạn thực hiện điều mình muốn. Đôi khi mọi người chỉ nghĩ đến các vấn đề gọi phương thức mà không cân nhắc đến việc làm thế nào “các đối tượng mở rộng” được tạo ra. Để rồi sau đó họ nhận ra rằng phần lớn các phương thức ảo chẳng giúp ích gì; họ buộc phải tạo ra một mô hình hoàn toàn khác để có thể mở rộng chức năng cho hệ thống.

Sealing

Sealing (sử dụng từ khóa sealed trong C#) là một cách hạn chế tính đa hình đối với class của bạn. Nếu bạn làm chủ hoàn toàn việc khai báo và thực thi, sealing sẽ giúp ích rất nhiều cho hiệu năng vì nó cho phép sử dụng lời gọi trực tiếp (direct call) cũng như chèn mã lệnh thực thi (inline).

Type và API rối rắm

Xu hướng chung khi pháp triển mã lệnh được quản lý (managed code) là có rất nhiều class cũng như khai báo được tạo ra nhằm phân nhỏ công việc mà chúng thực thi. Đây có thể là nguyên tắc thiết kế tốt nhưng không phải lúc nào cũng thích hợp. Hãy cân nhắc công việc thật cẩn thận và đảm bảo rằng các API được chia vừa đủ nhỏ (xem thêm bên dưới) để thực hiện tốt công việc. Đừng quên rằng mỗi lớp hay hàm đều có một liên kết tĩnh đến nó. Có thể thực hiện mọi thứ với ít class hay hàm hơn sẽ mang lại hiệu năng tốt hơn. Hãy đảm bảo rằng bạn không thêm mọi thứ vào class chỉ vì ý thích.

Phân mảnh API

Kích thước sai của API thường dẫn đến kích thước sai của các giao dịch tới cơ sở dữ liệu hay bộ nhớ lưu trữ. Hãy cân nhắc cẩn thận các vấn đề như đơn vị công việc (độ lớn của giao dịch như thế nào) và sự phân lập ngay cả khi bạn không làm việc trực tiếp với cơ sở dữ liệu. Việc nghĩ về các cấu trúc trong bộ nhớ như là các cấu trúc trong cơ sở dữ liệu thường mang lại hiệu quả tốt; chúng cần được truy cập đồng thời ngay cả khi thực tế chưa cần đến.

Concurrency (đồng thời)

Đừng sử dụng các mô hình đồng thời phức tạp nhiều hơn mức cần thiết. Đa số các trường hợp mô hình tối giản là tất cả những gì bạn cần. Các quy tắc chia sẻ phức tạp hay đồng bộ ở mức độ thấp thường mang lại vấn đề cho bạn hơn là giúp ích thực sự. Đặt các logic đồng bộ ở lớp nào làm việc với các “transaction”, không thêm vào ở các lớp cao hơn hay thấp hơn mỗi khi bạn có thể. Sử dụng các phương pháp đồng bộ phức tạp đòi hỏi kiến thức chuyên sâu về điểm mạnh cũng như điểm yếu trong mô hình bộ nhớ của bộ xử lý.

Ít DLL hơn

Coi như mọi chức năng là như nhau, bạn sẽ có hiệu năng tốt hơn với số ít DLL lớn thay vì nhiều DLL nhỏ. Đôi khi điểm này không thực sự chính xác, đặc biệt khi DLL khởi tạo quá mức các thành phần của nó. Trường hợp nhiều DLL mang lại hiệu quả là khi chia tách, bạn có cơ hội không phải tải chúng vào bộ nhớ khi chạy các chức năng thông thường. Hãy nhập các DLL lại nếu đó là việc làm có nghĩa.

Late Bound Semantics (truy xuất được xác định ở thời điểm thực thi)

Nếu bạn không cần Reflection thì đừng sử dụng chúng. Bạn không thể đạt được hiệu năng như “early-bound semantic” (truy xuất đến đối tượng được xác định ở thời điểm biên dịch) khi làm việc trên các kiểu thông qua Reflection. Nếu bạn sử dụng Reflection để tăng khả năng mở rộng, hãy cân nhắc tình huống liệu nó có đáng đánh đổi bằng hiệu năng bạn phải bỏ ra không.

Ít con trỏ hơn

Tôi thích nhìn mã lệnh có nhiều mảng các kiểu nguyên thủy hơn là một rừng các con trỏ. Các cấu trúc dữ liệu con trỏ phức tạp thường làm việc không tốt trên các bộ nhớ hiện tại. Nếu bạn phải trả cho tôi 1000 vnđ cho mỗi con trỏ, đến cuối năm bạn sẽ mất bao nhiêu tiền?

Bộ nhớ đệm và chính sách bộ nhớ đệm

Đảm bảo rằng bất kì bộ nhớ đệm nào bạn tạo ra đều có chính sách tốt, rõ ràng cho việc loại bỏ cũng như thời gian tồn tại của dữ liệu bên trong. Bộ nhớ đệm không phải để phình ra mãi mãi. Nếu không có chính sách phù hợp, bộ nhớ đệm sẽ trở thành memory leak (rò rỉ bộ nhớ). Sử dụng con trỏ yếu (WeakReference trong .NET) cho bộ nhớ đệm nhìn có vẻ đẹp nhưng thường thì bạn vẫn phải chịu hậu quả từ một chính sách không tốt.

0R8A4000_


Leave a comment

Quay lại tương lai – Tách rời

Tác giả: Dmitriy Gakh
Bài gốc: Back to the Future – Decapsulation

Lược dịch

Giới thiệu

Khi các mô-đun lập trình phải xử lý một lượng dữ liệu khổng lồ lưu trữ trong RAM, cấu trúc dữ liệu ảnh hưởng đến lượng RAM sử dụng cũng như hiệu suất. Để tiết kiệm tài nguyên máy tính, bạn nên sử dụng các kiểu dữ liệu nguyên thủy, dùng cấu trúc (struct) thay vì lớp (class) hoặc tốt hơn dùng dữ liệu cơ bản thay vì cấu trúc. Hướng tiếp cận này đi ngược lại lập trình hướng đối tượng, quay lại việc áp dụng các phương pháp lập trình cũ. Tuy nhiên, trong một số trường hợp, cách tối ưu này có khả năng xử lý rất nhiều vấn đề. Một nghiên cứu đơn giản chứng minh rằng hoàn toàn có thể giảm lượng bộ nhớ cần dùng xuống 3 lần.

Những vấn đề dưới đây sẽ được đề cập đến trong bài viết:

  • Sự ảnh hưởng của kiến trúc phần mềm đối với lượng bộ nhớ sử dụng cũng như hiệu suất
  • Sự khác nhau trong việc chạy ứng dụng trong chế độ 32 bit và 64 bit
  • Sự khác nhau giữa các con trỏ và các chỉ số trong mảng
  • Ảnh hưởng của việc sắp xếp dữ liệu bên trong cấu trúc (struct) và lớp (class)
  • Ảnh hưởng của bộ nhớ đệm CPU đến hiệu suất
  • Đánh giá chi phí liên quan đến việc hỗ trợ lập trình hướng đối tượng trong các ngôn ngữ lập trình cấp cao
  • Nhận thức sự cần thiết của những tính năng cấp thấp trong một nền tảng, ngay cả khi bạn đang sử dụng các ngôn ngữ cấp cao

Khái quát

Chúng tôi bắt đầu áp dụng phương pháp này khi pháp triển giải pháp tìm đường tối ưu mới cho cổng thông tin http://www.GoMap.Az. Thuật toán mới tạo sử dụng nhiều RAM hơn thuật toán cũ, kết quả là ứng dụng bắt đầu có tình trạng tắc nghẽn sau khi được cài đặt lên máy chủ. Việc nâng cấp phần cứng trong trường hợp này cần nhiều ngày trong khi việc tối ưu lượng RAM sử dụng bằng phần mềm cho phép giải quyết vấn đề nhanh chóng hơn nhiều. Trong bài viết này, chúng tôi sẽ chia sẻ kinh nghiệm của mình và mô tả theo cách đơn giản nhất những việc chúng tôi đã thực hiện cũng như lợi ích những việc đó mang lại.

Việc bố trí không gian lưu trữ cho một lượng lớn cấu trúc dữ liệu và truy xuất đến những dữ liệu đó là một vấn đề thực sự quan trọng đối với những hệ thống thông tin làm việc với dữ liệu địa lý. Loại vấn đề này có xu hướng xảy ra khi pháp triển những hệ thống thông tin hiện đại khác nhau.

Chúng ta cùng đánh giá việc lưu trữ và truy xuất dữ liệu thông qua một ví dụ về các con đường – các cạnh của một đồ thị. Để tiện hình dung, con đường được thể hiện bởi class Road và các con đường được lưu giữ trong class RoadContainer. Bên cạnh đó, class Node thể hiện một điểm trên đồ thị. Đối với Node, chúng ta chỉ cần biết nó là một class. Chúng ta cũng giả sử rằng các cấu trúc dữ liệu không chứ các hàm cũng như quan hệ thừa kế; nói theo cách khác, chúng chỉ được sử dụng để lưu trữ và xử lý dữ liệu.

Trong bài viết này, chúng ta sẽ sử dụng ngôn ngữ C# mặc dù trên thực tế chúng tôi sử dụng C++. Thật ra vấn đề và giải pháp cho vấn đề nằm trong lĩnh vực lập trình hệ thống. Tuy nhiên, nghiên cứu cũng chỉ ra việc sử dụng lập trình hướng đối tượng có thể phải đánh đổi bằng một chi phí đáng kể. C# có thể là cách tốt nhất để chỉ ra những chi phí ngầm này, mặc dù nó không phải là một ngôn ngữ lập trình hệ thống.

// Main data structure – class Road
public class Road
{
	public float Length;
	public byte Lines ;
	
	// Class Node is described anywhere 
        // Road refers to two Node objects here
	public Node NodeFrom;
	public Node NodeTo;

	// Other members
}

// Container of roads
public class RoadsContainer
{
	// Other members

	// Returns roads located in specific region
	public Road[] getRoads(float X1, float Y1, float X1, float Y1)
	{
		// Implementation
	}

	// Other members
}

Bộ nhớ RAM và hiệu suất

Khi đánh giá hiệu suất và mức độ sử dụng bộ nhớ, các yếu tố của kiến trúc nền tảng dưới đây nên được cân nhắc đến:

  • Sắp xếp dữ liệu:
    Việc sắp xếp dữ liệu giúp tăng tốc độ truy xuất của CPU đến bộ nhớ. Vì vậy, phụ thuộc vào loại CPU mà địa chỉ của cấu trúc dữ liệu hay đối tượng trong bộ nhớ có thể bắt đầu từ những địa chỉ là bội số của 32 hay 64. Các trường dữ liệu bên trong cấu trúc hay đối tượng có thể được sắp xếp theo từng khối 32, 16 hoặc 8 byte (ví dụ, trường Lines trong class Road chiếm 4 byte thay vì 1 byte). Theo cách này, lượng bộ nhớ sử dụng tăng lên do những vùng nhớ không sử dụng đến.
  • Bộ nhớ đệm CPU:
    Như đã biết, mục đích chính của bộ nhớ đệm CPU là tăng tốc độ truy xuất đến những khối bộ nhớ được sử dụng thường xuyên. Kích thước của bộ nhớ đệm là rất nhỏ do đây là một trong những loại bộ nhớ đắt đỏ nhất. Khi làm việc với cấu trúc dữ liệu hay đối tượng, các vùng nhớ không sử dụng cũng được lấp đầy trong bộ nhớ đệm mà không mang bất kì thông tin hữu ích nào. Điều này làm giảm hiệu quả của việc sử dụng bộ nhớ đệm.
  • Kích thước con trỏ:
    Trên các hệ thống 32 bit, một con trỏ trỏ đến địa chỉ của đối tượng trong bộ nhớ có kích thước là 32 bit; qua đó giới hạn ứng dụng làm việc với kích thước RAM tối đa là 4GB. Các hệ thống 64 bit có thể làm việc với lượng bộ nhớ nhiều hơn nhờ sử dụng con trỏ có kích thước 64 bit. Các đối tượng luôn có một con trỏ trỏ đến nó (nếu không vùng bộ nhớ sẽ bị rỏ rỉ hoặc nằm trong danh sách sẽ bị loại bỏ bởi bộ dọn rác – Garbage Collector). Trong ví dụ của bài viết, trường NodeFrom và NoteTo của class Road sẽ chiếm 8 bytes tronng hệ thống 64 bit và 4 byte trong hệ thống 32 bit.

Như một nguyên tắc, trình biên dịch luôn tạo ra mã nguồn tốt nhất có thể, nhưng hiệu quả cao nhất chỉ có thể đạt được thông qua các giải pháp ứng dụng phần mềm.

Mảng các đối tượng

Dữ liệu có thể được lưu trữ bằng nhiều cấu trúc khác nhau: danh sách (list), bảng băm (hash table)… Việc lưu trữ dữ liệu trong một mảng (array) có lẽ là cách đơn giản và phổ biến nhất; đó là lý do chúng tôi quyết định lựa chọn cấu trúc này. Bạn có thể tìm hiểu những cấu trúc dữ liệu khác theo cách tương tự.

Trong C#, mảng các đối tượng lưu trữ địa chỉ tham chiếu của các đối tượng; bản thân các đối tượng này được lưu trữ ở nơi khác trong bộ nhớ heap. Cách tổ chức này cho phép thao tác dễ dàng hơn với một tập hợp các đối tượng vì bạn chỉ phải làm việc với các con trỏ thay vì bản thân đối tượng. Trong ví dụ của chúng tôi, hàm getRoads của class RoadsContainer trả về một tập hợp các đối tượng thông qua địa chỉ tham chiếu của chúng thay vì sao chép dữ liệu bên trong các đối tượng. Điều này có thể thực hiện được do kiểu của đối tượng trong C# là kiểu dữ liệu tham chiếu.

Điểm bất lợi trong việc lưu trữ các đối tượng như một mảng chính là việc phải thêm không gian lưu trữ cho các con trỏ cũng như việc sắp xếp lại các đối tượng trong bộ nhớ heap. Trên các hệ thống 64 bit, mỗi con trỏ chiếm 8 byte bộ nhớ và mỗi đối tượng được sắp xếp sao cho địa chỉ của nó có thể chia hết cho 8.

Mảng các cấu trúc

Các lớp (class) được thiết kế để lưu trữ Road và Node có thể được chuyển sang cấu trúc (struct). Các chỉ số kiểu số nguyên sẽ được sử dụng thay vì con trỏ đến đối tượng. Kết quả của việc chuyển đổi như sau:

public struct Road
{
	public float Length;
	byte Lines ;
	Int32 NodeFrom;
	Int32 NodeTo;

	// Other members
}

public class RoadsContainer
{
	// Other members

	// Roads are in an array now, not in the heap
	Road[] Roads;

	// Returns roads located in specific region
	public Int32[] getRoads(float X1, float Y1, float X1, float Y1)
	{
		// Implementation
	}

	// Returns road by index
	public Road getRoad(Int32 Index)
	{
		return Roads[Index];
	}

	// Other members
}

// Container of nodes is similar by structure
// to the container of roades
public class NodesContainer
{
	// Other members

	Node []Nodes;

	// Returns node by index
	public Node getNode (Int32 Index)
	{
		return Nodes[Index];
	}

	// Other members
}

Việc thay đổi này có lợi gì?

Road được lưu trữ theo kiểu cấu trúc thay vì đối tượng. RoadsContainer sử dụng một mảng để lưu trữ chúng. Hàm getRoad sẽ trả về những cấu trúc riêng biệt thông qua các số nguyên 32 bit được sử dụng như một con trỏ đến dữ liệu trong mảng. Các node trong class NodesContainer cũng hoạt động hoàn toàn tương tự.

Sử dụng các chỉ số 32 bit thay vì con trỏ 64 bit giúp giảm bộ nhớ và đơn giản hóa tác vụ truy xuất. Việc sử dụng chỉ số để tham chiếu đến các trường NodeFrom và NodeTo trong cấu trúc Road sẽ làm giảm bộ nhớ cần dùng đi 8 bytes (nếu các trường được sắp xếp theo vùng địa chỉ 32, 16 hoặc 8 bit).

Việc cấp phát bộ nhớ sẽ được thực hiện một lần khi mảng được tạo ra. Trong trường hợp lưu trữ địa chỉ tham chiếu các đối tượng, mỗi đối tượng cần được tạo ra độc lập. Việc tạo ra các đối tượng độc lập không chỉ cần thời gian mà còn cần thêm bộ nhớ để sắp xếp các trường dữ liệu cũng như đăng ký đối tượng bên trong bộ nhớ heap cũng như hệ thống dọn rác – GC.

Điểm bất lợi khi sử dụng cấu trúc thay vì đối tượng, như đã nói, là bạn không thể sử dụng con trỏ đến các cấu trúc (do cấu trúc là kiểu giá trị chứ không phải kiểu tham chiếu). Điều này ngăn cản việc thao tác với tập hợp các đối tượng. Vì vậy, hàm getRoads sẽ phải trả về chỉ số của các cấu trúc trong mảng. Trong khi đó hàm getRoad trả về cấu trúc; tuy nhiên, hàm này sẽ sao chép toàn bộ dữ liệu của cấu trúc để trả về hàm gọi, quá trình này làm tăng băng thông cũng như thời gian xử lý của CPU.

Mảng các giá trị nguyên thủy

Mảng các cấu trúc có thể được chuyển thành các mảng tương ứng với từng trường của cấu trúc đó. Nói cách khác, cấu trúc có thể được tách rời rồi loại bỏ. Ví dụ, sau khi tách rời và loại bỏ cấu trúc Road, chúng ta sẽ có mã lệnh sau:

public class RoadsContainer
{
	// Other members
	// Fields of structure Road
	float[] Lengths;
	byte[] Lines;
	Int32[] NodesFrom;
	Int32[] NodesTo;

	// Other members

	// Returns roads located in specific region
	public Int32[] getRoads(float X1, float Y1, float X1, float Y1)
	{
		// Implementation
	}

	// Returns length of road by the index
	public float getRoadLengt(Int32 Index)
	{
		return Lengths[Index];
	}

	// Returns number of lines of road by the index
	public byte getRoadLines(Int32 Index)
	{
		return Lines[Index];
	}

	// Returns starting node of road by the index
	public Int32 getRoadNodeFrom(Int32 Index)
	{
		return NodesFrom[Index];
	}

	// Returns ending node of road by the index
	public Int32 getRoadNodeTo(Int32 Index)
	{
		return NodesTo[Index];
	}

	// Other members
}

Việc thay đổi này có lợi gì?

Thay vì lưu trữ toàn bộ cấu trúc trong một mảng riêng lẻ, các trường của cấu trúc đó được lưu trữ trong các mảng khác nhau. Việc truy xuất đến các trường được thực hiện riêng biệt thông qua chỉ số.

Bộ nhớ lãng phí do việc sắp xếp các trường dữ liệu bên trong cấu trúc được loại bỏ khi mà dữ liệu các kiểu nguyên thủy được lưu trữ liền nhau. Bộ nhớ để lưu trữ không còn là một khối duy nhất mà là nhiều khối, lưu trữ mảng của các trường. Ở một mức độ nào đó, việc phân chia đó có ích cho hệ thống; sẽ dễ dàng hơn nhiều khi phải chuyển các phần nhỏ của một vùng nhớ liên tục thay vì một đoạn bộ nhớ liên tục lớn.

Giờ đây, việc truy cập đến từng trường yêu cầu sử dụng chỉ số mọi thời điểm trong khi với mảng cấu trúc, chỉ số chỉ phải sử dụng 1 lần duy nhất. Trong thực tế, việc này được coi vừa là điểm bất lợi cũng vừa là điểm lợi. Nếu chỉ phải sử dụng một phần nhỏ các trường, bạn sẽ tối ưu việc sử dụng bộ nhớ đệm CPU nếu chúng được lưu trữ trong các mảng độc lập. Để tận dụng tất cả lợi thế của bộ nhớ đệm còn phụ thuộc vào thuật toán, tuy nhiên trong bất kì trường hợp nào lợi thế mang lại là rất rõ ràng.

Dọn rác và quản lý bộ nhớ

Vấn đề đưa ra liên quan đến việc quản lý bộ nhớ. Dù sao đi nữa, địa chỉ các đối tượng trong bộ nhớ vẫn ảnh hưởng đến thời gian truy xuất. Cho đến thời điểm hiện tại, có rất nhiều cách quản lý bộ nhớ khác nhau, bao gồm cả hệ thống dọn rác tự động. Những hệ thống tự động này không chỉ theo dõi quá trình thu dọn bộ nhớ mà còn khắc phục hiện tượng phân mảnh bộ nhớ.

Các hệ thống quản lý bộ nhớ chủ yếu hoạt động với con trỏ của các đối tượng được cấp phát trong bộ nhớ heap. Đối với trường hợp của mảng cấu trúc hay mảng các trường, nó không thể làm việc trực tiếp với các phần tử trong mảng; toàn bộ công việc liên quan đến việc tạo và giải phóng các phần tử được đặt lên đôi vai của lập trình viên. Có thể thấy rõ ràng việc sử dụng mảng các cấu trúc hay các trường đã vô hiệu hóa chức năng của bộ dọn rác. Tùy thuộc vào ứng dụng, giới hạn này vừa có thể coi là điểm lợi, vừa có thể coi là điểm bất lợi.

Đánh giá

Lợi ích của việc tách rời được ước lượng thông qua một bài kiểm thử nhỏ. Mã nguồn của bài kiểm thử này có thể được tải về tại địa chỉ https://github.com/dgakh/Studies/tree/master/CSharp/Decapsulation. Trong bài kiểm thử, các mảng chứa 10 triệu phần tử được tạo ra, đọc và ghi dữ liệu. Bài kiểm thử chạy trên cả 2 chế độ 32 bit và 64 bit. Có một vấn đề nên được đề cập đến là trong chế độ 32 bit, sẽ rất dễ xảy ra tình huống tràn bộ nhớ khi phải làm việc với một lượng dữ liệu lớn. Mặc dù hiện nay chế độ 32 bit cho các hệ thống máy chủ và máy để bàn ngày càng ít được sử dụng, các hệ thống di động chủ yếu với dùng chế độ 32 bit. Vì vậy, việc đánh giá vẫn được thực hiện trong cả 2 chế độ.

Bộ nhớ

Bộ nhớ sử dụng trong chế độ 32 bit

Bộ nhớ sử dụng trong chế độ 64 bit

Như bạn có thể thấy, phần lớn bộ nhớ lãng phí nằm ở mảng các đối tượng. Với các hệ thống 64 bit, dung lượng lưu trữ tăng lên nhanh chóng. Mảng các cấu trúc hay các trường có độ lớn tương đương trong cả 2 chế độ. Mặc dù lưu trữ trong mảng các trường có lợi về lượng bộ nhớ hơn nhưng mức giảm này không thực sự quan trọng; bộ nhớ sử dụng giảm đi là do mất mát bộ nhớ khi sắp xếp các trường của kiểu cấu trúc.

Thời gian truy xuất


* – thời gian truy xuất quá nhỏ để có thể đo đạc chính xác

Thời gian truy xuất đến dữ liệu khi lưu trữ trong mảng các đối tượng là lớn nhất trong khi có thể truy xuất nhanh hơn nhiều nếu dữ liệu được lưu trữ trong mảng các trường một cách độc lập. Sự tăng tốc này là kết quả của việc sử dụng bộ nhớ đệm CPU một cách hiệu quả. Cũng phải lưu ý rằng bài kiểm thử được thực hiện với việc đọc/ghi liên tiếp các phần tử, do đó việc sử dụng bộ nhớ đệm được tối ưu hơn.

Kết luận

  • Tránh sử dụng lập trình hướng đối tượng (OOP) khi làm việc với lượng dữ liệu lớn có thể giúp sử dụng bộ nhớ RAM hiệu quả hơn 3 lần trên các hệ thống 64 bit, 2 lần trên các hệ thống 32 bit. Điều này xảy ra do kiến trúc phần cứng; và như hệ quả, nó ảnh hưởng đến tất cả các ngôn ngữ lập trình.
  • Trong C#, thời gian truy xuất thông qua chỉ số mảng nhỏ hơn nhiều so với truy xuất thông qua con trỏ đối tượng.
  • Công nghệ lập trình ở mức độ càng cao thì càng tốn tài nguyên. Làm việc ở mức độ thấp (mức độ hệ thống), với dữ liệu nguyên thủy (có thể đạt được thống qua tách rời các lớp hay cấu trúc) sử dụng ít tài nguyên nhất nhưng yêu cầu bạn phải viết nhiều mã lệnh cũng như công sức hơn.
  • Làm việc với các kiểu dữ liệu nguyên thủy là một cách tối ưu mã lệnh. Vì vậy, kiến trúc này không được sử dụng trong thiết kế kế ban đầu mà được sử dụng khi cần giảm lượng tài nguyên sử dụng.
  • Trong C++, nhiều vấn đề đưa có thể được giải quyết một cách minh bạch, nhưng với C#, cách thực hiện bên dưới được che đi. Thêm vào đó, thông thường khi học C#, ảnh hưởng của nền tảng không được cân nhắc đến.
  • Trong C#, cấu trúc (struct) nên được cân nhắc sử dụng thay vì lớp (class) khi có thể.
0R8A4000_


Leave a comment

Quên Agile đi, hãy viết những dòng mã lệnh chết tiệt

Tác giả: JAX Editorial Team
Bài gốc: Forget agile, just write the damn code

Lược dịch

“Họp đứng” từ Shutterstock

Erik Meijer, huyền thoại lập trình người Hà Lan được biết đến thông qua những đóng góp cho C#, Visual Basic, LINQ, Volta và .NET, đã đưa ra những lời chỉ trích gay gắt về Agile tại ngày hội Reaktor Dev ở Helsinki.

“Agile là khối u cần phải loại bỏ ra khỏi ngành công nghiệp.”

Erik Meijer, anh quả thật biết làm thế nào để bắt đầu một bài diễn thuyết. Và bây giờ, khi đã thu hút được sự chú ý, hãy nói cho chúng tôi biết vấn đề lớn nhất của Agile (phương pháp được tán dương và được coi là bền vững nhất trong ngành công nghệ thông tin, tất nhiên là sau YOLO-Driven Development rồi) là gì.

“Họp đứng là thứ tệ hại nhất từng được nghĩ ra.”

Có quá nhiều lập trình viên đang lãng phí thời gian để tán chuyện về mã lệnh mà không thực sự viết mã, Meijer tuyên bố khi đứng trên sân khấu tại ngày hội Reaktor Dev ở Helsinki. Tương tự như những lời kêu gọi trên đài phát thanh âm nhạc đầu thập niên 90, Meijer muốn “nói ít, viết nhiều”.

Agile không chỉ tiêu tốn thời gian mà dường như còn khiến chúng ta giống như những cỗ máy.

Nhẹ nhàng nhất thì những cuộc họp đứng nổi tiếng của Scrum chỉ là sự phiền phức làm gián đoạn công việc. Trong tình huống tệ nhất, Meijer cho rằng đó chỉ là cơ chế kiểm soát tinh vi được sử dụng trong quản lý để tạo ra ảo tưởng về sự tự tổ chức. Không như chủ đích ban đầu của Agile, những nhà quản lý dường như vẫn thực sự nắm quyền quyết định.

Tín đồ Agile ở khắp mọi nơi, Erik Meijer muốn bạn tỉnh ngộ để nhận ra hệ thống phân cấp được biến tấu như hệ thống phẳng cũng như vai trò giả tạo của scrum master. “Tất cả chỉ là một phần của kim tự tháp lớn. Chúng ta đang bị lừa, bị lạm dụng bởi những nhà quản lý”, Meijer lớn tiếng.

“Chúng ta là những lập trình viên. Công việc của chúng ta là viết mã lệnh.”

Meijer thậm chí còn đi xa hơn bằng việc đặt dấu hỏi về khả năng không mắc lỗi của phương pháp phát triển hướng kiểm thử (Test-Driven Development). Tại sao không nên sử dụng TDD? Lý do là phương pháp này đã thất bại trong việc phát hiện ra những lỗi xảy ra trong thực tế. Thay vào đó, Meijer đề xuất hướng tiếp cận khác, theo đó phần mềm phải được hoàn thành nhanh chóng để các vấn đề có thể được xử lý ngay khi chúng được phát hiện.

Với cách nghĩ khác thường như vậy, không có gì phải ngạc nhiên khi Meijer sớm phải đối mặt với những lời chỉ trích. Mặc dù không phải là người cực kỳ thần tượng Scrum, Nic Ferrier (một blogger về công nghệ thông tin) nói rằng các phương pháp Agile không đáng bị lên án. Vấn đề là ở chỗ các lập trình viên và những người quản lý không có khả năng giao tiếp đúng cách cũng như không hiểu lẫn nhau.

Hiện nay có 2 loại người trên thế giới đang chà đạp lên những thành quả của phần mềm. Loại thứ nhất là những người không có chút hiểu biết gì phần mềm và họ thuộc vào số đông. Loại thứ 2, mặc dù là những lập trình viên kinh nghiệm, quá tập trung vào việc lập trình đến mức không thể nhận ra thế giới xung quanh họ. Với những lời công kích chống lại Agile, Erik Meijer đã tự đặt mình vào nhóm thứ hai.

Meijer hiển nhiên không phải là người đầu tiên đề cập đến sự thiếu hiệu quả của Agile. Ngay từ khi được giới thiệu vào năm 2001, phương pháp này đã bị chỉ trích là cứng nhắc, thiếu hiệu quả và là phương pháp quản lý lạc hậu.

Lý lẽ có sức thuyết phục nhất của Meijer về Agile là sự thành công của nó cũng chính là nguyên nhân khiến nó thất bại. Trên thực tế, Dave Thomas, một trong những người sáng lập nên phương pháp này, cũng có cách nhìn nhận tương đồng. Theo Thomas, Thế giới “Agile” chỉ xoay quanh những văn phòng công nghệ thông tin; ở một chừng mực nào đó nó sẽ dần trở nên vô nghĩa. Kể từ đó, Agile đã trở thành sân chơi của cả những chuyên gia cũng như đối tác thứ ba để quảng cáo cho sản phẩm và dịch vụ của họ.

Hãy cùng nhìn nhận theo một hướng khác: những điều hiện đang được nói về Agile liên quan rất ít đến những điều được nói đến trong tuyên ngôn của Agile. Dù có là khối u của ngành công nghệ thông tin hay không, đó có lẽ là điều mà tất cả chúng ta đều có thể đồng ý.

0R8A4000_


Leave a comment

10 mẹo phỏng vấn xin việc cho lập trình viên

Tác giả: Jack Wallens
Bài gốc: 10 job interview tips for developers

Lược dịch

Những buổi phỏng vấn xin việc không còn là nỗi ám ảnh khi bạn chợt nhận ra rằng mình không bước trên con đường một chiều. Người phỏng vấn đúng là người quyết định liệu bạn có phù hợp với công ty hay không, nhưng bạn cũng phải tự mình quyết định một vấn đề lớn: Liệu đây có phải là nơi thích hợp cho mình không? 10 mẹo dưới đây sẽ giúp bạn nhanh chóng đưa ra quyết định đó.

1. Vấn đề không phải chỉ là công việc (mà là cả dự án nữa!)

Đây là một vấn đề lớn cho lập trình viên. Bạn phải nhớ rằng mình không chỉ phỏng vấn để tìm một công việc mà còn để tìm một dự án (rốt cuộc thì đây là phần thú vị nhất). Thậm chí nếu công ty bạn phỏng vấn không phải là công ty lớn nhất, có uy tín nhất, bạn sẽ vẫn muốn cân nhắc những khả năng mà dự án có thể mang lại. Một dự án đặc biệt có thể kéo theo nhiều dự án lớn cũng như một tương lai sáng lạn hơn là việc chỉ đơn giản đồng ý ký vào hợp đồng với một công ty lớn nhưng chỉ phát triển các dự án có quy mô nhỏ, các ứng dụng và dịch vụ nội bộ.

2. Hỏi về công cụ

Nhiều lập trình viên rất kĩ tính với công cụ phát triển sử dụng trong công việc. Bạn có phải người không ưa các công cụ dùng làm môi trường phát triển tích hợp (IDE – Integrated Development Environment) và thích dùng các công cụ như vi hay make để thực hiện công việc? Nếu đúng vậy, chắc chắn bạn sẽ muốn người thuê mình không cấm bạn sử dụng các công cụ phát triển bạn thấy tin cậy và hiệu quả. Mặc dù đó không phải là rào cản lớn với một số người, rất nhiều lập trình viên sẽ chỉ làm việc với một số môi trường nhất định. Liệu bạn có quyết định ký hợp đồng với một công ty bắt bạn phải làm việc với một môi trường phát triển không quen thuộc và thiếu hiệu quả, để rồi công việc của bạn có thể bị ảnh hưởng?

3. Ăn mặc chỉnh tề

Nghe có vẻ ngu ngốc phải không? Nhưng rất nhiều lập trình viên đã quen làm việc ở nhà hoặc làm việc trong môi trường cho phép họ thoải mái trong việc ăn mặc. Xuất hiện trong một buổi phỏng vấn với quần sóoc và dép là cách chắc chắn nhất để họ không gọi lại cho bạn. Tất cả những gì bạn cần làm là mặc quần dài, áo sơ mi và một chiếc cà vạt. Thậm chí nếu bạn phỏng vấn với tất cả khả năng, bạn không muốn mạo hiểm xúc phạm người phỏng vấn hay công ty đó. Bạn có thể không bao giờ mặc bộ quần áo đó thêm một lần nào nữa nhưng nếu chúng có thể giúp bạn vượt qua buổi phỏng vấn thì đó là một vụ đầu tư hoàn toàn đáng giá.

4. Thể hiện đam mê nhưng đừng mù quáng

Lập trình viên là những người nhiệt huyết nhưng đam mêm nào cũng nên có giới hạn. Đừng tiêu tốn toàn bộ thời gian chỉ để nói về việc bạn yêu thích lập trình thế nào, thay vào đó hãy nói về đam mê của mình thông qua việc giới thiệu những dự án bạn đã từng kinh qua. Không chỉ thể hiện cảm giác vui sướng khi được tham gia vào nhóm mà cả tầm quan trọng của việc viết ra mã lệnh trong sáng, dễ dọc đối với bạn. Hãy làm người phỏng vấn hiểu rằng bạn là một lập trình viên, người sẵn sàng thức đêm để giải quyết một vấn đề lập trình nhưng bạn phải đảm bảo họ cũng biết đó không phải đam mê duy nhất của bạn. Bạn sẽ không muốn người đối diện nghĩ rằng mình là loại “ngựa non háu đá”.

5. Chỉ mang tới những dự án đã hoàn thiện

Đừng chỉ mang tới bản sao đơn xin việc, hãy mang tới cả bản sao dự án tốt nhất bạn đã từng làm. Hãy in một ít mã lệnh cũng như tệp tin của dự án làm ví dụ. Hãy để người phỏng vấn thấy rằng dự án đó thực sự do bạn thực hiện và bạn biết rõ từng ngóc ngách của dự án đó. Đảm bảo rằng bất kì dự án nào bạn mang ra giới thiệu vẫn còn hoạt động. Nếu dự án là một trang web, nó phải có khả năng truy cập bất kì thời điểm nào trong buổi phỏng vấn. Đừng mạo hiểm giới thiệu một dự án đã thất bại. Hãy thực hành trước việc sử dụng phần mềm (hoặc trang web) và chắc chắn rằng bạn biết rõ cách giới thiệu làm sao để người đối diện biết sản phẩm đó do bạn làm ra.

6. Chia sẻ kiến thức của bạn về công việc

Đừng chỉ bước vào phòng và nói: “Tôi biết công ty anh làm gì và tôi thích công việc đó”. Hãy nắm vững công việc của công ty, những dự án họ đang thực hiện, ngôn ngữ sử dụng trong các dự án và thậm chí là cả môi trường phát triển. Bạn càng biết nhiều những thông tin này, bạn càng có cơ hội có được việc làm. Bên cạnh đó, bạn cũng sẽ gây ấn tượng với người phỏng vấn bằng việc đã tìm hiểu chi tiết những thông tin liên quan đến công ty.

7. Đừng bỏ qua các đồng nghiệp

Chê bai người khác để tự đề cao mình luôn là việc dễ làm. Đừng làm vậy! Tuyệt đối không bao giờ! Nếu bạn cần chê bai người khác chỉ để đề cao mình, đó là thời điểm thích hợp bạn nên tự nhìn lại bản thân. Nếu người phỏng vấn hỏi ý kiến của bạn về mã lệnh của những lập trình viên khác, hãy giữ lại những ý kiến tiêu cực cho riêng mình. Nói chuyện theo hướng tích cực và nếu bạn cảm thấy không đồng tình, hãy cho họ biết bạn có thể làm theo hướng khác.

8. Nhìn vào mắt người đối diện

Điều này tương tự với việc ăn mặc chỉnh tề. Mặc dù nhiều lập trình viên có thiên hướng hướng nội, ấn tượng bạn đề lại trong cuộc phỏng vấn sẽ theo suốt sự nghiệp của bạn. Đừng bỏ qua việc giao tiếp bằng ánh mắt với người phỏng vấn. Nhìn thẳng vào mắt người đối diện thể hiện bạn là người tự tin mà sự tự tin là điều mà tất cả các lập trình viên đều cần.

9. Đừng tỏ ra cái gì cũng biết

Mặc dù giao tiếp bằng ánh mắt cho thấy bạn là người rất tự tin, bạn sẽ không muốn sự tự tin đó đi quá xa. Không ai muốn thuê hay làm việc cùng một người lúc nào cũng tỏ ra biết tất cả. Bất kể bạn viết mã lệnh tốt đến thế nào đi nữa, việc kiêu căng, tỏ ra tự tin thái quá sẽ gây phản tác dụng. Nhớ nằm lòng câu thần chú sau đây sẽ giúp bạn: có người biết ít hơn bạn thì cũng sẽ có người biết nhiều hơn bạn. Luôn có một ai đó thông minh hơn, viết mã lệnh tốt hơn bạn. Đừng quên điều này khi bạn bước vào cuộc phỏng vấn. Một chút khiêm tốn sẽ tạo ra ấn tượng tuyệt vời.

10. Đặt câu hỏi

Khi người phỏng vấn hỏi liệu bạn có bất kỳ câu hỏi nào không, đừng ngại mà bỏ qua. Sự tò mò của bạn về công ty và những dự án của công ty chứng minh rằng bạn biết bạn đang tìm kiếm công việc như thế nào; từ đó mang đến cho bạn nhiều lợi thế hơn việc chỉ đơn giản nhún vai. Nhưng đừng đặt câu hỏi chỉ để hỏi (câu hỏi về việc tăng lương, thời gian nghỉ và cách ăn mặc có thể để dành đến thời điểm bạn được đề nghị một vị trí làm việc). Hãy hỏi cụ thể và chắc chắn rằng câu hỏi của bạn hướng đến các dự án, ngôn ngữ dự án yêu cầu, nhóm làm việc và những điều khác bạn nghĩ đến khi bạn ở đó.

Đã qua rồi thời kì ngồi phỏng vấn giống như ngồi trên ghế nóng. Trong khi người phỏng vấn mong bạn nhận được thông tin, họ cũng chuẩn bị cẩn thận để đặt ra câu hỏi cho bạn. Hãy tiến tới thổi bay chúng đi, cho họ thấy bạn có thể giúp họ thành công; sau cùng bạn sẽ chợt nhận ra rằng toàn bộ quá trình phỏng vấn không quá kinh khủng như bạn nghĩ.

P/S: Bạn nào có công việc gì tốt giới thiệu cho tớ cái nhỉ😀

0R8A4000_


1 Comment

5 mẹo giúp bạn thuê được những nhân viên phát triển phần mềm tốt nhất

Tác giả: Jack Wallens
Bài gốc: 5 tips to help you hire the best software developers

Lược dịch

Thuê nhân viên phát triển phần mềm là một công việc không dễ dàng. Họ không đơn thuần là những kĩ sư, vì vậy bạn không thể áp đặt quá trình tuyển dụng thành một quy định cứng nhắc cho phòng IT. Trên thực tế, những người phát triển phần mềm thường rất rắc rối, đòi hỏi bạn phải có sự lưu tâm đặc biệt.

Những người phát triển phần mềm đồng thời cũng là những người thiết kế, những người có kĩ năng về kĩ thuật với tài năng bẩm sinh. Người ta thường nói rằng kĩ năng có thể học được nhưng khiếu thẩm mĩ thì không. Điều này cũng đúng đối với phát triển phần mềm. Hoặc là bạn có khả năng, hoặc là không. Chắc chắc bạn có thể học một ngôn ngữ như C hay C++ nhưng điều đó không đồng nghĩa với việc bạn có thể phát triển phần mềm.

Trước khi bạn trở nên quá căng thẳng, hãy sử dụng 5 mẹo dưới đây để có thể thuê được những nhân viên phát triển tốt nhất cho công việc của mình.

1. Phỏng vấn đa dạng

Khi bạn muốn thuê nhân viên quản lý hệ thống, tốt hơn nên sử dụng một phương pháp rõ ràng. Bạn cần biết họ có những kĩ năng gì. Liệu họ có quản lý được hệ thống máy chủ Windows không? Liệu họ có biết về Active Directory hay không? Kĩ năng bảo mật của họ tốt đến mức độ nào? Phương pháp này cũng sẽ đúng nếu bạn muốn thuê một nhân viên quản trị mạng. Cậu ta có biết gì về bảo mật không? Cậu ta thành thạo những nền tảng nào? Tuy nhiên, đối với việc phỏng vấn nhân viên phát triển phần mềm, các câu hỏi cần được nghiên cứ kĩ lưỡng chứ không chỉ đơn thuần là câu hỏi về kĩ năng.

Người đến phỏng vấn có thể có một danh sách dài những ngôn ngữ họ biết trong lý lịch, nhưng liệu họ có thể chắp nối chúng lại với nhau để tạo ra một cái gì đó không? Điều quan trọng nhất cần lưu tâm là những dự án họ đã tham gia. Những dự án nào chính nào học đã từng làm và kết quả công việc của họ có đạt yêu cầu không? Liệu họ có dự án riêng nào không và liệu học có thể giới thiệu các dự án không?

Bạn cần biết công việc thực tế của họ, tìm hiểu xem liệu họ có thể sử dụng ngôn ngữ mình biết để tạo ra những sản phẩm mang tính khả thi không. Hãy lưu tâm và tốc độ thực hiện và sự hiệu quả của họ. Mất bao lâu để họ có thể hoàn thành dự án từ những khái niệm ban đầu? Nếu bạn đang xem xét một ứng cử viên, người mất một khoảng thời gian đáng kể trong năm chỉ để phát triển một ứng dụng mobile đáp ứng mục tiêu nhỏ và trông khá tệ khi thực thi, bạn nên bỏ qua ứng cử viên đó. Tuy nhiên, nếu bạn xem xét một người phát triển phần mềm đã thực hiện nhiều website và ứng dụng chỉ trong một khoảng thời gian ấn tượng, đó có thể chính là người bạn cần.

Hãy nhớ rằng khi phỏng vấn những người phát triển phần mềm, luôn quan tâm đến kết quả và sản phẩm cuối cùng. Đừng chú tâm vào cách mà họ thực hiện chúng.

2. Không tập trung quá nhiều vào nỗ lực trong nhóm

Với phần lớn nhân viên có tiềm năng, bạn phải tập trung vào khả năng làm việc trực tiếp của họ với những người khác. Đó là một kĩ năng cực kì quan trọng. Làm thế nào những người quản trị làm việc với nhân viên, khách hàng và cấp trên của họ?

Khi nghĩ về những nhân viên phát triển phần mềm, bạn phải đặt vấn đề nhóm sang một bên, khi mà phần lớn thời gian họ phải làm việc độc lập. Thậm chí khi một dự án được thực hiện bởi cả nhóm, đa phần thành viên phát triển sẽ phải làm việc một mình, bởi vì họ phải tập trung vào một chứng năng trong tổng thể dự án. Khi công việc của họ hoàn thành, học đưa kết quả ra cho cả nhóm để tích hợp. Nếu có vấn đề, họ sẽ phải tự mình tìm ra sai sót. Công việc có thể thực sự tách biệt với mọi người.

Tất nhiên, điều đó không có nghĩa bạn hoàn toàn bỏ qua khía cạnh giao tiếp của ứng cử viên. Cuối cùng, nhân viên đó sẽ phải giao tiếp với những người khác chứ không chỉ là những người quản trị mạng hay hệ thống.

3. Xem xét những điểm đáng lưu tâm trên khía cạnh nghệ thuật hay những khía cạnh thiết kế khác

Thoạt đầu điều này có vẻ kì lạ nhưng hãy nhớ rằng, phát triển phần mềm tương đồng với công việc thiết kế hơn là công việc hỗ trợ các vấn đề về máy móc. Bạn sẽ muốn tìm một người phát triển quan tâm đến nghệ thuật, âm nhạc và những kĩ năng liên quan đến thiết kế khác. Những người này có khả năng tốt hơn trong việc nhìn nhận công việc phát triển từ một mức độ cao; khả năng khái quát dự án cũng như những thành phần cấu thành nên dự án.

Những mối quan tâm riêng này sẽ không được liệt kê trong lý lịch của họ. Để thực sự nắm được thông tin này, bạn phải vượt qua rào cản của việc phỏng vấn và nói chuyện thực sự với ứng cử viên. Hiểu nhiều hơn những thông tin cá nhân của ứng cử viên chứ không chỉ là kĩ thuật. Tìm ra những mối quan tâm, niềm đam mê cũng như quá khứ của họ. Đừng lo lắng việc này sẽ dẫn đến những câu chuyện vụn vặt. Bạn có thể tìm ra một ứng cử viên người cũng có thể viết nhạc; một khả năng có mối liên hệ thật sự với phát triển phần mềm.

4. Hỏi về kĩ năng gỡ lỗi

Khả năng tìm ra vấn đề trong phần mềm không quan trọng như khả năng hoàn chỉnh dự án từ đầu đến cuối. Nhưng khả năng nhanh chóng chỉ ra vấn đề là một năng khiếu cực kì đặc biệt. Khi một người tạo ra sản phẩm, họ không chỉ đơn giản tung ra thị trường rồi phủi tay. Họ phải giúp sức vào quá trình tìm lỗi. Nói gì đi nữa, nếu đó là mã lệnh của họ thì sẽ chẳng ai lại hiểu những dòng mã đó tốt như người tạo ra chúng.

Không phải mọi người đều có thể làm tốt việc này. Bạn sẽ thấy có những người thậm chí không thể thể tìm ra lỗi trong mã lệnh mình viết. Trên thực tế, bạn sẽ thấy có những nhân viên phát triển phủ nhận rằng có sai sót trong công việc của họ, đồng thời nhấn mạnh rằng lỗi đó thuộc về người dùng. Bạn tuyệt nhiên nên tránh xa bất kì ứng cử viên nào không thể gỡ lỗi hoặc luôn cho rằng mã lệnh của họ không bao giờ có lỗi.

5. Tìm kiếm những lập trình viên gọn gàn và ngăn nắp

Một trong những vấn đề lớn nhất với những nhà phát triển là khả năng viết mã lệnh sáng sủa, dễ hiểu. Nếu bạn thuê một người có thể hoàn thành công việc bằng những dòng mã lệnh cẩu thả (mà không ai khác có thể hiểu), bạn đã thất bại trong việc tuyển người. Điều gì xảy ra nếu anh ta nghỉ việc và không ai khác có thể làm việc với những dòng mã lệnh anh ta để lại? Liệu bạn có trả tiền cho một ai đó để họ bỏ ra nhiều giờ dọn dẹp những dòng mã lệnh cẩu thả trên?

Việc biết người bạn thuê có thể viết ra những dòng mã lệnh và nhận xét sáng sủa hay không là rất quan trọng. Những mã lệnh đó phải được hiểu và sử dụng bởi những đồng nghiệp khác. Nếu không bạn có thể đã thuê về một quả bom hẹn giờ.

Thuê nhân viên phát triển phần mềm không phải công việc khiến bạn phải quá lo lắng. Nếu bạn tiếp cận quá trình tuyển dụng bằng những lưu tâm nhỏ, bạn sẽ thành công trong việc tuyển dụng ứng viên, người sẽ giúp bạn xây dựng sản phẩm hoặc dự án phù hợp với nhu cầu của công ty bạn.

0R8A4000_


Leave a comment

Quản lý lập trình viên

Tác giả: Jon Evans (@rezendi)
Bài gốc: On Managing Developers

Lược dịch

Tôi là một kĩ sư phần mềm, tiểu thuyết gia, nhà báo, đồng thời cũng là một nhà quản lý; và quản lý các lập trình viên là công việc khó nhằn nhất mà tôi từng làm (không phải công việc nặng nhọc nhất nhưng là công việc khó nhằn nhất). Tôi không tự coi mình là chuyên gia hay một nhà quản lý xuất sắc; nhưng tôi có thể đảm bảo với bạn rằng tôi là một người cầu thị. Dưới đây là một số bài học rút ra từ sai lầm của chính bản thân tôi.

Nắm quyền phụ trách không có nghĩa bạn đang nắm quyền kiểm soát

Điều trớ trêu trong việc quản lý đó là chức vụ của bạn càng cao bao nhiêu, khả năng kiểm soát thực sự của bạn càng ít đi bấy nhiêu. Khi bạn chỉ là một người lập trình bình thường, bạn bắt máy tính thực hiện chính xác những gì bạn muốn. Khi bạn là một nhà quản lý, bạn chỉ hy vọng rằng mọi người hiểu những gì bạn muốn và sau đó tin tưởng (hoặc cầu nguyện) rằng họ sẽ thực hiện chính xác yêu cầu trong thời gian quy định.

Các nhà quản lý có xuất phát điểm là lập trình viên, đặc biệt là những lập trình viên đa năng (full-stack – hay còn gọi là “tài tử”) như tôi, thường gặp khó khăn với vấn đề này. Điều này đặc biệt chính xác khi họ từng do dự trong việc lựa chọn công việc lập trình hay quản lý (một số kết hợp cả hai). Tự mình làm hết mọi việc để đảm bảo nó được thực hiện chính xác là vô cùng khó khăn.

Vẫn đề trở nên khó khăn hơn nữa khi phải phân biệt giữa việc “đó không phải là cách tôi sẽ làm” và “đó là cách làm sai, cần phải tái cấu trúc / viết lại / bố trí lại” khi xem xét công việc của một ai đó. Nhưng bạn cũng phải tạo cơ hội cho những người mới vào để họ phát triển cũng như tạo môi trường cho những lập trình viên có kinh nghiệm để họ phát huy. Bạn phải buộc mình lui lại và chấp nhận rằng việc có ảnh hưởng lớn hơn đi kèm với việc giảm bớt khả năng kiểm soát.

Những nhà quản lý không có xuất phát điểm là kĩ sư thậm chí có ít khả năng kiểm soát cũng như thiếu hiểu biết về quá trình phát triển và khó khăn có thể mắc phải hơn. Tôi không tin kết luận này lắm nhưng không phủ nhận rằng có những người như vậy, thậm chí một số còn là những người giỏi nhất tôi từng làm việc cùng hay làm việc cho. Điều họ mang lại (hy vọng thế) là tăng khả năng suy nghĩ như một khách hàng, người vận hành hay người dùng cuối. Và có lẽ cũng nâng cao khả năng tránh xa khỏi ám ảnh rằng mọi thứ phải luôn nằm trong tầm kiểm soát. Những lập trình viên tiến thân thành nhà quản lý có xu hướng tự coi mình như vị tướng thống lĩnh một đội quân trong khi thực tế bạn là một hoa hiêu đang hy vọng hướng dẫn con tàu vượt qua cơn bão. Ở đó, điều những thủy thủ đoàn làm thực sự rất quan trọng.

Agile rất tốt. Nhưng tại sao là Agile?

Mọi người nói nhiều về phương pháp phát triển; câu trả lời là “quá nhiều” nếu bạn hỏi tôi. Ở nhiều nơi, “phát triển linh hoạt” (Agile development) đã được hệ thống hóa thành một quy trình cố định với những quy định cụ thể cho từng tiến trình như “standup”, “scrum” và “sprint”. Những quy tắc này được ám chỉ mơ hồ như là những nguyên tắc cơ bản trong tuyên ngôn của Agile bao gồm “Tính cá thể và tính tương tác quan trọng hơn qui trình và công cụ” và “Phản ứng với các thay đổi quan trọng hơn tuân thủ kế hoạch”. Vậy các công ty đã tạo ra và tuân theo những gì? Quy trình Agile, công cụ và kế hoạch. Chẹp! Nếu bạn là thạc sĩ được chứng nhận về Scrum, bạn đang làm hoàn toàn sai.

Bất kì quá trình riêng biệt nào được tạo ra có lẽ đều không thích hợp. Nhóm phát triển tốt nhất mà tôi từng làm việc cùng luôn khởi đầu một ngày bằng việc họp nhanh (standup). Một nhóm tệ hại nhất tôi từng gặp cũng làm như vậy. Mọi người tung hô ý kiến của Lean Startup về “Minimum Viable Product” nhưng họ cũng nói về nó như là một thiết kế lỗi thời. Họ muốn một thiết kế phải “đẹp” và “hoàn hảo” để bất kì dự án mới nào đều có thể thành công. Các cuộc họp trực diện có thể cực kỳ hiệu quả nhưng liệu có khả thi cho các nhóm làm việc từ xa ở các vùng địa lý khác nhau? Câu hỏi là: ai mới đúng? Ở đây, như thường lệ, câu trả lời là “điều đó còn tùy”.

Đừng hiểu lầm tôi. Tôi không khuyên bạn vứt bỏ tất cả những phương pháp tốt đã được tạo ra. Tôi chỉ muốn nói rằng các hệ thống cũng như phương pháp bạn chọn cho bất kì dự án nào nên mềm dẻo và linh hoạt; tùy thuộc vào nhóm phát triển cũng như hoàn cảnh cụ thể.

Thật may mắn là tôi được làm việc cho một công ty sử dụng phương pháp Agile nhưng vẫn quan tâm đến những gì thực sự quan trọng. Điều quan trọng nhất của phương pháp phát triển linh hoạt (Agile development) nằm trong chính tên của nó. Bạn phải linh hoạt. Và bạn phải tiến nhanh. (Tất nhiên thực tế là bạn phải viết mã kiểm tra. Điều đó không có trong tên phương pháp nhưng nó cũng rất quan trọng). Theo kinh nghiệm bản thân của tôi, sự trì trệ trong phần mềm chịu ảnh hưởng của hiệu ứng Lindy. Vì vậy bạn phải chuyển gia mã lệnh thường xuyên và liên tục; hiện tại trì hoãn càng nhiều, tương lại bạn càng trì hoãn nhiều hơn. Giống như một con cá mập, nếu bạn không bơi, bạn sẽ chết đói.

Công việc chết tiệt là công việc của bạn

Về cơ bản, công việc của người quản lý là giúp người khác làm việc hiệu quả hơn. Cách tốt để thực hiện điều đó là gì? Thực hiện công việc theo cách của họ. Điều này có nghĩa là bạn phải tìm ra công việc quan trọng nào mà lập trình viên ghét nhất rồi làm việc đó cho họ.

Rất hiếm lập trình viên thích viết tài liệu. Điều này đồng nghĩa viết tài liệu là công việc của bạn. Việc kiểm tra là thực sự quan trọng nhưng cũng chẳng mấy lập trình viên thích viết mã lệnh kiểm tra. Đây cũng là công việc của bạn. Không phải toàn bộ mã lệnh kiểm tra, việc này không cần thiết, nhưng phải đủ để tạo ra một ví dụ, một chuẩn để thúc đẩy những thứ tiếp theo. Bạn không phải là lập trình viên? Hãy học, đủ để tự mình viết mã lệnh kiểm tra. Nếu bạn là một lập trình viên? Hãy xây dựng bộ khung kiểm thử sao cho người khác có thể dễ dàng thêm vào nếu cần. Nếu bạn nghĩa kiểm tra chất lượng là công việc của người khác hay không thuộc trách nhiệm của bạn thì bạn thực sự là một nhà quản lý rất, rất, rất tồi.

Bạn cũng phải làm công việc chết tiệt khác là kết nối mọi người với nhau. Nếu một lập trình viên nói với bạn “đây là một mớ bòng bong, chúng ta phải chấp nhận thương đau bằng việc tái cấu trúc và làm lại cho đúng, tất nhiên phải lui thời hạn hoàn thành lại”, bạn có lẽ cần phải ủng hộ ý kiến đó dù sẽ phải chấp nhận mất mát trong ngắn hạn. Về lâu dài, bạn sẽ được đền đáp. Chỉ giữ những vấn đề kĩ thuật lại nếu nó không gây ra ảnh hưởng về lâu dài.

Kết luận của kết luận của kết luận: con người chính là vấn đề

Thật không may, có lẽ bạn cũng đã biết, con người thật đáng ghét. Người ta chõ mũi vào chuyện của bạn, trêu ngươi, làm ngơ, làm phiền, biến mất, bỏ rơi hoặc mất niềm tin vào bạn; thông thường chẳng vì lý do chính đáng nào cả. Thử đoán xem? Nếu bạn là một nhà quản lý, sự mất kiểm soát của họ là của bạn và ngay cả những vấn đề của họ cũng là vấn đề của bạn. Hãy làm quen với điều này. Bạn cần sớm nhận ra vấn đề của mọi người và có kế hoạch ứng phó với các vấn đề đó.

Ngoài ra, mọi người làm việc theo những cách khác nhau với tốc độ khác nhau. Đó là cách lịch sự để nói rằng việc thuê nhân viên thực sự là quan trọng, bởi vì như tôi đã nói, con người thật sự đáng ghét.

Nhưng đợi chút, bạn có biết cách làm cho mọi người (thật kinh ngạc) ít đáng ghét không? Không phải tôi cố tính tạo sự chú ý nhưng bài học đáng nhớ nhất trong sự nghiệp của tôi là: khi mọi người thấy có thể tin tưởng bạn cũng là lúc bạn thấy tin tưởng mọi người. Tôi thề đó là sự thật!

Vì vậy đừng bao giờ phỉ báng bất kì ai. Lời khen đáng giá nhất mà tôi nhận được là từ ông chủ cũ sau cuộc phỏng vấn. Ông ấy chậm rãi nói với tôi: “Tôi khi biết anh làm thế nào nhưng khi anh nói, mọi người trở nên chân thành hơn”. Hãy nói sự thật theo cách bạn nhìn nhận. Nói khách sáo, xin đừng hiểu lầm tôi, nhưng phải thật lòng. Chỉ có như vậy bạn mói nhận được sự tin tưởng từ người khác.

Về cơ bản bạn là người phiên dịch kĩ thuật cho mọi người

Những nhà quản lý diễn giải toàn cảnh dự án thành những nhiệm vụ độc lập cho từng lập trình viên cùng với những chi tiết cũng như các tương tác cụ thể sẽ diễn ra. Họ cũng diễn giải lại công việc thực hiện bởi lập trình viên nhằm giúp khách hàng, người vận hàng cũng như người dùng cuối có thể hiểu công việc đã hoàn tất. Và có lẽ điều quan trọng nhất là diễn giải lại chi tiết lỗi, hạn chết và cơ hội cho khách hàng, người vận hàng cũng như người dùng cuối. Bất kì dịch giả chuyên nghiệp nào cũng sẽ nói với bạn rằng điều này có nghĩa bạn cần phải hiểu công việc sâu sắc hơn chính bản thân tác giả. Với họ, đó là trực giác nhưng với bạn, đó là công việc. Chia nhỏ mọi thứ theo cách làm sao để bất kì ai đều có thể hiểu được.

Dưới danh nghĩa của một tác giả, tôi xin nói rằng những dịch giả không nhận được bất kì vinh quang nào cuốn sách mang lại. Tất cả những quyết định tốt có được là do tác giả. Tương tự vậy, những người sáng lập (trong trường hợp của chúng tôi là khách hàng) nhận được ca ngợi về sự sáng tạo còn lập trình viên nhận được sự ca ngợi về mã lệnh. Chẳng ai nhìn một em bé xinh xắn rồi ngợi ca những nữ hộ sinh cả.

Vậy thì tại sao lại phải làm công việc này? Lý do như tôi nói là từng cá nhân lập trình viên có thể kiểm soát rất tốt nhưng học lại thiếu tầm ảnh hưởng. Không làm và nhìn nhận theo cách của họ, quyết định bạn đưa ra sẽ ảnh hưởng vĩnh viễn đến việc liệu cái bạn xây dựng có tốt hay không. Và nếu điều đó chẳng có ý nghĩa gì với bạn, bạn không chỉ là một nhà quản lý tồi, bạn còn đang hoàn toàn sai đường lạc lối.