Tôi là lập trình viên với 1 năm kinh nghiệm, gần đây tôi nhận ra tôi hiếm khi bắt đầu một dự án một cách chính xác (hầu hết các dự án phụ của tôi), thông thường chu trình dự án diễn ra như sau

1. Bắt đầu với một vài trường hợp sử dụng
2. Bắt đầu viết mã
3. Nhận ra một số điều tôi đã xử lý không tốt và không phù hợp với cơ sở mã hiện tại.
4. Viết lại phần lớn mã

và điều này có thể đi một vài lần

Vì vậy, câu hỏi của tôi là

1. Là thực hành như vậy phổ biến, hoặc nó ngụ ý tôi không đủ năng lực?
2. Làm thế nào tôi có thể cải thiện bản thân về khía cạnh này?

Chu kỳ bạn mô tả là bình thường. Cách để cải thiện mọi thứ không phải là tránh chu kỳ này, mà là hợp lý hóa nó. Bước đầu tiên là chấp nhận rằng:

1. Gần như không thể biết mọi thứ vào ngày đầu tiên của dự án.
2. Ngay cả khi bạn bằng cách nào đó biết tất cả mọi thứ, vào thời điểm bạn hoàn thành dự án thì một cái gì đó (yêu cầu của khách hàng, thị trường mà họ đang làm việc, công nghệ bạn đang làm việc, mong muốn của khách hàng) sẽ thay đổi và thực hiện tại ít nhất là một phần của những gì bạn biết không hợp lệ hoặc không chính xác.

Do đó, không thể lập kế hoạch cho mọi thứ ở phía trước, và thậm chí nếu bạn có thể, theo kế hoạch đó sẽ dẫn bạn xây dựng một cái gì đó không hoàn hảo hoặc lỗi thời. Biết được điều này, chúng tôi tích hợp thay đổi vào kế hoạch của chúng tôi. Hãy xem các bước của bạn:

1. Bắt đầu với một vài trường hợp sử dụng
2. Bắt đầu viết mã
3. Nhận ra một số điều tôi đã xử lý không tốt và không phù hợp với cơ sở mã hiện tại.
4. Viết lại phần lớn mã

Đó thực sự là một điểm khởi đầu tuyệt vời. Đây là cách tôi tiếp cận nó:

1. Bắt đầu với một vài trường hợp sử dụng

Tốt Bằng cách nói "trường hợp sử dụng", bạn đang tập trung vào phần mềm dùng để làm gì . Bằng cách nói "một vài", bạn không cố gắng khám phá mọi thứ; bạn đang gắn bó với một khối lượng công việc có thể quản lý. Tất cả tôi muốn thêm ở đây là để ưu tiên chúng. Với khách hàng hoặc người dùng cuối của bạn, hãy tìm ra câu trả lời cho câu hỏi này:

Phần mềm nhỏ nhất, đơn giản nhất tôi có thể cung cấp cho bạn sẽ cải thiện tình hình của bạn là gì?

Đây là sản phẩm khả thi tối thiểu của bạn - bất cứ điều gì nhỏ hơn điều này không hữu ích cho người dùng của bạn, nhưng bất cứ điều gì rủi ro lớn hơn đều lên kế hoạch quá sớm. Nhận đủ thông tin để xây dựng này, sau đó di chuyển trên. Hãy chú ý rằng bạn sẽ không biết mọi thứ vào thời điểm này.

2. Bắt đầu viết mã.

Tuyệt quá. Bạn được làm việc càng sớm càng tốt. Cho đến khi bạn viết mã, khách hàng của bạn đã nhận được lợi ích bằng không. Bạn càng dành nhiều thời gian lên kế hoạch, khách hàng càng mất nhiều thời gian chờ đợi mà không hoàn vốn.

Ở đây, tôi muốn thêm một lời nhắc để viết mã tốt . Ghi nhớ và tuân theo các Nguyên tắc RẮN , viết các bài kiểm tra đơn vị đàng hoàng xung quanh bất cứ điều gì mong manh hoặc phức tạp, ghi chú về bất cứ điều gì bạn có thể quên hoặc điều đó có thể gây ra vấn đề sau này. Bạn muốn cấu trúc mã của mình để thay đổi sẽ không gây ra vấn đề. Để làm điều này, mỗi khi bạn đưa ra quyết định để xây dựng một cái gì đó này cách thay vì đó bằng cách nào, bạn cấu trúc mã của bạn để càng ít mã càng tốt bị ảnh hưởng bởi quyết định đó. Nói chung, một cách tốt để làm điều này là tách mã của bạn:

