it-swarm-vi.com

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

Xin vui lòng, giữ nguyên các vấn đề kỹ thuật, tránh các vấn đề về hành vi, văn hóa, nghề nghiệp hoặc chính trị.

52
Maniero
  1. Lỗi nằm trong 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 phức tạp IDE 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 có 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.

CHỈNH SỬA

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 đang tồn tại với chúng. Nhưng ngay cả như vậy, trước tiên bạn nên nghi ngờ mã của mình và chỉ bắt đầu đổ lỗi cho trình biên dịch/lỗi thư viện khi bạn có rõ ràng bằng chứng rằng mã của bạn không có lỗi.

Quay trở lại những ngày khi 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).

92
Stephen C
  • 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.
84
pramodc84

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

76
Chinmay Kanchi

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

63
systempuntoout

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.

44
Chris Holmes

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, đó 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 lập trình 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 đâu là nguồn gốc của vấn đề?
[.__.] 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ì đó .

39
JohnFx
  1. Đừng khéo léo; hãy 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.
37
KevBurnsJr

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.

34
clrod

Mọi lập trình viên nên biết rằng anh ta luôn đặt các giả định vào mã, ví dụ: "Con số này sẽ là 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ỡ.

26
LennyProgrammers

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

19
Tom Duckering

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

17
pramodc84

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ó.

16
Mladen Prajdic
14
Carlos

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ã.

14
btlog
13
Maniero

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.

13
Steven Evers

Đ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 bình thường, đối phó với đầu vào sai, tất cả các trường hợp Edge và góc, cá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.

13
ChrisF

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

11
Laurynas Biveinis

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 đặt ý nghĩa đó vào hệ thống loại.

11
Gonzales

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

11
Kyle B.

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.

10
Dan Diplo

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.

10
Rick Minerich

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. 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 trong một tuần một tháng 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.

8
Wedge

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ó nghĩa là đượ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.

8
user8

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.

6
Brian R. Bondy

Cách sử dụng Google

5
bruno077

Cấu trúc dữ liệu

5
Maniero

Đá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.

4

Lỗi người dùng là không; chúng là những sai lầm về khả năng sử dụng:

  • Chức năng nguy hiểm phải là không thể hoàn tác, không chỉ cảnh báo về. Đây là nhìn vào rm, mà vẫn không hoạt động với thùng rác.
  • Thực hiện điều ít gây hại nhất nếu người dùng phá vỡ (ESC, Ctrl-C). Lý tưởng nhất là hệ thống phải ở trạng thái như trước khi chạy lệnh. rm, một lần nữa.
  • Lựa chọn có hại nên cách xa những người vô hại. Nhấp chuột phải vào tệp trong Thùng rác Gnome có thể hiển thị "Xóa vĩnh viễn" liền kề với "Khôi phục" :(

Không chọn cụ thể trên GNU Công cụ hoặc Gnome, nhưng đây là những ví dụ dễ nhất để đưa ra.

4
l0b0

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 đó.

4
wheaties

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

  • vấn đề thụt đầu dòng nhất quán,
  • việc sử dụng nhất quán khoảng trắng (ví dụ: xung quanh các nhà khai thác) các vấn đề,
  • 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.

4
Stephen C

Nói về nhà phát triển phần mềm thương mại ở đây ... Rõ ràng có thể không áp dụng cho hệ thống bảo mật DOD hoặc số lượng quỹ phòng hộ.

  • Tập trung vào những gì hoạt động, không phải những gì thông minh, KISS.
  • Hãy ghi nhớ quy tắc 80/20 và đừng dành toàn bộ thời gian của bạn để cố gắng làm hài lòng/bán thiểu số.
  • Tham gia một khóa học về cấu trúc dữ liệu/thuật toán.
  • Kiểm tra, kiểm tra, kiểm tra.
  • Đừng mucking về mã đang được sản xuất và hiện đang làm việc. Trừ khi bạn có dòng tiền quá mức và không có ý tưởng mới. Vậy thì tốt rồi.
  • Phần lớn thời gian của bạn sẽ được dành cho việc sắp xếp thông qua hành trình, và không giải quyết các vấn đề lập trình thú vị. Trừ khi bạn đang phỏng vấn, trong trường hợp đó mọi người chỉ muốn xem cách bạn giải quyết các vấn đề lập trình thú vị.
3
red-dirt

Đó là -

1) Các mô hình lập trình khác ngoài chỉ OO (hướng đối tượng) 2) Các IDE tốt hơn ngoài Visual Studio (điều này đặc biệt dành cho các lập trình viên chỉ làm việc trên Windows và chỉ trên các công nghệ MS)

