Nói chung, loại tối ưu hóa nào bạn thường nghiêng về phía mình khi thiết kế phần mềm?

Bạn có phải là người thích tối ưu hóa thiết kế của bạn cho

• Thời gian phát triển (nghĩa là viết nhanh và / hoặc dễ bảo trì hơn)?
• Thời gian xử lý
• Dung lượng lưu trữ (cả RAM, DB, Disc, v.v.)

Tất nhiên, điều này rất chủ quan đối với loại vấn đề đang được giải quyết và thời hạn liên quan, vì vậy tôi muốn nghe về những lý do sẽ khiến bạn chọn một hình thức tối ưu hóa khác.

Bảo trì

Sau đó định hình nếu cần thiết và tối ưu hóa cho tốc độ. Hiếm khi nào tôi có nhu cầu lưu trữ - ít nhất là không trong 10 năm qua. Trước đó tôi đã làm.

Thời gian phát triển

Chế biến và lưu trữ là giá rẻ. Thời gian của bạn là không.

Chỉ cần lưu ý:

Điều này không có nghĩa là làm một công việc tồi tệ là viết mã chỉ để hoàn thành nó một cách nhanh chóng. Nó có nghĩa là viết mã theo cách tạo điều kiện cho sự phát triển nhanh chóng. Nó cũng phụ thuộc hoàn toàn vào các trường hợp sử dụng của bạn. Nếu đây là một trang web đơn giản, hai hoặc ba trang với một hình thức liên lạc, có lẽ bạn không cần phải sử dụng khung PHP. Một vài bao gồm và một kịch bản gửi thư sẽ tăng tốc độ phát triển. Nếu kế hoạch thay vào đó là tạo ra một nền tảng linh hoạt để phát triển và thêm các tính năng mới, bạn nên dành thời gian để trình bày nó đúng cách và viết mã theo đó vì nó sẽ tăng tốc độ phát triển trong tương lai.

Trong so sánh trực tiếp với thời gian xử lý và lưu trữ, tôi nghiêng về thời gian phát triển nhanh hơn. Là sử dụng chức năng trừ bộ sưu tập là phương pháp trừ bộ sưu tập hiệu quả và nhanh nhất? Không! Nhưng đó là thời gian phát triển nhanh hơn. Nếu bạn gặp phải tình trạng tắc nghẽn về hiệu năng hoặc bộ nhớ, bạn có thể giải quyết những vấn đề đó sau. Tối ưu hóa trước khi bạn biết những gì cần được tối ưu hóa là một sự lãng phí thời gian của bạn và đó là những gì tôi ủng hộ.

Kinh nghiệm người dùng.

Đây là giá trị duy nhất quan trọng đối với khách hàng của bạn.

Thời gian phát triển ít quan trọng. Tôi có thể viết một ứng dụng dòng lệnh đầy đủ tính năng nhanh hơn rất nhiều so với GUI, nhưng nếu bà Jane không thể tìm ra cách làm cho nó nhổ ra các báo cáo mà cô ấy muốn, thì nó vô dụng.

Bảo trì là ít quan trọng. Tôi có thể sửa chữa một cái bập bênh rất nhanh, nhưng nếu nó ở giữa một khu rừng, người dùng không thể tìm thấy nó.

Thời gian xử lý ít quan trọng. Nếu tôi tạo một chiếc xe đi 0 đến tốc độ ánh sáng trong 60 giây, người dùng không thể lái.

Thẩm mỹ là ít quan trọng. Tôi có thể vẽ Mona Lisa, nhưng nếu cô ấy giấu sau bức tường thì không ai được nhìn thấy cô ấy.

Trải nghiệm người dùng là giá trị duy nhất quan trọng. Làm cho một ứng dụng thực hiện chính xác những gì người dùng muốn theo cách người dùng mong đợi là thành quả cuối cùng.

Chỉ có một thứ để tối ưu hóa và đó là:

Khách hàng của bạn muốn gì

