Phần mềm có sử dụng lại ngăn chặn quá trình lặp lại không

Mã tái sử dụng là một vấn đề

Tôi đã suy nghĩ về câu hỏi này về phân phối phần mềm và tôi tiếp tục quay trở lại vấn đề về độ lặp lại và / hoặc độ tái lập . Chúng quan trọng, bởi vì nếu bạn không lặp lại một dự án thì việc cải thiện quy trình bạn sử dụng để xây dựng dự án sẽ trở nên khó khăn hơn. Kỹ thuật liên quan đến việc liên tục cải tiến các quy trình liên quan đến thiết kế và xây dựng để tạo ra các dự án chất lượng cao hơn.

Phần mềm có thể phụ thuộc rất nhiều vào việc tái sử dụng do hình thức kỹ thuật số của nó. Thay vì viết lại một mô-đun, chúng tôi chỉ cần gọi lại hoặc sao chép nó sang hệ thống khác. Một số ví dụ là xác thực / đăng nhập hoặc có lẽ là một chức năng đăng nhập. Có nhiều ví dụ nổi tiếng cho các loại đó, và sự khôn ngoan thông thường là sử dụng lại những gì tồn tại thay vì tự lăn.

Một số so sánh với các ngành khác

Xây dựng

Ngược lại, việc xây dựng các hệ thống vật lý (tòa nhà, cây cầu) không nơi nào có thể tái sử dụng. Đúng là bản thiết kế của một ngôi nhà có thể được tái sử dụng nhiều lần để xây dựng cùng một bản sao của ngôi nhà, nhưng việc xây dựng phải được thực hiện mỗi lần. Cắt và dán không hoạt động như thế trong thế giới tương tự. Bản thiết kế cầu ít sử dụng lại nhà ở vì điều kiện địa điểm sẽ thay đổi.