3
Manoj Waikar

Làm thế nào máy tính thực sự hoạt động, nguyên tắc cơ bản ngôn ngữ, thuật toán/cấu trúc dữ liệu, phân tích thuật toán và một số thước đo của lý thuyết phức tạp.

3
Paul Nathan

Không thể tin điều này chưa được đề cập

Mỗi giá trị lập trình viên là muối cần để có thể sản xuất phần mềm sẵn sàng trên thế giới .

Bằng cách này, tôi có nghĩa là tuân theo các nguyên tắc quốc tế hóa cơ bản như bên ngoài tất cả các chuỗi, v.v.

Tôi không thể tin được bao nhiêu lần tôi đã thấy các chuỗi hoặc hộp thoại tiếng Anh được mã hóa cứng với các chuỗi bị cắt, v.v. khi sản phẩm đã được dịch.

2
Jimmy Collins

Kiểm tra đơn vị không phải là một viên đạn bạc. Bạn vẫn có thể giới thiệu các lỗi, viết các bài kiểm tra sai và đó không phải là hình thức kiểm tra duy nhất bạn làm.

2
aqwert

Máy tính không hiểu ngữ nghĩa. Giả sử bạn có cái này:

var ferrari = new Ferrari();
ferrari.DriveTo(Places.Seattle);

Đối với máy tính, bạn cũng có thể đã sử dụng các loại tên khác nhau và được sử dụng:

var mxEEcceqs = new safHBBdueWE();
mxEEcceqs.HYBbQAW(n3dNm.pDojeW);

Đặt tên mọi thứ rất quan trọng, nhưng đừng phạm sai lầm khi cho rằng máy tính biết bạn "nghĩa là gì" chỉ vì bạn đặt tên cho loại "Ferrari" hoặc phương pháp của bạn là "DriveTo".

2
xofz

Trình tự thực hiện.

Bạn sẽ ngạc nhiên, khi nói chuyện với các lập trình viên so với những người chưa bao giờ nhìn thấy hoặc chạm vào mã hoặc các lập trình viên giả vờ *, điều họ không nhận được là thứ tự thực hiện. Nếu bạn gặp ai đó không thể chọn cấu trúc điều khiển, trước tiên hãy lấy ý tưởng này. Bạn sẽ thấy rằng họ học nhanh hơn sau đó.

* vâng, những người có khả năng kiếm việc làm lập trình viên, nhưng khi bạn hỏi họ câu hỏi kỹ thuật đơn giản nhất thì họ lại xì hơi .. Tôi nghĩ rằng tất cả chúng ta đã gặp một trong những người đó.

2
Philip

Mọi lập trình viên nên biết "khoa học" trong Khoa học máy tính (mẫu thiết kế, thuật toán, đối tượng, v.v.) nếu bạn có thể thành thạo điều đó, bạn có thể lập trình bằng bất kỳ ngôn ngữ nào, đó chỉ là vấn đề làm quen với cú pháp.

2
JD Frias

Lexing và phân tích cú pháp là gì, chỉ cần một cái nhìn tổng quan mơ hồ là tốt. Tốt hơn nữa, vượt qua sự quen thuộc với ít nhất một khung trình tạo trình phân tích cú pháp.

