Là kinh nghiệm thực tập tiêu cực của tôi đại diện của thế giới thực? [đóng cửa]

Tôi tò mò nếu kinh nghiệm hiện tại của tôi là một thực tập viên là đại diện của ngành công nghiệp thực tế.

Làm nền tảng, tôi thông qua phần tốt hơn của hai chuyên ngành điện toán và chuyên ngành toán tại một trường đại học lớn; Tôi đã học được tất cả các lớp và yêu thích tất cả trong số họ, vì vậy tôi muốn nghĩ rằng tôi không phải là khủng khiếp trong lập trình. Tôi đã được thực tập với một trong những công ty phần mềm lớn và đến nửa giờ tôi đã bị sốc với chất lượng mã cực kỳ thấp. Nhận xét không tồn tại, tất cả đều là mã spaghetti và mọi thứ có thể sai thậm chí còn tệ hơn. Tôi đã thực hiện rất nhiều công việc dạy kèm / TAing, vì vậy tôi rất quen đọc mã xấu, nhưng các sản phẩm chính của ngành tôi đã nhìn thấy tất cả những điều đó. Tôi làm việc 10-12 giờ mỗi ngày và không bao giờ cảm thấy như mình đang đi đâu cả, bởi vì nó ' hàng giờ cố gắng tìm ra API không có giấy tờ hoặc xác định hành vi của một số phần khác của sản phẩm (hoàn toàn không có giấy tờ). Tôi đã rời bỏ công việc ghét công việc hàng ngày cho đến nay và tôi rất muốn biết liệu đây có phải là thứ đang có trong phần còn lại của cuộc đời tôi không.

Có phải tôi đã rút ra một ống hút ngắn trong các đợt thực tập (mức lương lớn một cách vô lý ngụ ý rằng đó không phải là một vị trí chất lượng thấp), hay đây là thế giới thực?

Họ gọi nó là Real World ™ vì một lý do.

99% những gì bạn sẽ gặp trong thế giới doanh nghiệp thực sự sẽ bị coi là tào lao, và vì lý do chính đáng mà tôi sẽ giải thích. 1% không được coi là tào lao cuối cùng sẽ trở thành tào lao.

# 1 Viết mã, # 2 ????, # 3 Lợi nhuận!

Trước hết các doanh nghiệp tồn tại để kiếm lợi nhuận, họ không tồn tại để tạo ra hàng núi mã học thuật được thiết kế hoàn hảo về mặt lý thuyết và nguyên sơ nằm trong kho vàng hoàn hảo. Thậm chí không gần gũi, thậm chí không phải là những người trong doanh nghiệp bán mã nguồn mà họ sản xuất.

Trong thế giới kinh doanh mã là một phương tiện để kết thúc . Nếu một số mã giải quyết một vấn đề kinh doanh và kiếm được nhiều tiền hơn chi phí để tạo và duy trì thì đó là mong muốn cho doanh nghiệp. Sử dụng bạn để viết mã chỉ là một cách để doanh nghiệp có được mã.

Lý thuyết 0 - Thực hành

Bảo trì lý tưởng nên là mối quan tâm nhiều hơn nhưng thường thì không, vì trong ngắn hạn, nó không thắng được về mặt tài chính. Về lâu dài, phần mềm thường có vòng đời tương đối ngắn, đặc biệt là các ứng dụng dựa trên web, chúng bị lỗi thời một cách nhanh chóng và được viết lại thường xuyên hơn.

Trong các ứng dụng kinh doanh nội bộ là những ứng dụng bắt đầu như những gì được coi là dự án zombie bất tận vì nhiều lý do dựa trên động lực. Những dự án này thực sự là những thành công mà họ tiếp tục vì họ tiếp tục làm cho doanh nghiệp có lãi.

Trong lý thuyết không có sự khác biệt giữa lý thuyết và thực hành. Trong thực tế có. - Beri Yogi

Về lý thuyết, kiến ​​trúc hoàn toàn sạch sẽ, cơ sở mã nguyên sơ hoàn toàn sạch sẽ với bảo hiểm mã 100% sẽ tiết kiệm tiền cho các công ty, trong thực tế, nó thậm chí không tiến gần đến việc cung cấp bất kỳ thứ gì gần với lợi tức đầu tư hợp lệ.

Vật lý của vòng đời phần mềm

Ngoài ra còn có một lực lượng entropy siêu mạnh đang hoạt động trong thế giới phần mềm. Đó là một lỗ đen không thể tránh khỏi, lên án tất cả các phần mềm thoái hóa thành một quả bóng lớn .

Bạn bắt đầu từ BBM càng xa thì càng tốt, nhưng mọi hệ thống phần mềm cuối cùng sẽ đến đó khi có đủ thời gian. Mức độ nhanh chóng bạn tiếp cận 100% entropy được xác định bởi nơi bạn bắt đầu và mức độ nhanh chóng của bạn đối với nợ kỹ thuật và mức độ quan tâm của nó.

Hệ thống phần mềm suy thoái và mục nát vì bảo trì, không phải vì thiếu nó. Một hệ thống được áp dụng trong nhiều năm mà không có thay đổi mã theo định nghĩa đáp ứng tất cả các yêu cầu và mục tiêu của nó và là một thành công.

Đó là các hệ thống đòi hỏi phải thay đổi liên tục vì chúng bắt đầu gần với entropy tối đa là những hệ thống liên tục bị chọc và chọc và đó là sự bảo trì giúp đẩy nhanh sự thay đổi tiêu cực.

Đủ tốt là đủ tốt

Các hệ thống vòng đời ngắn như các trang web thay đổi liên tục không được hưởng lợi từ thiết kế trả trước 100% mã lớn đắt tiền trong các thử nghiệm đơn vị, vì thời gian khấu hao quá ngắn để thu lại chi phí.

