Tôi có ý tưởng sai về công nghệ phần mềm không? [đóng cửa]

Tôi có một câu hỏi đã được đưa ra bởi công việc mới nhất của tôi (chứ không phải thực tập).

Chỉ cần đặt mọi thứ vào bối cảnh - Tôi 21 tuổi và tôi đã hoàn thành năm thứ 2 đại học trước đó, tôi đã có khoảng 2 năm kinh nghiệm làm các công việc quản trị / quản trị hệ thống và về cơ bản tôi có thể nói rằng tôi đã thấy sự khác biệt Lĩnh vực CNTT hoạt động. Chuyển sang thời điểm hiện tại và đây là một công việc thực tập tại một trong những tổ chức nghiên cứu hàng đầu ở Anh.

Những gì tôi phải làm là tạo ra một số công cụ nội bộ bằng cách sử dụng hỗn hợp các công nghệ - chủ yếu là AWS / Java / Bash - bạn sẽ có được hình ảnh. Mọi thứ đều ổn, tôi đang làm việc NHƯNG tôi không vui. Tại sao vậy - bởi vì tôi dự kiến ​​sẽ làm việc trong một vấn đề đặc biệt. Đó là tạo ra mọi thứ một cách nhanh chóng, không mất thời gian vào thiết kế. Người quản lý của tôi nói rõ ràng rằng nó được dự kiến ​​sẽ "vượt qua" các vấn đề khi chúng phát sinh và về cơ bản chúng tôi. Kết quả là hóa ra mọi thứ phải được thực hiện lại và tái thiết kế và chúng vẫn chưa hoàn hảo. Theo như thử nghiệm có liên quan - giữ nó ở mức tối thiểu, miễn là nó hoạt động thì nó vẫn ổn.

Tôi có lỗi khi không đồng ý với cách tiến hành công việc này không? Có sai không khi nghĩ về toàn bộ hệ thống, sau đó tập trung vào các thành phần khác nhau và xem chúng có thể hoạt động như thế nào, đến 0 trong các "điểm chính" khác nhau có thể trở thành vấn đề trong tương lai? Có phải là một tội ác khi muốn làm một công việc tốt và không phải là một "công việc nhanh chóng"? Có phải là một sai lầm hoặc thái độ sai lầm khi muốn nghiên cứu các cấu trúc dữ liệu áp dụng cho một vấn đề để bạn có thể chọn phương án tốt nhất tùy thuộc vào một vấn đề cụ thể không? Theo hiểu biết của tôi, bit "Kỹ thuật" trong "Kỹ thuật phần mềm" phải thực hiện chính xác với điều này - nghiên cứu miền vấn đề của bạn và đưa ra giải pháp thông tin sau đó tinh chỉnh khi cần thiết?

Tôi đã từng đến một cuộc phỏng vấn tại văn phòng của Arm ở Anh và họ chỉ cho tôi phòng SCRUM của họ và có vẻ như họ có ý tưởng khá hay về cách quản lý dự án của họ - họ đã tồn đọng, họ có số liệu về thời gian mỗi lần vấn đề có thể cần giải quyết - những điều thông thường đối với SCRUM - hoàn toàn khác với cách mọi thứ được vận hành "ở đây"

Tôi đã xây dựng một ý tưởng sai về ngành công nghiệp phần mềm nói chung? Tôi muốn nghe ý kiến ​​của bạn về điều đó. Ý tôi là tôi "nhập" phát triển phần mềm hoàn toàn vì tôi muốn tạo ra mọi thứ - đơn giản và đơn giản, nhưng tôi muốn tạo ra những thứ chất lượng. Tôi muốn xem phần mềm của mình được sử dụng trong các tình huống khác nhau, tôi muốn xem phần mềm chống đạn - đó không phải là động lực cho tất cả các kỹ sư phần mềm? Tôi nghĩ mọi người đều có thể trở thành lập trình viên / lập trình viên chỉ bằng cách học cú pháp nhưng đối với tôi, nơi niềm vui thực sự bắt đầu là khi bạn thực sự phải đưa ra một thiết kế có thể thực hiện được trong thế giới thực.

