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

245

Bất kể ngôn ngữ lập trình hoặc (các) hệ điều hành được sử dụng hoặc môi trường họ phát triển để làm gì, mọi lập trình viên nên biết gì?

Một số nền tảng:

Tôi quan tâm đến việc trở thành lập trình viên tốt nhất có thể. Là một phần của quá trình này, tôi đang cố gắng hiểu những gì tôi không biết và sẽ có lợi cho tôi rất nhiều nếu tôi làm. Mặc dù có vô số danh sách xung quanh các dòng "n điều mà mọi nhà phát triển [ngôn ngữ lập trình chèn] nên biết", tôi vẫn chưa tìm thấy bất cứ điều gì tương tự không giới hạn trong một ngôn ngữ cụ thể.

Tôi cũng mong đợi thông tin này sẽ được quan tâm và mang lại lợi ích cho người khác.

language-agnostic  skills 
— Matt Lacey
nguồn

Câu trả lời:

636

Làm thế nào để nuốt niềm tự hào và thừa nhận sai lầm mà không nhận chúng cá nhân.

— Hân Đồng
nguồn
60
Đó là điều mà mỗi con người nên làm bất kể công việc của họ (... giới tính, tôn giáo, văn hóa, địa vị xã hội ...), bạn có nghĩ vậy không? ;)
3
Ồ vâng. Nhưng chúng tôi lập trình viên (ít nhất là tôi) có xu hướng có niềm tự hào công khai hơn hầu hết :-)
17
Tôi ước tôi có thể bầu bạn lên hai lần.
4
Tôi nghĩ rằng đây là một điều tôi học được ở trường đại học. Ở trường trung học, tôi luôn là một trong những đứa trẻ thông minh. Nếu tôi không đến uni, tôi sẽ nghĩ mình khá thông minh và có cái tôi lớn. Đến uni và giao lưu với những người thực sự giỏi hơn tôi đã được giúp tôi thấy tôi thật ngu ngốc
— Kibbee
4
Mặc dù điều này rất đúng, nhưng vấn đề không phải lúc nào cũng là phủ nhận hay là một cái tôi lớn, nhưng hậu quả tiềm tàng của việc công khai thừa nhận mắc lỗi, ít nhất là không phải không có biện pháp tự kiểm soát / thiệt hại nào trước tiên. Đôi khi đó là một điều văn hóa. :)
309

Làm thế nào để suy nghĩ như một người dùng, và không giống như một lập trình viên công nghệ.

— Nick B
nguồn
2
Tôi luôn thấy mỉa mai rằng điều mà dường như hầu hết chúng ta trong ngành thiếu có thể là một trong những kỹ năng quan trọng nhất cần có: kỹ năng giao tiếp.
Không thể đồng ý với điều này hơn. Điều này nên là # 1.
23
Tôi thực sự không đồng ý. Đó là những gì bạn thuê người cho. Bạn sẽ không bao giờ có thể nghĩ như người dùng, nhưng bạn chắc chắn có thể có người cho bạn biết người dùng nghĩ gì và hành động theo lời khuyên đó. Đừng hỏi người dùng họ nghĩ như thế nào! Đó là lựa chọn tồi tệ nhất trong tất cả.
1
Bạn có thể thuê người khác làm điều đó, nhưng nếu nhóm phát triển của bạn có thể hiểu được cách người dùng nghĩ, thì bạn sẽ có ít tranh luận và lặp lại hơn trước khi mọi thứ trở nên đúng đắn. Thêm vào đó, nếu một nhà phát triển có thể suy nghĩ như một người dùng, người biết những tính năng mới mà họ sẽ đưa ra
3
Người dùng rất có thể là một lập trình viên công nghệ, nhưng ít có khả năng là một lập trình viên đam mê công nghệ cũng đã thực hiện mã . Nếu ứng dụng có ngữ nghĩa / hành vi rất tinh vi và phức tạp, người viết mã có thể là người duy nhất có thể hiểu cách sử dụng ứng dụng ...
— Reuben
244

Khi nào cần giúp đỡ, và khi nào KHÔNG yêu cầu giúp đỡ.

