Lập trình viên có thể học được gì từ ngành xây dựng? [đóng cửa]

Khi nói chuyện với các đồng nghiệp về các nguyên tắc thiết kế và phát triển phần mềm, tôi đã nhận thấy một trong những nguồn phổ biến nhất cho các chất tương tự là ngành xây dựng. Chúng tôi xây dựng phần mềm và chúng tôi coi thiết kế và cấu trúc là kiến trúc .

Một trong những cách tốt nhất để học (hoặc dạy) là thông qua việc phân tích các chất tương tự - những gì tương tự khác có thể được rút ra từ xây dựng? (cho dù đã được sử dụng phổ biến trong phần mềm hay chưa).

Vui lòng cung cấp một mô tả hoặc kinh nghiệm cá nhân của bạn, liên quan đến cách khái niệm lập trình tương tự như khái niệm xây dựng.

^{[Tín dụng cho các khái niệm lập trình được lấy từ nghệ thuật và nhân văn cho ý tưởng]}

Đó là nơi mà các mẫu thiết kế đến từ.

Người được cho là đã giới thiệu khái niệm này với thế giới là Christopher Alexander trong cuốn sách "Ngôn ngữ mẫu: Thị trấn, Tòa nhà, Xây dựng" năm 1977 . Từ đó, Gang of Four (GoF) nhặt nó lên , và phần còn lại là lịch sử.

Ngay cả bây giờ trong các bài giảng và trong phát triển phần mềm và sách kiến ​​trúc tương tự giữa thế giới xây dựng và thế giới phát triển phần mềm vẫn chiếm ưu thế.

Một số tương tự và tài liệu tham khảo tôi có thể nghĩ hoặc nhớ lại:

• Ví dụ, việc thay đổi các yêu cầu trong quá trình xây dựng một tòa nhà có lẽ sẽ trở nên rõ ràng hơn đối với khách hàng về việc điều này thật vô lý, ví dụ: "OH, và tôi muốn có một nhà để xe thay vì nơi nhà bếp bạn vừa hoàn thành".
• Các công cụ hỗ trợ tạm thời như giàn giáo (nghĩa là trong thế giới xây dựng | phát triển phần mềm )
• Khách hàng không thể tiếp tục thêm các tính năng mà không phải trả phí, nhiều lần họ muốn mọi thứ được thực hiện miễn phí và đôi khi chúng tôi đủ ngu ngốc để chấp nhận; Điều đó không thể xảy ra trong thế giới xây dựng (xem yêu cầu leo ).
• Các vai trò trong phát triển phần mềm: kiến ​​trúc sư là trung tâm của việc thiết kế giải pháp; tư vấn và nhà thầu có thể được hoán đổi cho nhau; các công nhân là những lập trình viên.
• Khách hàng không thể cung cấp các yêu cầu chính xác trong cả hai trường hợp.
• Ngân sách và ước tính thời gian thường sai.
• Sản phẩm không thể thực sự được nhìn thấy ở dạng thật cho đến khi kết thúc .
• Một tòa nhà có thể có lỗi xây dựng sau khi được xây dựng, cùng một cách phần mềm có lỗi .
• Nếu sản phẩm được thực hiện kém, đôi khi nó có thể phá hủy và bắt đầu lại hơn là sửa chữa nó.
• Không biết về kết quả thực tế và thực tế của công việc chất lượng kém, khách hàng muốn giải pháp rẻ nhất .
• Nguồn mở . Tôi chỉ xem cuộc nói chuyện này từ Doc Searls có tên " Tại sao tất cả doanh nghiệp sẽ dựa trên nguồn mở " nơi anh ấy nói về cách cộng đồng xây dựng chia sẻ các kỹ thuật và kiến ​​thức chung thay vì cấp bằng sáng chế cho họ giống như cộng đồng nguồn mở, ngay cả khi một số thứ trong các tòa nhà chứa các sản phẩm độc quyền tích hợp.
• Dự án bật ra tốt hơn cho mọi người nếu khách hàng tham gia tích cực .

(Nếu có nhiều ý tưởng, tôi sẽ thêm chúng.)

Có một số người không nghĩ rằng sự tương tự chung là chính xác, một cách đọc được khuyến nghị cho điều này là Tương tự xây dựng phần mềm bị hỏng . Ngoài ra, có một câu hỏi về điều này trên SO có tiêu đề Có gì sai với sự tương tự giữa phần mềm và xây dựng công trình? .

