Một câu hỏi về đạo đức lập trình

Bài viết được dịch từ blog Coding Horror

Đây là một số chuẩn mực về đạo đức trong lập trình từ tổ chức uy tín ACM:

Là một thành viên của ACM tôi sẽ

  • Đóng góp cho xã hội và sự hạnh phúc của nhân loại.
  • Tránh làm hại những người khác.
  • Trở nên thành thật và đáng tin cậy.
  • Công bằng và hành động mà không phân biệt đối xử.
  • Tôn trọng quyền sở hữu tài sản bao gồm cả quyền tác giả và bằng sáng chế.
  • Mang lại một sự tín nhiệm thích hợp cho tài sản trí tuệ.
  • Tôn trọng quyền riêng tư của những người khác.
  • Tôn trọng thông tin bí mật.
Lập trình viên nên tuân theo những chuẩn mực đạo đức trong nghề.Lập trình viên nên tuân theo những chuẩn mực đạo đức trong nghề.

Đọc tiếp >>

Advertisements

Làm theo chỉ dẫn trên thùng sơn

Bài viết được dịch từ blog Coding Horror

Tôi đã nói chuyện qua điện thoại với một người bạn của tôi một vài ngày trước đây, và anh ta đã mô tả một dự án mà anh vừa tiếp nhận gần đây. Nó là sản phẩm của nửa tá lập trình viên khác nhau, mỗi người xây dựng một phần trong cái dự án đó theo một cách hoàn toàn khác nhau, mà có rất ít hoặc không có sự trao đổi nào giữa bất kỳ ai trong số họ cả. Code của dự án đó đã nói lên một câu chuyện rằng: bạn sẽ thấy đó là một đội ngũ nghiệp dư; chả tuân theo một khuôn mẫu nào cả; một đám ô hợp.

Lập trình viên cần tuân theo những chỉ dẫn để dự án có thể thành công.Lập trình viên cần tuân theo những chỉ dẫn để dự án có thể thành công.

Đọc tiếp >>

Code tốt nhất là không code chút nào cả

Bài viết được dịch từ blog Coding Horror

Rich Skrenta viết rằng code chính là kẻ thù của chúng ta.

Code thì rất dở. Mó mục nát. Nó yêu cầu phải được bảo trì theo định kỳ. Nó có nhiều bug mà cần phải được phát hiện. Những đặc trưng mới nghĩa là code cũ đã bị điều chỉnh. Bạn càng có nhiều code, thì càng có nhiều chỗ để cho các bug trú ẩn. Thời gian checkout và biên dịch sẽ lâu hơn. Và một nhân viên mới sẽ cần thời gian lâu hơn để có thể hiểu được hệ thống của bạn. Nếu bạn phải tái cấu trúc nó thì sẽ có rất nhiều thứ phải thay đổi.

Code được tạo ra bởi các kỹ sư. Để tạo ra nhiều code hơn thì yêu cầu nhiều kỹ sư hơn. Các kỹ sư có chi phí truyền đạt là n^2, và tất cả phần code mà họ đã bổ sung vào hệ thống trong khi mở rộng khả năng của nó thì cũng làm tăng toàn bộ phí tổn. Bạn nên làm bất cứ điều gì có thể để tăng năng suất của những lập trình viên riêng lẻ thông qua code mà họ viết. Bớt đi những đoạn code làm cùng công việc giống nhau. Số lượng lập trình viên phải thuê sẽ ít đi. Chi phí truyền thông trong tổ chức cũng sẽ giảm đi rất nhiều.

Thực ra code tốt nhất là không code một chút nào cả!Thực ra code tốt nhất là không code một chút nào cả!

Đọc tiếp >>

Kỹ năng lập trình bớt tệ hơn sau mỗi năm

Bài viết được dịch từ blog Coding Horror

Bài viết tổng hợp về điểm mạnh yếu các ngôn ngữ lập trình của Steve Yegge thì, theo như ông ta đã chỉ ra rằng, nó chẳng tốt cũng chẳng phải là hoàn thiện, nhưng thực sự nó là một trong những bài blog có giá trị nhất mà tôi đã đọc trong năm nay. Tôi sẽ tóm tắt một đoạn cho bạn: theo như Steve thì ngôn ngữ lập trình Ruby là sự kết hợp của những đặc trưng tốt nhất của các ngôn ngữ khác như Perl, Smalltalk, Python, và Lisp vào trong một chiếc túi có sức mạnh vô địch, và nó cũng tránh được những thiếu sót trong khi thiết kế mà các ngôn ngữ khác đã gặp phải trước đó.

Bạn phải liên tục học hỏi để nâng cao kỹ năng lập trình sau mỗi năm.Bạn phải liên tục học hỏi để nâng cao kỹ năng lập trình sau mỗi năm.

Đọc tiếp >>

Có một thứ mà mọi kỹ sư phần mềm đều nên biết

Bài viết được dịch từ blog Coding Horror