Các hệ thống vòng đời dài như dòng ứng dụng kinh doanh nội bộ đã đề cập ở trên, không thực sự được hưởng lợi từ các khoản đầu tư lớn cho các thử nghiệm đơn vị bảo hiểm mã 100%, bởi vì tỷ lệ thay đổi trong vòng đời của dự án đạt đến một hằng số gần bằng 0 thời trang phi tuyến tính.

Đó là lý do tại sao các kế hoạch cuối đời quan trọng hơn và các hệ thống thay thế nên được lên kế hoạch giống như một cái gì đó đang được phát hành, chứ không phải khi nó đã qua được vài năm và không thể hỗ trợ nên một hệ thống mới phải được đưa vào sử dụng.

Họ không dạy về BBM theo như tôi biết, tôi chưa bao giờ gặp một sinh viên tốt nghiệp CS gần đây biết nó là gì, ít hơn nhiều tại sao nó lại xảy ra.

Đó là lý do tại sao Đủ tốt là Đủ tốt , bất cứ điều gì nhiều hay ít đều không.

Slumlords phần mềm

Có những lãnh chúa khu ổ chuột bất động sản vì một lý do, họ kiếm được lợi nhuận từ việc điều hành các tòa nhà tồi tàn mà họ sở hữu. Lợi nhuận kiếm được nhiều hơn số tiền họ chi cho việc bảo trì gia tăng tài sản. Nếu họ không làm, họ sẽ phá hủy tòa nhà và thay thế nó. Nhưng họ không làm thế, vì chi phí gia tăng ít hơn nhiều so với đại tu hoặc thay thế toàn bộ tòa nhà. Cũng có những khách hàng (người thuê nhà) sẵn sàng trả tiền để chạy xuống tài sản.

Không có chủ sở hữu tòa nhà, chúa tể khu ổ chuột hay không sẽ chi tiền cho một bất động sản chỉ vì một số khái niệm học thuật về sự hoàn hảo không mang lại lợi nhuận đáng kể so với chi phí liên quan.

Không có khách hàng sẽ trả tiền để nâng cấp lên một hệ thống phần mềm đang hoạt động chấp nhận được với họ. Không có doanh nghiệp sẽ chi tiền cho chỉ viết và viết lại mã cho lợi nhuận đáng kể hữu hình.

Microsoft đang chiếm ưu thế và thành công nhất trong khu ổ chuột. Windows đã không bắt đầu nhận được viết lại nền tảng lớn cho đến gần đây. Và họ vẫn không bỏ tất cả mã kế thừa từ kernel. Điều đó không có ý nghĩa kinh doanh đối với họ, mọi người không sẵn sàng chấp nhận những kỳ vọng thấp mà họ đã đặt ra trong thập kỷ qua.

Tiên lượng

Đây là một mô hình trong hơn 20 năm tôi đã phát triển phần mềm. Nó sẽ không thay đổi bất cứ lúc nào sớm. Đây không phải là cách mọi người muốn nó ra khỏi một số hệ thống niềm tin, đó là một thực tế của các lực lượng bên ngoài đối với một doanh nghiệp. Kinh doanh thúc đẩy việc ra quyết định, lợi nhuận không phải là xấu mà họ trả lương cho bạn, tầm nhìn ngắn hạn hay dài hạn là không liên quan, đây là một ngành ngắn hạn thay đổi liên tục theo định nghĩa. Bất cứ ai lập luận chống lại đủ tốt để kiếm lợi nhuận đều không hiểu kinh doanh.

Tôi đã dành 15 năm để tư vấn và học rất nhanh rằng đủ tốt chỉ là, bất cứ điều gì khác đều làm tôi mất tiền. Vâng tôi muốn mọi thứ phải hoàn hảo, nhưng trừ khi bạn đang bán một cơ sở mã, mà 99,99999% thời gian bạn đang bán một giải pháp , tất cả các mã thanh lịch được tổ chức sạch sẽ bị mất và bạn chỉ lãng phí thời gian của mình, bạn sẽ không bao giờ được hoàn trả .

Tiến bộ và Hy vọng

Các phương pháp nhanh nhẹn là một bước tốt theo đúng hướng, ít nhất là về mặt triết học. Họ giải quyết sự hỗn loạn và thay đổi liên tục như một công dân hạng nhất và chấp nhận nó. Họ từ chối các thực hành giáo điều, thừa nhận rằng các phương pháp và thực tiễn nên thay đổi cũng như các yêu cầu và công nghệ.

Họ chấp nhận entropy được giới thiệu bởi các thiếu thời gian hoặc thay đổi yêu cầu, thay đổi nhân viên và các liveness của một hệ thống phần mềm với các khái niệm về nợ kỹ thuật.

Nhưng Agile không phải là thuốc chữa bách bệnh, nó sẽ không thay đổi các định luật cơ bản của vật lý và các cơ sở mã sẽ bị thối rữa. Tùy thuộc vào quản lý để lên kế hoạch đối phó với sự thối rữa trước khi nó hoàn toàn mất kiểm soát và không thể quản lý được.

Nhanh nhẹn khi được thực hiện chính xác, giúp quản lý entropy, làm chậm nó, theo dõi nó, đo lường và đối phó với nó một cách có kế hoạch. Nó sẽ không dừng lại đâu!

Quyết định nghề nghiệp

Nếu đây là một vấn đề triết học thực sự cho bạn, có lẽ bạn nên xem xét các lựa chọn nghề nghiệp khác, bởi vì cách mọi thứ hoạt động có giá trị kinh doanh hợp lệ đằng sau nó. Các dự án nguồn mở không có bất kỳ hồ sơ theo dõi nào tốt hơn và trong nhiều trường hợp, mã thậm chí còn tệ hơn hầu hết các mã công ty tôi đã thấy.

Tôi tò mò nếu kinh nghiệm hiện tại của tôi là một thực tập viên là đại diện của ngành công nghiệp thực tế.