— Brian Knoblauch
nguồn
2
Thật vậy. Gần đây, câu trả lời đã xuất hiện trong đầu tôi khi tôi đang hỏi ai đó. :(
— kevindaub
vậy, câu trả lời là gì?)
28
Hỏi vịt cao su của bạn đầu tiên. Nếu anh ta không thể giúp bạn, thì hãy hỏi người khác ...
— Dean Thay
3
được khuyến khích bởi vì khi tôi mới bắt đầu, tôi đã không nhận ra mình đã làm phiền các nhà phát triển khác đến mức nào khi liên tục hỏi họ những thứ đơn giản. Tôi nên tự mình tìm ra cho đến khi tôi có vài n00b làm điều đó với tôi.
1
Tôi luôn tự hỏi mình một câu hỏi dọc theo dòng chữ "Đồng nghiệp của tôi sẽ nói gì nếu tôi hỏi họ". Thông thường điều đó giúp tôi hiểu thêm một chút về vấn đề trước khi tôi phải thực sự hỏi.
184

Cách đọc mã của người khác.

— Hóa đơn thằn lằn
nguồn
102
Phụ lục: Cách viết mã người khác có thể đọc
42
Phụ lục số 2: Cách đọc mã của riêng bạn 6 tháng sau
10
@Nathan Koop: Sẽ tốt hơn "Cách viết mã để bạn có thể tự đọc nó 6 tháng sau".
— Doc Brown
4
Khi được 6 tháng, nó đã trở thành mã của người khác. Theo nghĩa là bạn đã phát triển, trở nên tốt hơn và cũng có thể là người khác đã viết nó ngay từ đầu, vì vậy hãy đối xử với nó như vậy.
— MPelletier
7
Phụ lục số 3: Cách đọc mã của bạn 6 phút sau.
— mở
152

Làm quen với các hệ thống kiểm soát phiên bản. Nó không phải là mỗi một, nhưng những khái niệm cơ bản có thể được áp dụng cho tất cả chúng nên được biết đến.

— Thomas Owens
nguồn
và điều khiển sửa đổi đó không phải là phần mềm
— jrhicks
4
Tôi sẽ nói thêm rằng có một sự khác biệt đủ đáng kể giữa các SCM tập trung (ví dụ lật đổ, CVS) và SCM phân tán (ví dụ: git, mercurial, bazaar) rằng điều quan trọng là phải tìm hiểu từng loại.
— trực giác
128

Đây là 10 bit của tôi:

  • Làm sao phải khiêm nhường. Tất cả chúng ta ở đây để học hỏi. Bạn có thể thông minh hơn người khác, nhưng có rất nhiều người thông minh hơn bạn.
  • Làm thế nào để nghiên cứu / tiêu thụ thông tin. Tôi không biết về bạn, nhưng tôi mãi mãi học! Sách, Internet, sao cũng được!
  • Từ điển là gì và làm thế nào để sử dụng một từ, và làm thế nào để tìm ra các từ viết tắt một cách nhanh chóng.
  • Các công cụ cơ bản của thương mại là gì và chúng làm gì (IDE, CVS et al).
  • Biết thuật ngữ chung và ý nghĩa của chúng: mẫu thiết kế, khả năng sử dụng, thử nghiệm (ha!), Ngăn xếp, v.v.
  • Có một sự hiểu biết về OOP.
  • Hãy "có khả năng" trong ít nhất một ngôn ngữ, không có gì đáng kinh ngạc, chỉ cần biết cách xác định các biến và phương thức, v.v ... Từ đây bạn có thể học NHANH CHÓNG.
  • Hiểu rằng cuối cùng mọi người sử dụng phần mềm và muốn làm cho những người đó hạnh phúc.
— Rob Cooper
nguồn
38
Đây phải là một bài bát phân.
— Ngay cả Miên
10
Về bit đầu tiên .... "Đừng khiêm tốn quá, bạn không tuyệt lắm đâu".
— Magnus
@TheOtherScott, bắt lol tốt, nhưng tôi thực sự đã nói 2 bit: D;)
3
Về điểm 3: www.acronymfinder.com
— Jasper Bekkers
1
@ jasper / intuited: chỉ cần gõ từ viết tắt vào google và nó sẽ kéo lên cái này hay cái khác ... câu trả lời thường nằm trong một trong 10 kết quả đầu tiên. Thông tin thêm có thể được lấy bằng cách nhấp vào!
— mpen
104