• sử dụng các thành phần đơn giản, riêng biệt (tùy thuộc vào ngôn ngữ và tình huống của bạn, thành phần này có thể là chức năng, lớp, lắp ráp, mô-đun, dịch vụ, v.v. Bạn cũng có thể có một thành phần lớn được xây dựng từ các thành phần nhỏ hơn, như một lớp có nhiều hàm hoặc một tập hợp có nhiều lớp.)
• mỗi thành phần thực hiện một công việc hoặc các công việc liên quan đến một việc
• thay đổi cách thức một thành phần hoạt động bên trong của nó không nên làm cho các thành phần khác phải thay đổi
• các thành phần nên được cung cấp cho những thứ họ sử dụng hoặc phụ thuộc, thay vì tìm nạp hoặc tạo chúng
• các thành phần nên cung cấp thông tin cho các thành phần khác và yêu cầu chúng thực hiện công việc, thay vì tìm nạp thông tin và tự thực hiện công việc
• các thành phần không nên truy cập, sử dụng hoặc phụ thuộc vào hoạt động bên trong của các thành phần khác - chỉ sử dụng các chức năng có thể truy cập công khai của chúng

Bằng cách này, bạn sẽ tách biệt các tác động của thay đổi để trong hầu hết các trường hợp, bạn có thể khắc phục sự cố ở một nơi và phần còn lại của mã của bạn không nhận thấy.

3. Gặp phải các vấn đề hoặc thiếu sót trong thiết kế.

Điều này sẽ xảy ra. Đó là điều không thể tránh khỏi. Chấp nhận điều này. Khi bạn gặp một trong những vấn đề này, hãy quyết định loại vấn đề đó là gì.

Một số vấn đề là các vấn đề trong mã hoặc thiết kế của bạn khiến bạn khó thực hiện những gì phần mềm nên làm. Đối với những vấn đề này, bạn cần quay lại và thay đổi thiết kế của mình để khắc phục sự cố.

Một số vấn đề xảy ra do không có đủ thông tin hoặc do có điều gì đó mà trước đây bạn không nghĩ đến. Đối với những vấn đề này, bạn cần quay lại với người dùng hoặc khách hàng của mình và hỏi họ xem họ muốn giải quyết vấn đề như thế nào. Khi bạn có câu trả lời, sau đó bạn đi và cập nhật thiết kế của bạn để xử lý nó.

Trong cả hai trường hợp, bạn nên chú ý đến phần nào trong mã của bạn phải thay đổi và khi bạn viết thêm mã, bạn nên suy nghĩ về phần nào có thể phải thay đổi trong tương lai. Điều này giúp dễ dàng tìm ra phần nào có thể quá liên kết với nhau và phần nào có thể cần được cách ly hơn.

4. Viết lại một phần của mã

Khi bạn đã xác định cách bạn cần thay đổi mã, bạn có thể thực hiện thay đổi. Nếu bạn đã cấu trúc mã của mình tốt, thì điều này thường sẽ chỉ liên quan đến việc thay đổi một thành phần, nhưng trong một số trường hợp, nó cũng có thể liên quan đến việc thêm một số thành phần. Nếu bạn thấy rằng bạn phải thay đổi nhiều thứ ở nhiều nơi, thì hãy nghĩ về lý do tại sao. Bạn có thể thêm một thành phần giữ tất cả các mã này bên trong chính nó, và sau đó có tất cả những nơi này chỉ sử dụng thành phần đó không? Nếu bạn có thể, hãy làm như vậy và lần sau bạn phải thay đổi tính năng này, bạn sẽ có thể làm điều đó ở một nơi.

5. Kiểm tra

Một nguyên nhân phổ biến của các vấn đề trong phần mềm là không biết rõ các yêu cầu. Đây thường không phải là lỗi của nhà phát triển - thông thường, người dùng không chắc chắn họ cần gì. Cách dễ nhất để giải quyết điều này là đảo ngược câu hỏi. Thay vì hỏi "bạn cần phần mềm để làm gì?", Mỗi lần bạn thực hiện các bước này, hãy cung cấp cho người dùng những gì bạn đã xây dựng cho đến nay và hỏi họ "Tôi đã xây dựng cái này - nó có làm những gì bạn cần không?". Nếu họ nói có, thì bạn đã xây dựng một cái gì đó giải quyết vấn đề của họ và bạn có thể ngừng hoạt động! Nếu họ nói không, thì họ sẽ có thể cho bạn biết một cách cụ thể hơn những gì sai với phần mềm của bạn và bạn có thể cải thiện điều cụ thể đó và quay lại để nhận thêm phản hồi.

