Bạn nghĩ gì về nguyên tắc đầu tiên của lập trình?

Tôi luôn thích tự hỏi mình "nguyên tắc đầu tiên của việc này là gì?" sau khi tôi học được những thứ cơ bản của một cái gì đó (ví dụ lập trình). Đó là một câu hỏi đầy cảm hứng, IMO, có thể buộc bạn phải suy nghĩ về (các) nguyên tắc quan trọng nhất đằng sau một cái gì đó, đặc biệt là một kỹ năng như lập trình.

Vì vậy, bạn nghĩ gì là nguyên tắc đầu tiên của lập trình? Tôi sẽ đưa ra câu trả lời của tôi dưới đây một chút sau.

1. KISS - Giữ cho nó đơn giản ngu ngốc
2. DRY - Đừng lặp lại chính mình
3. YAGNI - Bạn sẽ không cần nó

Viết mã như nếu đó là bạn sẽ phải duy trì mã đó.

Hãy lười biếng nhất có thể.

Zen, phần I: Lập trình chỉ là con đường, không phải con đường.

Lập trình chỉ là kỹ thuật để dạy cho máy tính những gì nó phải làm. Để thành công trong việc tạo ra phần mềm nhanh, đáng tin cậy có nghĩa là phải biết các thuật toán, thực tiễn tốt nhất của bạn và tất cả những thứ khác không nhất thiết phải được kết nối với Lập trình (ngôn ngữ) của bạn.

Zen, phần II: Nếu bạn đang vội, hãy đi bộ chậm rãi. Nếu bạn thực sự đang vội, hãy đi đường vòng.

Nghe có vẻ ngớ ngẩn, nhưng đừng để bản thân thỏa hiệp mà sau đó (thực sự) có thể gây rắc rối cho bạn sau đó. Tôi có một quy tắc: Nếu bạn là cốt lõi của một chương trình, hãy cố gắng chính xác và tốt nhất có thể. Nếu bạn đang sử dụng các phương thức từ cốt lõi nằm sâu trong phần mềm của mình, hãy thử mã hóa nhanh hơn. Nếu bạn đang viết mã trên hai cái này, bạn thậm chí có thể trở nên cẩu thả hơn một chút.

Lỗi thiết kế là khó tìm và / hoặc sửa lỗi nhất, bước tiếp theo là lỗi lập trình ở các bộ phận mà mọi người đều dựa vào, sau đó là "các phần mềm hiển thị thực sự". Nếu bạn cần sửa một lỗi thiết kế ở cuối dự án, ừm, điều đó không tốt ... ;-)

Zen, phần III: Biết con đường của bạn, Neo.

Biết môi trường, công cụ của bạn và những thứ bạn dựa vào hàng ngày và sắp xếp nó để nó phù hợp với bạn. Tốt nhất nếu bạn sử dụng "môi trường" lập trình của mình một cách tự nhiên đến mức bạn thậm chí không phải nghĩ về nó. Nếu bạn phải hoàn thành công việc, đừng giới thiệu "những thứ mới lạ mắt" mà hãy thực hiện công việc của bạn. Công cụ này có thể được giới thiệu trong một dự án mới, cụ thể là khi bạn có thời gian chuẩn bị và sử dụng nó.

KISS (giữ cho nó đơn giản, ngu ngốc).

Nó thực sự đặt ra câu hỏi "Làm thế nào để bạn xác định đơn giản?" Và cũng "Khi nào thì một cái gì đó quá đơn giản cho nhiệm vụ trong tay?" Đây là lý do tại sao bạn không thể trở thành một lập trình viên giỏi chỉ bằng cách biết nguyên tắc đầu tiên của lập trình.

Tối ưu hóa sớm là gốc rễ của mọi tội lỗi. - Donald Knuth

Đừng phát minh lại bánh xe.

Hiểu vấn đề trước!

YAGNI - Bạn không cần nó . Ý tưởng đằng sau YAGNI là lập trình cho các yêu cầu của bạn, không phải cho các tính năng tiềm năng, tiềm năng. Tiền đề là bằng cách tuân thủ những gì bạn cần lập trình, bạn sẽ (trong số những thứ khác) cắt giảm sự phình to mã, giảm độ phức tạp, tránh creep tính năng và giảm các hạn chế về những gì có thể được thực hiện (và cách thực hiện) Tương lai.

Tôi cho rằng nó hoạt động song song với thiết kế mô-đun: Các tính năng trong tương lai có thể được tăng cường mà không cần thiết kế lại mã hiện có.

Biết khi nào không nên lập trình.

Cà phê trong, mã ra.

Nếu nó không được thử nghiệm, nó đã bị hỏng.