Chúng tôi đã lấy rất nhiều từ ngữ và ý tưởng từ ngành xây dựng trong suốt lịch sử phát triển phần mềm và trên thực tế có lẽ chúng tôi đã thực hiện với nhiều người và tôi không nghĩ còn gì để làm.

Chúng tôi đã thực hiện toàn bộ quá trình để khách hàng đưa ra một đặc điểm kỹ thuật, sau đó lên kế hoạch kiến ​​trúc sư, sau đó là các kỹ sư thiết kế và cuối cùng là những con khỉ thực hiện từ ngành xây dựng, và hóa ra nó hoàn toàn sai lầm.

Điều này là bởi vì khi bạn xây dựng một ngôi nhà, nếu nền tảng của bạn sai, bạn bị ảnh hưởng. Nghiêm túc thực hiện. Để nâng một tòa nhà và thay thế nền móng của nó tốn nhiều chi phí hơn là tháo dỡ toàn bộ và bắt đầu lại. Nhưng trong phần mềm thì hoàn toàn có thể. Tôi đã làm lại phần mềm máy khách thành giải pháp máy chủ-máy khách mà không cần người dùng nhận thấy bất cứ điều gì, ngoại trừ việc tôi đã chuyển modem sang phòng máy chủ. Điều đó giống như thay thế nền móng bê tông bằng một chiếc thuyền trong khi cư dân đang ngủ.

Phần mềm không giống như xây dựng. Và đó là lý do tại sao toàn bộ ngành công nghiệp phần mềm đã khởi đầu một thời gian bắt đầu các vụ án và toàn bộ quá trình "thác nước" của các dự án đang chạy đã được thay thế bằng các quy trình nhanh chỉ trong vài năm.

Đối với các từ nhiều được lấy từ xây dựng, đúng và sai.

Khung là rõ ràng nhất chưa được thực hiện. Và có đường ống .

Tôi đã sử dụng sự tương tự này ... rất nhiều dự án phần mềm bắt đầu bởi vì người cần một số phần mềm biết tương đương với "người siêng năng" và họ thuê người này xây dựng cho họ phần mềm tương đương với một khu vườn. Đây là một ứng dụng nhỏ, hữu ích, hoạt động rất tốt.

Sau đó, khách hàng quay lại với người siêng năng, hài lòng với công việc của họ và yêu cầu họ thay đổi phần mềm để làm thêm một việc nữa. Rất nhiều lần, tính năng mới này không liên quan nhiều đến yêu cầu ban đầu, vì vậy, gần giống như họ đang yêu cầu bạn xây một phòng khác ở phía sau khu vườn có một lối đi riêng.

Sau đó, họ muốn đặt một ánh sáng bên trong nhà kho, để họ có người siêng năng trở lại, và anh ta chạy một mạch từ bảng điều khiển chính trong nhà, lắp đặt một công tắc đèn kéo ở trần của mỗi phòng và kết nối chúng với mạch .

Sau đó, khách hàng quyết định họ muốn chạy một số công cụ điện, nhưng nó tiếp tục thổi bộ ngắt mạch, vì vậy họ gọi lại cho người đó và anh ta thực sự phải rút ra một mạch đơn mà anh ta chạy đến bảng điều khiển chính, và cài đặt một dây dẫn lớn hơn và một bảng phụ trong nhà kho. Ông đã phải chạy dây hai lần và trả tiền cho hai giấy phép điện, v.v ... Điều này không hiệu quả.

Sau đó, khách hàng yêu cầu một điều vô lý: bạn có thể biến khu vườn của tôi thành nhà để xe không? Tôi không muốn bạn làm lại bất cứ điều gì bạn đã làm ... Tôi chỉ muốn bạn làm cho nó lớn hơn để tôi có thể đỗ xe ở đó. Sau đó, trong rất nhiều trường hợp, người siêng năng nghĩ rằng "khách hàng luôn luôn đúng" và tiến hành xây dựng bổ sung vào 3 bên của nhà kho để làm cho nó lớn hơn, đánh sập bức tường giữa các vách ngăn, v.v ... Tất nhiên, mái nhà kết thúc lên xuống vì nó không được xây dựng đúng, v.v.