Khách hàng của bạn cần chương trình nhanh nhất có thể? Tối ưu hóa cho tốc độ.

Khách hàng của bạn cần độ tin cậy tuyệt đối? Tối ưu hóa cho điều đó.

Họ cần nó được giao vào ngày mai hoặc nó sẽ vô dụng? Tối ưu hóa cho tốc độ phát triển.

Chạy trên một thiết bị cực kỳ hạn chế tài nguyên? Tối ưu hóa cho các tài nguyên đó.

Thời gian xử lý

Tôi vừa nâng cấp một ứng dụng tôi sử dụng vào năm ngoái. Họ đã viết lại hoàn toàn ứng dụng, và cậu bé thì chậm. Cuối cùng tôi đã phải mua một máy tính mới để chạy nó một cách nhanh chóng. Tôi đảm bảo với bạn rằng nó không rẻ, nhưng thời gian của tôi có giá trị hơn.

Tôi có xu hướng nghiêng về việc hạn chế tiêu thụ bộ nhớ và phân bổ. Tôi biết đó là trường học cũ, nhưng:

• Hầu hết các mã không vứt bỏ tôi viết là rất nhiều song song. Điều này có nghĩa là phân bổ bộ nhớ quá mức và hoạt động thu gom rác sẽ tuần tự hóa rất nhiều mã song song khác. Điều đó cũng có nghĩa là sẽ có rất nhiều tranh cãi về một chiếc xe buýt bộ nhớ dùng chung.
• Ngôn ngữ chính của tôi là D, chưa có hỗ trợ 64 bit tốt (mặc dù điều này đang được khắc phục).
• Tôi làm việc với các bộ dữ liệu khá lớn một cách thường xuyên.

Tôi muốn nói rằng tôi tối ưu hóa hiệu quả, với hiệu quả được định nghĩa là sự thỏa hiệp giữa thời gian phát triển, khả năng duy trì trong tương lai, trải nghiệm người dùng và tài nguyên tiêu thụ. Là một nhà phát triển, bạn cần phải sắp xếp tất cả những thứ này để duy trì một số loại cân bằng.

Làm thế nào để bạn đạt được sự cân bằng đó? Chà, trước tiên bạn cần thiết lập một vài hằng số, chẳng hạn như thời hạn là gì, ứng dụng của bạn sẽ chạy trên phần cứng nào và loại người nào sẽ sử dụng nó. Nếu không biết những điều này, bạn không thể thiết lập số dư chính xác và ưu tiên nơi cần thiết.

Chẳng hạn, nếu bạn đang phát triển một ứng dụng máy chủ trên một cỗ máy mạnh mẽ, bạn có thể muốn đánh đổi hiệu quả hiệu suất để đảm bảo bạn đạt được thời hạn bất động. Tuy nhiên, nếu nhà phát triển của bạn một ứng dụng cần phản hồi nhanh với đầu vào của người dùng (nghĩ là trò chơi video) thì bạn cần ưu tiên thói quen nhập liệu của mình để đảm bảo ứng dụng không bị lag.

Bất cứ công nghệ ảo hóa nào tôi đang sử dụng

Bạn còn nhớ những ngày mà các hệ thống có hơn 512 MB RAM được coi là xuất huyết không? Tôi dành ngày của tôi để viết mã cho trước.

Tôi làm việc chủ yếu trên các chương trình cấp thấp chạy trên miền đặc quyền trong môi trường Xen. Mức trần của chúng tôi cho miền đặc quyền là 512 MB, để lại phần còn lại của RAM miễn phí cho khách hàng sử dụng. Nó cũng là điển hình cho chúng tôi giới hạn miền đặc quyền chỉ trong một lõi CPU.

Vì vậy, tôi ở đây, viết mã sẽ chạy trên một máy chủ hoàn toàn mới $ 6k và mỗi chương trình phải hoạt động (lý tưởng) trong mức trần được phân bổ 100kb hoặc phân bổ bộ nhớ động hoàn toàn.

