Mọi lập trình viên nên biết gì về lập trình?

Xin vui lòng, ở lại về các vấn đề kỹ thuật , tránh các vấn đề hành vi, văn hóa, sự nghiệp hoặc chính trị.

1. Lỗi nằm trong mã của bạn , không phải trình biên dịch hoặc thư viện thời gian chạy.

2. Nếu bạn thấy một lỗi không thể xảy ra, hãy kiểm tra xem bạn đã xây dựng và triển khai chính xác chương trình của mình chưa. (Đặc biệt nếu bạn đang sử dụng một IDE phức tạp hoặc khung xây dựng cố gắng che giấu các chi tiết lộn xộn khỏi bạn ... hoặc nếu bản dựng của bạn bao gồm nhiều bước thủ công.)

3. Các chương trình đồng thời / đa luồng rất khó viết và khó kiểm tra hơn. Tốt nhất là ủy thác càng nhiều càng tốt cho các thư viện và khung công tác đồng thời.

4. Viết tài liệu là một phần công việc của bạn là một lập trình viên. Đừng để nó cho "người khác" làm.

BIÊN TẬP

Vâng, quan điểm số 1 của tôi là quá cường điệu. Ngay cả các nền tảng ứng dụng được thiết kế tốt nhất cũng có phần lỗi và một số nền tảng ít được thiết kế tốt hơn cũng đầy rẫy. Nhưng ngay cả như vậy, bạn nên luôn nghi ngờ mã của mình trước và chỉ bắt đầu đổ lỗi cho trình biên dịch / lỗi thư viện khi bạn có bằng chứng rõ ràng rằng mã của bạn không có lỗi.

Quay trở lại những ngày tôi thực hiện phát triển C / C ++, tôi nhớ các trường hợp được cho là "lỗi" tối ưu hóa hóa ra là do tôi / một số lập trình viên khác đã làm những việc mà thông số ngôn ngữ nói không có kết quả. Điều này áp dụng ngay cả đối với các ngôn ngữ được cho là an toàn như Java; ví dụ, hãy nhìn kỹ vào mô hình bộ nhớ Java (JLS chương 17).

• Cách đọc mã của người khác.
• Mã không tồn tại nếu nó không được kiểm tra trong Hệ thống kiểm soát phiên bản.

Tính toán dấu phẩy động không chính xác.

Đừng ngừng học hỏi.

Rằng điều số 1 bạn có thể làm để tăng chất lượng và khả năng duy trì mã của bạn là GIẢM NGAY LẬP TỨC.

Kỹ năng khắc phục sự cố và gỡ lỗi

Họ hầu như không dành thời gian cho chủ đề này trong bất kỳ khóa học lập trình nào tôi đã tham gia, và theo kinh nghiệm của tôi, nó là một trong những yếu tố quyết định lớn nhất đến việc lập trình viên làm việc hiệu quả như thế nào. Dù muốn hay không, bạn dành nhiều thời gian hơn trong giai đoạn bảo trì ứng dụng của mình so với giai đoạn phát triển mới.

Tôi đã làm việc với rất nhiều lập trình viên, những người gỡ lỗi bằng cách thay đổi ngẫu nhiên mọi thứ mà không có chiến lược nào để tìm ra vấn đề. Tôi đã có cuộc trò chuyện này hàng chục lần.

Lập trình viên khác: Tôi nghĩ chúng ta nên thử xem nó có sửa nó không.
Tôi: Được rồi, giả sử rằng nó đã sửa nó. Điều đó cho bạn biết nguồn gốc của vấn đề là gì?
Lập trình viên khác: Tôi không biết, nhưng chúng tôi phải thử một cái gì đó .

1. Đừng khéo léo; được rõ ràng
2. Sử dụng trước khi sử dụng lại.
3. Tên vấn đề.
4. Một chức năng làm 1 điều và làm nó tốt.
5. Nhỏ thì tốt hơn lớn.

Những thứ cơ bản. Hiện tại các lập trình viên học các công nghệ không phải là khái niệm. Nó sai.

Mọi lập trình viên nên biết rằng anh ta luôn đặt giả định vào mã, ví dụ: "con số này sẽ tích cực và hữu hạn", "mã này sẽ có thể kết nối với máy chủ mọi lúc trong nháy mắt".

Và anh ta nên biết rằng anh ta nên chuẩn bị khi những giả định đó bị phá vỡ.

Mỗi lập trình viên nên biết về thử nghiệm.

Tìm hiểu các khái niệm . Bạn có thể Google cú pháp.

Tư duy phản biện và logic. bạn không thể làm bất cứ điều gì tốt mà không có nó.

Kiểm tra đơn vị. Đây là một cách tuyệt vời để mã hóa các giả định của bạn về cách sử dụng mã.

Tối thiểu tuyệt đối mỗi nhà phát triển phần mềm Tuyệt đối, tích cực phải biết về bộ ký tự Unicode và ký tự (Không có lý do!) .

Điều đó khó hơn bạn nghĩ.

Mặc dù thật dễ dàng để kết hợp một thứ gì đó hoạt động khi sử dụng bình thường, đối phó với đầu vào sai, tất cả các trường hợp cạnh và góc, chế độ thất bại có thể, v.v ... đều tốn thời gian và có lẽ sẽ là phần khó nhất của công việc.

