Cuốn sách có ảnh hưởng nhất mà mỗi lập trình viên nên đọc là gì? [đóng cửa]

Nếu bạn có thể quay ngược thời gian và bảo mình đọc một cuốn sách cụ thể khi bắt đầu sự nghiệp với tư cách là một nhà phát triển, thì đó sẽ là cuốn sách nào?

Tôi hy vọng danh sách này sẽ được thay đổi và bao gồm nhiều thứ.

Để tìm kiếm: Sử dụng hộp tìm kiếm ở góc trên bên phải. Để tìm kiếm câu trả lời của câu hỏi hiện tại, sử dụng inquestion:this. Ví dụ:

inquestion:this "Code Complete"

• Code Complete (phiên bản 2) của Steve McConnell
• Lập trình viên thực dụng
• Cấu trúc và giải thích các chương trình máy tính
• Ngôn ngữ lập trình C của Kernighan và Ritchie
• Giới thiệu về thuật toán của Cormen, Leiserson, Rivest & Stein
• Các mẫu thiết kế của Gang of Four
• Tái cấu trúc: Cải thiện thiết kế mã hiện có
• Tháng người đàn ông huyền thoại
• Nghệ thuật lập trình máy tính của Donald Knuth
• Trình biên dịch: Nguyên tắc, Kỹ thuật và Công cụ của Alfred V. Aho, Ravi Sethi và Jeffrey D. Ullman
• Gôdel, Escher, Bach của Douglas Hofstadter
• Clean Code: Cẩm nang về thủ công phần mềm linh hoạt của Robert C. Martin
• C ++ hiệu quả
• C ++ hiệu quả hơn
• MÃ của Charles Petzold
• Ngọc trai lập trình của Jon Bentley
• Làm việc hiệu quả với Bộ luật kế thừa của Michael C. Feathers
• Phần mềm con người của Demarco và Lister
• Coders tại nơi làm việc của Peter Seibel
• Chắc chắn là bạn đang đùa, ông Feynman!
• Phiên bản Java 2 hiệu quả
• Các mô hình kiến ​​trúc ứng dụng doanh nghiệp của Martin Fowler
• Tiểu thư
• Sơ đồ dày dạn
• Hướng dẫn tại sao (sâu sắc) về Ruby
• Các tù nhân đang chạy tị nạn: Tại sao các sản phẩm công nghệ cao khiến chúng tôi phát điên và làm thế nào để khôi phục sự tỉnh táo
• Nghệ thuật lập trình Unix
• Phát triển dựa trên thử nghiệm: Ví dụ của Kent Beck
• Thực tiễn của một nhà phát triển Agile
• Đừng làm tôi suy nghĩ
• Phát triển phần mềm, nguyên tắc, mô hình và thực tiễn Agile của Robert C. Martin
• Thiết kế hướng tên miền của Eric Evans
• Thiết kế của mọi thứ hàng ngày của Donald Norman
• Thiết kế C ++ hiện đại của Andrei Alexandrescu
• Phần mềm tốt nhất tôi viết bởi Joel Spolsky
• Thực hành lập trình của Kernighan và Pike
• Suy nghĩ và học tập thực dụng: Tái cấu trúc Wetware của bạn bởi Andy Hunt
• Ước tính phần mềm: Làm sáng tỏ nghệ thuật đen của Steve McConnel
• Lập trình viên đam mê (Công việc của tôi đã đi đến Ấn Độ) của Chad Fowler
• Hacker: Anh hùng của cuộc cách mạng máy tính
• Thuật toán + Cấu trúc dữ liệu = Chương trình
• Viết mã rắn
• JavaScript - Phần tốt
• Bắt Real bằng 37 Tín hiệu
• Nền tảng lập trình của Karl Seguin
• Đồ họa máy tính: Nguyên tắc và thực hành trong C (Phiên bản 2)
• Suy nghĩ bằng Java của Bruce Eckel
• Các yếu tố của hệ thống máy tính
• Tái cấu trúc các mẫu của Joshua Kerievsky
• Hệ điều hành hiện đại của Andrew S. Tanenbaum
• Turing chú thích
• Những điều làm cho chúng ta thông minh của Donald Norman
• Con đường vượt thời gian của Christopher Alexander
• Hạn chót: Tiểu thuyết về Quản lý dự án của Tom DeMarco
• Ngôn ngữ lập trình C ++ (ấn bản thứ 3) của Stroustrup
• Các mô hình kiến ​​trúc ứng dụng doanh nghiệp
• Hệ thống máy tính - Quan điểm của lập trình viên
• Nguyên tắc, mô hình và thực tiễn nhanh nhẹn trong C # của Robert C. Martin
• Phát triển phần mềm hướng đối tượng, được hướng dẫn bởi các thử nghiệm
• Nguyên tắc thiết kế khung của Brad Abrams
• Tư duy đối tượng của Tiến sĩ David West
• Lập trình nâng cao trong môi trường UNIX của W. Richard Stevens
• Tin tặc và họa sĩ: Những ý tưởng lớn từ thời đại máy tính
• Linh hồn của một cỗ máy mới của Tracy Kidder
• CLR qua C # của Jeffrey Richter
• Con đường vượt thời gian của Christopher Alexander
• Các mẫu thiết kế trong C # của Steve Metsker
• Alice ở xứ sở thần tiên của Lewis Carol
• Zen và nghệ thuật bảo dưỡng xe máy của Robert M. Pirsig
• Về khuôn mặt - Những điều cốt yếu của thiết kế tương tác
• Ở đây có tất cả mọi người: Sức mạnh của việc tổ chức mà không có tổ chức của Clay Shirky
• Đạo của lập trình
• Vẻ đẹp tính toán của thiên nhiên
• Viết mã rắn của Steve Maguire
• Hướng dẫn của Philip và Alex về xuất bản web
• Phân tích và thiết kế hướng đối tượng với các ứng dụng của Grady Booch
• Java hiệu quả bởi Joshua Bloch
• Khả năng tính toán của NJ Cutland
• Chủ mưu lập trình
• Đạo Đức Kinh
• Lập trình viên năng suất
• Nghệ thuật lừa dối của Kevin Mitnick
• Lập trình viên nghề nghiệp: Chiến thuật Guerilla cho một thế giới không hoàn hảo của Christopher Duncan
• Mô hình lập trình trí tuệ nhân tạo: Nghiên cứu trường hợp ở Lisp thông thường
• Bậc thầy của Doom
• Thử nghiệm đơn vị thực dụng trong C # với NUnit của Andy Hunt và Dave Thomas với Matt Hargett
• Làm thế nào để giải quyết nó bởi George Polya
• Nhà giả kim của Paulo Coelho
• Smalltalk-80: Ngôn ngữ và cách thực hiện
• Viết mã bảo mật (phiên bản 2) của Michael Howard
• Giới thiệu về lập trình chức năng của Philip Wadler và Richard Bird
• Không có lỗi! của David Thielen
• Làm lại bởi Jason Freid và DHH
• JUnit trong hành động