Có lẽ nó quá tinh tế, nhưng tôi nghĩ đó là "biết vấn đề nào cần giải quyết." Rất nhiều lập trình viên (và người bình thường) lãng phí nỗ lực to lớn để giải quyết những việc đơn giản là không quan trọng lắm; hoặc họ tạo ra một giải pháp, với rất nhiều công việc làm thêm, đó không phải là điều cần thiết.

— thức ăn cho mèo
nguồn
4
Đồng ý, lo lắng về các tình huống sử dụng rìa mà chỉ một số ít người dùng sẽ gặp phải thay vì chức năng cốt lõi hơn là một cái bẫy quá phổ biến! Tôi vẫn học được điều này một cách khó khăn ...
— Ian Robinson
Tôi nên đặt một liên kết đến câu trả lời của bạn làm trang chủ của đồng đội cũ của tôi. bạn nói rất đúng.
4
Tôi thích rằng bạn đã nói "rất nhiều lập trình viên (và người bình thường)" :-)
95

Làm thế nào để thư giãn. Đó là bí quyết cho năng suất.

Cuối cùng, ý chí và caffeine là không đủ. Sự co thắt liên tục này chúng tôi làm là rất tai hại.

Đây là một vấn đề lớn.

— Brian MacKay
nguồn
1
Bạn có ý nghĩa gì bởi sự co lại?
4
@Egg: Đôi khi khi tôi làm việc, tôi có thể hoàn toàn thoải mái và làm việc rất hiệu quả. Vào những ngày tồi tệ của tôi, tôi chạy bằng adrenaline và caffeine, và tôi cảm thấy căng thẳng rất lớn trong cơ thể. Nếu tôi chú ý, tôi thực sự đang co thắt một số cơ bắp. Tôi nhận thấy sự căng thẳng này ở những người khác mọi lúc. Thật không may, nó có thể dẫn đến tất cả các loại vấn đề như kiệt sức và bệnh tim, và nó cũng có thể dẫn đến mất năng suất ròng vì chỉ có thể chạy nước rút trong một khoảng thời gian hữu hạn. Đó là sự co thắt mà tôi đang nói đến.
— Brian MacKay
@Egg, anh có nghĩa là co các cơ không sử dụng.
2
nói về cà phê và sự co thắt, bạn có biết rằng cà phê làm co lại động mạch dẫn máu lên não. Điều đó khiến não thức dậy. Cà phê không phải là một điều tốt như vậy sau tất cả. tl; dr uống nước
— Reno
83

Kiểu dữ liệu cơ bản & lý thuyết thuật toán. Những thứ như ký hiệu Big O, mảng, hàng đợi, v.v.

— Glenn Slaven
nguồn
Hoàn toàn không giúp bạn nếu tất cả những gì bạn làm là tạo các mẫu cho hệ thống quản lý nội dung web.
3
Chà, ngày nay các thuật toán tiêu chuẩn được triển khai trong các thư viện / khung nhưng tôi đồng ý rằng một số suy nghĩ giống như thuật toán cứng là hữu ích, nhưng không thường xuyên
7
Chỉ vì chúng được triển khai không có nghĩa là bạn không cần phải sử dụng cái gì khi nào, đảm bảo độ phức tạp, v.v ... Đây là thứ quan trọng đằng sau các thuật toán.
3
Đồng ý với Greg Rogers. Bạn có thể cần phải thực hiện các thuật toán nhưng bạn hiểu rõ hơn về sự phức tạp và sự đánh đổi của chúng. Ví dụ. Một số thuật toán chiếm nhiều bộ nhớ hơn nhưng nhanh hơn.
6
Bạn sẽ không biết nên sử dụng cái nào nếu bạn không hiểu chúng. Thuật toán rất quan trọng.
60