Không có nó không phải là. Nó là đại diện cho mức độ nghề nghiệp và kinh nghiệm của bạn. Đó là tất cả các phần của việc tìm hiểu về cách các doanh nghiệp làm việc từ góc độ kiểm soát chất lượng nội bộ.

Làm nền tảng, tôi thông qua phần tốt hơn của hai chuyên ngành điện toán và chuyên ngành toán tại một trường đại học lớn; Tôi đã học được tất cả các lớp và yêu thích tất cả trong số họ, vì vậy tôi muốn nghĩ rằng tôi không phải là khủng khiếp trong lập trình. Tôi đã được thực tập với một trong những công ty phần mềm lớn và đến nửa giờ tôi đã bị sốc với chất lượng mã cực kỳ thấp.

Kỹ năng của bạn, kinh nghiệm của bạn, giáo dục của bạn không có tác động đến chất lượng công việc được thực hiện bởi người khác. Đơn giản vì bạn không có quyền thay đổi những thực hành đó. Không có vấn đề gì nếu bạn tốt hay xấu ở trường đại học. Điều đó không thay đổi cách công ty bạn làm việc hiện đang hoạt động. Vì vậy, trong khi nó tuyệt vời, bạn có tất cả nền tảng này. Đó thực sự là vì lợi ích của riêng bạn chứ không phải của họ. Đó là lý do tại sao điều quan trọng là nghiên cứu những gì bạn yêu thích.

Tôi đã được thực tập với một trong những công ty phần mềm lớn và đến nửa giờ tôi đã bị sốc với chất lượng mã cực kỳ thấp. Nhận xét không tồn tại, tất cả đều là mã spaghetti và mọi thứ có thể sai thậm chí còn tệ hơn. Tôi đã thực hiện rất nhiều công việc dạy kèm / TAing, vì vậy tôi rất quen đọc mã xấu, nhưng các sản phẩm chính của ngành tôi đã nhìn thấy tất cả những điều đó.

Điều tôi đã học được trong nhiều năm lập trình là có sự khác biệt giữa "chất lượng mã" và "mã chấp nhận được". Sự thật là hoặc ai đó có thẩm quyền tìm thấy mã nguồn trong điều kiện chấp nhận được, hoặc họ thấy nó không được chấp nhận nhưng cần thiết. Mặc dù thật tuyệt nếu tất cả chúng ta có thể dọn sạch các dự án mà chúng ta tham gia. Nó thường không nằm trong lợi ích hoặc ngân sách của doanh nghiệp để phân bổ nguồn lực để thực hiện công việc đó. Lập luận logic có thể được đưa ra cho đến khi mặt trời mọc vào ngày hôm sau tại sao điều này sẽ là một điều tốt để khắc phục, nhưng khi quản lý đã quyết định trạng thái hiện tại là "chấp nhận được" thì có thể làm được rất ít. Tất cả đều liên quan trực tiếp đến người điều hành mọi thứ. Họ đánh giá chất lượng nội bộ tốt hoặc không. Bạn rõ ràng coi trọng nó và do đó trạng thái hiện tại làm phiền bạn.

Bạn sẽ tìm thấy các ví dụ về loại vấn đề này trong bất kỳ ngành nào phụ thuộc vào kiểm soát chất lượng nội bộ. Khác nhau, từ phát triển phần mềm đến sản xuất. Bạn cần học cách xem đây không phải là một vấn đề, mà đơn giản là điều kiện hiện tại của mã nguồn của họ. Đây là cách nó hoạt động, phải mất X số phút để tìm thứ gì đó, phải mất X số phút để sửa một cái gì đó.

Doanh nghiệp không quan tâm đến thời gian thêm này hoặc có thể chấp nhận được.

Tôi làm việc 10-12 giờ mỗi ngày và không bao giờ cảm thấy như mình đang ở bất cứ đâu, bởi vì đó là vô tận khi cố gắng tìm ra API không có giấy tờ hoặc xác định hành vi của một số phần khác của sản phẩm (hoàn toàn không có giấy tờ). Tôi đã rời bỏ công việc ghét công việc hàng ngày cho đến nay và tôi rất muốn biết liệu đây có phải là thứ đang có trong phần còn lại của cuộc đời tôi không.

Tại sao bạn có thể chấp nhận bỏ học nhiều giờ ở trường đại học để học một môn học, nhưng bây giờ không thể chấp nhận để học nhiều giờ để học mã nguồn? Tôi chắc chắn lý do nhà tuyển dụng thuê bạn là vì họ nghĩ bạn có thể xử lý nó.

Hãy để tôi cho bạn một số lời khuyên. Các nhà phát triển giỏi biết khi nào cần yêu cầu trợ giúp từ các đồng đội của họ. Đừng nghĩ rằng câu trả lời luôn nằm trong mã. Tôi đã tiết kiệm cho mình hàng giờ bằng cách chỉ cần hỏi mọi người một vài câu hỏi. Âm thanh như bạn cần một số trợ giúp đến tốc độ.

Thứ hai, chúng tôi không biết điều kiện làm việc. Làm việc nhiều giờ là một thực tế của cuộc sống trong rất nhiều ngành công nghiệp. Rằng bạn cần tự mình giải quyết, nhưng tôi có thể nói với bạn. Ghét công việc của bạn không bao giờ là một dấu hiệu tốt. Bạn nên đối phó với cảm giác đó và đi đến gốc rễ của nó. Tôi xin lỗi vì bạn thấy trải nghiệm này tiêu cực.

Có phải tôi đã rút ra một ống hút ngắn trong các đợt thực tập (mức lương lớn một cách vô lý ngụ ý rằng đó không phải là một vị trí chất lượng thấp), hay đây là thế giới thực?

Bạn đã học rất giỏi ở trường, nhưng bây giờ bạn có một kỳ thực tập và bạn không làm tốt lắm. Âm thanh như bạn đã ở trong thế giới thực. Đó là một phần của cuộc sống. Câu hỏi là, bạn sẽ làm gì với nó? Đó là bạn của tôi, là điều duy nhất quan trọng. Chúng tôi không thể cho bạn biết phải làm gì. Bạn phải làm cho tâm trí của riêng bạn.