Hầu hết các WTF khủng khiếp nhất tôi từng thấy là thói quen phân tích cú pháp tùy chỉnh của mọi người. Kinh khủng để mã ban đầu, tệ hơn để duy trì.

2
angusgr

Đánh giá.

Một lập trình viên nên biết cách đánh giá các câu lệnh họ viết. a(line.of(code) is aSequenceOf(evaluations)) và nếu bạn không hiểu dòng đó trông như thế nào sau mỗi bước đánh giá, bạn sẽ bị hạn chế rất nhiều với tư cách là một lập trình viên về khả năng tận dụng các tính năng ngôn ngữ.

Tôi không chỉ nói về cơ bản

if (bool == false):
    return true
else:
    return false

mà tất nhiên chỉ có thể được thay thế bằng return !bool.

Tôi cũng đang đề cập đến khả năng hiểu ngôn ngữ của bạn đến mức bạn có thể nghĩ ra thứ gì đó như thế này:

string[] thingsToOutput;
for(int i = 0; i <= thingsToOutput.Length; print(thingsToOutput[i++]));    

Khi tôi lần đầu tiên nhìn thấy một tuyên bố như vậy, nó đã thổi vào tâm trí tôi một chút; nó đã không xảy ra với tôi Tôi có thể tận dụng vòng lặp for theo cách như vậy. Người đã viết tuyên bố đó hiểu đầy đủ hơn các khả năng có sẵn cho họ - họ đã thấy nhiều cánh cửa mở hơn tôi, điều này cho họ nhiều tự do và sức mạnh hơn trong khả năng thiết kế mã.

Bây giờ, cho dù đó là tốt mã là một vấn đề - cho dù bất kỳ cửa nào trong số đó nên được mở - đó là tranh luận. Vẫn còn đó với sức mạnh lớn đi kèm với trách nhiệm lớn.

2
doppelgreener

Việc biết câu trả lời cho câu hỏi này không giúp bạn trở thành một lập trình viên

2
hplbsh

Khái niệm cơ bản về cấp phép phần mềm

  • Sự khác biệt giữa giấy phép copyleft "virus" (GPL) khi so sánh với Apache thân thiện với nguồn đóng và MS-PL/MS-RL không virus.

  • Khi nào bạn nên sử dụng LGPL, và khi nào thì không.

  • Giấy phép tương thích. Ví dụ: bạn có thể liên kết thư viện giấy phép Apache hiện đại với mã GPLv3, nhưng không phải GPL 1 hoặc 2.

  • Nếu bạn sở hữu toàn bộ mã nguồn, bạn có thể xuất bản nó theo nhiều (hoặc ít) giấy phép như bạn muốn.

Lưu ý đến S.O. cộng đồng:
[.___.] Xin vui lòng chỉnh sửa câu trả lời này khi bạn thấy phù hợp ... chủ yếu là thông tin không phù hợp với phần bình luận bên dưới.

2
goodguys_activate

Mật mã học. Bạn không cần phải có thể viết thuật toán mã hóa của riêng mình, nhưng bạn phải có hiểu biết cơ bản về cách mã hóa, xác thực tin nhắn và PKI hoạt động. Tôi đã đấu tranh quá lâu với thử nghiệm mù và lỗi trong lĩnh vực này. Gần đây, tôi đã chọn cuốn sách "Kỹ thuật mã hóa" (của tác giả Ferguson, Schneier, Kohno) và nó đã là một công cụ mở mắt thực sự.

2
Tobias

Biết hệ điều hành/nền tảng của bạn trước khi bạn bắt đầu mã hóa.

Nếu bạn viết mã Windows/Linux/Android/iOS, v.v. hãy bắt đầu bằng cách học HĐH. Nếu bạn nhắm mục tiêu một cái gì đó khác như Web thì cũng vậy.

1
Amir Rezaei

viết mã cho mọi người!

không còn số ma thuật!

đừng viết tất cả mã trong một dòng!