Làm thế nào để chọn đúng công cụ cho đúng nhiệm vụ và không tham gia vào các cuộc chiến rực lửa ngớ ngẩn về các công cụ lập trình yêu thích của mình.

— Ga cuối
nguồn
+1 để cái này không ở lại 42 :)
— CharlesB
54

Chà, đây là 0,02 $ của tôi:

  • Việc học không bao giờ dừng lại. Cho dù bạn nghĩ bạn giỏi đến đâu, luôn có một người tốt hơn bạn, và luôn có điều gì đó bạn có thể cải thiện về bản thân. Nếu bạn ngừng học hỏi, chắc chắn bạn sẽ xuống cấp như một lập trình viên. Đọc sách. Đọc blog. Nói chuyện với các lập trình viên khác.
  • Cố gắng học nhiều ngôn ngữ. Ít nhất một trong số họ hướng đối tượng. Ngoài ra, bạn nên biết điều gì đó về các công nghệ khác nhau liên quan đến ngôn ngữ bạn học (ví dụ: Nếu bạn học Java, sẽ rất tuyệt nếu bạn biết điều gì đó về Spring, v.v.).
  • Tái cấu trúc. Sớm muộn gì bạn cũng sẽ cần kiến ​​thức đó.
  • Tìm hiểu làm thế nào để đối phó với mã di sản.
  • Viết bài kiểm tra đơn vị. Tìm hiểu về TDD.
  • Học cách làm việc theo nhóm.
  • Viết mã thanh lịch và dễ đọc. Như người xưa thường nói: "Viết mã của bạn 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."
  • Học cách lười biếng và kỷ luật cùng một lúc. Lập trình viên giỏi đặt ra cả hai phẩm chất này. Có vẻ lạ, dường như chúng không mâu thuẫn với nhau, nhưng bổ sung cho nhau.
— Người cát
nguồn
Đó là 0,02 đô la hay 0,02 xu của bạn? CƯỜI NGẢ NGHIÊNG! :-D
"Viết mã của bạn 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." +1
— Ben
50

Bạn không thể kiểm tra chất lượng thành sản phẩm.

— Jeff cao
nguồn
2
Do đó, các chuyên gia "Đảm bảo chất lượng" có tên sai.
1
Về mặt kỹ thuật, nói QA và Test không giống nhau, mặc dù theo quan điểm của bạn, tôi không chắc rằng hầu hết các tổ chức thực sự thực hành sự khác biệt.
— Cao Jeff
5
Gần đây gặp phải - và bị mắc kẹt: "Kết quả của thử nghiệm không phải là chất lượng, mà là kiến ​​thức".
— peterchen
richdiet: Chuyên gia của SQA James Bach tin rằng "A" trong SQA / QA nên có nghĩa là "Hỗ trợ". Tôi hoàn toàn đồng ý với ý kiến ​​của anh ấy và tuyên bố của bạn.
44

Mỗi lập trình viên nên hiểu các mẫu thiết kế .

— lông tơ
nguồn
13
Tôi sẽ nói thêm rằng họ cũng cần một sự hiểu biết rằng không phải mọi thứ đều có thể được cắm sừng vào một mẫu thiết kế nhất định.
— tloach
10
Tôi cũng sẽ thêm rằng không phải mọi lập trình viên nên hiểu các mẫu thiết kế. Có những ngôn ngữ ngoài kia ở những vùng đất xa xôi có những tính năng mạnh mẽ đến mức suy nghĩ chảy trực tiếp ra khỏi lập trình viên và vào các chương trình làm việc. Trong các ngôn ngữ đó, các mẫu có chủ ý là một định hướng sai.
— Ali
2
các mẫu thiết kế dành cho những người ham muốn không phải là "lập trình viên" - một lập trình viên sẽ cần biết rằng khi anh ta / cô ta trở thành một "nhà thiết kế"
10
Có hai loại người .. những người thích viết mã và những người thích nói về tiền mã hóa. Các mẫu thiết kế là điều bắt buộc đối với nhóm thứ hai ..
— Bjorn Reppen
1
Những mô hình như vậy là một cách để khắc phục những hạn chế của ngôn ngữ. Một lập trình viên chỉ nên hiểu chúng bởi vì anh ta nên hiểu và có thể khắc phục những điểm yếu trong ngôn ngữ của mình.
44