Tôi có thể nói với bạn rằng có vẻ như trải nghiệm của bạn ở tuổi của bạn tốt hơn nhiều so với bất kỳ cơ hội nào mà tôi có. Cuộc sống đối với tôi trong những năm 90 là một cuộc đấu tranh để trả tiền thuê nhà và tìm hợp đồng tiếp theo của tôi. Tự coi mình là may mắn.

Sau 25 năm và một loạt các công ty và ngành công nghiệp tôi có thể nói:
Vâng, nó khá phổ biến.
Đây là lý do tại sao các kỹ sư được trả lương khá thường xuyên, họ phải giỏi trong việc gặp phải những cái chuồng lộn xộn và vẫn có thể thay đổi trong khi chống lại mong muốn cấp bách để tái cấu trúc toàn bộ thứ chết tiệt đó và tìm ra cái quái gì thực sự là đang làm. Tôi đã mang lại cảm xúc cho bạn ở đó - thật bình thường khi cảm thấy như vậy về mã bạn gặp phải!

Mã bạn nhìn thấy thường sẽ trải qua các lần lặp vô tận bởi các lập trình viên khác nhau với các cách tiếp cận và tiêu chuẩn khác nhau và các quy ước đặt tên khác nhau, v.v.

Điều xảy ra mặc dù là áp lực $ luôn luôn. Luôn luôn hấp dẫn để mô tả cách thức và lý do tại sao mã tốt hơn là cách duy nhất trong dài hạn nhưng trong rất nhiều công việc, đồng hồ đang đánh dấu một giải pháp khắc phục nhanh ngắn hạn. Chỉ mất 1 kỹ sư một thời gian ngắn để phá hủy các tiêu chuẩn trong một dự án. Cần một người quản lý rất giỏi, biết cách ngăn chặn điều này và bảo vệ cách tiếp cận đúng (khi có thể) để thực sự giải quyết nó.

Một điều chắc chắn, thuật ngữ 'mã tốt' chỉ là quá chủ quan để không hữu ích. Tất nhiên nó không chủ quan với bạn, bạn có thể liệt kê các lý do / mục cụ thể. Tuy nhiên, những người khác liệt kê các mục và ưu tiên khác nhau, một số thậm chí không mang tính kỹ thuật mà họ cho là quan trọng và do đó nó mang tính chủ quan.

Giống như Drekka, điều này đang bắt đầu nghe có vẻ buồn, vì vậy hãy để tôi cố gắng tích cực hơn một chút, bởi vì điều đó chắc chắn đúng: -

• Có những tổ chức, thường là những tổ chức có các thành phần kỹ thuật lớn nhất đang làm việc đúng.
• Công ty càng mới ... và mã ... nó càng có xu hướng sạch hơn . Spaghetti phát triển do thời gian và con người.
• Một số người làm TDD và BDD, những người khác thì không. Phạm vi là rất lớn.
• Sau khoảng 10 năm, hiện tại, toàn bộ cơ sở công nghệ thay đổi, vì vậy những người ở lại trong ngành có thể có một thời gian khó khăn để theo kịp những người mới.

Cuối cùng, như Anthony Blake chỉ ra, luôn có 3 yếu tố - thời gian, chi phí và chất lượng.
Tôi thích biểu thức liên quan: "chọn 2" !

Có rất nhiều ý kiến ​​về điều này bởi vì kinh nghiệm của mọi người là khác nhau.

Của tôi là khoảng một nửa các nhà phát triển tôi gặp có ý định tốt, nhưng khả năng trung bình. Có một nhóm nhỏ những người xuất sắc ở phía trên, và một nhóm nhỏ ở phía dưới đang cố gắng nhưng về cơ bản nên làm một cái gì đó khác vì họ không thực sự hiểu được. Thật không may, cũng có một nhóm nhỏ những kẻ ngu ngốc bất tài khác nghĩ rằng họ thông minh hơn những người khác và thường khá rõ ràng về cách bạn nên theo dõi họ.

Dự án khôn ngoan, tôi đã đi vào rất nhiều công việc và ngay lập tức được yêu cầu "chăm sóc" một số dự án đã thành lập, thường là một công việc mà doanh nghiệp vừa phát hiện ra nó thực sự cần sau khi mất nhà phát triển cuối cùng về nó. Tôi thường tìm thấy chính xác những gì bạn đã phác thảo ở trên - spaghetti không có giấy tờ, quá kỹ thuật, lỗi. Đôi khi tôi có thể sửa nó, đôi khi tôi chỉ bắt đầu lại. Nó thậm chí không cần phải là mã cũ, tôi đã tìm thấy điều này trên các dự án mới mà tôi đã được yêu cầu "giúp đỡ".

Bạn phải lấy lòng từ thực tế là hầu hết các công ty sẽ cung cấp cho thực tập sinh những công việc nhảm nhí. Những điều thú vị đến sau khi bạn đã thực hiện hai điều: 1 - chứng tỏ bản thân và 2 - dành thời gian để làm những việc khác ngoài sửa chữa lỗi lầm của người khác. Nói cách khác, bạn phải thể hiện khả năng và sự chủ động.

Bí quyết thực sự để xử lý mã xấu là tìm ra cái gì có thể cứu được và cái gì không. Điều này xuất phát từ kinh nghiệm và nghiên cứu.

Lựa chọn nghề nghiệp khác mà bạn có là ngừng làm việc cho các công ty đã thành lập và tìm cách làm việc trong các công ty khởi nghiệp. Sau đó, sẽ không có mã di sản tào lao để duy trì để bạn có cơ hội giúp xây dựng một cái gì đó tốt hơn. Nhược điểm là áp lực phân phối được đặt vào các dự án khởi động thường có nghĩa là các phím tắt và hack được sử dụng khi không nên sử dụng.