K & R

@Juan: Tôi biết Juan, tôi biết - nhưng có một số điều chỉ có thể học được bằng cách thực sự bắt tay vào công việc. Nói trong những lý tưởng trừu tượng cả ngày chỉ đơn giản là làm cho bạn thành một học giả. Đó là trong ứng dụng của bản tóm tắt mà chúng ta thực sự tìm hiểu lý do cho sự tồn tại của chúng. : P

@Keith: Đề cập tuyệt vời về "Các tù nhân đang chạy tị nạn" bởi Alan Cooper - một người mở mắt chắc chắn, bất kỳ nhà phát triển nào đã làm việc với tôi kể từ khi tôi đọc cuốn sách đó đã nghe tôi đề cập đến những ý tưởng mà nó tán thành. +1

Toán học rời rạc cho các nhà khoa học máy tính http://ecx.images-amazon.com/images/I/51HCJ5R42KL._SL500_BO2,204,203,200_AA219_PIsitb-sticker-dp-arrow,TopRight,-24,-23_SH20

Toán học rời rạc cho các nhà khoa học máy tính của JK Truss.

Trong khi điều này không dạy bạn lập trình, nó dạy bạn toán học cơ bản mà mọi lập trình viên nên biết. Bạn có thể nhớ những thứ này từ trường đại học, nhưng thực sự, làm logic vị ngữ sẽ cải thiện kỹ năng lập trình của bạn, bạn cần học Lý thuyết tập hợp nếu bạn muốn lập trình bằng cách sử dụng các bộ sưu tập.