1
linjunhalida
  1. xây dựng một cái gì đó mà mọi người muốn
  2. xây dựng một cái gì đó mà bạn muốn sử dụng hàng ngày
  3. nếu bạn không bình luận mã của mình, hãy đảm bảo nó đọc sạch
  4. nhận xét mã của bạn
1
Michael Ossareh

Không có lỗi nào là lỗi không thể xảy ra.

1
Rayne

"Hello world" không phải là một ứng dụng hoàn chỉnh, vì không có sự khẳng định nào được chứng minh/lập trình rằng đầu ra thực tế là "Hello world". Mã không hoàn thành cho đến khi nó đã được thử nghiệm đơn vị.

1
stimpy77

Một số trong số này đã được đăng, nhưng đây là danh sách của tôi:

  • Xây dựng theo yêu cầu, không thêm những thứ bạn không cần, đặc biệt nếu bạn "nghĩ" bạn sẽ làm. Nếu bạn cần nó sau này, thêm nó sau đó.
  • Cách sử dụng tìm kiếm Google. Đừng làm phiền đồng nghiệp của bạn, cho đến khi bạn nhìn.
  • Đừng khéo léo.
  • Nó không được thực hiện cho đến khi nó đáp ứng TẤT CẢ các yêu cầu, được kiểm tra, ghi lại và kiểm tra vào SVN.
  • Các tiêu chuẩn mã hóa phù hợp, ví dụ: quy ước đặt tên
1
Tyler Egeto

Tìm hiểu cách triển khai mã, kiểm tra và gói phần mềm của bạn tốt.

Một trong những thói quen tồi tệ nhất của các nhà phát triển mà tôi đã thấy trong ngành là sự thiếu hiểu biết chung về cách đặt phần mềm của bạn vào tay người khác, đây là một số dấu hiệu xấu:

Môi trường phát triển mới-itus:

  • Tôi muốn tìm hiểu Ruby vì vậy chúng tôi đã viết nội dung của chúng tôi trong đó, khách hàng và bản dựng chính sẽ phải chọn môi trường Ruby ngay bây giờ

Phiên bản-itus:

  • Nhóm của chúng tôi đã chuyển sang phiên bản trình biên dịch X + 1 vì đây là phiên bản mới nhất, chúng tôi không nói cho ai biết?
  • Chúng tôi cần thư viện phiên bản Y, oh, công cụ của bạn không hoạt động với điều đó?
  • Chúng tôi đã thử nghiệm trên một bản phát hành thực sự cũ, nó không hoạt động với bản dựng mới nhất?
  • Chúng tôi đã hack một phiên bản kernel đặc biệt để phát hành hoạt động

Nhị phân chỉ-itus:

  • Môi trường xây dựng của chúng tôi rất phức tạp, chúng tôi sẽ cung cấp cho bạn nhị phân

Đa lõi-itus:

  • Vô hiệu hóa SMP, công cụ của chúng tôi chỉ hoạt động trên môi trường không có bộ xử lý

Mã hóa cứng-tính năng-itus:

  • Bỏ ghi chú #define này để bật tính năng X, ý bạn là gì khi muốn chạy?
1
tonylo

Đơn giản, rõ ràng, rộng rãi. http://www.math.harvard.edu/computing/programming/rules.html

  • xây dựng hệ thống như mạng của các quy trình đơn giản được kết nối bằng ổ cắm/ống
  • trao đổi dữ liệu theo định dạng văn bản đơn giản: bộ bản ghi của các cặp "key: value" hoặc TSV

"Công cụ gỡ lỗi hiệu quả nhất vẫn là suy nghĩ cẩn thận, cùng với các tuyên bố in được đặt một cách thận trọng." BẠC

1
user2137

Bạn càng biết nhiều về cách bảo mật hoạt động trên nền tảng lựa chọn của bạn thì càng tốt.

1
Ripped Off

Sử dụng các công cụ thích hợp cho công việc.

Lập trình viên là yếu tố quan trọng, và ngôn ngữ và công cụ nên được chọn dựa trên vấn đề. Đừng sợ ngôn ngữ và dự án mới.