Các lập trình viên thường quá sẵn sàng nhận nợ công nghệ để giao hàng sớm hoặc đúng hạn. Thật không may, tác động của khoản nợ công nghệ này thường được che đậy, giảm thiểu, bỏ qua hoặc loại bỏ bởi các nhà phát triển và quản lý cho đến khi quá muộn và họ gặp rắc rối.

Xin lỗi nếu điều này nghe có vẻ buồn. Tôi chắc chắn rằng người khác có thể làm một phần tích cực hơn. :-)

Có một số câu trả lời tuyệt vời ở đây, nhưng hãy để tôi thêm bit của mình;

Chào mừng đến với thế giới thực - thật không may, điều này rất phổ biến.

Tham khảo sơ đồ bên dưới;

Với phần mềm công ty, bạn chỉ có thể chọn 2 hoặc ở trên và bạn phải hy sinh một.

Như bạn đã phát hiện ra, phần lớn thế giới doanh nghiệp đi với tốc độ và giá cả.

Không hoàn toàn chỉ ra ngành công nghiệp, nhưng từ kinh nghiệm hạn chế của tôi hơn 5 năm. Tôi sẽ làm việc trong thời gian thực tập của bạn và học hỏi nhiều nhất có thể từ kinh nghiệm. Tìm kiếm dấu hiệu, và các chỉ số. Ví dụ cho vị trí tiếp theo của bạn, bạn chắc chắn sẽ phải trải qua một loạt các cuộc phỏng vấn. Quá trình này là một con đường hai chiều, và cho bạn cơ hội để cảm nhận về một công ty. Điều này là cực kỳ quan trọng và có khả năng sẽ dẫn đến hạnh phúc và hạnh phúc của riêng bạn.

Để tổng hợp mọi thứ, phát hiện các dấu hiệu kể chuyện;

• Ai đang điều hành công ty? Có phải là một người quản lý duy nhất, nhóm tiếp thị (nếu vậy, tránh xa), nhóm phát triển, v.v ... Góc này có nghĩa là bạn có thể nhận được ít nhiều đòn bẩy cho các dự án, thời gian dành cho các dự án, v.v.
• Có một sự đánh giá cao kỹ thuật? Hãy nhìn cách quản lý, người giám sát và các thành viên của nhóm đối xử với nhau. Tôi đã tham gia một cuộc phỏng vấn nơi các nhà quản lý đã thực hiện tất cả các loại chuyển động của lông mày khi lãnh đạo kỹ thuật bắt đầu nói. Sau đó và học họ không sử dụng kiểm soát nguồn - bạn không thể chỉ cho tôi cửa đủ nhanh.
• Mục tiêu kinh doanh? Công ty có sống từng ngày không, như trong các mục tiêu tài chính hàng ngày, hay công ty có kế hoạch dài hạn mà bạn là một phần của. Phát triển phần mềm thường được thực hiện trong nhiều tháng nên việc có một công ty có bản chất tâm thần phân liệt thường dẫn đến phần mềm lộn xộn.
• Đào xung quanh rất nhiều - khi đặt câu hỏi kỹ thuật và xem nếu mọi người xáo trộn. Kiểm soát nguồn, kiểm soát tài liệu, quy trình phát hành, báo cáo lỗi, phong cách quản lý, T & C, v.v.

Vì vậy, sống và học hỏi, và suy nghĩ về vai trò tiếp theo của bạn. Có một trải nghiệm tồi tệ không phải là điều tồi tệ, bởi vì bạn sẽ được giáo dục tốt hơn về thế giới công việc & kinh doanh.

Chà, tôi đang chạy lên thập kỷ thứ hai trong công việc kinh doanh và tôi có thể nói với bạn rằng mã sạch hoàn hảo rất hiếm khi xảy ra, và khi nó xảy ra, nó sẽ không tồn tại lâu như vậy. Nhìn chung, bạn sẽ thấy mình liên tục cố gắng sửa chữa những sai lầm của quá khứ, trong khi (đáng buồn) bị ép buộc bởi những hạn chế về thời gian và khả năng lãnh đạo kém để phạm phải những sai lầm của hiện tại.

Trừ khi bạn đang ở trong một loại hình kinh doanh phần mềm rất cụ thể, áp lực để đưa một sản phẩm chức năng ra khỏi cửa sẽ ghi đè lên tất cả các mối quan tâm khác, và tối ưu hóa vượt quá một điểm nhất định được coi là vô nghĩa. Nếu chương trình chạy trong 5 phút và chúng tôi chỉ cần nó chạy trong 5 phút, không ai sẽ cung cấp cho bạn một vài tuần để giảm thời gian chạy xuống còn 2 phút.

Nếu, bằng một phép màu nào đó, bạn có sự hợp lưu hoàn hảo của quản lý có thẩm quyền, mục tiêu rõ ràng, tiền bạc, tài năng và thời gian, và bạn tạo ra một sản phẩm sạch, siêu tốc ... Cách duy nhất sẽ duy trì theo cách đó là nếu bạn không bao giờ chạm vào nó một lần nữa . Bảo trì và mở rộng hầu như luôn được ưu tiên rất thấp, các thay đổi luôn cần thiết trong thông báo không có hiệu quả và cuối cùng bị chặn lại một cách thất thường.

Tôi đã suy nghĩ về một dự án này ngày hôm qua. Đó là một giấc mơ rõ ràng đối với tôi, rằng tôi đã bật ra một mảnh thực sự chức năng tối thiểu ra khỏi cửa. Tôi đã xem nó như một sự lãng phí thời gian và tài nguyên.

Vâng, bất ngờ, ngạc nhiên, mọi người đều thích nó và nó hoạt động tốt. Vì vậy, tôi đã nhảy trở lại bảng vẽ và làm điều đó đúng. Và phiên bản mới thật tuyệt vời! Nhưng sau đó, có một doanh thu trong quản lý và toàn bộ mọi thứ đã bị loại bỏ theo hướng "hướng kinh doanh mới".