Thực sự có rất nhiều thông tin thú vị ở đây có thể khiến bạn suy nghĩ về các vấn đề theo những cách khác nhau. Thật tiện lợi khi có, chỉ thỉnh thoảng mới nhặt được một thứ mới.

Systemantics: Hệ thống hoạt động như thế nào và đặc biệt là cách chúng thất bại . Nhận nó sử dụng giá rẻ. Nhưng bạn có thể không có được sự hài hước cho đến khi bạn làm việc với một vài dự án thất bại.

Vẻ đẹp của cuốn sách là năm bản quyền.

Có lẽ là "luật" takeaway sâu sắc nhất được trình bày trong cuốn sách:

Định lý chế độ thất bại cơ bản (FFT): Các hệ thống phức tạp thường hoạt động ở chế độ thất bại.

Ý tưởng là có những phần bị lỗi trong bất kỳ phần mềm cụ thể nào bị che dấu bởi những lỗi ở những phần khác hoặc bởi những xác nhận ở những phần khác. Xem một ví dụ trong thế giới thực tại máy bức xạ Therac-25 , có lỗi phần mềm bị che bởi các lỗi phần cứng. Khi các lỗi phần cứng được gỡ bỏ, tình trạng cuộc đua phần mềm đã không bị phát hiện trong suốt những năm đó dẫn đến việc cỗ máy giết chết 3 người.

Một trong những mục yêu thích cá nhân của tôi là Hacker Delight , vì nó rất thú vị khi đọc vì nó mang tính giáo dục.

Tôi hy vọng phiên bản thứ hai sẽ sớm được phát hành!

Khái niệm, kỹ thuật và mô hình lập trình máy tính.

văn bản thay thế http://ecx.images-amazon.com/images/I/51YZ50ZR13L._SL500_AA240_.jpg

Giải thích lập trình cực đoan: Embrace Change của Kent Beck. Mặc dù tôi không ủng hộ việc phát triển phần mềm mạnh mẽ cho XP, tôi ước mình đã được giới thiệu các nguyên tắc trong cuốn sách này sớm hơn nhiều trong sự nghiệp của mình. Thử nghiệm đơn vị, tái cấu trúc, đơn giản, tích hợp liên tục, chi phí / thời gian / chất lượng / phạm vi - những điều này đã thay đổi cách tôi nhìn vào sự phát triển. Trước Agile, tất cả là về trình gỡ lỗi và sợ yêu cầu thay đổi. Sau Agile, những con quỷ đó không lớn bằng.

Các loại và ngôn ngữ lập trình của Benjamin C Pierce để hiểu thấu đáo về nền tảng của ngôn ngữ lập trình.

văn bản thay thế http://ecx.images-amazon.com/images/I/51E0Ojkz8iL._BO2,204,203,200_PIsitb-sticker-arrow-click,TopRight,35,-76_AA300_SH20_OU01_.jpg

Khái niệm hệ thống cơ sở dữ liệu là một trong những cuốn sách tốt nhất bạn có thể đọc để hiểu các nguyên tắc thiết kế cơ sở dữ liệu tốt.

Việc thực hành lập trình. Tác giả Brian W. Kernighan, Rob Pike.

Phong cách thể hiện ở đây là tuyệt vời - mã chỉ nói cho chính nó, và toàn bộ cuốn sách tuân theo nguyên tắc KISS. Cá nhân tôi không phải ngôn ngữ của tôi, nhưng vẫn có ảnh hưởng đến tôi.

Lập trình từ mặt đất lên. Nó miễn phí trên internet. Cuốn sách này đã dạy tôi AT & T asm. Nó rất dễ để đọc.