Có hai cách để xây dựng một thiết kế phần mềm: Một cách là làm cho nó đơn giản đến mức rõ ràng là không có thiếu sót, và cách khác là làm cho nó phức tạp đến mức không có thiếu sót rõ ràng. Phương pháp đầu tiên là khó khăn hơn nhiều.

- Charles Antony Richard Hoare

1. Phân biệt giữa nguyên nhân và kết quả (làm việc với máy tính)

2. Phân biệt giữa thực tế và ý kiến ​​(làm việc với mọi người)

3. Càng đơn giản càng tốt, nhưng không đơn giản hơn (thiết kế)

Lập trình là một phương tiện không phải là kết thúc. Hoặc có lẽ, "Có thể không có nghĩa là nên."

1. Hiểu lý do tại sao chương trình sẽ làm cho ai đó hạnh phúc (nếu không, tại sao bạn không ở ngoài chơi với tất cả những đứa trẻ khác?). (Người này có thể là bạn.)
2. Phát triển một mô hình khái niệm về lĩnh vực kinh doanh nắm bắt tất cả sự phức tạp cần thiết, và không còn nữa.
3. Phát triển một mô hình khái niệm về kiến trúc phần mềm , nắm bắt tất cả sự phức tạp cần thiết, và không còn nữa.
4. Tàn nhẫn giữ tất cả sự phức tạp khác ra.

Theo tôi, nguyên tắc quan trọng nhất là giảm độ phức tạp bằng cách tạo ra sự trừu tượng tốt .

Điêu nay bao gôm

• hiểu vấn đề cần giải quyết,
• thiết kế một giải pháp thích hợp cho nó và
• thực hiện nó
• tốt nhất là theo cách giữ cho mã dễ hiểu và có thể duy trì được,

nhưng cũng xác định điểm dừng tạo trừu tượng và đi xuống các thuộc tính cơ bản của các công nghệ triển khai (ví dụ: hệ thống cơ sở dữ liệu, ngôn ngữ lập trình) để ngăn chặn việc tạo ra sự phức tạp bổ sung có thể tránh được.

Chương trình với một khán giả trong tâm trí. Do đó, đừng cho rằng bất cứ điều gì bạn viết sẽ không được đọc và duy trì bởi bạn hoặc người khác.

Một hệ quả tất yếu: Chứng minh rằng bạn hiểu vấn đề bạn đang cố gắng giải quyết bằng cách đặt tên cho các biến và hàm và các lớp của bạn thật tốt!

nó không hoạt động cho đến khi bạn cho thấy nó trong một thử nghiệm

Suy nghĩ trước, mã sau.

Bạn không ở đâu thông minh như bạn nghĩ. Hỏi câu hỏi. Học cách coi trọng đồng nghiệp của bạn.

Khi gỡ lỗi, câu trả lời đầu tiên sẽ luôn luôn sai.

Mã bạn viết với ý định tung ra có xu hướng trở thành nền tảng của các quy trình lớn hơn nhiều. Không bao giờ để lại bất cứ điều gì viết ngớ ngẩn.

Bất kỳ vấn đề có thể được giải quyết với một lớp cảm ứng khác.

Biết công cụ của bạn.

Nguyên tắc: Phần mềm là nắm bắt kiến ​​thức .

Hậu quả: Nhiều kỹ thuật biểu diễn tri thức, tất cả được thành lập trên Trừu tượng . Cung cấp cho chúng tôi các lớp, tầng, đóng gói, tách các mối quan tâm.

Nhiều kỹ thuật để biểu diễn thủ tục, tất cả được thành lập trên Trình tự , Lựa chọn , Lặp lại .

Viết mã cho anh chàng tiếp theo.

Luôn viết mã như thể người sẽ duy trì nó là một kẻ giết người hàng loạt tâm thần, người biết bạn sống ở đâu

Ngoài ra, đừng bao giờ nghĩ rằng bạn biết mọi thứ về lập trình, hãy tiếp tục học hỏi

Tôi tham gia lập trình bằng cách nghiên cứu thiết bị điện tử kỹ thuật số, vì vậy tôi đoán đối với tôi các cổng logic cơ bản (không, và, hoặc, xor, ngụ ý) là những nguyên tắc đầu tiên của lập trình.

Đó là tất cả về người dùng.

Rác vào - Rác ra Không quan trọng giao diện người dùng của bạn đẹp như thế nào nếu dữ liệu xấu.

DRY, khá nhiều thứ khác sinh ra từ nó. KISS là kết thúc khác của hành động cân bằng để đảm bảo bạn không theo đuổi sự thanh lịch của phần mềm đến mức độ điên rồ.

Bắt đầu với đầu ra và làm việc lạc hậu.