Lặp lại thứ hai đã có một triển khai thực sự nửa vời trong công ty và tôi chưa bao giờ nghe thấy điều gì khác về nó, điều này thật thú vị bởi vì tôi biết ít nhất ~ 10 đơn vị kinh doanh vẫn đang sử dụng nó (phần mềm chúng tôi đang ủy thác để thực hiện công việc chậm hơn 2 năm so với lịch trình) và dường như nó không bao giờ bị phá vỡ.

Điều này đưa chúng ta đến điểm cuối cùng của tôi. Ngay cả khi bạn tạo ra thứ gì đó kỳ diệu, thực tế là nó hoạt động rất tốt có nghĩa là KHÔNG ai sẽ ít quen thuộc với nó nhất, và khi nó bị hỏng (thường là vì họ đã làm điều gì đó ngu ngốc) thì họ sẽ nguyền rủa tên bạn tệ hơn họ đã từng nguyền rủa tên ngốc đó đã viết thứ đó phá vỡ vào thứ ba hàng tuần.

Thật khó để nói những gì bạn cho là mã chất lượng thấp khủng khiếp, nhưng vâng, rất ít lập trình viên rất giỏi (theo định nghĩa). Khi phần mềm phát triển, mọi người mắc lỗi. Theo thời gian những thứ này tích tụ, và áp lực kinh doanh (và sự lười biếng / thiếu hiểu biết của lập trình viên) khiến việc tái cấu trúc ... Không phổ biến.

Không thể nói cho tất cả mọi người nhưng đây là những gì tôi có thể nói.

Tôi đã không làm việc hơn 30 năm trong lĩnh vực này nhưng tôi đã thấy đủ để nói một vài điều. Một dự án có một cuộc đời khá giống như một con người. Thiết kế ban đầu có thể không phù hợp với nhu cầu hiện tại, giả sử một dự án sau 20 năm phát triển. Điều đó nói rằng trong khoảng thời gian đó, rất nhiều người đã thay đổi mã bị nhầm lẫn với nó và thêm vào những thứ mà trước đây không thể có được.

Thật sự không khó để tưởng tượng mã xấu xí trong các dự án cũ hoặc các dự án khá cũ. Chúng tôi không thể mong đợi mọi người hiểu đầy đủ các thiết kế ban đầu. Thật đáng buồn nhưng đó là như vậy.

Điều đó nói rằng, bạn phải nhớ rằng tái cấu trúc một dự án cũ không phải lúc nào cũng có thể và đôi khi thậm chí không mong muốn. Tôi đã làm việc trong một công ty nơi họ đang phát triển thay thế cho dự án mà tôi đang làm việc. Tôi đã không được phép cấu trúc lại quá nhiều dự án của mình vì sợ rằng nó sẽ hoạt động tốt hơn dự án mới. Tôi khá chắc chắn rằng không có cách nào dự án này có thể hoạt động tốt hơn một dự án mới. cụm từ này hơi giống như "Đừng làm cho nó tốt hơn, chỉ làm cho nó hoạt động".

Cuối cùng, bạn sẽ không có loại dự án đó thường xuyên, vì tôi thường đọc và nghe. Bạn nên cố gắng tìm việc với các công ty khởi nghiệp thay vì tập đoàn lớn. Các công ty khởi nghiệp khá thú vị và cuối cùng bạn có thể tiến lên nhanh chóng nếu bạn thấy rằng nó không đi theo cách bạn muốn.

Ngoài ra một điều bạn có thể làm, tôi thực sự không hứa bất cứ điều gì nhưng nếu bạn cảm thấy mã thực sự tệ và cần tái cấu trúc. Chia sẻ nó với nhóm. Hãy nhớ rằng những người đã viết mã xấu xí đó có thể đang làm việc với bạn. Đó không phải là về việc làm tổn thương cảm giác của mọi người nhưng nếu bạn thấy rằng dự án bạn đang thực hiện sẽ sụp đổ sau đó và mọi người sẽ dành nhiều thời gian hơn để hiểu những gì nó làm thay vì cải thiện nó. Tốt hơn là lên tiếng và truyền đạt vấn đề hơn là giữ nó cho riêng mình. Nếu bạn đủ may mắn, bạn có thể sẽ tái cấu trúc dự án.

Nếu bạn kết thúc việc tái cấu trúc dự án, bạn có thể sẽ trở thành người chỉ ra các lựa chọn thiết kế tồi! Và sau đó bạn có thể hiểu tại sao tái cấu trúc không xảy ra thường xuyên. Hy vọng nếu toàn đội phải tái cấu trúc, thì không ai được chỉ vào. Họ sẽ chỉ bắn mọi người =)

Tôi sẽ cố gắng tổng hợp một câu trả lời cho câu hỏi này bằng một trích dẫn đơn giản:

All code turns to crap given enough time and hands.

Phần còn lại chỉ là những câu chuyện ...

Chất lượng mã phụ thuộc chủ yếu vào hai yếu tố.

Đầu tiên luôn là tiền. Các công ty có áp lực sống sót cao thường trả lương thấp, thu hút các nhà phát triển ít kinh nghiệm hơn, có lịch trình chặt chẽ và không có thời gian cũng như không có tiền để thúc đẩy các nhà phát triển của họ.

Thứ hai là con người. Trước hết, những người quyết định ngân sách phải chọn chi tiêu cho chất lượng mã, sau đó họ phải thu hút những người muốn "sống". Như bạn có thể tưởng tượng, thật khó để chuyển đổi một lập trình viên Delphi từ năm mươi tuổi được trả lương cao (không có ý định rập khuôn, xin lỗi) thành Nhà phát triển Java cập nhật, người xây dựng và sản xuất CI mã ghép lỏng lẻo. Nhiều nhà phát triển có ác cảm với các bài học bởi các đồng nghiệp (có thể trẻ hơn), họ không thích ai đó câu cá trong ao của họ - hoặc đập phá ngai vàng của họ.