6. Học

Khi bạn trải qua chu trình này, hãy chú ý đến những vấn đề bạn đang tìm kiếm và những thay đổi bạn đang thực hiện. Có mẫu nào không? Bạn có thể cải thiện?

Vài ví dụ:

• Nếu bạn tiếp tục phát hiện ra rằng bạn đã bỏ qua một quan điểm nhất định của người dùng, bạn có thể khiến người dùng đó tham gia nhiều hơn vào giai đoạn thiết kế không?
• Nếu bạn cứ phải thay đổi mọi thứ để tương thích với công nghệ, bạn có thể xây dựng thứ gì đó để giao diện giữa mã của bạn và công nghệ đó để bạn chỉ phải thay đổi giao diện không?
• Nếu người dùng liên tục thay đổi suy nghĩ về từ ngữ, màu sắc, hình ảnh hoặc những thứ khác trong giao diện người dùng, bạn có thể xây dựng một thành phần cung cấp cho phần còn lại của ứng dụng để tất cả chúng ở cùng một nơi không?
• Nếu bạn thấy rằng rất nhiều thay đổi của bạn nằm trong cùng một thành phần, bạn có chắc chắn thành phần đó chỉ dính vào một công việc không? Bạn có thể chia nó thành một vài phần nhỏ hơn? Bạn có thể thay đổi thành phần này mà không cần phải chạm vào bất kỳ người khác?

Nhanh nhẹn

Những gì bạn đang hướng tới đây là một phong cách làm việc được gọi là Agile. Agile không phải là một phương pháp, đó là một nhóm các phương pháp kết hợp toàn bộ tải trọng của mọi thứ (Scrum, XP, Kanban, để đặt tên cho một số thứ) nhưng điểm chung của tất cả chúng là ý tưởng rằng mọi thứ thay đổi và là nhà phát triển phần mềm, chúng tôi nên có kế hoạch thích ứng với những thay đổi hơn là tránh hoặc bỏ qua chúng. Một số nguyên tắc cốt lõi của nó - cụ thể là những nguyên tắc phù hợp với tình huống của bạn - là như sau:

• Đừng có kế hoạch xa hơn bạn có thể dự đoán với sự tự tin
• Trợ cấp cho những thứ thay đổi khi bạn đi
• Thay vì xây dựng một cái gì đó lớn trong một lần, hãy xây dựng một cái gì đó nhỏ và sau đó tăng dần nó
• Giữ người dùng cuối tham gia vào quá trình và nhận được phản hồi nhanh chóng, thường xuyên
• Kiểm tra công việc và tiến bộ của chính bạn, và học hỏi từ những sai lầm của bạn

Điều này là bình thường.

Bạn có thể thực hiện một trong hai cách tiếp cận:

1. Chào mừng thay đổi

Nếu bạn cho rằng bạn sẽ hiểu sai, bạn phải xây dựng một cơ sở mã được mở để thay đổi. Hầu hết điều này liên quan đến việc lấy mã ở cuối cuốn sách về tái cấu trúc và xây dựng mã của bạn theo cách đó ngay từ đầu (khả năng phân tách, độ bao phủ kiểm tra tốt, ...).

2. Tránh thay đổi

Trong trường hợp này, bạn phải thực hiện một BDUF (thiết kế lớn lên phía trước). Bạn phải thực hiện nhiều nguyên mẫu giấy, thảo luận về ý tưởng với người dùng tiềm năng hoặc bằng cách sử dụng vịt cao su, thử nhiều thứ khác nhau trong nguyên mẫu hoặc mô phỏng, viết ra một đặc điểm kỹ thuật hoàn chỉnh và chỉ khi bạn cảm thấy bạn đã đóng đinh giải pháp thì cuối cùng bạn có thể bắt đầu mã hóa. Làm tất cả những gì không thực sự thoát khỏi sự thay đổi bất ngờ, nó chỉ làm giảm nó một chút, trong năm đầu tiên hoặc lâu hơn. Vì vậy, bạn vẫn phải xây dựng mã của mình để dễ thay đổi.