Các nhà xây dựng chính là các chuyên gia được công nhận vì đã thiết kế và / hoặc xây dựng hàng chục, hàng trăm hoặc hàng ngàn thứ trong khu vực của họ. Ví dụ, Frank Lloyd Wright , một kiến ​​trúc sư và nhà thiết kế nổi tiếng thế giới designed more than 1,000 structures and completed 532 works. Trái ngược với với Anders Hejlsberg , người đã thiết kế ra năm ngôn ngữ của Hồi giáo (Turbo Pascal; Delphi; J ++; C #; Typecript). Theo nhiều cách, đó là một so sánh không công bằng vì các tên miền là khác nhau. Nhưng ở cấp độ rộng, sản xuất có thể định lượng từ hai người rất thông minh là rất khác nhau.

Võ thuật

Các võ sĩ sẽ nói rằng việc làm chủ một động tác chỉ đến từ hàng ngàn lần lặp lại. Sau khi một phần tốt của những lần lặp lại đó được đưa vào, nhiều võ sĩ ngạc nhiên khi thấy một kata hoặc hình thức phức tạp trước đây trở nên đơn giản. Giáo viên hướng dẫn của những sinh viên đó cũng sẽ nhận thấy làm thế nào chuyển động trở nên trôi chảy và có mục đích hơn cũng như có một nền kinh tế của chuyển động. Tương tự như vậy, các võ sĩ giàu kinh nghiệm có thể nhận được các thanh katas phức tạp nhanh hơn các học sinh ít kinh nghiệm hơn. Kinh nghiệm từ sự lặp lại đã cho họ một khuôn khổ hoặc quy trình cho phép họ học nhanh hơn.

Chế biến gỗ

Thợ gỗ trải qua một sự chuyển đổi tương tự. Thợ mộc sở thích luôn quay trở lại dự án đầu tiên của họ đòi hỏi rất nhiều ngăn kéo. Nếu họ hoàn thành dự án, họ sẽ đạt được sự đánh giá cao mới về hiệu quả mà dây chuyền lắp ráp tạo ra. Có những lợi ích khác như hiểu rõ hơn về cách bố trí các bộ phận ngăn kéo trên tấm gỗ để tối đa hóa việc sử dụng gỗ. So với những người có sở thích, thợ gỗ chuyên nghiệp có thể nhanh chóng thiết kế, bắt đầu và xây dựng các vật phẩm mà họ đã thực hiện nhiều lần trước đây. Họ cũng có khả năng nhìn thấy các vấn đề cố hữu trong thiết kế của người khác đã mắc phải sai lầm đó trong công việc của họ.

Vì vậy, việc tái sử dụng phần mềm có ngăn cản các nhà phát triển phần mềm trở nên thành thạo hơn không?

Theo nhiều cách, thiết kế và xây dựng phần mềm luôn luôn mới. Chúng tôi không lặp lại các công việc trong quá khứ, bởi vì nếu chúng tôi có thể sử dụng lại một mô-đun, thư viện hoặc hệ thống thì chúng tôi sẽ làm. Chúng tôi ưu tiên mở rộng một hệ thống hiện có trước khi viết lại toàn bộ từ đầu. Nhưng sự lặp lại là những gì cho phép chúng tôi tìm thấy hiệu quả trong thiết kế và xây dựng. Bất cứ ai đã luyện tập một môn thể thao hoặc hoạt động thể chất sẽ nói với bạn rằng sự lặp lại là chìa khóa để trở thành một học viên giỏi.

Câu hỏi của tôi: Khả năng được sử dụng lại của phần mềm có ngăn cản sự cải thiện quy trình và hiệu quả cần thiết đến từ việc lặp lại một dự án không?

Khả năng tái sử dụng phần mềm không ngăn cản cải tiến quy trình.

Nếu bạn nghĩ về các quy trình xây dựng phần mềm - phát triển các yêu cầu, thiết kế hệ thống, triển khai hệ thống, triển khai hệ thống, quản lý yêu cầu, quản lý cấu hình, xác minh và xác thực sản phẩm công việc, theo dõi các thay đổi và một số khác (xem Các khu vực xử lý CMMI cho một sự cố có thể xảy ra đối với các hoạt động chính trong phát triển phần mềm) - những điều này được lặp lại trên mỗi dự án bất kể bạn có bao nhiêu lần sử dụng lại. Ngoài ra, mỗi loại có một số loại biện pháp định lượng và định lượng có thể được sử dụng để xác định quá trình hoặc hoạt động cụ thể đó tốt như thế nào và kết quả là toàn bộ quá trình phát triển tốt như thế nào.

Cuối cùng, chúng ta có thể giả sử một dòng sản phẩm phần mềm mạnh mẽ. Mặt khác, bạn có thể giả định phát triển trường xanh. Vẫn cần phải thực hiện tất cả các quy trình này, ở các mức độ khác nhau, mặc dù chúng có thể xảy ra ở các mức độ khác nhau hoặc thậm chí ở các trình tự khác nhau. Ví dụ, với số lượng tái sử dụng cao, phần lớn thời gian được phân bổ có thể được dành cho các hoạt động tích hợp và xác minh / xác nhận ở cấp hệ thống (yêu cầu V & V, kiểm tra tích hợp, kiểm tra hệ thống, kiểm tra chấp nhận). Với những nỗ lực phát triển mới, phần lớn thời gian có thể được yêu cầu khi thiết kế và thực hiện. Miễn là bạn thực hiện một quy trình ít nhất một lần trong suốt quá trình của dự án, bạn có thể đo lường nó (định lượng và định tính). Khi bạn thực hiện điều chỉnh và xem những điều chỉnh đó ảnh hưởng đến một số biện pháp của khu vực quy trình hoặc khả năng tổng thể để cung cấp phần mềm,

Chìa khóa để cải tiến quy trình là có một số loại phân tích logic các hoạt động và quy trình của bạn, xác định cách đo lường chúng (tốt nhất là nhất quán) và cách hiểu các phép đo đó để thay đổi quy trình theo hướng kết thúc. Đó không phải là về việc lặp lại dự án, mà là về sự nhất quán trong cách bạn lặp lại quy trình.

Tôi nghĩ rằng các ngành kỹ thuật khác không sử dụng tái sử dụng là sai. Ngay cả khi thiết kế các tòa nhà / máy móc, bạn vẫn có các thành phần được sử dụng bởi nhiều dự án khác. Ví dụ, bạn có thiết kế ốc vít của riêng bạn? Động cơ? Cửa ra vào hay cửa sổ? Tất nhiên là không. Những người thường được thiết kế bởi những người khác nhau sau đó sử dụng chúng trong các sản phẩm khác nhau. Và chúng thường được tiêu chuẩn hóa, điều này thúc đẩy việc tái sử dụng nhiều hơn.

Tôi nghĩ rằng vấn đề thích phức tạp. Bạn chỉ đơn giản là không thể so sánh sự phức tạp của ngay cả những tòa nhà phức tạp nhất với phần mềm phức tạp. Đó là một ý tưởng thường được chấp nhận rằng sự phức tạp của phần mềm là điều khiến nó khó tiếp cận từ phía kỹ thuật. Thời điểm bạn có một quy trình tại chỗ cho phép bạn tạo ra phần mềm có chất lượng chấp nhận được, bạn thấy rằng sự phức tạp của phần mềm bạn cần để tạo ra các bước nhảy theo thứ tự độ lớn. Vì vậy, quá trình không thể được sử dụng. Vì vậy, nếu chúng tôi phải lặp lại một số phần mềm nhiều lần cho đến khi chúng tôi hài lòng với kết quả, chúng tôi sẽ không bao giờ hoàn thành phần mềm đó.

Đó là lý do tại sao mã sạch được quảng bá. Khả năng thay đổi mã quá khứ dựa trên kinh nghiệm mới có thể nói là hình thức tái sử dụng thiết kế. Vì vậy, thay vì tạo ra các phần mềm khác nhau nhiều lần, chúng tôi tái cấu trúc và tinh chỉnh một phần mềm duy nhất bằng cách sử dụng lại các trải nghiệm mới và thiết kế cho các vấn đề cũ. Tất cả trong khi cố gắng làm cho phần mềm làm điều tương tự.

Phần mềm là khác biệt so với hầu hết các lĩnh vực khác, vì vậy kinh tế của nơi mà chúng tôi dành tốt nhất thời đại chúng ta thường khác.

Trong xây dựng, bạn dành một số tiền nhất định của thời gian và tiền bạc vào một kế hoạch chi tiết (và phần mềm là xa hơn như sản xuất một kế hoạch chi tiết hơn như xây dựng một tòa nhà), sau đó, nói đại khái, nhiều hơn cả trên thực tế việc xây dựng nó một hoặc nhiều lần. Vì vậy, nó là giá trị nó để đặt khá nhiều công việc để có được bản thiết kế đúng. Cụ thể hơn cho câu hỏi của bạn - đáng để lặp lại nỗ lực làm lại từ đầu để làm cho sản phẩm cuối tốt hơn một chút.

Trong phần mềm, khi bạn có bản thiết kế, việc xây dựng sản phẩm sẽ rẻ hơn nhiều so với việc tạo bản thiết kế. Ít nhất là hầu hết thời gian - nếu phần mềm sẽ được nhúng vào máy điều hòa nhịp tim, bạn sẽ gần gũi hơn với tình huống của một người xây dựng cầu theo một số cách. Nhưng nói chung, việc sử dụng lại phần mềm có thể tiết kiệm 90% chi phí cho mục ngân sách lớn nhất của bạn, so với tiết kiệm 90% cho mục ngân sách nhỏ hơn nhiều để xây dựng cây cầu. Vì vậy, sử dụng lại chiến thắng thường xuyên hơn rất nhiều.

Theo như năng suất - khi bạn xây dựng, nói, một cây cầu, bạn phải đối mặt với những hạn chế trong thế giới thực. Hãy tưởng tượng nếu các kiến ​​trúc sư được trả một khoản tiền lớn để thiết kế cầu cho các trò chơi trực tuyến nhiều người chơi, trong đó chi phí xây dựng gần bằng 0 và giới hạn ít hơn đáng kể so với thế giới thực. Họ sẽ thiết kế những cây cầu phức tạp đến kỳ lạ theo tiêu chuẩn cầu thực tế. Giai đoạn kế hoạch chi tiết có thể mất một chút thời gian.

Ngoài ra, có một số lượng cầu hạn chế để xây dựng, và, vì thiết kế là một phần nhỏ của chi phí, bạn có thể trả tiền tốt nhất, và một vài trong số tốt nhất có thể làm hầu hết thiết kế. Có hàng trăm ngàn nhà phát triển phần mềm và về cơ bản tất cả họ đều tồn đọng một lượng lớn những việc họ sẽ làm nếu có thời gian. Bạn sẽ không tìm thấy một anh chàng nào làm phần lớn tất cả những điều đó - thật đáng ngạc nhiên khi có những người đến gần, thực sự.

Quan điểm thực sự của bạn dường như là chúng ta có thể đang mất thứ gì đó bằng cách sử dụng lại thay vì cố gắng lặp lại và cải thiện mọi thứ. Tôi nghĩ rằng bạn có một điểm. Vấn đề là mặc dù rất có thể sẽ hiệu quả hơn trên toàn cầu để viết lại một số nội dung nền tảng và cố gắng cải thiện nó, bất cứ ai chấp nhận điều đó đều nhận được tất cả rủi ro và có lẽ không nhiều phần thưởng. (Ngoài ra còn có một vấn đề thực tế rất lớn về địa ngục phụ thuộc, có lẽ sẽ lấy đi một phần thắng trong việc viết lại, nhưng không đến mức nó sẽ không đáng giá, ít nhất là nhìn vào bức tranh toàn cầu. Bản quyền và bằng sáng chế cũng có thể buộc một nỗ lực tái thiết kế được đề xuất cắn đứt khá nhiều công việc viết lại để làm lại các đoạn mã nhỏ hơn hiện có).

Về mặt học hỏi từ sự lặp lại - trong tất cả các lĩnh vực này xảy ra ít hơn trong thiết kế so với xây dựng, bởi vì có là ít lặp lại, vì vậy ít có cơ hội để tìm hiểu, và lợi ích có lẽ ít hơn. Ngoài ra, quá trình thiết kế có lẽ không thể lặp lại. Nó giống như có một quá trình để viết một cuốn tiểu thuyết. Một quy trình tốt gần như chắc chắn có thể giúp ích, và phần mềm thường hợp tác hơn nhiều so với tiểu thuyết, nhưng việc lặp lại một quy trình khi mục tiêu là phát minh ra thứ gì đó mới là vấn đề. Ngay cả các tiểu thuyết gia cũng học được từ quá khứ, rất nhiều, nhưng một quá trình lặp lại là yếu tố phụ cho nỗ lực sáng tạo. Và nếu bất kỳ phần nào của phát triển phần mềm thực sự có thể lặp lại, tại sao máy tính không làm điều đó?

Khả năng được sử dụng lại của phần mềm có ngăn cản sự cải thiện quy trình và hiệu quả cần thiết đến từ việc lặp lại một dự án không?

Tôi đã làm việc như một kỹ sư hệ thống và phần mềm trong cùng một dự án lớn trong 17 năm qua, tình cờ (nghĩ đến tài liệu tham khảo Airbus A380 trong liên kết đầu tiên của bạn) trong ngành công nghiệp máy bay, mặc dù trách nhiệm của tôi thuộc về lĩnh vực máy bay quân sự. Những câu chuyện như thế về cơ bản là hư cấu thuần túy, và thực sự rất buồn cười khi xem khi bạn có cái nhìn sâu sắc bên trong.

Nhưng đối với câu hỏi ngắn gọn và súc tích của bạn: Từ kinh nghiệm của tôi, tôi sẽ nói cả có và không.

Trước tiên, hãy nói rằng tôi là tất cả để tái chế phần mềm dưới mọi hình thức (tốt, có thể không phải tất cả ...). Những lợi ích của việc tái sử dụng bất cứ thứ gì, từ các đoạn mã và thuật toán cắt và dán, cho đến toàn bộ mô-đun mã và thư viện hàm, tốt hơn nhiều so với việc luôn bắt đầu lại từ đầu (để đẩy nó một chút).

Nhược điểm là, như bạn chỉ ra (hoặc ít nhất là suy ra), rằng khi bạn thêm chức năng bằng cách đơn giản kết hợp một bộ các thành phần nhất định (và, vâng, tôi đơn giản hóa điều này đến mức cực đoan), bạn không thực sự phát triển như một lập trình viên, kỹ sư hoặc bất cứ điều gì.

Chỉ cần nhìn vào các kỹ sư phần mềm xung quanh tôi làm việc, tôi biết từ kinh nghiệm lâu năm mà phần lớn trong số họ không biết, và tệ hơn - không có hứng thú tìm hiểu, bất cứ điều gì về sản phẩm chúng tôi đang xây dựng ngoài mức tối thiểu mà họ cần để sản xuất tài liệu hoặc đoạn mã mà họ được chỉ định làm.

Tôi đang quay cuồng một chút về chủ đề ở đây, nhưng quan điểm của tôi là khi các lập trình viên không cần phải học mã mà họ đang xây dựng sẽ thực sự được sử dụng để làm gì và không cần phải học các hoạt động bên trong của hệ thống vì họ chỉ có thể tái sử dụng các thành phần đã được viết và thử nghiệm, sau đó hầu hết chúng sẽ không bận tâm để làm như vậy.

Cấp, điều này cũng là do các trường hợp khác, chẳng hạn như sản phẩm chúng tôi đang xây dựng cực kỳ phức tạp và không ai có thể tìm hiểu về tất cả (và tôi chỉ nói về một trong những máy tính trong máy bay - một trong những phức tạp nhất trong số họ, nhưng vẫn còn).

Nếu các kỹ sư phần mềm của chúng tôi không có tùy chọn sử dụng lại nhiều mã, tôi tin chắc rằng họ sẽ trở nên tốt hơn trong nghề nghiệp nói chung và tài sản lớn hơn nhiều cho dự án.

Ồ, và bạn có thể nhận thấy rằng tôi nói về họ rất nhiều ở đây. Tôi tất nhiên cũng bao gồm trong số các kỹ sư phần mềm. Trường hợp ngoại lệ là tôi dường như tò mò và ham học hỏi những điều mới hơn những người khác :-) Khi phải đối mặt với một nhiệm vụ mới, tôi luôn tự mình tìm hiểu về nó nhiều nhất có thể hình thức của sự kiện và bằng cách nghiên cứu mã nguồn (vâng, tôi thực sự cũng thích điều đó).