Tôi là một fan hâm mộ Steve Yegge, vì vậy thật là một vinh hạnh lớn khi mời được Steve Yegge nói chuyện trong một podcast gần đây trên Stack Overflow. Tuy nhiên, có một điều mà tôi không thể đoán trước được, đó là một chủ đề đặc biệt theo kinh nghiệm của Steve tại Google và Amazon cứ tiếp tục lặp đi lặp lại:

Nếu có một thứ mà tôi có thể dạy cho mọi kỹ sư, thì đó là cách làm thế nào để tiếp thị.

Không phải là làm thế nào để gõ, không phải là làm thế nào để viết, không phải là làm thế nào để thiết kế một ngôn ngữ lập trình, mà là tiếp thị.

Tiếp thị mà một trong những kỹ năng quan trọng nhất mà một lập trình viên nên biết.Tiếp thị mà một trong những kỹ năng quan trọng nhất mà một lập trình viên nên biết.

Đọc tiếp >>

Lập trình thực dụng

Bài viết được dịch từ blog Coding Horror

Như đã đề cập trong một bài viết trước đây rằng tôi có giới thiệu tác giả Andrew Hunt của nhóm lập trình viên pragmatic programmer nổi tiếng đến nói chuyện trực tiếp với nhóm chúng tôi. Anh ta tình cờ lại sống trong vùng này, điều đó khiến cho mọi việc rất thuận lợi. Tôi phải thừa nhận rằng mình không biết nhiều về những gã này cho tới khi tôi tình cờ xem qua bài thuyết trình Làm Thế Nào Để Giữ Công Việc Của Bạn của họ vào cuối năm ngoái khi tôi đang tìm kiếm thông tin về xu hướng offshoring (gia công ra nước ngoài). Đó là một trong những cách xử lý tốt nhất của chủ đề offshoring, vì vậy tôi đã rất vui mừng khi có thể mời Andy đến thuyết trình và nói thêm về một số vấn đề riêng với tư cách cá nhân.

Bạn hãy xử lý hoặc khoanh vùng bất kỳ lỗi nào dù nhỏ nhất trong hệ thống, để tránh việc dẫn đến những hậu quả khôn lường.Bạn hãy xử lý hoặc khoanh vùng bất kỳ lỗi nào dù nhỏ nhất trong hệ thống, để tránh việc dẫn đến những hậu quả khôn lường.

Đọc tiếp >>

Vấn đề lớn nhất của quản lý dự án là con người

Bài viết được dịch từ blog Coding Horror

Đôi khi tôi cảm thấy giống như là mình đã học được tất cả mọi thứ cần biết về việc quản lý dự án phần mềm trên chương trình truyền hình Monster House.

Chính việc phối hợp tốt giữa các thành viên trong nhóm sẽ quyết định sự thành bại của dự án.Chính việc phối hợp tốt giữa các thành viên trong nhóm sẽ quyết định sự thành bại của dự án.

Đọc tiếp >>

Tại sao việc nhân bản Thung lũng Silicon là không thể

Bài viết được dịch từ Technology Review

Lời bàn của Vinacode:

Người ta nói rằng sự hình thành của Thung lũng Silicon thì gồm 3 yếu tố: thiên thời, địa lợi nhân hòa. (Bạn đọc thêm bài này để biết thêm.)

Các cột mốc thời gian để hình thành Thung lũng Silicon như ngày hôm nay, bắt đầu từ cuộc đổ xô đến California tìm vàng vào năm 1849.

Các cột mốc thời gian để hình thành Thung lũng Silicon như ngày hôm nay, bắt đầu từ cuộc đổ xô đến California tìm vàng vào năm 1849.

  • Thiên thời: là bắt đầu từ cuộc đổ xô đến California tìm vàng năm 1849 đã tạo nên dân cư đông đúc nơi đây, tiếp đến là sự hình thành nên trường đại học Stanford (1891), rồi sau đó là có sự phát minh ra transitor. Và ông hiệu trưởng trường đại học Stanford vì lý do thiếu tài chính nên đã nhượng khu vực đất trống xung quanh trường cho các doanh nghiệp lập các trung tâm nghiên cứu. Sự hợp tác này khiến đại học Stanford có tiền trang trải chi phí, và sinh viên ra trường không phải đi xa để kiếm việc làm (và điều này cũng vô tình tạo ra một hệ sinh thái công nghệ tuyệt vời).
  • Địa lợi: khu vực California có biển, có núi bao quanh. Thiên nhiên tuyệt vời đã tạo bầu không khí cởi mở sáng tạo. Và diện tích Thung lũng Silicon có thể mở rộng rất thoải mái.
  • Nhân hòa: có rất nhiều tài năng xuất hiện ở thời điểm 1957, đặc biệt là bộ “8 kẻ phản bội” (bạn nhìn thấy trong hình phía dưới), đặc biệt là có Gordon Moore và Robert Noyce là nhà sáng lập ra Intel. Còn 6 người kia cũng đã tạo ra rất nhiều doanh nghiệp và làm chủ các quỹ đầu tư để cấp vốn hình thành rất nhiều công ty nổi tiếng sau này.