Tôi hơi muộn với điều này, nhưng tôi sẽ đi với kiến ​​thức được đặt ra bởi Edsger Dijkstra:

Bên cạnh thiên hướng toán học, một khả năng làm chủ đặc biệt của ngôn ngữ bản địa là tài sản quan trọng nhất của một lập trình viên có năng lực.

Nếu bạn không thể viết một đoạn văn hay, rất có thể bạn cũng không thể viết mã tốt.

— KevDog
nguồn
8
Tuy nhiên, tôi ngạc nhiên về chính tả, ngữ pháp và dấu câu khủng khiếp được sử dụng trong văn bản ngôn ngữ tự nhiên của một số lập trình viên. Bạn sẽ nghĩ rằng làm việc mỗi ngày với các hệ thống không dung sai cho lỗi chính tả và cú pháp không hợp lệ sẽ có tác dụng có lợi ...
1
@cheduardo, đó là bởi vì một khi bạn biên dịch hoặc chạy một chương trình, trong hầu hết các ngôn ngữ, bạn sẽ được thông báo về bất kỳ lỗi chính tả, ngữ pháp hoặc dấu câu nào, sau đó có thể dễ dàng sửa chữa. Không phải như vậy đối với các lỗi logic.
— Inshallah
@Inshallah: trừ khi bạn làm một số việc như thế if (BlowUpTheSystem = 1). Cấp, được thử nghiệm đơn vị thích hợp, bạn có thể chỉ tiết kiệm thời gian. Nhưng sau đó thời gian là khá quan trọng.
— trực giác
2
Đồng ý .. hmm ... trừ phần "tiếng mẹ đẻ", một số người trong chúng ta [không may?] Giao tiếp tốt hơn / rõ ràng hơn bằng tiếng mẹ đẻ của chúng ta.
39

Đừng quá xúc động, gắn bó hoặc tôn giáo về bất kỳ công nghệ, hệ điều hành hoặc ngôn ngữ cụ thể nào - không có gì là hoàn hảo - về lâu dài bạn có thể sẽ kết thúc với mong muốn bạn có thể tạo ra ala carte từ chính bạn thích về mỗi cái khác nhau

Hãy nghĩ về nó giống như ô tô - trước đây bạn có thể chưa lái một chiếc xe cụ thể nào, nhưng tất cả chúng đều có chìa khóa, vô lăng, chân ga và phanh - bạn sẽ có thể vào trong và nhanh chóng lái xe đi khi bạn sắp xếp được những gì. Đối xử với các hệ điều hành và ngôn ngữ tương tự nhau và tập trung vào việc tìm hiểu các khái niệm thiết yếu bên dưới chúng ngay cả khi bạn đang ở trong các chi tiết cụ thể của bất kỳ trường hợp cụ thể nào.

Và theo thời gian cố gắng để hiểu và đánh giá cao tổ tiên, di sản và sự tương đồng của các công nghệ khác nhau sẽ giúp bạn giữ quan điểm. Ví dụ, nhận ra rằng, trong khi cây tiến hóa đang phân nhánh tích cực và đầy ngõ cụt, công nghệ theo thời gian có xu hướng liên tục hội tụ xung quanh 'các thực tiễn tốt nhất' và 'quy mô kinh tế' ( ví dụ: Mac không khác gì PC dưới mui xe những ngày này ...).

Cuối cùng, hãy nhớ cho dù bạn có bao nhiêu niềm vui với tất cả, công nghệ chủ yếu thể hiện một lăng kính không hoàn hảo giữa những gì tâm trí bạn có thể hình dung và những gì bạn thực sự sản xuất. Làm hết sức, học để học và vẫn thích nghi ...

— J nặng nề
nguồn
35

Ngày bạn ngừng học nên là ngày bạn không còn là lập trình viên nữa.