Sau đó, bạn phải làm cho ứng dụng trông cũng tốt.

Kiến thức tên miền. Thông số kỹ thuật không bao giờ là 100%; biết tên miền thực tế mà bạn đang phát triển sẽ LUÔN LUÔN tăng chất lượng sản phẩm.

Ký hiệu O lớn và ý nghĩa của nó.

Một số tài liệu tham khảo hữu ích

• http://www.perlmonks.org/?node_id=227909
• http://www.programmerinterview.com/datastruct/big-o-notation-example.php
• http://en.wikipedia.org/wiki/Big_O_notation

Con trỏ, rõ ràng. :)

Mã hoàn thành 2 - bìa để che

Dữ liệu quan trọng hơn mã.

Nếu dữ liệu của bạn thông minh, mã có thể bị câm.

Mã câm là dễ hiểu. Dữ liệu thông minh cũng vậy.

Hầu như mọi sự đau buồn về thuật toán mà tôi từng có là do dữ liệu ở sai vị trí hoặc bị lạm dụng ý nghĩa thực sự của nó. Nếu dữ liệu của bạn có ý nghĩa hãy đặt ý nghĩa đó vào hệ thống loại .

Ngôn ngữ và môi trường nào phù hợp nhất cho công việc. Và nó không phải luôn luôn là yêu thích của bạn.

Phân chia và chinh phục. Đó thường là cách tốt nhất để giải quyết bất kỳ loại vấn đề thực tế nào từ lập lịch đến gỡ lỗi.

Kỹ năng thực sự được thể hiện ở khả năng thực hiện tốt một thiết kế đơn giản, chứ không phải ở khả năng làm cho một thiết kế phức tạp hoạt động cả.

Kỹ năng này xuất phát từ việc làm chủ nhiều hơn các nguyên tắc cơ bản, không phải là thông thạo về ma trận. Một lập trình viên có trình độ cao không được xác định bởi khả năng mã hóa những gì người khác không thể (sử dụng các hàm cấp cao hơn, lập trình chức năng nâng cao, những gì bạn có) mà thay vào đó là khả năng tinh chỉnh mã hóa hoàn toàn trần tục. Lựa chọn phân rã thích hợp của chức năng giữa các lớp; xây dựng trong sự mạnh mẽ; sử dụng các kỹ thuật lập trình phòng thủ; và sử dụng các mẫu và tên dẫn đến tài liệu tự lớn hơn, đây là bánh mì và bơ của lập trình có năng lực cao.

Viết mã tốt mà bạn hoặc người khác có thể quay lại sau một tuần hoặc một năm và hiểu cách sử dụng, sửa đổi, nâng cao hoặc mở rộng mã đó là rất quan trọng. Nó giúp bạn tiết kiệm thời gian và nỗ lực tinh thần. Nó làm tăng các bánh xe năng suất bằng cách loại bỏ các rào cản mà bạn sẽ vấp ngã trước đây (có thể làm gián đoạn quá trình suy nghĩ của bạn, hoặc có thể mất hàng giờ hoặc nhiều ngày nỗ lực từ công việc khác, v.v.) Giúp bạn dễ dàng tập trung vào các vấn đề khó khăn hơn và đôi khi nó làm cho những vấn đề khó khăn biến mất

Trong một từ: thanh lịch. Mỗi lớp, mọi phương thức, mọi điều kiện, mọi khối, mọi tên biến: phấn đấu cho sự thanh lịch.

Không bao giờ đổ lỗi cho người dùng những gì có thể được sửa chữa với trải nghiệm người dùng sạch hơn hoặc tài liệu tốt hơn. Thông thường, các lập trình viên tự động cho rằng người dùng là một thằng ngốc không thể làm gì đúng, khi vấn đề là trải nghiệm tổng thể kém hoặc thiếu giao tiếp. Các chương trình được sử dụng và đối xử với người dùng một cách khinh miệt là bỏ lỡ điểm lập trình ngay từ đầu.

Mỗi lập trình viên nên biết cách sử dụng trình gỡ lỗi và biết cách sử dụng nó tốt .

Cấu trúc dữ liệu

Cách sử dụng Google

Đánh giá ngắn mạch, mặc dù đó là một trong những điều đầu tiên họ dạy cho bạn về các toán tử boolean.

Cách ước tính chính xác thời gian một tính năng sẽ mất để thực hiện. Quan trọng hơn, làm thế nào để truyền đạt bạn không nhảm nhí khi bạn gửi ước tính đó.

Các vấn đề về phong cách mã hóa:

• vấn đề thụt đầu dòng nhất quán,
• sử dụng nhất quán không gian trắng (ví dụ như xung quanh các nhà khai thác),
• vị trí nhất quán của {} s vấn đề,
• vấn đề định danh được lựa chọn tốt,
• Vân vân.

... và các vấn đề thiết kế tốt.

Lý tưởng nhất, lập trình viên học những điều này trước (hoặc trong) đánh giá mã đầu tiên của anh ấy / cô ấy. Trong trường hợp xấu nhất, lập trình viên học được chúng khi ông chủ bảo anh ta / cô ta thực hiện một số thay đổi không tầm thường đối với một số mã khủng khiếp một cách vội vàng.