Vì vậy, khách hàng không còn ấn tượng nữa, nhưng họ vẫn muốn nhiều hơn nữa. Họ yêu cầu người siêng năng lặp đi lặp lại chỉ cần thêm một phòng, hoặc thay đổi căn phòng hiện có này để làm điều này, v.v. Bạn kết thúc với một cái gì đó trông giống như The Burrow và giống như âm thanh kiến ​​trúc.

Bây giờ hầu hết mọi người không đủ ngớ ngẩn để thử điều này trong thế giới xây dựng, nhưng nó xảy ra mọi lúc trong thế giới phần mềm, bởi vì mọi người không tạo ra các kết nối này:

1. Một người đủ điều kiện để xây dựng một khu vườn thực sự tốt đẹp không nhất thiết phải đủ điều kiện để xây dựng một ngôi nhà.

2. Nếu bạn biết trước rằng bạn sẽ xây dựng một ngôi nhà theo từng giai đoạn, nhưng nó sẽ chỉ bắt đầu như một khu vườn, bạn sẽ làm những việc khác và nhà vườn sẽ tốn nhiều tiền hơn (bạn sẽ đổ miếng đệm thực sự dày, đảm bảo bạn chạy một dây dẫn đủ lớn cho toàn bộ tải trọng của một ngôi nhà đã hoàn thành, v.v.).

3. Trong rất nhiều trường hợp, việc nâng cấp từ giai đoạn này sang giai đoạn khác liên quan đến việc hoàn tác rất nhiều công việc đã được thực hiện trước đó, khiến nó trở nên đắt hơn so với nó có vẻ như nó phải như vậy.

4. Trong thế giới xây dựng, chúng tôi có thể cung cấp cho khách hàng một ý tưởng tốt về kết quả sẽ như thế nào trong giai đoạn thiết kế, nhưng chúng tôi không có khả năng đó trong thế giới phần mềm. Nếu bạn hiểu điều đó, về cơ bản bạn đã viết một phần đáng kể của phần mềm.

Tuyên ngôn Agile là kết quả của việc thừa nhận rằng sự tương tự phần mềm / xây dựng bị hỏng. Những thứ như kiểm tra đơn vị tự động và chu kỳ phát hành lặp không có song song trong xây dựng. Những điều này tận dụng chi phí gần như bằng không để đi từ thiết kế đến nguyên mẫu (chúng tôi gọi nó là biên dịch hoặc xây dựng).

Các điều khoản Kết thúc công việc và Trim đến với tâm trí.

Ý tưởng rằng việc chấp nhận một số lựa chọn thẩm mỹ là ổn khi hoàn thành các quyết định cơ cấu chính.

Một câu ngạn ngữ cũ: Đo hai lần và cắt một lần.

Chỉnh sửa: Có một phần trong Bản kê khai Danh sách kiểm tra của Atul Gawande, nói về việc quản lý các công việc xây dựng lớn. Khi họ đến một điểm thực sự phức tạp, họ có một cuộc họp với các chuyên gia liên quan để xem xét lại vấn đề và xem có bất cứ điều gì trong dự án xảy ra mà mọi người nên biết không. Chúng tôi có lẽ không thể lập kế hoạch cho họ trước.

Hạn chế tồn tại cả trong xây dựng và lập trình .

Nếu bạn là khách hàng không thể đưa ra những yêu cầu lố bịch như mở rộng một tòa nhà khách sạn đã hoàn thành vào cuối tuần và đặt một sân bay vào tầng ngầm và một đường băng trên căn hộ của nó, tại sao bạn không thể chấp nhận rằng không phải tất cả điều chỉnh với hoàn thành phần mềm có khả thi không? Nó không phải là một quả bóng ma thuật 0 và 1, nó là một cấu trúc xây dựng phức tạp, tuy phi vật chất nhưng cũng có những hạn chế.

Tôi đã làm việc trong ngành xây dựng thông qua trường học và có những nơi thậm chí không giống nhau, khái niệm tương tự được áp dụng. Nhưng thông thường, sự cám dỗ so sánh đi quá xa.

Khi tôi làm việc trên một ước tính cho một công việc, tôi biết có trung bình khá vững chắc về thời gian để làm một cái gì đó. Ví dụ, để chế tạo cửa sổ cửa hàng, chúng tôi chỉ cần đếm số lượng khớp trong các khung từ các kế hoạch và có một ý tưởng khá hay là sẽ mất bao lâu. Cũng giống như lập trình, chúng tôi phải tính đến các biến trong lịch trình mặc dù điều đó có thể hút cuộc sống của bạn. Ví dụ: có một đội ống nước xuất hiện để thấy rằng bãi đậu xe đang được lát và họ không thể vào tòa nhà vì đường nhựa nóng trên đường khá đắt.