Mô hình lập trình trí tuệ nhân tạo : Nghiên cứu trường hợp trong Lisp chung của Peter Norvig

Tôi bắt đầu đọc nó vì tôi muốn học Common Lisp. Khi tôi đi được nửa đường, tôi nhận ra đây là cuốn sách vĩ đại nhất về lập trình mà tôi đã đọc cho đến nay.

Thủ công phần mềm dứt khoát

văn bản thay thế http://ecx.images-amazon.com/images/I/5186JKTDVWL._SL500_AA240_.jpg

Cuốn sách này giải thích rất nhiều điều về công nghệ phần mềm, phát triển hệ thống. Nó cũng cực kỳ hữu ích để hiểu sự khác biệt giữa các loại phát triển sản phẩm khác nhau: khung web VS VS thu nhỏ của IBM. Mọi người đã nghĩ gì khi họ quan niệm mô hình thác nước? Đọc điều này và tất cả chúng ta sẽ trở nên rõ ràng (hy vọng)

@Peter Coulton - bạn không đọc Knuth, bạn học nó.

Đối với tôi và công việc của tôi ... Cấu trúc dữ liệu chức năng hoàn toàn phù hợp để suy nghĩ và phát triển với các ngôn ngữ chức năng trong tâm trí.

"Thế giới phẳng" của Thomas Friedman.

Xuất sắc trong lập trình đòi hỏi một sự đầu tư của năng lượng tinh thần và sự cống hiến để tiếp tục học tập tương đương với các ngành nghề y học hoặc pháp luật. Nó trả một phần nhỏ của những gì các ngành nghề đó trả, ít hơn nhiều so với tiền lương trả cho những người am hiểu toán học đứng đầu trong lĩnh vực tài chính. Và tiền lương cho việc xây dựng mã đang bị xói mòn bởi vì đó là một nghề tương đối dễ dàng cho người thông minh và tự kỷ luật ở hầu hết các nền kinh tế.

Lập trình đã bị xói mòn đến mức trả ít hơn, nói, hệ thống ống nước. Hệ thống nước không thể "lạc hậu". Bạn không cần phải trả $ 2395 để tham dự Hội nghị Thợ sửa ống nước chuyên nghiệp mỗi năm vì đặc quyền nhận được một bộ công nghệ hệ thống ống nước hoàn toàn mới sẽ khiến bạn mất một năm để học.

Nếu bạn sống ở Bắc Mỹ hoặc Châu Âu, còn trẻ và thông minh, lập trình không phải là lựa chọn nghề nghiệp hợp lý. Các doanh nghiệp liên quan đến lập trình, hoàn toàn. Học kinh doanh, biết đủ về lập trình để tinh chỉnh máy dò BS của bạn: xuất sắc. Nhưng dành phần lớn năng lượng tinh thần của bạn cho việc làm chủ các thư viện, cấu trúc dữ liệu và thuật toán? Điều đó chỉ có ý nghĩa nếu lập trình là một cái gì đó cho bạn nhiều hơn là một lựa chọn kinh tế.

Nếu bạn yêu thích lập trình và vì lý do đó có ý định biến nó thành sự nghiệp của bạn, thì nó sẽ khiến bạn phát triển sự hiểu biết lạnh lùng về các lực lượng đang và sẽ tiếp tục, để biến nó thành một nghề khó hơn và khó hơn để kiếm sống . "Thế giới phẳng" sẽ không dạy bạn cách đặt tên cho các biến của bạn, nhưng nó sẽ khiến bạn đắm chìm trong 6 hoặc 8 giờ trong thực tế kinh tế đã đến. Nếu bạn có thể đọc nó, và không được sợ hãi, sau đó đi ra ngoài và mua "Code Complete".

Năm ngoái tôi đã tham gia một số lớp học. tôi đọc

Thế lưỡng nan của nhà cải tiến (công nghệ đột phá)
Tháng người đàn ông huyền thoại (phần mềm quản lý)
Vượt qua
hệ thống quản lý cơ sở dữ liệu (khởi động) ,
Lập trình sách COW C #, Sách phát triển iPhone của OSTRICH, Sách GRAPEFRUIT