1
Jonathan Hendler
1
Daniel Grillo

Không có khóc trong lập trình!

1
Billy Coover
  1. một sự hiểu biết thấu đáo về các khái niệm nền tảng, ví dụ kiểu dữ liệu, giao diện
  2. hiểu biết từ trung bình đến cao về công cụ họ đang sử dụng, ví dụ: kiến thức cụ thể .net/Java
  3. một ý tưởng hợp lý về 'các công nghệ khác mà giao diện công cụ của bạn với' ví dụ: cơ sở dữ liệu hoạt động như thế nào
  4. đại khái là nơi cơ sở công nghệ của họ đang đứng đầu, ví dụ điện toán đám mây là gì và nó sẽ có tác động gì đến bộ kỹ năng hiện tại của họ
1
adolf garlic

Cách viết chương trình FizzBuzz.

1
CtrlDot

Khi bạn phải phân phối một ứng dụng hoặc đưa một trang web vào sản xuất bên ngoài giới hạn của công ty bạn, mọi thứ bạn nghĩ không quan trọng, đều có.

1
JeffO

Mã chỉ đẹp nếu nó làm những gì nó phải làm.

1
sambeau
  • Nhị phân với sự hiểu biết cơ bản về ký và không dấu.
  • Hiểu làm thế nào bất kỳ hệ thống số vị trí hoạt động.
  • Hiểu cách cấu trúc dữ liệu cơ bản được lưu trữ trong bộ nhớ.
1
Michał Piaskowski

Sửa mã yêu cầu thông minh hơn so với viết mã tương tự ban đầu.

Do đó, nếu bạn viết mã ở giới hạn của sự thông minh của bạn thì theo định nghĩa, bạn không đủ thông minh để sửa nó khi nó bị hỏng.

1
Adam Bachman

Viết cấu trúc dữ liệu của bạn trước - điều đó có nghĩa là tất cả mọi thứ từ các lược đồ cơ sở dữ liệu đến các cơ chế xáo trộn/tuần tự hóa.

Hầu hết các dự án là về lưu trữ và di chuyển dữ liệu từ điểm A đến điểm B ở định dạng C.

Khi tất cả được nói và thực hiện, khoảng 90% mã của bạn sẽ là logic để thực hiện định dạng, nhưng kẻ giết người thực sự chỉ là có một định dạng để truy cập và ghi dữ liệu của bạn. Khi bạn có API để truy cập dữ liệu, bạn có thể thực hiện theo định dạng mà bạn muốn, nhưng một khi bạn bắt đầu sản xuất với API lưu trữ, điều đó thực sự đau đớn khi nhận ra rằng bạn đã làm hỏng nó.

1
user2040

Trong 5 câu hỏi trên màn hình điện thoại quan trọng của Steve Yegge, anh ấy đang cố gắng đảm bảo người được phỏng vấn có kiến ​​thức cơ bản về:

  1. Mã hóa. Ứng viên phải viết một số mã đơn giản, với cú pháp đúng, bằng C, C++ hoặc Java.
  2. Thiết kế OO. Ứng viên phải xác định các khái niệm cơ bản OO và đưa ra các lớp để mô hình hóa một vấn đề đơn giản.
  3. Kịch bản và regexes. Ứng viên phải mô tả cách tìm số điện thoại trong 50.000 trang HTML.
  4. Cấu trúc dữ liệu. Ứng viên phải chứng minh kiến ​​thức cơ bản về các cấu trúc dữ liệu phổ biến nhất.
  5. Bit và byte. Ứng viên phải trả lời các câu hỏi đơn giản về bit, byte và số nhị phân.

http://sites.google.com.vn/site/steveyegge2/five-essential-phone-screen-questions

Vào thời điểm anh ấy viết bài này, anh ấy đã ở Amazon, nhưng làm việc (và có thể tiến hành các cuộc phỏng vấn) tại Google bây giờ. Điều này chỉ giúp bạn vượt qua màn hình. Đây là cách anh ấy mô tả những gì anh ấy đang tìm kiếm:

những gì tôi đang tìm kiếm ở đây là một khoảng trống hoàn toàn ở một trong những khu vực này. Không sao nếu họ vật lộn một chút và sau đó tìm ra nó. Không sao nếu họ cần một số gợi ý nhỏ hoặc nhắc nhở. Tôi không phiền nếu chúng bị gỉ hay chậm. Những gì bạn đang tìm kiếm là các ứng cử viên hoàn toàn không biết gì, hoặc bối rối khủng khiếp, về lĩnh vực được đề cập.

1
Lou Franco

Tài liệu rất quan trọng. Hơn nữa nếu bạn đang xây dựng một cái gì đó từ đầu. Nó giúp ghi lại ý tưởng của bạn trước khi viết bất kỳ mã nào.

Tôi học được điều này một cách khó khăn.

1
Pablo

Chưa thể bình luận, nhưng về chủ đề "Kỹ năng kiểm tra và gỡ lỗi", viên ngọc nhỏ này của Ned Batchelder là một thứ phải đọc. (Sau đó đạt được, phần lớn những gì anh ta nói về gỡ lỗi và xác nhận là đáng để xem xét.)

0
Stan Rogers

Mọi lập trình viên nên biết rằng điều duy nhất họ biết là họ không biết gì. Có rất nhiều thứ để học.

0
sharjeel

Mỗi lập trình viên nên liên kết các hành động FindNextSelected và FindPreinglySelected (visual studio) với các phím trên bàn phím (tốt nhất là F4 và F2). Bạn nhận được hai điều từ đó:

  1. Cách nhanh hơn để điều hướng giữa các điểm khác nhau của việc sử dụng biến/chức năng/chuỗi con (nhanh hơn so với "Tìm tất cả tài liệu tham khảo")
  2. Khả năng khác biệt trong một tài liệu. Bằng cách nhảy qua lại trong khi tìm kiếm một số chuỗi con, bạn có thể thấy sự khác biệt giữa các vị trí khác nhau. Không cần sử dụng Winmerge khi cần so sánh các phần của cùng một tài liệu.
0
AareP

Biết cú pháp biểu thức chính quy cơ bản bao gồm cả nhóm có điều kiện. Tránh xa việc sử dụng các addons lệnh regex cụ thể của thư viện hoặc ít nhất là nhận xét/yếu tố ra các phần đó.

0
Bob Dobelina

Làm thế nào để làm nó.

... Ý bạn là gì tôi cần 15 ký tự?

0
Randall Schulz

Chương trình với khả năng duy trì trong tâm trí.

0
Jesse

Biểu thức chính quy THE Book about regular expressions

Tôi không thể nói số lần biểu thức thông thường đơn giản chuyển đổi dữ liệu mà mọi người nghĩ sẽ mất nhiều ngày để thao tác. Nó phải có mặt trong mọi hộp công cụ lập trình viên.

Chắc chắn, chúng ta không thể quên xkcd: Wait, forgot to escape a space. Wheeeeee—taptaptap—eeeeee.

0
neves

Mỗi lập trình viên nên biết làm thế nào một bộ xử lý làm việc.

0
Brian Makin

Be Master của Something, nhưng Be Nhận thức của Mọi thứ !!!!

0
user11020

Có một số gợi ý rất hay ở đây, nhưng tôi ngạc nhiên không ai nhắc đến loạt bài viết xuất sắc của Ulrich Drepper: Điều mà mọi lập trình viên nên biết về bộ nhớ .

0
Mansur

Tất cả các vấn đề trong khoa học máy tính có thể được giải quyết bằng một mức độ gián tiếp khác.

0
FreeMemory

Thiết kế mã của bạn và nếu người quản lý của bạn muốn sử dụng RAD hãy thử và lấy càng nhiều chi tiết càng tốt. Sau đó, khi thêm chức năng, hãy thử và nghĩ xem mã hiện có có thể được viết lại trước đó không chỉ cần chồng thêm mã và bạn kết thúc với một ngôi nhà cao tầng thay vì một ngôi nhà.