À - dang, lại bị theo dõi một lần nữa ... Lý do của tôi là tôi đã không ngủ trong 32 giờ, vì vậy khả năng tập trung của tôi là một chút ... tôi đang nói gì vậy?

Nếu bất cứ ai vẫn đọc, kết luận của tôi là:

Có , việc sử dụng lại quá nhiều phần mềm làm cho các kỹ sư phần mềm ít hiểu biết hơn, điều này làm cho chúng kém hiệu quả hơn khi họ thực sự cần biết cách thức hoạt động của công cụ. Phân tích vấn đề là một ví dụ tốt, hoặc thậm chí chỉ có thể biết liệu một giải pháp thiết kế được đề xuất có khả thi hay không. Và tất nhiên, cải tiến quy trình cũng khó đạt được hơn khi bạn không thực sự biết mình đang làm gì :-)

và Không , việc sử dụng lại phần mềm một cách cẩn thận , có khả năng giúp bạn có nhiều thời gian rảnh rỗi để xem xét và lên kế hoạch cải tiến quy trình.

Như đã chỉ ra trong câu trả lời được chấp nhận trong một câu hỏi khác của Lập trình viên, các phép tương tự với xây dựng sẽ được thực hiện cẩn thận:

một cách đọc được đề nghị cho điều này là Tương tự xây dựng phần mềm bị hỏng

