Những thực hành cụ thể nào có thể được gọi là kỹ năng chế tạo phần mềm của Cameron, chứ không phải là kỹ thuật phần mềm của Cameron? [đóng cửa]


11

Mặc dù không phải là một ý tưởng mới , dường như đã có sự gia tăng lớn về sự quan tâm đến nghề thủ công phần mềm trong vài năm qua (đáng chú ý là cuốn sách thường được đề xuất của Clean Code là Clean Code: A Handbook of Agile Software Crafts ).

Cá nhân tôi thấy nghề thủ công phần mềm là kỹ thuật phần mềm tốt, có thêm sự quan tâm trong việc đảm bảo rằng kết quả cuối cùng là niềm vui khi làm việc (cả với tư cách là người dùng cuối và là người duy trì phần mềm đó) - và cũng tập trung hơn vào mức độ mã hóa của những thứ hơn các quy trình cấp cao hơn.

Để rút ra một sự tương tự - có rất nhiều tòa nhà được xây dựng vào những năm 50 và 60 theo phong cách rất hiện đại, điều này rất ít quan tâm đến những người sẽ sống trong đó hoặc những tòa nhà đó sẽ già đi theo thời gian như thế nào. Nhiều tòa nhà trong số đó nhanh chóng phát triển thành khu ổ chuột hoặc đã bị phá hủy từ lâu trước tuổi thọ dự kiến ​​của chúng. Tôi chắc chắn rằng hầu hết các nhà phát triển với một vài năm dưới vành đai của họ sẽ có kinh nghiệm tương tự.

Những điều cụ thể mà một người thợ phần mềm có thể làm mà một kỹ sư phần mềm (có thể là một người xấu) có thể không làm được là gì?


1
Sự tương tự dường như không phù hợp. Cả hai nghề thủ công phần mềm và công nghệ phần mềm đều có chung một mục tiêu (và được quan tâm) là cải thiện tính hữu dụng lâu dài của phần mềm.
rwong

3
Tôi nghĩ vấn đề này chủ yếu là vấn đề bạn xem "kỹ sư" hay "thợ thủ công" tiêu đề hay hơn, và những câu trả lời hiện tại dường như chứng minh điều đó. Dù sao, bất kỳ tiêu đề nào bạn thích rõ ràng đều ngụ ý rằng người đó biết họ đang làm gì.
Ben Brocka

Tôi muốn nói rằng sự khác biệt giữa hai người là một nghệ nhân làm việc một mình, một kỹ sư làm việc như một phần của một nhóm. Trong các nét rộng, điều này dường như thỏa mãn các mô tả chính của hai vai trò, không phải là có kỹ năng khác nhau mà cách tiếp cận của họ đến từ các vị trí khác nhau.
gbjbaanb

Nó chỉ giống như một tiêu đề thực sự tự phụ để cung cấp cho chính mình.
michaelsnowden

Câu trả lời:


13

Tôi muốn nói rằng sự khác biệt duy nhất giữa một chuyên gia và một nghệ nhân là chăm sóc với một chút đam mê pha trộn . Không có thực hành cụ thể, có thể quan sát nào có thể phân loại một người là thợ thủ công, mà là một bộ sưu tập các phẩm chất:

  • Một thợ thủ công quan tâm đến chất lượng thực tế của công việc của mình, và không chỉ là chất lượng cảm nhận.
  • Một thợ thủ công có hứng thú với nghề của mình vượt ra ngoài việc hoàn thành công việc, và tự nhiên hướng về nghề của mình.
  • Một thợ thủ công quan tâm đến nghề nghiệp của mình, tham vọng cải thiện kỹ năng của mình và không chỉ thăng tiến trong sự nghiệp .
  • Một thợ thủ công dành một lượng thời gian ngoài giờ làm việc được trả lương của mình (ngay cả khi đó là một khoảng thời gian nhỏ) để làm một cái gì đó với nghề của mình, có thể là thảo luận, học hỏi hoặc thậm chí nghĩ về nó.
  • Một nghệ nhân biết làm thế nào anh ta thực sự biết ít, và bị hạ thấp bởi nó.
  • Một thợ thủ công sẵn sàng dạy cho những người sẵn sàng học hỏi, hướng dẫn những người tìm kiếm sự hướng dẫn và tự mình tìm kiếm những thứ đó khi anh ta cần.

Một chút đam mê bao trùm tất cả những điều này mà không đổ mồ hôi.