Vì vậy, về cơ bản, thay đổi là một định. Giả sử nó sẽ xảy ra. Xây dựng mã của bạn cho phù hợp. Trong thực tế, bạn có thể tìm thấy một nền tảng trung gian giữa các phương pháp thiết kế trước và chỉ bắt đầu mã hóa để tránh thay đổi vô cớ mà không bị kẹt trong tê liệt phân tích. Nó chỉ cần một chút kinh nghiệm.

Phát triển phần mềm đã được mô tả là một loạt các vấn đề "xấu xa" vốn có .

Horst Rittel và Melvin Webber đã định nghĩa một vấn đề "xấu xa" là một vấn đề chỉ có thể được xác định rõ ràng bằng cách giải quyết nó hoặc bằng cách giải quyết một phần của nó *. Nghịch lý này ngụ ý, về cơ bản, bạn phải "giải quyết" vấn đề một lần để xác định rõ ràng và sau đó giải quyết lại để tạo ra giải pháp hiệu quả. Quá trình này đã được làm mẹ và làm bánh táo trong phát triển phần mềm trong nhiều thập kỷ

Điều này mô tả hoàn hảo vấn đề bạn gặp phải. Về cơ bản, những gì chúng tôi làm là khó khăn . Nếu có một phần có thể được mô tả là "thói quen", theo thời gian chúng ta sẽ cô lập và tự động hóa nó. Vì vậy, tất cả những gì còn lại là mới hoặc khó khăn.

Có nhiều cách khác để khắc phục các vấn đề như thế này; một số người dành nhiều thời gian để xem xét các vấn đề trước và không viết mã cho đến khi họ cảm thấy thoải mái với thiết kế. Những người khác tìm kiếm hướng dẫn từ những người đã xử lý các vấn đề như thế này, thông qua lập trình cặp hoặc chỉ các trang web như thế này.

Nhưng chắc chắn cách tiếp cận của bạn không đề xuất sự bất tài. Vấn đề duy nhất có thể là nếu, khi bạn quay trở lại, bạn không phản ánh lý do tại sao bạn chọn làm công cụ theo cách này để bắt đầu và liệu bạn có thể thấy cách "tốt hơn" mà không cần viết lại.

Trong rất nhiều trường hợp, đã có, và bạn có thể kết hợp nó vào quá trình thiết kế của mình cho lần tiếp theo. Trong một số trường hợp, không có (hoặc chi phí sẽ cao hơn hoặc cao hơn chi phí của phương pháp khác của bạn) và bạn có thể để mối quan tâm của mình biến mất.

1. Có, điều này là phổ biến, ngoại trừ có thể cho phần "viết lại hầu hết mã". Bạn sẽ không bao giờ nhận được tất cả các yêu cầu ngay từ đầu, vì vậy điều quan trọng là phải đối phó với sự thay đổi tốt. Đó là tất cả những gì về khái niệm "khả năng duy trì mã". Tất nhiên nó cũng giúp dành nhiều thời gian hơn để có được các yêu cầu và thiết kế đúng.
2. Đầu tiên, hãy nghĩ về những thay đổi được yêu cầu trong các dự án trước đây và làm thế nào bạn có thể thấy trước những điều đó hoặc chuẩn bị cho chúng tốt hơn. Khi bắt đầu một dự án, hãy suy nghĩ thêm về các chi tiết của các trường hợp sử dụng. Thực hiện một số thiết kế trừu tượng (các thành phần chính của mã là gì và cách chúng giao tiếp, API của chúng là gì) trước khi bạn bắt đầu triển khai. Quan trọng nhất, hãy cố gắng giữ mã đơn giản và dễ thay đổi nhất có thể, đọc các khái niệm như RẮN, KHÔ, KISS và YAGNI.

Là thực hành như vậy phổ biến, hoặc nó ngụ ý tôi không đủ năng lực?

Những cái đó không loại trừ lẫn nhau. Mô hình có thể là phổ biến, và bạn vẫn có thể không đủ năng lực. Năng lực của bạn có thể được xác định bằng cách đo hiệu suất của bạn so với mục tiêu của bạn. Bạn đang đạt được mục tiêu của mình?

Là mô hình phổ biến? Không may là đúng vậy. Nhiều người lao vào các dự án mà không có ý tưởng rõ ràng về vấn đề họ đang giải quyết, cách họ sẽ thiết kế một giải pháp chính xác và những số liệu nào sẽ tạo nên thành công.

Làm thế nào tôi có thể cải thiện bản thân về khía cạnh này?