phần mềm thường được ví như xây dựng. Thật không may, sự tương tự này là thiếu sót và bài học kinh nghiệm từ ngành xây dựng là nghi ngờ ...

Những gì tôi quan sát được là, các dự án phần mềm tốt "chuyển" rất nhiều tính lặp lại thành đảm bảo chất lượng.

Khi tôi là người thử nghiệm trong dự án dài 1,5 năm, chúng tôi chạy các chu kỳ thử nghiệm tại các bản phát hành "điểm kiểm tra" hàng tuần, tổng cộng khoảng 70 lần thông qua dự án. Đó là ... khá lặp lại, nói nhẹ nhàng (không có nhiều thứ thay đổi trong một tuần). Thử nghiệm các bản dựng hàng đêm, một cách tự nhiên, thậm chí có thể lặp lại nhiều hơn - khoảng 500 lần thông qua dự án (một vài lỗi showstopper giải trí quá hiếm để tạo ra sự khác biệt).

Bây giờ, theo sự tương tự "nghi ngờ" đó, hãy cho tôi biết một công ty xây dựng đã xây dựng 500 cây cầu - tất cả đều có cùng một đội.

• Theo dõi nó thêm, cho tôi biết một công ty đã sử dụng hầu hết các loại gạch và sắt giống nhau ở mỗi cây cầu mới của họ (ở đây, tôi đề cập đến thực tế là các bản phát hành mà chúng tôi đã thử nghiệm có hầu hết các bit mã từng ngày, từng tuần tuần - "không có nhiều thứ thay đổi").
  