Chính xác, tôi tối ưu hóa cho:

• Mức chiếm dụng bộ nhớ
• Sắp xếp (nơi phần lớn mã của tôi dành phần lớn thời gian)

Tôi cũng phải cực kỳ siêng năng khi phải dành thời gian chờ đợi khóa, chờ I / O hoặc chỉ chờ đợi nói chung. Một lượng đáng kể thời gian của tôi dành cho việc cải thiện các thư viện ổ cắm không chặn hiện có và xem xét các phương pháp thực tế hơn về lập trình khóa miễn phí.

Mỗi ngày tôi thấy hơi mỉa mai rằng tôi đang viết mã giống như tôi đã làm 15 năm trước, trên các hệ thống được mua vào tháng trước, do những tiến bộ trong công nghệ.

Đây là điển hình cho bất kỳ ai làm việc trên các nền tảng nhúng, mặc dù nhiều người trong số họ có ít nhất 1GB theo ý của họ. Như Jason chỉ ra, nó cũng là điển hình khi viết chương trình để chạy trên thiết bị di động. Danh sách này tiếp tục, kiốt, khách hàng mỏng, khung ảnh, v.v.

Tôi bắt đầu nghĩ rằng các hạn chế phần cứng thực sự tách biệt các lập trình viên khỏi những người có thể làm một cái gì đó hoạt động mà không quan tâm đến những gì nó thực sự tiêu thụ. Tôi lo lắng (bỏ phiếu cho tôi nếu bạn phải) những ngôn ngữ hoàn toàn trừu tượng và kiểm tra bộ nhớ đối với nhóm chung có ý nghĩa chung (trước đây) được chia sẻ giữa các lập trình viên thuộc nhiều lĩnh vực khác nhau.

Kết quả nghiên cứu

Là một học giả, tôi cho rằng tôi nên chia sẻ những gì tôi tối ưu hóa. Lưu ý rằng điều này không hoàn toàn giống như tối ưu hóa trong thời gian phát triển ngắn hơn. Thông thường nó có nghĩa là công việc có thể hỗ trợ một số câu hỏi nghiên cứu, nhưng không phải là một sản phẩm đánh bóng, có thể giao được. Đây có thể được coi là một vấn đề với chất lượng và nó có thể giải thích tại sao nhiều người nói rằng các nhà khoa học máy tính (hàn lâm) không có bất kỳ kinh nghiệm "thế giới thực" nào. (Ví dụ: "Họ có biết cách phát triển một sản phẩm có thể giao hàng không?" )

Đó là một dòng tốt. Về mặt tác động, bạn muốn tác phẩm của mình được người khác sử dụng và trích dẫn, và Hiệu ứng Iceberg của Joel phát huy tác dụng: một chút đánh bóng và tỏa sáng có thể đi một chặng đường dài. Nhưng nếu bạn không tạo nền tảng cho các dự án khác được xây dựng, bạn có thể không thể biện minh cho thời gian làm một sản phẩm có thể giao được.

1. Thiết kế
   • khớp nối thấp, mô-đun
   • súc tích, xác định rõ, khu vực chức năng
   • tài liệu tốt
   • liên tục tái cấu trúc cho cruft
2. Bảo trì
   • xây dựng lại và gỡ lỗi
   • kiểm tra đơn vị
   • kiểm tra hồi quy
   • kiểm soát nguồn

... sau đó mọi thứ khác

... Cuối cùng, tối ưu hóa cho hiệu suất ;-)

Chất lượng / Kiểm tra

Tối ưu hóa về chất lượng, vì đảm bảo có thời gian trong lịch trình phát triển để thử nghiệm, cả thử nghiệm đơn vị và thử nghiệm sau các tính năng / giai đoạn.

Nó phụ thuộc vào nhu cầu của chương trình của bạn.