— Nick trung sĩ
nguồn
Nếu tôi có một điều ước, đó sẽ là ông già Noel.
Vì ông già Noel ...?
1
Ngày bạn ngừng học nên là ngày bạn chết. :) +1 dù sao đi nữa
— ShdNx
Vậy để sống mãi bạn phải luôn học hỏi? Bây giờ có một ý tưởng tôi có thể chứng thực!
— canadiancreed
34

Kiểm thử đơn vị và gỡ lỗi.

— Jon
nguồn
Cái đầu tiên loại bỏ sự cần thiết cho cái thứ hai. ;-)
4
Không, khi kiểm tra đơn vị thất bại, cần gỡ lỗi. Hai người đi cùng nhau.
— Zan Lynx
Không thể nhấn mạnh điều này đủ.
— fastcodejava
33

Nó đã được đề cập trước đây nhưng tôi nghĩ nó xứng đáng với câu trả lời của riêng nó.

— alexp206
nguồn
Tôi sử dụng nó ngày càng nhiều hơn và tôi nhặt các mảnh ở đây và đó, nhưng tôi thậm chí còn không phải là một kẻ nghiệp dư.
Tôi hoàn toàn đồng ý. Có vẻ lạ và khó khi bạn không hiểu nó, nhưng khi bạn hiểu nó, nó dễ dàng hơn nhiều so với một tấn các hàm gọi chuỗi con / hàm chỉ mục cần thiết để làm điều tương tự. Tôi chỉ đảm bảo rằng các mẫu của bạn được nhận xét tốt.
— Kibbee
9
Một số người, khi đối mặt với một vấn đề, nghĩ rằng "Tôi biết, tôi sẽ sử dụng các biểu thức thông thường." Bây giờ họ có hai vấn đề. - "Jamie Zawinski": jwz.livejournal.com , trong comp.lang.emacs
— Bjorn Reppen
Sử dụng một trình soạn thảo về cơ bản được xây dựng xung quanh chúng là một cách tốt để tìm hiểu gritty nitty khó chịu. Kinh nghiệm của tôi là với vim Gianwhich sử dụng hầu hết tương đương với PCREs tiêu chuẩn trên thực tế nhưng tôi có ấn tượng rằng các quy tắc tương tự được áp dụng trong thế giới emacs.
— trực giác
1
Một số người, khi đối diện với một biểu hiện bình thường, nghĩ rằng tôi biết, tôi sẽ trích dẫn Jamie Zawinski. Hiện tại họ có hai vấn đề (một trong số đó là có lẽ họ không biết họ đang làm gì ở nơi đầu tiên) .
— Donal Fellows
29

Không ai muốn sử dụng phần mềm. Họ muốn giải quyết vấn đề.

— Andrew
nguồn
7
Chính xác. Khi tôi nghe các nhà phát triển cố gắng giải thích cơ sở dữ liệu cho người dùng cuối như một câu trả lời cho câu hỏi của họ về lý do tại sao một cái gì đó không thể được thực hiện, tôi co rúm lại. Họ không cần biết chúng ta làm thế nào. Họ chỉ muốn nó hoạt động. Và đó là cách nó phải như vậy.
— Kevin Fairchild
Tôi muốn tin rằng người ta có thể viết phần mềm mọi người tìm thấy niềm vui để sử dụng.
Không thể đồng ý nhiều hơn. Điều này tuy nhiên cũng áp dụng cho API. Không ai muốn học API mới vì nó rất buồn cười. Chúng tôi muốn chức năng của API, không phải mã mà nó đại diện.
— Blub
Kevin, tôi ước "lập trình viên thực hiện" của chúng tôi (từ posh cho người thử nghiệm) sẽ đọc và hiểu điều đó. Tôi cũng ngồi sau bàn làm việc với hy vọng thế giới sẽ nuốt chửng anh ta khi anh ta bắt đầu nói về các vòng lặp và nếu tuyên bố với người dùng cuối.
27

Cà phê và IntelliSense là những người bạn tốt nhất của bạn