Các nhà xây dựng chính là các chuyên gia được công nhận vì đã thiết kế và / hoặc xây dựng hàng chục, hàng trăm hoặc hàng ngàn thứ trong khu vực của họ.

Tốt thôi, theo dõi lời giải thích của bạn về độ lặp lại được trích dẫn ở trên, tôi có thể nói như vậy là gì? Trước đó, nhóm thử nghiệm nhỏ, không đặc biệt của chúng tôi đã xác minh, xem ở trên ("khoảng 500") hàng trăm thứ trong khu vực của chúng tôi.

Đối với các nhà phát triển dự án, họ đã xây dựng theo nghĩa đen ("xây dựng hàng đêm") - hãy xem, từ này giống nhau và ý nghĩa là đúng trong bối cảnh này - hàng trăm thứ trong khu vực của họ.

Nếu người ta muốn tiếp tục sự tương tự "nghi ngờ" đó lên đến "hàng ngàn thứ", thì những khoản tiền này, một lần nữa, không có gì ngoạn mục trong phát triển phần mềm khi người ta nhìn vào những điều đúng đắn.

• Một ví dụ, một dự án trước đây của tôi (một lần nữa, không có gì ngoạn mục, khá thường xuyên), lần này trong vai trò nhà phát triển, đã diễn ra được hơn 5 năm (8 bản phát hành chính, vài chục bản nhỏ). Có các điểm kiểm tra hàng tuần tương tự ( 5x52~=250trong số chúng), các bản phát hành hàng đêm tương tự ( 5x365~=1800trong số chúng) và tương tự, các nhóm dev / QA tương tự làm việc trên các nhóm này. Ngày qua ngày, tuần này qua tuần khác, tháng này qua tháng khác, chủ yếu là những thứ lặp đi lặp lại (không thay đổi nhiều giữa hai bản dựng hàng đêm) - như đã hứa, trong phạm vi hàng ngàn lần (1800).