Hầu hết những gì tôi làm bị hạn chế rất nhiều bởi khả năng xử lý và bộ nhớ, nhưng không trải qua rất nhiều thay đổi đáng kể trong năm trung bình.

Trước đây tôi đã làm việc cho các dự án nơi mã được thay đổi thường xuyên để khả năng bảo trì trở nên quan trọng hơn trong những trường hợp đó.

Tôi cũng đã làm việc trên các hệ thống trong quá khứ, nơi lượng dữ liệu là vấn đề quan trọng nhất, ngay cả trên đĩa để lưu trữ, nhưng thông thường hơn là kích thước trở thành vấn đề khi bạn phải di chuyển toàn bộ dữ liệu hoặc chậm. liên kết.

Sang trọng .

Nếu mã của bạn được thiết kế tốt, nó sẽ có một số hiệu ứng:

1. Nó sẽ dễ dàng hơn để duy trì (cắt giảm chi phí cho khách hàng)
2. Sẽ dễ dàng hơn để tối ưu hóa (đối với JIT hoặc trình biên dịch đầy đủ)
3. Nó sẽ dễ dàng hơn để thay thế (khi bạn nghĩ đến một giải pháp tốt hơn)

Thời gian phát triển, hoàn toàn. Tôi cũng tối ưu hóa băng thông, nhưng tôi không chuyển sang hệ nhị phân.

Vì tôi cài đặt trên nhiều loại hệ thống, mọi thứ từ máy tính lớn của IBM đến PC, trước tiên tôi tối ưu hóa để tương thích, sau đó là kích thước, sau đó là tốc độ.

Nó phụ thuộc

Nếu bạn đang làm việc trên một hệ thống xử lý video nhúng thời gian thực thì bạn tối ưu hóa cho tốc độ xử lý. Nếu bạn đang làm việc trên một trình xử lý văn bản, bạn tối ưu hóa cho thời gian phát triển.

Tuy nhiên, trong mọi trường hợp mã của bạn phải hoạt động và nó phải được duy trì.

Biểu hiện của ý định của tôi.

Tôi muốn ai đó đọc mã của tôi để có thể dễ dàng xem những hoạt động tôi đang cố gắng gọi trên miền. Tương tự, tôi cố gắng giảm thiểu rác phi ngữ nghĩa (dấu ngoặc nhọn, từ khóa 'hàm' trong js, v.v.) để giúp quét dễ dàng hơn.

Tất nhiên bạn phải cân bằng điều đó bằng khả năng bảo trì. Tôi thích viết các hàm trả về các hàm và tất cả các loại kỹ thuật nâng cao và chúng làm mục tiêu của tôi hơn nữa, nhưng nếu lợi ích không đáng kể, tôi sẽ không chấp nhận các kỹ thuật mà các lập trình viên jr vững chắc sẽ quen thuộc.

Tất cả bọn họ

Thời gian xử lý

Máy tính ngày nay rất nhanh, nhưng còn lâu mới đủ. Có nhiều tình huống trong đó hiệu suất là rất quan trọng - nếu bạn phát trực tuyến các máy chủ phương tiện.

Lưu trữ

Khách hàng của bạn có thể có một đĩa lớn, giả sử, 1Tb. Có thể chiếm tới 1000 phim HD, nếu bạn muốn biến nó thành một dịch vụ thì nó không đủ xa, phải không?

Thời gian phát triển

Chà, tôi không chắc đây có được tính là tối ưu hóa trên mạng không ", những gì tôi làm là tôi sử dụng Java thay vì C ++ và sự phát triển nhanh hơn gấp 10 lần. Tôi cảm thấy như mình đang nói trực tiếp những gì tôi nghĩ với máy tính về phía trước và hoàn toàn đá!

BTW Tôi tin rằng để tăng tốc độ phát triển quá trình phát triển của bạn, bạn nên chọn java, đừng bao giờ thử rác như trăn ... điều này tuyên bố họ có thể rút ngắn thời gian DEV của bạn.