Vì vậy, như đã nói, và cũng xem xét thực tế rằng bạn có mã kế thừa ở bên cạnh mọi công ty, tôi muốn nói rằng bạn nhận được rất nhiều thứ đó trong cuộc sống thực. Những gì bạn có thể làm là cư xử như một kẻ tẩy chay: Đi vào rừng, nhặt một ít rác và dọn sạch. Lần tới bạn sẽ bớt lộn xộn hơn để bước qua.

Chào mừng bạn đến với mã với ngân sách! Có một sự khác biệt lớn khi sự phát triển được thúc đẩy bởi ban quản lý sẽ được thực hiện quá sớm, không có kế hoạch và với các góc cắt. Tôi đã có một trải nghiệm tương tự về cú sốc trong thế giới thực khi tôi có được công việc lập trình đầu tiên khi ra trường. Không có tài liệu! Theo thời gian tôi đã học được rất nhiều thời gian, viết và giữ tài liệu chính thức được cập nhật chỉ là một sự lãng phí thời gian. May mắn cho tôi, đó là một đội tuyệt vời. Nó được dẫn dắt bởi một anh chàng biết mình đang làm gì và các thành viên khác trong nhóm thực sự quan tâm đến việc viết mã đúng cách. Kể từ đó, kinh nghiệm của tôi tương tự như của bạn. Rất nhiều mã khủng khiếp, rất nhiều mã xấu, rất nhiều "nhà phát triển" không biết gì. Đối với mỗi nhà phát triển tốt, dường như có 100 người xấu.

Bạn sẽ không cam chịu ghét công việc của mình mãi mãi. Bạn chỉ cần tìm một công ty đủ thông minh để nhận ra lợi ích lâu dài sẵn sàng đầu tư một chút về phía trước. Tôi đã quản lý để chứng minh làm mọi việc đúng cách thay vì cách nhanh nhất là có lợi và đã trở nên rất được tôn trọng và tin tưởng vì điều đó tại các công ty tôi từng làm việc. Theo thời gian, mã spaghetti được sửa chữa hoặc trở nên lỗi thời và mã của bạn tiếp quản. Chỉ cần chuẩn bị để thỏa hiệp. Đôi khi cách lập trình thú vị nhất hoặc mạnh mẽ nhất chỉ là quá mức cần thiết và bạn có thể thực hiện nó một cách nhanh chóng và bẩn thỉu.

Tôi đã được thực tập với một trong những công ty phần mềm lớn

Không phải tất cả các công ty đều giống nhau. Bạn sẽ tìm thấy các nhóm crappy và cơ sở mã phần mềm crappy trong hầu hết các công ty. Nhưng bạn cũng có thể tìm thấy các đội tuyệt vời và cơ sở mã tuyệt vời.

Tôi nghĩ rằng những người ở Solaris đã mô tả rất tốt và trung thực về loại cơ sở mã mà bạn sẽ tìm thấy ở các công ty lớn: http://hub.opensolaris.org/bin/view/Community+group+on/dev_solaris

Tôi đã rời bỏ công việc ghét công việc hàng ngày cho đến nay và tôi rất muốn biết liệu đây có phải là thứ đang có trong phần còn lại của cuộc đời tôi không.

Không, tôi đã viết mã được hơn 15 năm và tôi vẫn thích nó.

Điều đó không có nghĩa là mọi thứ đều hoàn hảo. Tôi đã thấy một số cơ sở mã khủng khiếp và một số cơ sở tuyệt vời. Bí quyết là tìm đúng nơi cho bạn.

Một công ty lớn rất khác với một công ty nhỏ. Trong cùng một nhóm công ty A đôi khi là một nhóm rất khác nhau B. Tìm một nhóm có sự cân bằng phù hợp với bạn (ví dụ: các dự án đầy thách thức, một nền văn hóa mà bạn thích, lương cao, et cetera)

Chúc may mắn!

Tôi đã thấy những điều tương tự như bạn. Tôi có hai kinh nghiệm về các trường hợp khi nó xảy ra.

1. Khi phát triển quá dự án định hướng. Điều duy nhất quan trọng là cung cấp chức năng đúng hạn, sau đó đăng xuất. Thay đổi tiếp theo sẽ được thực hiện bởi người khác, bởi một số người quản lý nhóm / dự án khác với ngân sách mới.
2. Khi một phần mềm được duy trì bởi chỉ một vài người trong một khoảng thời gian dài, các nhà phát triển có xu hướng trở nên lười biếng, vì dù sao họ cũng biết phần mềm của họ. Nguyên tắc học tập là xa.

Thật đáng buồn, nhưng đó là cách nó ở một số nơi.

Xem nếu bạn có thể thực hiện một thay đổi nhỏ để tốt hơn, làm quen với nó hoặc thay đổi sang một công ty khác và yêu cầu sàng lọc một số mã tại cuộc phỏng vấn :-)

Đây sẽ là một câu trả lời ngắn.

Giáo dục là rất hữu ích để làm cho bạn cảm thấy đủ điều kiện và lý tưởng. Đây là một điều tốt, và bạn nên cố gắng giữ vững chủ nghĩa duy tâm.

Nếu bạn hoàn toàn khách quan, và bạn có thể nhìn lại công việc của chính mình trong tương lai, thì đó sẽ không phải là một kinh nghiệm rất đầy đủ. Trừ khi bạn nói dối chính mình hoặc bạn không học được gì, bạn sẽ thấy nhiều cách để cải thiện những gì bạn đã làm.