Các dự án tồn tại lâu hơn như Windows hoặc Java hoặc AutoCAD có thể kéo dài 10, 20, 30 năm, dễ dàng lặp lại nhiều lần "hàng ngàn" bản dựng hàng đêm và các bài kiểm tra hàng đêm.

Khái niệm về sự lặp lại chuyển sang QA càng trở nên nổi bật hơn với tích hợp liên tục ...

thực tiễn ... về việc hợp nhất tất cả các bản sao làm việc của nhà phát triển với dòng chính được chia sẻ nhiều lần trong ngày ... CI có thể được coi là một sự tăng cường thực hành tích hợp định kỳ ..

Ngoài các thử nghiệm đơn vị tự động, các tổ chức sử dụng CI thường sử dụng máy chủ xây dựng để thực hiện các quy trình liên tục áp dụng kiểm soát chất lượng nói chung - những nỗ lực nhỏ, được áp dụng thường xuyên. Ngoài việc chạy các bài kiểm tra đơn vị và tích hợp, các quy trình này còn chạy các bài kiểm tra tĩnh và động bổ sung, đo lường và hiệu suất hồ sơ, trích xuất và định dạng tài liệu từ mã nguồn và tạo điều kiện cho các quy trình QA thủ công. Việc áp dụng kiểm soát chất lượng liên tục này nhằm cải thiện chất lượng phần mềm và giảm thời gian cung cấp phần mềm , bằng cách thay thế cách áp dụng kiểm soát chất lượng truyền thống sauhoàn thành mọi sự phát triển. Điều này rất giống với ý tưởng ban đầu về việc tích hợp thường xuyên hơn để tích hợp dễ dàng hơn, chỉ áp dụng cho các quy trình QA ...

Lặp lại? Nó ở ngay đó, nhiều như nó có thể nghĩ.

Với QA thường xuyên / liên tục, những điều không ổn sẽ nhanh chóng quay trở lại với các nhà phát triển, những người buộc phải lặp lại các nỗ lực để thực hiện đúng cho đến khi thất bại trong các thử nghiệm vượt qua. Theo một nghĩa nào đó, chu kỳ lặp lại cho đến khi nó vượt qua giống như mã cata ,

một bài tập trong lập trình giúp lập trình viên trau dồi kỹ năng của họ thông qua thực hành và lặp lại ...