— Công thức
nguồn
Tôi ước tôi có thể cung cấp nhiều hơn 1 upvote này!
— Dinah
Tôi hy vọng sẽ có nhiều cà phê !!!! ñ_ñ
Tôi nghĩ rằng tôi đồng ý với điều này hơn bất kỳ điều gì khác về SO.
— Unkwntech
Tôi thực tế không bao giờ uống cà phê trừ khi tôi thực sự cần hoàn thành một dự án trong X giờ, khi: Số giờ sử dụng hết + X> 8 trong một ngày.
— Blub
Cà phê không cung cấp cho bạn bất kỳ năng lượng. Nó chỉ bóp một số từ dự trữ nội bộ của bạn. Điều đó thật tệ / không lành mạnh.
— Andrei Rinea
18

Làm thế nào để quan sát một vật thể phức tạp lớn và phân hủy nó trong những vật thể đơn giản nhỏ mà vẫn hoàn thành nhiệm vụ tương tự khi đặt lại với nhau.

— Manrico Corazzi
nguồn
18

Không bao giờ tin tưởng người dùng ( đặc biệt nếu ứng dụng là công khai!), Họ sẽ thường làm mọi thứ trong khả năng của mình để phá vỡ ứng dụng của bạn bằng cách này hay cách khác.

Làm cho nó trở thành bằng chứng trong tương lai và có thể mở rộng - bạn không bao giờ biết khi nào bạn muốn mở rộng nó trong một vài năm và nhận ra cần bao nhiêu nỗ lực để mã hóa lại mã được tạo xấu.

— Robinb
nguồn
1
Điều này là quá khái quát. Một số chủ nghĩa thực dụng là tốt.
— mafu
18

Rằng lập trình viên không biết tất cả mọi thứ và phải luôn cố gắng học các ngôn ngữ / công nghệ mới, v.v.

— Người trợ giúp
nguồn
16

Những điều cơ bản của thiết kế UI tốt và thiết kế truyền thông (hay còn gọi là đồ họa) .

Tôi thấy rất nhiều ứng dụng và dự án bị hủy hoại bởi thiết kế tồi hoặc khả năng sử dụng kém. Chỉ cần học những điều cơ bản có thể tạo ra một thế giới khác biệt. Cộng với các kỹ thuật giải quyết vấn đề trực quan (nghĩa là làm thế nào để truyền đạt một khái niệm một cách trực quan) là một thách thức kích thích sẽ mở mắt cho bạn những cách nhìn mới, từ đó sẽ có tác động đến mã của bạn.

Một cuốn sách được đề xuất là Sách thiết kế không phải của nhà thiết kế của Robin Williams

Đây là những gì Joel Spolsky nói về nó :

Ồ Mọi người đều phải làm một số thiết kế đồ họa, và không phải đội ngũ phần mềm nào cũng có sự sang trọng của các nhà thiết kế chuyên nghiệp. Cuốn sách mỏng, tuyệt vời này sẽ giúp bạn nắm được các nguyên tắc đằng sau bố cục trang, phông chữ, v.v ... Tin vui là, bạn có thể đọc nó trong bồn tắm trước khi nước lạnh, và ngày hôm sau, hộp thoại và các điểm mạnh của bạn và các trang web sẽ bắt đầu tìm kiếm tốt hơn.

— Charles Roper
nguồn
1
Tôi sẽ thứ hai với một cái gật đầu bổ sung cho 'thiết kế của những thứ hàng ngày'. amazon.com/Design-Everyday-Things-Donald-Norman/dp/0385267746
— Stimul8d
14

Mỗi lập trình viên nên biết cách học nhanh. Rất nhiều lần bạn đi làm và sẽ được yêu cầu phát triển công nghệ mà bạn chưa từng sử dụng. Họ có thể cho bạn một tuần hoặc lâu hơn để có được trên đôi chân của bạn (nếu bạn may mắn) trước khi bạn được yêu cầu viết mã chất lượng sản xuất.

— Ryan Thames
nguồn
Tôi bắt đầu công việc lập trình đầu tiên của mình và trong vòng một tuần là viết mã mà cuối cùng sẽ đi vào hoạt động. May mắn thay tôi là một người học nhanh và có kinh nghiệm lập trình trong quá khứ. Trong vòng 6 tháng, tôi đã cơ cấu lại kết nối máy khách-máy chủ để cải thiện hiệu suất gấp ba lần. Đây là ngôn ngữ tôi chưa từng sử dụng trước đây.
14