Nói chung, cả thế giới đang làm điều này xung quanh bạn. Vì vậy, khi bạn nhìn vào công việc từ quá khứ, ngoại lệ sang một bên, nó sẽ xuất hiện thấp kém và cần sự ngẫu hứng. Nếu bạn không cảm thấy như vậy, điều đó có nghĩa là bạn đang làm sai công việc hoặc trả tiền quá cao.

Tin tốt là, bạn có thể hưởng lợi từ những sai lầm của người khác và so sánh với quá khứ. Nếu tất cả các ứng dụng hoạt động tốt và dễ duy trì thì các nhà phát triển mới sẽ không được yêu cầu. Theo tôi, duy trì một số nhà phát triển khác là một kinh nghiệm học tập hữu ích và nên là một yếu tố đào tạo bắt buộc cho tất cả các nhà phát triển bầu trời xanh.

Trải nghiệm tiêu cực của bạn là quá điển hình của các công ty thương hiệu nổi tiếng lớn mà rất nhiều nhà phát triển học cách tiếp cận với sự thận trọng và lo lắng lớn hơn so với lần đầu tiên họ có cơ hội làm việc. Về cơ bản, bạn càng có nhiều lớp quản lý, càng có nhiều tầm thường. Các nhà quản lý cấp trung không báo cáo cho các nhà quản lý cấp cao về chất lượng mã. Họ báo cáo về các tính năng được phân phối trong X lượng thời gian và đưa ra các bài thuyết trình powerpoint về tính năng UI gọn gàng mà họ hy vọng sẽ hoạt động đủ lâu để giúp họ vượt qua nó. Nếu tất cả sụp đổ một tháng sau đó, đó thường là vấn đề của người khác và họ biết điều đó.

Vì vậy, có, các nhà phát triển là những người sống ở những nơi như vậy có xu hướng không quan tâm quá nhiều. Họ không thể sống sót ở đó nếu họ đã làm. Tôi đã nghe nói về Thung lũng Silicon, rằng nếu bạn muốn lười biếng, hãy làm việc cho một trong những tên tuổi lớn. Nếu bạn muốn công việc thú vị, hãy tìm một startup gần đây chưa phải là tên hộ gia đình. Tôi làm việc ở Chicago và có thể chứng minh cho một hiện tượng tương tự ở đây.

Theo nguyên tắc chung (với nhiều trường hợp ngoại lệ tôi chắc chắn), bạn sẽ thấy sự đánh giá cao hơn về mã chất lượng tại các công ty nhỏ hơn và được quản lý hoặc sở hữu bởi những người cũng tiếp tục viết mã. Việc bồi thường thường ít hơn, nhưng theo tôi thì công việc thường bổ ích hơn nhiều.

Là một nhà phát triển cấp đầu tiên, bạn không có khả năng kiểm soát nhiều người bạn làm việc lúc đầu nhưng tôi sẽ nói rằng có một tên tuổi lớn trong hồ sơ của bạn trong một năm hoặc lâu hơn chắc chắn sẽ kích thích các nhà tuyển dụng và nhân sự. Ngoài ra, bạn có thể học được khá nhiều thứ mà bạn sẽ không học nếu không làm việc cho ai đó hoàn toàn khủng khiếp trong sáu tháng đầu hoặc lâu hơn và nó cũng giúp bạn hiểu rõ hơn về những thực tiễn tốt nhất thực sự quan trọng và tại sao và những gì chỉ là công nghệ- mốt nhất thời

Và tất nhiên, khi làm việc với nhiều công cụ phổ biến chính của công ty, bạn sẽ có xu hướng thấy rằng mức độ tài năng trung bình sẽ trở nên tồi tệ. Nếu các kỹ năng chính của bạn là sự kết hợp giữa Java và C #, hãy mở rộng tầm nhìn của bạn một chút. Bạn có thể tìm thấy một phân khúc vui hơn ở cấp độ viết Erlang hoặc Python hoặc: o JavaScript.

Và đừng để ai nói với bạn điều gì khác. Bạn có thể không có lựa chọn nào trong vấn đề làm thế nào để tiến hành nhưng mã tào lao là! @ # $ Ing đắt tiền.

Câu hỏi của bạn tập trung vào thực tập. Tôi chưa bao giờ có chương trình, nhưng đã thực tập tại một đài phát thanh, không thực sự áp dụng ở đây.

Câu hỏi của bạn cũng đề cập đến kinh nghiệm của bạn trong quá trình thực tập của bạn. Kinh nghiệm thực tập của bạn và câu trả lời bạn đã nhận được cho đến nay tất cả tổng hợp khá nhiều kinh nghiệm của tôi, sau hai mươi bảy năm viết phần mềm (bắt đầu từ giữa tháng 6 năm 1985).

Tôi chưa bao giờ hoàn toàn tin vào điều đó khi đi học khi những người hướng dẫn của chúng tôi nói rằng có nhiều suy nghĩ hơn là thực sự viết mã. Họ đã đúng. Và, nếu bạn đang cố gắng tìm ra mã của người khác, điều đó còn tệ hơn khi không có bình luận và gần như tệ với các bình luận. Hãy thử duy trì một hệ thống thu thuế thành phố được trồng tại nhà mà không có ý kiến, không có tài liệu, không có bản dựng chính thức và không có kiểm soát mã nguồn.

Bất cứ khi nào bạn có thể làm tốt mà không vi phạm trực tiếp các đơn đặt hàng tiêu chuẩn, thì hãy làm tốt. Luôn nhớ rằng, xin lỗi sẽ dễ dàng hơn khi làm điều gì đó mà bạn không xin phép làm hơn là không được phép và đi ngược lại với lệnh trực tiếp.

Đừng quên các tiêu chuẩn bạn đã được dạy ở trường. Chúng không vô dụng, nhưng nhiều khả năng những tiêu chuẩn đó là sự không có triệu chứng trong giới hạn Giải tích. Bạn luôn có thể cố gắng tiếp cận họ, nhưng bạn có thể không bao giờ đạt được giá trị của họ.

Chúc may mắn.