Tôi đã từng làm bài tập đại học của mình bằng cách chỉ nhìn vào chúng và trực tiếp bắt đầu viết mã và có thể dễ dàng đạt điểm trên 75% và không bao giờ thực sự đánh giá cao mô-đun "vòng đời phát triển phần mềm". Nhưng bây giờ khi tôi thấy trong thế giới thực, việc làm việc tồi tệ như thế nào nếu không có bất kỳ quy trình chính thức nào và sự thất vọng vốn có trong tình huống mà bạn không biết liệu các yêu cầu sẽ thay đổi vào ngày mai (ồ, tôi đã nói rằng chúng ta không 't đã xác định rõ phân tích yêu cầu?)

Tôi thực sự muốn tin rằng tôi vừa đạt được một vị trí mà một số người chỉ cần một con khỉ mã để thực hiện công việc bẩn thỉu của họ và đây không phải là trường hợp thế giới phần mềm hoạt động rộng lớn.

Làm cho phần mềm có thể sử dụng lại và bằng chứng đạn không phải là động lực của công nghệ phần mềm. Kỹ thuật là giải quyết các vấn đề trong thế giới thực một cách tối ưu trong các ràng buộc của thế giới thực . Hầu hết các kỹ sư thích làm việc trên Ferrari - nhưng một toa xe ga cần nhiều kỹ thuật và lý do một toa xe ga không hoạt động tốt (theo một số cách) là do các hạn chế thiết kế khó khăn hơn, không phải do kỹ thuật kém hơn .

Khi bạn nói rằng bạn muốn làm một "công việc tốt" chứ không phải là "công việc nhanh chóng", hầu hết các kỹ sư đều làm, nhưng đôi khi một phần của những gì định nghĩa tốt là việc hoàn thành nhanh như thế nào. Vì vậy, không đúng khi nghĩ "tốt" và "nhanh" là những lựa chọn đối nghịch. Hoặc nghĩ rằng bạn đang làm một công việc tồi tệ, hoặc chỉ là một "con khỉ mã", để làm công việc tốt nhất có thể trong thời gian có sẵn.

Tất nhiên, hoàn toàn có thể là quy trình không tối ưu và sẽ làm tốt hơn với một chút thiết kế phía trước. Thử nghiệm axit sẽ là, cách làm hiện tại đang tạo ra nhiều vấn đề hơn là giải quyết cho người dùng , hay chỉ là làm phiền các nhà phát triển phải làm việc theo cách đó? Nếu nó thực sự gây ra vấn đề cho người dùng, một phần công việc của bạn là cố gắng chứng minh rằng đây là trường hợp và cố gắng thu hút mọi người qua một quy trình được kiểm soát hơn một chút.

Thật ra, điều này làm phiền tôi. Bạn đang ở một nghề mà bạn phát triển các công cụ cho các nhà khoa học nghiên cứu, đúng vậy. Tuy nhiên, bạn được yêu cầu làm cho các chương trình này nhanh chóng và chúng có vẻ hoạt động tối thiểu. Bất ngờ bất ngờ. Đây chỉ đơn giản là cách tiếp cận điển hình của nhà nghiên cứu về lập trình với sự biến đổi thành một lập trình viên thực tế.

Mối quan tâm chính ở đây là việc thiếu kiểm tra nói riêng có thể bị nghi ngờ về mặt đạo đức nếu các công cụ có mục đích quan trọng. Nếu người ta không chắc phần mềm có lỗi vì một phần bị giới hạn trong thời gian thử nghiệm tối thiểu, điều này có nghĩa là KHÔNG ai chịu trách nhiệm với điều kiện làm việc của phần mềm và Atlas nhún vai.

Hãy dừng lại và suy nghĩ về điều này trong một giây. Bạn đang phát triển loại công cụ nào? Nếu bạn đang phát triển phần mềm mô hình hóa dữ liệu, sẽ có một vấn đề nan giải về đạo đức lớn ở đây. Trong một số tình huống, nghiên cứu khoa học dẫn đến các quyết định ảnh hưởng đến rất nhiều người trên quy mô lớn.

Giả sử ngay lập tức, chủ đề gây tranh cãi về biến đổi khí hậu nhân tạo. Giả sử họ đặt các tiêu chuẩn giống nhau trên phần mềm mô hình mà họ sử dụng để đi đến kết luận họ có ngày hôm nay. Chủ đề có tác động lớn đến cách chúng ta tiếp cận quản lý chính xác môi trường và chính sách quốc tế.

Có phải là không đạo đức để đảm bảo rằng phần mềm mô hình hóa không có vấn đề lớn với dự đoán của nó?

Toàn bộ vấn đề không phải là khí nhà kính làm ấm trái đất. Vấn đề là liệu kết quả ròng của các hiệu ứng phản hồi có phải là sự gia tăng nhiệt độ hay không, mà sau khi phá vỡ một ngưỡng sẽ không còn có thể đảo ngược.

Nếu cho biết mức tăng đã xảy ra, bằng chứng về kết quả ròng sẽ không đáng kể, có thể nằm trong phạm vi sai lầm.

Vì vậy, tính toán sai lầm nhỏ, thậm chí phương pháp liên quan đến lưu trữ và truy xuất dữ liệu ở mặt sau, có thể dẫn đến việc bỏ qua một vấn đề môi trường nghiêm trọng ở một đầu của sự thất bại, hoặc chính sách quốc tế ảnh hưởng đến nhiều người (phá hủy công việc, phá hủy lương hưu, v.v. ) mặt khác.

Vì vậy, vâng, bạn đúng. Tôi không quan tâm tốc độ nghiên cứu là gì ... Nếu các nhà nghiên cứu muốn dựa vào các công cụ phần mềm để quản lý dữ liệu và thực hiện các tính toán cho họ, họ cần học cách chờ đợi phần mềm được thực hiện đúng. Mặt khác, phần mềm này trở thành một điểm dễ bị tổn thương trong lý thuyết của họ rằng họ không chịu trách nhiệm, dẫn đến hành vi sai trái về đạo đức.

Bạn không có ý tưởng sai về kỹ thuật phần mềm là gì. Tuy nhiên, bạn đang thiếu một khía cạnh rất quan trọng của nó: đây là một ngành dịch vụ. Một số người trong chúng ta đã làm việc trên một sản phẩm trong nhiều năm, và trải qua thiết kế và sau đó nhiều lần lặp lại trước khi nó ở v1. Những người khác phải sản xuất một cái gì đó trong 3 giờ. Nó phụ thuộc vào người bạn phục vụ và mục đích là gì.

Nếu bạn có thể tạo một ứng dụng trong 3 giờ (hoặc ngày), đó là những gì nó có nghĩa là làm, tại sao lại dành nhiều thời gian hơn cho nó để thiết kế trước? Bạn đang lãng phí tiền bạc. Lãng phí tiền nói chung là không có ý tưởng tốt ™.

Như những người khác đã nói, một phần lớn của công nghệ phần mềm là gì về "những hạn chế bên ngoài". ví dụ. Thời gian, ngân sách, dịch vụ, hỗ trợ, đáp ứng nhu cầu ngu ngốc phi lý, v.v.

Rất nhiều người trong chúng tôi (bao gồm cả tôi) đã nghĩ đến việc lập trình nghĩ rằng đó là tất cả về chính chương trình - mã hóa các phần mềm đẹp và thanh lịch trong chân không (hoặc ít nhất là chân không tương đối). Nó hiếm khi là. Có thể có một số công việc phần mềm học thuật hoặc R & D hiếm hoi gần với nó, nhưng phần lớn, phần lớn công việc phát triển phần mềm không giống như vậy. Đặc biệt là trong giai đoạn bảo trì - thường là 90% + tuổi thọ của sản phẩm - và thói quen hàng ngày của bánh mì và bơ của hầu hết các phần mềm thương mại vĩnh viễn.

Trong một thời gian dài, tôi đã có một cuộc xung đột nội bộ về điều này thường khiến tôi không hài lòng về công việc của mình (và đó là một phần của những gì cuối cùng dẫn đến sự kiệt sức vào năm ngoái). Tôi luôn cảm thấy rằng một công việc tệ hại nếu đó không phải là tất cả về việc tạo mã đẹp và dành thời gian để thực hiện nó một cách chính xác. Nhưng thực sự, đây là thực tế - và một số người thực sự phát triển mạnh về một luồng công việc rất hướng đến dịch vụ. Đó là những gì làm cho họ cảm thấy thực dụng và hữu ích. Ngay cả khi các khía cạnh "công nghệ phần mềm thuần túy" thực sự của một dự án trở nên tương đối vội vàng và cẩu thả.

Dù sao, thật tốt khi bạn đang đặt câu hỏi này. Đây là một trong những điều mà họ không bao giờ thực sự giải thích đúng ở trường. Và các công ty thích giả vờ rằng họ tuân theo các thực hành kỹ thuật rất tốt ngay cả khi họ không làm như vậy. Gợi ý: hầu hết không.

Tất cả những gì đã nói, mọi thứ khác nhau. Một số công ty (chủ yếu là những người mà phần mềm là ngành kinh doanh cốt lõi của họ và những người làm việc trên các phần mềm quan trọng an toàn cao như thiết bị y tế) thực hiện theo một quy trình kỹ thuật rất nghiêm ngặt. Nhưng nhìn chung, vâng, tôi sẽ nói với bạn ngay bây giờ rằng hầu hết các phần mềm thương mại hoạt động tương đối cẩu thả. Thường có một số quy trình chính thức, nhưng tuân thủ nghiêm ngặt hầu như luôn luôn có chỗ dựa để phản ứng với đầu vào của khách hàng và các áp lực thương mại khác. Nó không thực sự "chậm chạp" mỗi se, nó chỉ là sự hữu dụng thực tế đơn giản. Bí quyết là tìm ra thị trường ngách của bạn và xem xét vai trò từ quan điểm từ dịch vụ mà nó cung cấp, thay vì khía cạnh "lập trình thuần túy" của nó tuyệt vời như thế nào.

EDIT : Tôi nghĩ rằng tôi có thể nghe có vẻ quá phiến diện trong đánh giá ban đầu của tôi. Tôi muốn nói thêm rằng thường có đang còn là vấn đề chính hãng với những thứ là quá cẩu thả và thiếu của quá trình tốt - đến điểm mà nó lái xe dự án vào nợ kỹ thuật và thực sự là xấu cho doanh nghiệp. Nhưng nhìn thấy điều này đi kèm với kinh nghiệm. Điểm ban đầu về cơ bản vẫn đứng vững: hầu hết các phần mềm thương mại ngày nay không theo định hướng kỹ thuật cứng nhắc như những người theo chủ nghĩa thuần túy có thể thích.

Thật là một câu hỏi xuất sắc! Đôi khi bạn có thể làm cho một cái gì đó có giá trị bằng cách nhanh chóng . Đây thường là trường hợp trong một phòng thí nghiệm nghiên cứu nơi chúng ta có thể học những gì chúng ta không biết càng nhanh, chúng ta sẽ càng có lợi. Phần mềm bạn sản xuất tồn tại chỉ để trả lời câu hỏi. Đó là "vứt mã". Đây cũng là trường hợp với những người khởi nghiệp không biết khách hàng thực sự muốn gì. Ngoài ra, lần đầu tiên bạn làm một cái gì đó, nó sẽ là crappy. Đọc Tháng huyền thoại .

Đôi khi bạn có thể làm cho một cái gì đó có giá trị bằng cách tốt . Đây thường là trường hợp với phần mềm thu nhỏ như Adobe Photoshop. Nghiên cứu đã được thực hiện từ nhiều năm trước và bây giờ câu hỏi là làm thế nào để thêm danh sách các tính năng mà khách hàng muốn theo cách không giới thiệu lỗi. Đó là một vấn đề về kiến ​​trúc, thiết kế, và thử nghiệm, thử nghiệm, thử nghiệm. Bản thân mã là những gì có giá trị, không phải những gì bạn học được từ nó.

Nếu bạn không hài lòng với nghiên cứu (thực hiện điều đầu tiên, học những điều mới mà trước đây không ai biết) thì hãy thử phần mềm thu nhỏ. Trên thực tế, ở tuổi của bạn, bạn nên thử càng nhiều thứ càng tốt. Đi mạo hiểm! Bạn sẽ học được rất nhiều và bạn sẽ tốt hơn về lâu dài.

Tôi nghĩ rằng bạn đã nhận thấy rất sớm trong sự nghiệp của mình rằng làm mọi thứ nhanh chóng, không có thiết kế phù hợp hoặc thử nghiệm thích hợp, có xu hướng quay lại cắn bạn. Bạn rõ ràng không thích điều này và bạn có lý do chính đáng để không. Thật nực cười khi dự kiến ​​sẽ "vượt qua các vấn đề", đặc biệt là nếu bạn phải xem lại chúng sau này khi các giải pháp ban đầu không chính xác hoặc không đầy đủ. Bạn chỉ có thể cung cấp giải pháp cho các vấn đề nếu bạn hiểu chúng hoàn toàn, và điều đó cần có thời gian và kế hoạch cẩn thận.

Đề nghị của tôi cho bạn là để cho cấp trên của bạn biết rằng điều này làm phiền bạn và đề nghị với họ một cách tiếp cận tốt hơn để thực hiện công việc của bạn. Nếu họ không đồng ý và muốn bạn tiếp tục "vội vàng" trong công việc, tôi sẽ bắt đầu tìm việc ở nơi khác. Không có ý nghĩa trong việc thực hiện mọi thứ theo cách không theo tiêu chuẩn của riêng bạn, chứ chưa nói đến một tiêu chuẩn về chất lượng phát triển phần mềm mà ngành công nghiệp mong đợi.

Đây là lời khuyên của tôi dựa trên kinh nghiệm của tôi, tôi 20 tuổi và hiện đang làm việc cho tổ chức tài chính lớn ở Anh và có cùng cảm xúc với bạn vài tháng trước, điều tôi nhận thấy là điều này có thể là do bản chất của công việc bạn đang làm

Ý tôi là gì khi bạn nói:

Những gì tôi phải làm là tạo ra một số công cụ nội bộ bằng cách sử dụng hỗn hợp các công nghệ - chủ yếu là AWS / Java / Bash Bash

Tôi cũng đã phải tạo ra các công cụ nội bộ để giúp quản lý và tự động hóa một số quy trình nhất định và thực tế là trong một môi trường có nhịp độ nhanh, những điều nhỏ bé bắt buộc phải thực hiện nhanh chóng. Tôi không có hứng thú áp dụng hầu hết các kỹ thuật phần mềm hoặc thuật toán và nguyên tắc cấu trúc dữ liệu mà tôi đã được dạy vào năm thứ 2 bởi vì một phiên bản hoạt động của công cụ được yêu cầu trong vài tuần. Tôi rất thất vọng với điều này tuy nhiên nó đã bị không tệ như tôi đã học cách viết mã dễ đọc hơn.

Tôi đã phải kiên nhẫn và gần đây tôi đã chuyển sang một nhóm mới đang làm việc với một hệ thống xây dựng nội bộ mới được sử dụng bởi người dùng 10K + và tôi có thể đảm bảo với bạn rằng khía cạnh kỹ thuật phần mềm của nó được thực hiện rất nghiêm túc. Tôi đã được thông báo rằng tôi sẽ đạt được tiếp xúc với vòng đời phần mềm hoàn chỉnh từ việc nắm bắt / phân tích các yêu cầu cho đến khi thực hiện và thử nghiệm. Tôi tin rằng tôi sẽ có được trải nghiệm này vì tôi không làm việc trên các công cụ nội bộ nhưng tôi đang làm việc trên một hệ thống quy mô đầy đủ với lượng người dùng lớn.

Điều tôi khuyên là bạn hãy kiên nhẫn, hoàn thành việc tạo ra các công cụ và hoàn thành công việc thật tốt để người giám sát của bạn có thêm niềm tin vào bạn và giao cho bạn những nhiệm vụ khó khăn hơn đòi hỏi phải sử dụng các nguyên tắc kỹ thuật phần mềm. Có thêm kiến ​​thức từ việc đọc thêm và áp dụng kiến ​​thức đó vào những gì bạn đang làm, tôi nhớ việc lục soát toàn bộ thư viện sách điện tử tại công ty chỉ để hiểu thêm về muhahah, từ tất cả những cuốn sách tôi đọc tôi cảm thấy rằng java hiệu quả cuốn sách thực sự tốt đã giúp tôi rất nhiều.

Chỉ cần kiên nhẫn, đầu tư mạnh vào kiến ​​thức của riêng bạn và áp dụng kiến ​​thức đó nếu có thể. Nếu bạn đang làm một công việc rất tốt sẽ có người sớm nhận ra.

Tôi đồng ý rằng cách thức hoạt động của công việc hiện tại của bạn là tối ưu, vâng. Tuy nhiên, nếu bạn muốn nói rằng nó hoàn toàn không hoạt động, tôi không đồng ý với bạn ở đó vì có nhiều kết quả khác nhau và tổ chức vẫn còn ở đó.

Câu hỏi chính của tôi cho bạn là bạn đang xử lý các đám cháy ở mức độ nào cần các giải pháp tức thời được thực hiện nhanh chóng tương tự như cấp cứu cho bệnh nhân y tế so với các yêu cầu có thể được thiết lập như các dự án và được xử lý ở quy mô khác với bệnh nhân y tế phải lên lịch kiểm tra và các thủ tục khác nhau không cần thiết phải làm ngay lập tức nhưng trong thời gian tới.

Dành thời gian để hoàn thành tốt công việc phụ thuộc một chút vào sự trưởng thành của tổ chức cùng với tầm quan trọng của việc hoàn thành công việc so với yêu cầu được thực hiện.

Câu hỏi về nghiên cứu cấu trúc dữ liệu là bao lâu bạn muốn làm điều này. Nếu bạn muốn mất một thập kỷ để nghiên cứu một cấu trúc dữ liệu hoàn toàn khác với việc muốn một vài giờ. Mặc dù tôi có thể đánh giá cao mong muốn có được câu trả lời tốt nhất, nhưng có một điều cần nói về việc giảm lợi nhuận sau khi dành thời gian cho một vấn đề, ví dụ bạn có thể dành hàng giờ để tìm giải pháp cho FizzBuzz vì bạn có thể cố gắng giải quyết bằng nhiều ngôn ngữ khác nhau phần cứng khác nhau để tối ưu hóa nó có thể chạy nhanh như thế nào.

Trong khi nó có thể quan trọng để nghiên cứu, nó cũng quan trọng để cung cấp một cái gì đó. Nếu bạn không cung cấp một cái gì đó, bạn thực sự tốt như thế nào? Lập trình viên băng keo sẽ là một ví dụ về việc hoàn thành công việc ở đây.

Scrum là một phương pháp cụ thể mà bạn có thể cố gắng áp dụng tại nơi làm việc hiện tại của bạn. Đừng nghĩ Scrum là một viên đạn bạc. Theo những trường hợp nào các dự án có thể thất bại trong Scrum và Agile? sẽ là một bài viết trên blog về chủ đề đó có thể được quan tâm.

Tôi đoán là bạn sẽ không thấy các quy trình của địa điểm hiện tại của bạn không chính thức như thế nào và nghĩ rằng cỏ sẽ xanh hơn rất nhiều ở phía bên kia nơi có một phương pháp chính thức. Trong khi nó có thể tốt hơn ở đó, một số người có thể thích những gì bạn có bây giờ với sự tự do to lớn là một cao bồi .

Tôi nghĩ rằng tình hình của bạn vẫn ở quy mô Real World theo hướng ít chú trọng hơn vào khía cạnh chất lượng. Sở thích của bạn là ở phía bên kia của thế giới thực. Thông số kỹ thuật thay đổi, vượt qua nó. Những điều cần phải được thực hiện.

Xem xét các cách để xác định các loại công ty này khi bạn áp dụng cho công việc tiếp theo của bạn. Rất ít nơi có một mô hình kinh doanh mà họ có thể đủ khả năng để các nhà phát triển phân tích thiết kế của họ mãi mãi (Ngay cả các giáo sư cũng phải dạy.). Khách hàng hiếm khi trả tiền nếu công việc của bạn không rời khỏi bảng xóa khô. Ghét khi thấy bạn tự làm mình phát điên sớm như vậy trong sự nghiệp.