Kiểm soát phiên bản. Và để trích dẫn người bạn gái của tôi: "Tôi không chỉ muốn bạn làm các món ăn, tôi muốn bạn thích nó !"

— Matt
nguồn
10

Yêu cầu thay đổi, mã của bạn sẽ phải thích ứng và nó có thể hoặc không phải là bạn phải điều chỉnh nó.

Đã có một số câu hỏi ở đây liên quan đến các chủ đề bị ảnh hưởng bởi điều này.

— Adam Bellaire
nguồn
10

Off đỉnh đầu của tôi:

  1. Rất ít vấn đề lập trình yêu cầu toán học ngoài phép cộng, phép trừ, phép nhân và phép chia. Nếu bạn đang nghĩ đến việc sử dụng tính toán để giải quyết vấn đề, hãy nghiên cứu kỹ các phương án trước khi thực hiện.

  2. Bất cứ khi nào bạn thấy mình đoán về cách một cái gì đó nên hoạt động, bạn đang làm sai. Đó không phải là công việc của bạn để có khả năng ngoại cảm.

  3. Người cung cấp cho bạn thông số kỹ thuật hiếm khi biết mọi thứ anh ta muốn cho đến khi bạn băm nó ra.

  4. Hơn một nửa là một lập trình viên tuyệt vời đến từ việc giao tiếp với con người. Tương tác với nhóm của bạn, quản lý người quản lý của bạn và làm hài lòng người dùng cuối là một nửa công việc.

  5. Mã tốt được viết để mọi người đọc nhiều như nó được đọc bởi trình biên dịch của bạn.

  6. Thực tiễn tốt nhất và thực tế thực tế sẽ xung đột nhiều hơn các lập trình viên nghĩ, nhưng ít hơn so với người quản lý. Khi chúng có vẻ mâu thuẫn, bạn phải phân định và hiểu xung đột và sau đó nhượng bộ thực tế. Giải pháp tinh tế và thông minh chỉ tốt hơn giải pháp xấu xí, tàn bạo nếu nó hiệu quả hơn về lâu dài.

  7. Những công cụ tuyệt vời không thể tạo ra những lập trình viên tuyệt vời, nhưng những công cụ tồi tệ khiến chúng ta trở nên khủng khiếp không kém.

  8. Không bao giờ xem thường một công nghệ, nhưng luôn luôn tìm kiếm sự thay thế tốt nhất.

  9. Bạn càng biết nhiều ngôn ngữ, bạn sẽ càng sử dụng ngôn ngữ tốt hơn.

  10. Đừng bị làm phiền bởi sự chậm chạp của những suy nghĩ định hướng lập trình vào cuộc sống hàng ngày của bạn. Ngay cả khi chúng ta không ở máy tính, tất cả chúng ta đều bị giới hạn băng thông, bị phạt hiệu năng từ chuyển đổi tác vụ và cần tải mọi thứ từ bộ lưu trữ dự phòng. Máy tính được cho là bắt chước suy nghĩ của con người và các chất tương tự ở khắp mọi nơi.

— Phải - Jake đó.
nguồn
Số 10 làm tôi cười. Vì vậy, nhiều lần tôi sẽ giải quyết một vấn đề tại nơi làm việc nhưng chỉ trên giường lúc 10 giờ tối, cuối cùng tôi mới đưa ra câu trả lời!
9

Đọc mã của người khác sẽ không làm hỏng bộ não của bạn, mà là tìm hiểu lý do tại sao bạn sẽ không làm theo cách đó (nếu tốt hơn hay không là một câu hỏi khác).

Điều này cung cấp cho bạn lập trình gedankenexperiment , và đôi khi bạn tìm thấy ai đó thực hiện một cái gì đó tốt hơn! Giống như cách tốt hơn.

Câu trả lời này tự nhiên mở rộng để đọc mã của riêng bạn, do đó nó mở rộng để sử dụng kiểm soát phiên bản và DIFF, và do đó đến 42.

— Martin
nguồn
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookie và Chính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.