Mỗi cuốn sách đều tuyệt vời nhưng Dilemma của Nhà cải cách của Clayton Christensen (1997 !!!) thực sự là một cuốn sách tuyệt vời và nó khiến tôi thực sự nghĩ về thế giới phần mềm hiện đại. Thách thức được giải quyết là công nghệ đột phá, và làm thế nào các công ty ổ đĩa và các công ty phi kỹ thuật luôn bị phá vỡ bởi công nghệ thay đổi trò chơi mới. Nó mang đến cho người ta một viễn cảnh mới khi nghĩ về Google, có lẽ là công ty 'web' lớn nhất. Tại sao họ có bàn tay của họ trong MỌI THỨ? Đó là bởi vì họ không muốn bị phá vỡ vị trí của mình bởi một cái gì đó mới. Việc xem trước trên google là rất nhiều để có được ý tưởng. Đọc nó!

tin tặc, bởi Steven Levy.

Tính cách và cách sống phải đến trước. Mọi thứ khác có thể được học.

Thực hành lập trình

và

Làm thế nào để giải quyết nó bằng máy tính

văn bản thay thế http://img.infibeam.com/img/7101e0ee/496b1/05/629/PMB-9788131705629.jpg?hei=200&wid=160&op_sharpen=1

Ngôn ngữ Python có ảnh hưởng rất lớn đối với tôi, tôi ước mình đã đọc những cuốn sách này từ nhiều năm trước. Vẻ đẹp và sự đơn giản của ngôn ngữ Python thực sự ảnh hưởng đến cách tôi viết mã bằng các ngôn ngữ khác.

Omnibus Turing mới http://ecx.images-amazon.com/images/I/51HlYd-%2BRwL._BO2,204,203,200_PIsitb-sticker-arrow-click,TopRight,35,-76_AA300_SH20

Cuốn sách thực sự tốt. Có một hương vị cấp cao của các lĩnh vực quan trọng nhất của khoa học máy tính. Vâng, CS! = Lập trình, nhưng điều này vẫn hữu ích cho mọi lập trình viên.

Phân tích và thiết kế hướng đối tượng với các ứng dụng của Brady Booch

Tháng huyền thoại của Fred Brooks http://en.wikipedia.org/wiki/The_Mythical_Man-Month

Tôi nghĩ rằng "Nghệ thuật lập trình Unix" là một cuốn sách tuyệt vời, bởi một hacker xuất sắc / một bộ óc thông minh tuyệt vời như Eric S. Raymond, người cố gắng làm cho chúng ta hiểu một vài nguyên tắc thiết kế phần mềm (chủ yếu là đơn giản). Cuốn sách này là bắt buộc cho mọi lập trình sắp bắt đầu một dự án dưới nền tảng Unix.

Mặc dù tôi đồng ý rằng nhiều cuốn sách ở trên là phải đọc (Lập trình viên thực dụng, Tháng huyền thoại, Nghệ thuật lập trình máy tính và SICP ngay lập tức), tôi muốn đi theo một hướng hơi khác và đề xuất Kỷ luật lập trình bởi Edsger Dijkstra. Mặc dù đã 32 tuổi, việc nhấn mạnh vào "thiết kế để kiểm chứng" rất phù hợp (ngay cả khi "tính xác minh" có nghĩa là "bằng chứng" thay vì "kiểm tra đơn vị").

Code Craft của Pete Goodliffe là một tác phẩm hay!

Code Craft http://ecx.images-amazon.com/images/I/51WZ9AEC3GL._SL500_BO2,204,203,200_PIsitb-dp-500-arrow,TopRight,45,-64_OU01_AA240_SH20_.jpg

Tái cấu trúc của Martin Fowler : Cải thiện thiết kế mã hiện tại đã được liệt kê. Nhưng tôi sẽ nói chi tiết tại sao nó lại tác động đến tôi.