Tôi nghĩ rằng cái cuối cùng đặc biệt quan trọng
Lovis

7

Cá nhân tôi thấy nghề thủ công phần mềm là kỹ thuật phần mềm tốt, có thêm sự quan tâm trong việc đảm bảo rằng kết quả cuối cùng là niềm vui khi làm việc (cả với tư cách là người dùng cuối và là người duy trì phần mềm đó) - và cũng tập trung hơn vào mức độ mã hóa của những thứ hơn các quy trình cấp cao hơn.

Như một giáo sư của tôi đã từng nói (diễn giải): "Là một kỹ sư phần mềm, công việc của bạn không chỉ là cung cấp phần mềm. Công việc của bạn là cung cấp phần mềm khiến khách hàng hài lòng."

Những điều cụ thể mà một người thợ phần mềm có thể làm mà một kỹ sư phần mềm (có thể là một người xấu) có thể không làm được là gì?

Không có gì - một kỹ sư là một thợ thủ công ... nhưng hơn thế nữa. Kỹ thuật xây dựng trên tay nghề.

Là một thợ thủ công và một kỹ sư, bạn là những cá nhân lành nghề, thông qua sự kết hợp giữa giáo dục và kinh nghiệm. Bạn làm theo thủ tục thành lập. Bạn cũng thực dụng và nhận ra những gì đã hỏng và cần phải tốt hơn.

Tuy nhiên, một kỹ sư thêm mối quan tâm về kinh tế, lý thuyết và khoa học lên trên hết. Bạn quan tâm đến việc có được lợi ích cao nhất với chi phí thấp nhất. Bạn muốn áp dụng các lý thuyết từ tâm lý học, xã hội học, quản lý, tương tác giữa người với máy tính và khoa học máy tính để giải quyết các vấn đề của bạn (cả giữa cá nhân và kỹ thuật). Và bạn chắc chắn có một nền giáo dục để sao lưu kinh nghiệm của bạn.


2
Và bạn chắc chắn có một nền giáo dục để sao lưu kinh nghiệm của mình - rất vui vì bạn đã không nói "chính thức".
treecoder

@greengit Ở nhiều nơi, để sử dụng danh hiệu "kỹ sư", bạn phải có giáo dục chính thức. Ở châu Âu, điều này có nghĩa là tốt nghiệp với bằng kỹ sư. Ý cũng thêm một yêu cầu để vượt qua một kỳ thi chứng chỉ. Ở Bắc Mỹ, Texas, Florida và Canada yêu cầu những người sử dụng danh hiệu "kỹ sư" (bao gồm cả kỹ sư phần mềm) phải vượt qua kỳ thi cấp phép.
Thomas Owens

Mặc dù điều đó không có nghĩa là ai đó không có giáo dục chính thức này không thể thực hành kỹ thuật. Họ không thể gọi mình là một kỹ sư như một chức danh chuyên nghiệp.
Thomas Owens

1
Tôi không đồng ý, một kỹ sư không nhất thiết phải là thợ thủ công.
Nicole

2
@Renesis Theo định nghĩa, kỹ thuật là một nghề. Định nghĩa về thủ công: "một nghệ thuật, thương mại hoặc nghề nghiệp đòi hỏi kỹ năng đặc biệt, đặc biệt là kỹ năng thủ công". Kỹ thuật là một nghề đòi hỏi những kỹ năng đặc biệt, do đó nó là một nghề thủ công. Tuy nhiên, đó cũng là ứng dụng của lý thuyết khoa học (trong số những thứ khác), làm cho nó nhiều hơn.
Thomas Owens

2

Phong trào chế tác phần mềm được khởi xướng để phản ứng với những thất bại và kết quả không thỏa mãn của công nghệ phần mềm "truyền thống" (cùng với sự bất cẩn của một số nhà phát triển) ngày nay dẫn đến sự mất lòng tin từ các bên liên quan và người dùng đối với nghề nghiệp của chúng tôi.

Mục tiêu của nó có hai mặt: khôi phục niềm tin vào các lập trình viên, và để làm được điều đó, nâng cao chất lượng phần mềm và kỹ năng của nhà phát triển.

Sw craft craft thúc đẩy thực hành kỹ thuật như:

  • Nguyên tắc thiết kế RẮN
  • Mẫu thiết kế
  • TDD (ẩn dụ "kế toán kép")
  • ...