Tuy nhiên, xây dựng có hàng ngàn năm kinh nghiệm để rút kinh nghiệm. Các quy tắc cơ bản của thương mại được thúc đẩy bởi cùng các định luật vật lý mà chúng luôn luôn có. Tải trọng gió và tính toán tải trọng chết giống như khi chúng được thực hiện với các quy tắc trượt. Những cải tiến về công cụ và kỹ thuật đã xuất hiện, nhưng với tốc độ chóng mặt so với những gì chúng ta trải nghiệm.

Mặt khác, chúng tôi vẫn đang khám phá ra rằng nhiều mô hình và thực tiễn của chúng tôi cần có chỗ để cải tiến. Singleton từng là một ý tưởng hay, bây giờ hầu hết mọi người nghĩ về nó đều thích các mẫu IoC / DI.

Trường hợp chúng ta cũng thiếu là cấp phép và chứng nhận có ý nghĩa. Trong nhiều lĩnh vực, ngay cả khi chỉ là thợ sửa chữa, hãy để một người lắp đặt, thợ sửa ống nước phải được cấp phép hoặc làm việc dưới sự giám sát của một người nào đó. Để có được giấy phép đó đòi hỏi một lượng thời gian nhất định làm việc trong lĩnh vực này. Tôi không làm cho trường hợp hoặc chống lại việc cấp phép, chỉ nêu ra vì đó là một sự khác biệt rất lớn.

Tất nhiên trong cả hai lĩnh vực, một kiến ​​trúc sư có thể vẽ một cái gì đó không thể thực hiện được.

Giàn giáo , "một cấu trúc tạm thời được sử dụng để hỗ trợ con người và vật liệu trong việc xây dựng hoặc sửa chữa các tòa nhà và các cấu trúc lớn khác." ^{[định nghĩa từ wikipedia]}

Khái niệm này hoạt động vì một giàn giáo trong lập trình có thể nhanh chóng được tạo ra và cung cấp chức năng tạm thời cho đến khi cấu trúc thực sự được đưa ra.

Tôi biết một số công ty xây dựng làm việc với người trả giá thấp nhất, làm công việc cẩu thả, trốn tránh những gì nên làm nhiệm vụ bảo hành, tập trung vào ngày qua chất lượng và sau đó tính lợi nhuận vô lý cho sản phẩm "hoàn thành".

Nhưng tôi không nghĩ các lập trình viên hoặc các cơ quan tư vấn đã học được gì từ những thực tiễn đó.

Lỗi có thể trở nên đắt đỏ như địa ngục, hoặc thậm chí giết người?

Có các hướng dẫn cơ bản cho các dự án kỹ thuật phức tạp của bất kỳ ngành nào:

1. tầm quan trọng của quy hoạch, bản in màu xanh, thiết kế, vv,
2. tầm quan trọng của toán học cơ bản
3. tái sử dụng ý tưởng / học hỏi từ các dự án tương tự khác
4. sử dụng các khối / thành phần xây dựng sẵn do người khác xây dựng
5. sửa chữa các vấn đề rất sớm trong vòng đời
   , vv

Điểm tương đồng giữa các ngành kiến ​​trúc, dân dụng và kỹ thuật phần mềm dường như chủ yếu xuất phát từ việc không có dây chuyền lắp ráp : mỗi dự án là duy nhất theo cách riêng của nó.

Tăng ca

Nhưng trong ngành xây dựng, công nhân được trả lương ngoài giờ.

Sử dụng các tiêu chuẩn, quy ước và các thành phần được xây dựng trước. Bạn không có khả năng gặp phải loại vấn đề này.

Tôi không thể tìm thấy bất cứ điều gì trên thị trường phù hợp với ổ cắm được xây dựng tùy chỉnh của chúng tôi.

Khi tất cả những gì bạn có là một cái búa, mọi thứ trông giống như một cái đinh. :)

Chấn thương căng thẳng lặp đi lặp lại

Chúng là một mối nguy hiểm nghề nghiệp trong cả hai ngành và phải có biện pháp phòng ngừa để ngăn chặn chúng. Một khi chúng bắt đầu, chúng rất khó chữa.