Một số điều bạn nói là đúng: ví dụ: thư viện giải quyết các hàm không được giải quyết bằng các ngôn ngữ cấp cao giải quyết các vấn đề không được giải quyết bằng cách lắp ráp, giải quyết các vấn đề không được giải quyết bằng mã máy. Khi bạn gọi System.out.println () trong java, bạn sẽ mất khả năng CPU xuất ra thiết bị.

Vì vậy, có, bạn đang mất một cái gì đó. Những gì bạn đạt được là khả năng tập trung vào các vấn đề chưa được giải quyết. Bây giờ có thể là bạn cần đắm mình vào một số khía cạnh khác của công nghệ (ví dụ như cách thức hoạt động của mạng) để giải quyết vấn đề. Nhưng bạn không cần phải trở thành một chuyên gia về đọc ngôn ngữ máy khi tất cả những gì bạn muốn làm là xây dựng một trang web.

Cùng một cách, các nhà xây dựng cầu đang giải quyết một vấn đề hơi khác nhau mỗi lần (đó là một dòng sông khác nhau). Họ không lo lắng về việc làm thế nào để tạo ra các dầm thép có độ bền kéo nhất định, hoặc làm thế nào để gia công bu lông đến một dung sai nhất định. Họ để lại cho các chuyên gia đã giải quyết vấn đề đó.

Nhìn kỹ, và bạn sẽ thấy toàn bộ xã hội và cơ sở hạ tầng của chúng tôi được xây dựng trên 99% tái sử dụng và chỉ có 1% tiến bộ thực sự. Hầu hết những thứ mới chỉ là những thứ cũ với thêm một chút gì đó được thêm vào hoặc loại bỏ. Đó là sự tích lũy kiến ​​thức của con người. Bạn có thể viết mã bằng một ngôn ngữ cấp cao với các thư viện phong nha vì ai đó đã tìm ra tất cả những thứ phức tạp cực kỳ cần thiết để đi đến điểm này. Nó cho phép bạn giải quyết các vấn đề mới và thú vị.

Để gắn kết tất cả lại với nhau và trả lời các bình luận: Bạn không phải giải quyết các vấn đề đã được giải quyết để phát triển thành thạo. Hơn nữa, phần lớn những gì bạn làm sẽ được phát minh lại bánh xe. Vì vậy, trong ngắn hạn, câu trả lời là không - bạn không cần phải thực hiện lại các chức năng của thư viện để thành thạo. Có rất nhiều cơ hội, một số trong đó là vẹt, một số trong đó sáng tạo để trau dồi thủ công của bạn.

Đó là tất cả về tài nguyên. Nhiều năm trước, nếu bạn phát triển các dự án phần mềm cho các máy tính lớn, chúng có thể tồn tại trong khoảng 15 năm hoặc lâu hơn với môi trường phát triển tĩnh. Chương trình FORTRAN được viết để tính toán tiền lương hoặc chương trình COBOL đã được hoàn thiện trong nhiều thập kỷ vì nó liên tục được sử dụng. Có tài nguyên để xem làm thế nào điều này có thể được cải thiện. Chúng ta không còn môi trường chậm chạp đó nữa để tinh chỉnh và đánh bóng các kỹ năng cho một dự án cụ thể. Nhưng chúng tôi có các kỹ năng và thích ứng chúng với các tài nguyên dự án tiếp theo cho phép. Nhưng cuối cùng, nếu trở thành một sự lựa chọn tiền dành cho dự án mới để thực hiện công việc, hoặc để thực hiện công việc mới với số lượng lớn mạ vàng. Mạ vàng một dự án có nghĩa là cải thiện nó đến mức thứ n và thêm một tấn chuông và còi ngay cả khi người dùng không '

Điều tốt nhất chúng ta có thể làm là nhìn vào thiết kế tổng thể của một dự án mới và xem nó có thể được cải thiện như thế nào dựa trên kinh nghiệm trong quá khứ của nhóm. Nhưng phải có một kiến ​​trúc sư phần mềm kinh nghiệm thực sự để có một tầm nhìn về những gì thực sự được coi là cải thiện thiết kế để cải thiện các kỹ năng so với việc đơn giản đưa ra các từ thông dụng mới nhất trong phát triển như Agile, OOP, v.v.