0
Luke Tongs

mỗi lập trình viên cần có một nền tảng vững chắc trong công nghệ phần mềm, và cả các khái niệm phân tích/thiết kế hệ thống và hệ thống thông tin. bằng cách này nếu họ được kêu gọi đóng góp đáng kể cho phân tích/thiết kế hệ thống và/hoặc kiến ​​trúc thông tin, họ sẽ ở vị trí của kiến ​​thức + ý kiến..như vậy, thông thường dường như chỉ là ý kiến ​​cá nhân thường chỉ xuất phát từ sở thích cá nhân giải pháp vấn đề tốt nhất. kỹ thuật phần mềm khó hơn một chút để đo lường, nhưng kiến ​​thức cần thiết có sẵn ở đó, và tại các khóa học đại học phù hợp, nơi họ dạy nhiều hơn là chỉ cách ghép một chút mã với nhau. dù sao điều này không có nghĩa là tiêu cực bởi vì tinh thần chính là nhưng cải thiện, nhưng sau đó tôi đã làm việc với một số người không có kiến ​​thức về CNTT hoặc có những "kịch bản" có đầu óc mã hóa và mã hóa lại (và chỉ trong ngôn ngữ của họ lựa chọn) và chỉ xem mọi vấn đề là sự lặp lại của các giải pháp được áp dụng trước đó (bởi người viết mã đó.) vì vậy tôi rất thích nếu các lập trình viên tập trung nhiều hơn vào bức tranh lớn hơn về mặt kỹ thuật phần mềm (SSADM) và xem các vấn đề là cơ hội để làm tốt hơn cho khách hàng.

0
chris

Chạy mã hoặc logic trong đầu hoặc giấy của bạn đầu tiên. Đừng vội vàng để biên dịch và chạy lệnh để kiểm tra.

0
Aditya Kothadiya

Nó đứng trong một vài chữ cái, thực sự:

Ok, tôi đơn giản hóa quá mức, nhưng về cơ bản nếu bạn khá tự động, không bao giờ ngừng học hỏi và là một người cầu toàn, bạn nên có cơ sở để trở thành một lập trình viên giỏi.

Bất cứ điều gì ngoài đó sẽ được cụ thể hơn cho vai trò và công nghệ cụ thể.

0
haylem

Nếu một cái gì đó có thể đi sai, sau đó nó sẽ. Giả sử trường hợp xấu nhất

0
Adham Saad

Đừng quên người sẽ sử dụng phần mềm bạn đang tạo.

0
Dan Goldstein

Nhận ra rằng bất cứ điều gì có thể đi sai sẽ đi sai. Dành rất ít thời gian để viết mã - nhưng nhận ra và sử dụng lại các mẫu phổ biến. Mã tái cấu trúc liên tục để đạt được thiết kế lý tưởng.

0
zkarthik

Tất cả dữ liệu phải sống ở đâu đó. Bạn có thể tìm thấy nó nếu bạn nhìn đủ cứng.

0
Jonathan

Họ cần biết về sức mạnh của việc đóng cửa và bắt đầu sử dụng chúng.

0
nickik

Ký hiệu thập lục phân. Ngoài ra các trường bit - ANDing, ORing (bao gồm và độc quyền), bổ sung (1 và 2), dịch chuyển bit.

0
tcrosley

Phiếu bầu đầu tiên của tôi sẽ là cho các quy ước đặt tên.

0
Gopi

Khi ai đó yêu cầu bạn xây dựng một cái gì đó, hãy nhớ rằng: họ cũng đang yêu cầu bạn duy trì nó. Có thể, mãi mãi.

0
Yevgeniy Brikman

Rằng bất cứ chương trình nào làm được, hơn là nói cho máy biết cách thực hiện công việc, chúng là một cách rõ ràng nhất để chỉ cho đồng loại biết cách thực hiện công việc.

0
vpit3833