Hôm nay chúng ta sẽ đọc một bài viết nói về yếu tố quan trọng nhất (là con người) đã góp phần hình thành Thung lũng Silicon như ngày nay. Và trước khi bạn đi vào bài viết thì mình xin trích một câu nói của Giáo sư Jay Schalin rằng:

“Sự biến đổi của Thung lũng Silicon trở thành một thánh địa Mecca của công nghệ cao thì xảy ra phần nhiều là do các sự kiện ngẫu nhiên hơn là được thiết kế, và đó là một khoảng thời gian rất dài.”

Bộ 8 kinh điển: nhóm 8 người làm việc tại Fairchild Semiconductor, vào năm 1960 tại San Jose, California, đã sản xuất ra mạch tích hợp đầu tiên từ silicon. Trong đó hai người Gordon Moore và Robert Noyce, sau đó đã sáng lập ra gã khổng lồ Intel.Bộ 8 “kinh điển”: nhóm 8 người làm việc tại Fairchild Semiconductor, vào năm 1960 tại San Jose, California, đã sản xuất ra mạch tích hợp đầu tiên từ silicon. Trong đó hai người Gordon Moore và Robert Noyce, sau đó đã sáng lập ra gã khổng lồ Intel.

Đọc tiếp >>

Những lầm tưởng về lập trình viên Ấn Độ

Bài viết được dịch từ blog Avinashsingh

Lời bàn của Vinacode:

Ở Việt Nam thì bất cứ ai làm công việc lập trình thì đều gọi chung là lập trình viên (mặc dù có thể là tự học, học các khóa ngắn hạn, tốt nghiệp đại học 5 năm, Thạc sĩ,…). Trong bài viết này thì tác giả đã chia người làm phần mềm ra làm 2 loại: loại thứ nhất là programmer (lập trình viên, thường là kỹ sư phần mềm) và loại thứ hai là coder (dạng chỉ viết code thuần túy, thường là tốt nghiệp các khóa ngắn hạn như NIIT, APTECH…).

Như chúng ta đều đã biết, việc gia công phần mềm không có gì là xấu. Nhưng nếu các doanh nghiệp chỉ chăm chăm vào làm outsource mà không quan tâm đến khâu R&D để phát triển sản phẩm cho riêng mình, thì trong tương lai dài hạn các lợi thế cạnh tranh như (nhân công giá rẻ, dân số vàng…) sẽ qua đi. Hơn nữa, người lao động cũng dần trở nên nhàm chán vì công việc không có sự sáng tạo. Bài viết sau đây cho ta thấy bài học từ nền công nghiệp gia công phần mềm của Ấn Độ, người Ấn đi trước chúng ta và dường như đã gặp phải ngưỡng giới hạn. Còn người Việt thì sao? Người ta đang hết sức cổ vũ cho công việc làm gia công này phải không nhỉ? Hay một giấc mơ về Thung lũng Silicon viển vông nào đó?

Để bắt đầu bài viết này, mình xin trích lại một câu nói đùa đã trở nên phổ biến tại Ấn Độ là:

Bangalore có khoảng 40,000 con chó; và cũng có khoảng từng đó lập trình viên. Nếu bạn ném một hòn đá ngẫu nhiên lên không trung, thì hoặc là nó sẽ trúng vào đầu một con chó hoặc sẽ trúng đầu một lập trình viên. Trong khi con chó thì có thể có hoặc không một sợi dây (sợi xích) quanh cổ, nhưng một lập trình viên thì chắc chắn sẽ có.

Ngành công nghiệp phần mềm Việt Nam cũng định hướng làm gia công giống Ấn Độ?Do định hướng gia công nên ngành công nghiệp phần mềm Ấn Độ đang dần đi vào ngõ cụt? Người Việt nhận được bài học gì từ người Ấn?

Đọc tiếp >>

5 Điều tôi ước gì được biết khi mới bắt đầu nghề phát triển phần mềm

Bài viết được dịch từ Simple Programmer

Tôi bắt đầu vào nghề phát triển phần mềm khoảng 15 năm về trước. Nhưng chỉ trong khoảng 5 năm gần đây, tôi mới thực sự bắt đầu nhận thấy có một sự phát triển vượt trội trong nghề nghiệp lập trình viên của mình.

Sau đây là một số điều mà tôi ước gì mình biết được khi mới chân ướt chân ráo bước vào nghề phát triển phần mềm; những điều này sẽ giúp cho tôi thành công nhiều hơn hoặc sớm hơn, nếu tôi có được những kiến thức đó.

1. Không có một “phương pháp đúng” trong phát triển phần mềm

Tôi đã tốn một lượng thời gian rất lớn, cả trong việc học và tranh luận ở giai đoạn đầu trong nghề nghiệp của mình; tôi đã sai lầm trong việc tin rằng có một “phương pháp hoàn toàn đúng” trong nhiều mặt của phát triển phần mềm.

Một số điều trước đây tôi cứ nghĩ rằng nó là đúng trong phát triển phần mềm, nhưng sau này tôi lại nhận ra nó là sai lầm.

Nghề lập trình viên.Nếu biết trước những điều này thì tôi đã thành công sớm hơn trong nghề phát triển phầm mềm.

Đọc tiếp >>