Bản chất của toàn bộ cuốn sách là về cấu trúc mã để con người đọc và hiểu đơn giản hơn . Nó dạy tôi mạnh mẽ rằng mã mà tôi viết có nghĩa là để các đồng nghiệp và người kế nhiệm của tôi tiêu thụ và có thể học được điều gì đó tốt từ nó. Nó truyền cảm hứng cho tôi để lập trình một cách có ý thức theo cách khiến mọi người ca ngợi tên của tôi, và không nguyền rủa tôi đến chết tiệt mãi mãi .

văn bản thay thế http://ecx.images-amazon.com/images/I/61dECNkdnTL._SL500_AA240_.jpg

C ++ Cách lập trình Rất tốt cho người mới bắt đầu. Đây là cuốn sách tuyệt vời hoàn chỉnh với 1500 trang.

Đây là một cuốn sách tuyệt vời không được hoan nghênh rộng rãi, nhưng đầy hiểu biết sâu sắc: Phát triển phần mềm Agile: Trò chơi hợp tác , của Alistair Cockburn.

Có gì đặc biệt về nó? Chà, rõ ràng mọi người đều đã nghe cụm từ "Agile", và dường như hầu hết là những tín đồ ngày nay. Dù bạn có tin hay không, tuy nhiên, có một số nguyên tắc sâu xa đằng sau lý do tại sao phong trào Agile tồn tại. Cuốn sách này khám phá và nói rõ những nguyên tắc này một cách chính xác, khoa học. Một số nguyên tắc là (btw, đây là những lời của tôi, không phải của Alistair):

1. Điều khó nhất trong việc phát triển phần mềm nhóm là làm cho bộ não của mọi người có cùng sự hiểu biết. Chúng tôi đang xây dựng những hệ thống lớn, phức tạp, phức tạp, vô hình trong thế giới hữu hình. Bạn càng giỏi trong việc thu hút được nhiều bộ não của mọi người để chia sẻ hiểu biết sâu sắc hơn, nhóm của bạn sẽ càng phát triển phần mềm hiệu quả hơn. Đây là lý do cơ bản mà lập trình cặp có ý nghĩa. Hầu hết mọi người bỏ qua nó (và tôi đã làm quá ban đầu), nhưng với nguyên tắc này, tôi khuyên bạn nên cho nó một phát súng khác. Bạn kết nối với HAI người hiểu sâu sắc hệ thống con bạn vừa xây dựng ... không có nhiều cách khác để có được sự chuyển thông tin sâu sắc nhanh như vậy. Nó giống như một meld tâm trí Vulcan.
2. Bạn không phải lúc nào cũng cần từ ngữ để truyền đạt sự hiểu biết sâu sắc một cách nhanh chóng. Và một hệ quả: quá nhiều từ và bạn vượt quá khả năng của người nghe / người đọc, nghĩa là việc chuyển giao sự hiểu biết mà bạn đang cố gắng không xảy ra. Hãy xem xét rằng trẻ học cách nói ngôn ngữ bằng cách "đắm mình" và "tiếp thu". Không chỉ ngôn ngữ ... anh ấy còn đưa ra ví dụ về một số trẻ em chơi với xe lửa trên sàn nhà. Cùng với một đứa trẻ khác thậm chí chưa bao giờ TÌM một chuyến tàu trước đó ... nhưng bằng cách xem những đứa trẻ khác, nó nhặt lên ý chính của trò chơi và chơi ngay. Điều này xảy ra tất cả thời gian giữa con người. Điều này cùng với hệ quả của quá nhiều từ giúp bạn thấy nó đã sai lầm như thế nào trong những ngày "thác nước" cũ để cố gắng viết 700 trang thông số kỹ thuật yêu cầu chi tiết.

Có quá nhiều thứ trong đó nữa. Tôi sẽ im lặng ngay bây giờ, nhưng tôi rất muốn giới thiệu cuốn sách này!

Bậc thầy của sự diệt vong. Theo như động lực và tình yêu cho nghề nghiệp của bạn đi: nó sẽ không tốt hơn những gì được mô tả trong cuốn sách này, câu chuyện truyền cảm hứng thực sự!