Và thực hành nhóm / tổ chức:

  • Lập trình cặp
  • Kèm cặp
  • Mã katas
  • Dojos / rút lui mã
  • ...

Vì vậy, tôi muốn nói rằng sự khác biệt giữa 2 là rõ ràng: nghề thủ công phần mềm cố gắng giải quyết một phần lớn các vấn đề mà công nghệ phần mềm đã tồn tại hơn 40 năm qua mà ngày nay khiến ngành học của chúng ta trông không đáng tin cậy và bị tê liệt với lịch sử thất bại.


1
Tôi không đồng ý - lý do kỹ thuật phần mềm thất bại là vì nó không có kỹ sư, chỉ có thợ thủ công giả làm kỹ sư. NASA đã không gửi tàu vũ trụ lên mặt trăng bằng cách sử dụng thợ thủ công!
gbjbaanb

@gbjbaanb Tôi nghĩ điều đó hoàn toàn ngược lại - chúng tôi đã có các kỹ sư và đó là lý do tại sao họ cố gắng giải quyết một mô hình kỹ thuật truyền thống và tư duy từ các ngành công nghiệp khác vào phần mềm, nhưng nó không hoạt động.
guillaume31

Tàu vũ trụ không được làm bằng những thứ vô hình có thể được tu sửa, tái thiết kế và triển khai lại nhiều lần. Các luật mà họ tuân theo phần lớn khác với các chương trình phần mềm.
guillaume31

Tàu con thoi có các tên lửa đẩy có thể triển khai, ít nhất, và không nghi ngờ gì về việc sử dụng lại các bit (hoặc ít nhất là kiến ​​thức) từ các tên lửa trước đó. Và tàu vũ trụ có rất nhiều phần mềm trong đó. Tôi không nghĩ rằng họ bắt đầu từ đầu với mọi vệ tinh hoặc đầu dò mới và hầu như không bao giờ áp dụng các bản cập nhật một khi được triển khai. Kỹ thuật phần mềm có thể và rõ ràng có thể hoạt động - nhưng chỉ khi bạn tiếp cận nó với tư duy của một kỹ sư, không phải là thợ thủ công.
gbjbaanb

Vui lòng xác định "tư duy của kỹ sư", trong ngữ cảnh của phần mềm.
guillaume31

1

Đi bằng http://manifesto.softwareccraft Skill.org/ Tôi sẽ rút ra được những điều sau đây.

Một thợ thủ công khác với nhận thức truyền thống về một "kỹ sư" bởi vì

  • Họ tập trung vào giá trị, không chỉ đáp ứng yêu cầu.
  • Họ tập trung vào chất lượng ngay cả trong phong cách mã của họ, không chỉ đáp ứng yêu cầu.
  • Họ tham gia vào cộng đồng phát triển phần mềm rộng lớn hơn, không chỉ nơi làm việc của họ.
  • Họ không hiểu rằng tình trạng nghệ thuật ngày nay là rác rưởi vào ngày mai, họ chủ động đưa nó về cấp độ này hay cấp độ khác.
  • Nó không chỉ là một công việc, đó là những kẻ đang .

4
Thành thật mà nói, tất cả những gạch đầu dòng đó mô tả một kỹ sư giỏi. Đặc biệt là 1, 2 và 4.
Thomas Owens

@ThomasOwens Còn kỹ sư xấu thì sao? Có phải ông cũng là một thợ thủ công? Hoặc tốt so với thợ thủ công xấu?
Euphoric

@Euphoric Tôi không nghĩ bạn có thể là một kỹ sư giỏi mà không phải là một thợ thủ công giỏi. Nó giống như một sân khấu. Bạn phải đạt được "thợ giỏi" trước khi bạn đạt được "kỹ sư giỏi". Tuy nhiên, bạn có thể là một thợ thủ công giỏi và không phải là một kỹ sư giỏi.
Thomas Owens

1

Chú Bob bằng cách nào đó ám chỉ rằng lập trình là một ngành học rất trẻ chưa có luật pháp hoặc quy tắc ổn định được công nhận bởi chính phủ (hoặc đó là Frederick Brooks?). Tôi không đưa ra một trích dẫn verbatin ở đây.

Bạn không thể thu hồi bất cứ ai giấy phép lập trình do sơ suất. Lập trình thiếu một bộ luật và quy tắc hơn là được thực thi một cách hợp pháp bởi luật phù hợp với một "nghề". Một bác sĩ giết chết một bệnh nhân do không đủ năng lực và anh ta mạo hiểm với chức danh bác sĩ hoặc sự cho phép của anh ta.