Nếu bạn quyết định đi đâu đó và bắt đầu đi bộ, và sau đó phát hiện ra một ngày trong đó điều bạn thực sự cần làm là vận chuyển một con voi từ Cape Town đến Thành phố New York, tất cả thời gian bạn dành cho việc đi bộ đều lãng phí. Chỉ ra những gì bạn đang làm trước khi bạn bắt đầu làm nó.

Khi bạn bắt đầu thực hiện nó, hãy xem xét: mã không phải viết lại bao giờ trông như thế nào? Mã đó:

• Có một điều hữu ích.
• Liệu nó có đúng không.
• Liệu nó với hiệu suất đủ.

Vì vậy: càng nhiều mã bạn viết trong đó mã đó thực hiện tốt một điều hữu ích, chính xác, với hiệu suất tốt, càng ít mã bạn sẽ phải viết lại.

Tôi nghĩ thật an toàn khi nói rằng bạn không quá xa cách làm việc tốt hơn và bạn không phải là người duy nhất trên chiếc thuyền này.

Điều tôi nghĩ bạn đang thiếu là, mặc dù bạn xác định những gì bạn muốn, bạn không dừng lại để thực hiện quy trình tương tự cho cách bạn sẽ làm điều đó.

Bước dừng lại và suy nghĩ về cách giải quyết vấn đề tổng thể được gọi là thiết kế, đây là bước khiến bạn dành thời gian để phát triển cấu trúc hoặc kiến ​​trúc của hệ thống để mọi thứ bạn làm từ chúng đều góp phần vào giải pháp cuối cùng, như ghép các mảnh vào một trò chơi ghép hình một khi bạn đã làm việc ra các cạnh.

Nhiều người không làm bước này, nhưng khi tôi bắt đầu viết mã thì điều đó là bắt buộc. Tôi nghĩ rằng sự khác biệt là ở các công cụ phát triển - trong khi tôi bắt đầu với trình soạn thảo văn bản, giờ đây bạn đã biết tất cả các loại tính năng cho phép bạn nhảy vào và gõ đi.

Vì vậy, hãy dành một ít thời gian để tìm ra các khu vực rộng lớn, các thành phần và khả năng tương tác giữa chúng và xác định các đối tượng sẽ bao gồm giải pháp của bạn trước khi bắt đầu viết mã. Nó không phải là chi tiết to lớn và hiểu rằng bạn sẽ không hoàn toàn đúng ngay từ đầu, vì vậy nó sẽ phát triển theo thời gian, nhưng điều này là để giúp bạn không lãng phí nỗ lực xem lại những thứ không nên làm ' T cần phải thay đổi nhiều.

Bạn đã có một số câu trả lời tuyệt vời nhưng câu hỏi của bạn mang đến một vài điều mà tôi nghĩ rằng tôi sẽ cố gắng chạm vào.

1. Như bạn đã lưu ý khi gặp phải những thay đổi trên đường, tôi khuyên bạn nên suy nghĩ về cách mọi thứ ảnh hưởng đến dự án của bạn và cách bạn có thể giảm thiểu tác động với các lựa chọn thiết kế / mã hóa đồng thời tạo ra một bản đồ tinh thần về nơi mọi người thường thực hiện các thay đổi muộn. Với kinh nghiệm bạn có thể dự đoán và mã hóa một cách linh hoạt cho những điều mà bạn biết sẽ rất quan trọng - mặc dù có sự bất đồng về khái niệm này trong ngành vì một số người sẽ phản đối bạn đang đầu tư vào một lĩnh vực không được yêu cầu cụ thể .

2. Một mặt trận thử nghiệm, đưa ra một nguyên mẫu cho các bên liên quan dự án của bạn có thể là một cách tuyệt vời để tinh chỉnh các yêu cầu. Tuy nhiên, trong quá trình phát triển, bạn có thể tìm cách "nhìn" những gì đang xảy ra trong mã của mình mà không gây ra nhiều sự lộn xộn hoặc phức tạp. Chắc chắn có các công cụ có sẵn để giúp đỡ nhưng bạn cũng có thể làm rất nhiều mà không cần chúng nếu bạn muốn. Dù bằng cách nào, việc ra khỏi mã để xem xét những gì đang xảy ra với con mắt quan trọng có thể cung cấp nhiều loại hiểu biết khác nhau.