Một lập trình viên tạo ra một chương trình lỗi hoặc làm cho một dự án thất bại do không đủ năng lực và anh ta có thể tự do tiếp tục lập trình.

Tôi nghĩ đó là khá nhiều những gì làm cho lập trình thủ công. Một nhà sản xuất nồi đất sét không làm cho hai nồi giống hệt nhau. Bạn cũng chưa từng nghe nói về một nhà sản xuất nồi đất sét buộc phải thu hồi những chiếc nồi bị lỗi. Lập trình vẫn là một công việc rất thủ công, cá nhân. Đôi khi bạn thậm chí có thể nói ai đã viết một đoạn mã đánh giá theo phong cách của nó.


0

Tái cấu trúc các mẫu.

Đó là, xây dựng một cái gì đó đáp ứng 90% yêu cầu phần mềm, sau đó cấu trúc lại toàn bộ dự án thành một thiết kế thanh lịch, sạch sẽ.

Thông thường, công nghệ phần mềm sẽ ngăn bạn thực hiện điều này, bởi vì đáp ứng 90% yêu cầu có nghĩa là phần mềm có đủ giá trị kinh doanh cho khách hàng mà không nên sửa đổi theo bất kỳ cách quan trọng nào (ngoại trừ các lỗi có mức độ ưu tiên cao).

Kỹ thuật phần mềm thay vào đó sẽ khuyên bạn ổn định phần mềm vào thời điểm này.

Hơn nữa, nếu một dự án không bắt đầu với thiết kế thanh lịch đó ngay từ đầu, nó sẽ được coi là một dự án được thực hiện kém (bất kể kết quả của dự án), theo kỹ thuật phần mềm.

Giải pháp tăng đột biến.

Một thiết kế được lấy cảm hứng từ một giải pháp tăng đột biến thường không được chấp nhận theo phương pháp kỹ thuật phần mềm hiện hành.

Khấu hao , vì lý do gì.

Trong công nghệ phần mềm, mọi loại khấu hao chỉ được phép xảy ra khi kết thúc vòng đời của hệ thống phần mềm. Điều này phải được lên kế hoạch như một phần của SDLC.

Trong thực tế, điều khá phổ biến là những thiếu sót của một phần cụ thể của giao diện phần mềm được phát hiện vài năm sau khi sản xuất và phần cụ thể đó có thể được loại bỏ ở giữa vòng đời, mà không làm mất hiệu lực phần còn lại của phần mềm. Điều này sẽ yêu cầu chứng nhận lại toàn bộ hệ thống phần mềm sau khi khấu hao, theo kỹ thuật phần mềm.

Cuối cùng, nghề thủ công phần mềm là một nỗ lực cá nhân để đánh giá tốt từ các cá nhân, trong khi công nghệ phần mềm là một cơ quan tri thức bảo thủ. Cho phép đánh giá tốt vào việc ra quyết định của dự án là điều tách biệt sự khéo léo của phần mềm với công nghệ phần mềm.


-1

Tôi có thể nói rằng các bài kiểm tra đơn vị bao gồm 100% mã sẽ là một bài kiểm tra tốt. Vì điều đó cho phép những thứ dư thừa bị tước đi.

Đôi khi tôi so sánh sự phát triển phần mềm với điêu khắc. Đó không phải là những gì bạn thêm vào, đó là những gì bạn lấy đi.

Rõ ràng bạn có thể đi quá xa. Không ai sẽ nói một viên sỏi nhỏ sáng bóng là một tác phẩm điêu khắc tốt: S


3
Làm thế nào sáng bóng chúng ta đang nói về ở đây? :-)
Chris

1
Hầu hết thời gian tôi đồng ý với điều này - nhưng tôi không chắc chắn 100% nghiêm ngặt luôn có giá trị - ví dụ: getters / setters nơi họ không có logic. Mã được tạo cũng thường tốt hơn bên trái mà không cần kiểm tra đơn vị (mặc dù các thử nghiệm tích hợp có thể phù hợp)
FinnNk

@FinnNk - tôi đồng ý. Gần đây tôi đã sử dụng dotCover và điều đó nói rằng getter / setter được bảo hiểm nếu nó được sử dụng trong một thử nghiệm khác. Vì vậy, tôi thực sự không có nghĩa là một phương pháp thử nghiệm cho mỗi getter & setter
Antony Scott
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 cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.