3. Tìm kiếm các hoạt động chung. Bạn sẽ thấy mình xử lý các vấn đề tương tự lặp đi lặp lại. Sau một thời gian, bạn nên khám phá những thiếu sót hoặc đánh đổi của các lựa chọn khác nhau và không tham gia vào một phương pháp giúp bạn tránh chúng. Tất nhiên, nếu bạn đang làm việc trong một khung, một số vấn đề này có thể được gói gọn trong các công cụ bạn đang sử dụng.

4. Nếu bạn đang làm việc trong một khuôn khổ dành thời gian, nếu bạn có thể tiết kiệm nó, để xem xét làm thế nào để làm mọi thứ từ đầu. Ví dụ: bạn có thể dễ dàng lắp ráp một thông báo yêu cầu, mở một ổ cắm và đưa ra yêu cầu GET hoặc POST theo cách thủ công. Nếu bạn thích, bạn có thể phân tích các thông điệp XML theo cách thủ công. Dù bạn làm gì, những câu hỏi bạn tạo ra và câu trả lời bạn tìm thấy sẽ phát triển kỹ năng của bạn. Tất nhiên, bạn có thể chọn loại vấn đề cơ bản nào là quan trọng hoặc đáng quan tâm. Tôi sẽ xem xét sự phát triển cá nhân này và không hy vọng sẽ dành nhiều thời gian cho đồng hồ ở đây.

5. Đạn bạc, phương pháp luận và các vấn đề yếu tố buzz cao ở khắp mọi nơi. Về cơ bản, thực tế cơ bản của việc làm việc với thông tin không thay đổi nhanh chóng. Hãy lưu ý xem khung, bộ công cụ hoặc phương pháp tại chỗ là trợ giúp hay cản trở trong các tình huống khác nhau. Trong các công ty lớn, tôi đã thấy rất nhiều phương pháp đã cố gắng mặc dù công ty không thể thực hiện chúng một cách hiệu quả. Cũng giống như các khung công tác, các phương pháp không phải là một cách không an toàn để hoạt động ở mức cao ngay cả khi chúng dựa trên thực tiễn của một số nhóm chức năng cao.

Thật khó để rút kinh nghiệm và có thể truy cập được. Tôi đoán một cách ngắn gọn để đặt tất cả những điều này là để giữ cho đôi mắt của bạn mở, suy nghĩ về những gì bạn nhìn thấy và không bao giờ ngừng học hỏi.

Tôi muốn thêm một vài gợi ý

1) Cá nhân tôi thấy thật hữu ích khi bắt đầu với những thứ trực quan . Vẽ hộp, mũi tên, đường kẻ ... Đừng bận tâm bất kỳ ngôn ngữ mô hình nào bạn sử dụng. Ở nơi đầu tiên bạn đang làm điều đó CHO BẠN. Nó sẽ giúp dòng suy nghĩ của bạn.

2) Tìm một đối tác sparring - lấy một tách cà phê và bảng lật / sơ đồ, vv từ trên cao và đến thị trấn. IMHO thậm chí còn tốt hơn nếu bạn không có kỹ năng công nghệ phù hợp. Bạn nảy qua lại các ý tưởng để thực hiện usecase. Bạn tìm thấy một hoặc hai ngõ cụt - bạn tìm thấy một giải pháp. Với một bộ óc nhanh nhẹn, thường có ít thời gian dành cho giai đoạn này hơn là nếu bạn viết mã, nó không hoạt động và bạn phải giết chết các công việc của bạn hoặc làm lại chúng

3) Tìm một ông chủ có thể hiểu rằng bạn có khả năng không bao giờ hoàn thành việc cải thiện phần mềm bằng văn bản của mình. Nếu bạn luôn cắm các tính năng / yêu cầu mới bị đổ trên bàn và không bao giờ quan tâm đến phần mềm của mình, nó sẽ tấn công lại bạn với các lỗi, duy trì sự không thân thiện và rất nhiều tóc kéo xuống vài năm. Nhận phần mềm này thời gian bảo trì / ngân sách được phân bổ! Số lượng ma thuật tròn tốt của tôi là khoảng 20% ​​thời gian cần thiết để phát triển phần mềm là cần thiết mỗi năm để giữ cho nó giữ được hình dạng trong suốt vòng đời của nó.

4) Quá trình học tập gia tăng này không bao giờ dừng lại (và không nên)! Bạn sẽ nhìn lại sau 10 năm và mỉm cười.

Hy vọng điều này sẽ giúp một chút và may mắn!