Bởi nhân viên Techopedia, ngày 15 tháng 3 năm 2017
Takeaway: Người dẫn chương trình Eric Kavanagh đã thảo luận về việc gỡ lỗi cơ sở dữ liệu và lập hồ sơ với Tiến sĩ Robin Bloor, Dez Blanchfield và IDERA của Bert Scalzo.
Bạn hiện chưa đăng nhập. Vui lòng đăng nhập hoặc đăng ký để xem video.
Eric Kavanagh: Được rồi, thưa quý vị và các bạn, bây giờ là 4:00 giờ Đông vào thứ Tư, và tất nhiên điều đó có nghĩa.
Robin Bloor: Không thể nghe thấy bạn, Eric.
Eric Kavanagh: Tôi đã ở đó vài ngày trước, vì vậy bạn không cô đơn. Nhưng vì vậy, chủ đề hôm nay là thứ thực sự thú vị. Đó là điều mà bạn muốn chắc chắn đang diễn ra trong nền tại công ty của bạn, trừ khi bạn là người làm việc đó, trong trường hợp đó bạn muốn chắc chắn rằng mình đang làm đúng. Bởi vì chúng ta đang nói về gỡ lỗi. Không ai thích lỗi, không ai thích khi phần mềm ngừng hoạt động - mọi người buồn bã, người dùng không thân thiện. Điều đó không tốt. Vì vậy, chúng ta sẽ nói về "Phản ứng nhanh: Gỡ lỗi cơ sở dữ liệu và lập hồ sơ để giải cứu."
Có một điểm về bạn thực sự, đánh tôi lên Twitter, tất nhiên là @eric_kavanagh.
Năm nay trời nóng. Và gỡ lỗi sẽ trở nên nóng bỏng, không có vấn đề gì. Đây thực sự sẽ là một trong những vấn đề sẽ không bao giờ biến mất, cho dù chúng ta có làm tốt công việc này đến đâu, vẫn luôn có vấn đề, vậy vấn đề quan trọng là làm thế nào để bạn có thể giải quyết những vấn đề đó một cách nhanh chóng? Lý tưởng nhất là bạn có những lập trình viên tuyệt vời, môi trường tuyệt vời, nơi không có quá nhiều sai sót, nhưng như người xưa vẫn nói, Tai nạn xảy ra trong những gia đình tốt nhất. Một điều tương tự cũng đúng với các tổ chức. Vì vậy, những thứ này xảy ra, nó sẽ xảy ra, câu hỏi đặt ra là đâu sẽ là giải pháp của bạn để giải quyết và giải quyết những vấn đề đó?
Chúng tôi sẽ nghe từ Tiến sĩ Robin Bloor, sau đó là Dez Blanchfield của chúng tôi từ dưới lên, và tất nhiên, người bạn tốt của chúng tôi, Bert Scalzo, từ IDERA. Và trên thực tế, tôi sẽ trao chìa khóa cho Robin Bloor, mang nó đi. Sàn là của bạn.
Robin Bloor: OK. Đây là một chủ đề thú vị. Tôi nghĩ bởi vì Dez có lẽ sẽ tiếp tục về các kỹ thuật thực tế và câu chuyện chiến tranh về gỡ lỗi, tôi nghĩ tôi chỉ cần làm một cuộc thảo luận nền để chúng ta có được một bức tranh toàn cảnh về những gì đang diễn ra. Tôi đã làm điều này trong một thời gian dài và tôi đã từng là một lập trình viên, vì vậy nó rất thích và tôi gần như bị cám dỗ với bài thuyết trình này để bắt đầu viết bài trữ tình về ý tưởng về nguồn mở nhưng tôi nghĩ tôi sẽ để nó cho người khác.
Đây là danh sách các lỗi nổi tiếng và hầu hết trong số này đều lọt vào danh sách hàng đầu của bất kỳ ai, về cơ bản, ngoại trừ hai lỗi cuối cùng có giá ít nhất 100 triệu đô la. Cái đầu tiên là Tàu quỹ đạo Khí hậu Sao Hỏa, bị lạc trong không gian và đó là do vấn đề mã hóa, nơi mọi người nhầm lẫn các đơn vị số liệu với (cười) feet và inch. Ariane Five Flight 501 có sự không phù hợp giữa một động cơ được đưa vào và các máy tính được cho là đang chạy tên lửa khi nó được phóng. Nhiều lỗi máy tính, tên lửa phát nổ, tin tức tiêu đề. Đường ống khí đốt của Liên Xô năm 1982, được cho là vụ nổ lớn nhất trong lịch sử hành tinh; Tôi không chắc liệu nó có. Người Nga đã đánh cắp một số phần mềm điều khiển tự động và CIA nhận ra rằng họ sẽ làm điều đó và đưa các lỗi vào đó, và Liên Xô đã thực hiện nó mà không cần thử nghiệm. Vì vậy, thổi một đường ống lên, nghĩ rằng đó là thú vị.
Con sâu Morris là một thí nghiệm mã hóa, đột nhiên trở thành một con sâu hung dữ đi vòng quanh con người của nó, nó dường như gây ra thiệt hại trị giá 100 triệu đô la; đó là một ước tính của khóa học. Intel đã mắc một lỗi nổi tiếng với chip toán học - một hướng dẫn toán học trên chip Pentium vào năm 1993 - được cho là có giá hơn 100 triệu USD. Chương trình Bản đồ của Apple có thể là sự ra mắt tồi tệ nhất và tai hại nhất của bất cứ điều gì mà Apple từng làm. Những người đã thử sử dụng nó, ý tôi là, có ai đó đang lái xe dọc theo 101 và phát hiện ra rằng Bản đồ Apple nói rằng họ đang ở giữa Vịnh San Francisco. Vì vậy, mọi người bắt đầu gọi ứng dụng Apple Maps là iLost. Sự cố mất điện lâu nhất của chúng tôi vào năm 1990 - thật thú vị từ quan điểm về chi phí của một thứ tương tự - AT & T đã hết khoảng chín giờ và phải trả khoảng 60 triệu đô la cho các cuộc gọi đường dài.
Và tôi đang ở một công ty bảo hiểm của Anh và cơ sở dữ liệu, họ đã triển khai một phiên bản mới của cơ sở dữ liệu và nó bắt đầu xóa sạch dữ liệu. Và tôi nhớ điều đó cực kỳ tốt, vì sau đó tôi đã được gọi tham gia vào một số loại lựa chọn cơ sở dữ liệu vì điều đó. Và điều rất thú vị là họ đã lấy một phiên bản mới của cơ sở dữ liệu và họ có một loạt các thử nghiệm mà họ đã làm cho các phiên bản mới của cơ sở dữ liệu mà nó đã vượt qua tất cả các thử nghiệm. Nó tìm thấy một cách thực sự tối nghĩa để xóa sạch dữ liệu.
Vì vậy, dù sao, đó là điều đó. Tôi nghĩ tôi sẽ nói về sự không phù hợp trở kháng và SQL đã ban hành. Thật thú vị khi cơ sở dữ liệu quan hệ lưu trữ dữ liệu trong các bảng và bộ mã hóa có xu hướng thao tác dữ liệu trong các cấu trúc đối tượng thực sự không ánh xạ rất tốt đến các bảng. Và vì điều đó, bạn có được thứ gọi là sự không phù hợp trở kháng, và ai đó phải đối phó với nó bằng cách này hay cách khác. Nhưng những gì thực sự xảy ra, bởi vì một mô hình, mô hình của người lập trình và cơ sở dữ liệu mô hình khác, không được liên kết đặc biệt. Bạn gặp phải những lỗi không thể xảy ra nếu ngành công nghiệp đã xây dựng những thứ hoạt động cùng nhau, điều mà tôi nghĩ là rất vui nhộn. Vì vậy, về cơ bản, về phía các lập trình viên, khi bạn có cấu trúc phân cấp, nó có thể là các kiểu, nó có thể dẫn đến các tập hợp, nó có thể là khả năng API kém, có thể có rất nhiều thứ chỉ cần loại bỏ sự tương tác với cơ sở dữ liệu. Nhưng điều đó đối với tôi nhất, thực sự thú vị; luôn làm tôi ngạc nhiên rằng bạn có rào cản SQL này cũng là một loại trở kháng theo cách mà các lập trình viên và cơ sở dữ liệu làm việc với nhau. Vì vậy, SQL có nhận dạng dữ liệu, điều này tốt và nó có DML để chọn, dự án và tham gia, điều này là tốt. Bạn có thể ném rất nhiều khả năng về việc lấy dữ liệu ra khỏi cơ sở dữ liệu với điều đó. Nhưng nó có rất ít ngôn ngữ toán học để làm việc. Nó có một chút về điều này và điều đó, và nó có rất ít công cụ dựa trên thời gian. Và do đó, SQL là một phương tiện không hoàn hảo, nếu bạn muốn, có được dữ liệu. Vì vậy, các cơ sở dữ liệu đã xây dựng các thủ tục được lưu trữ để sống trong cơ sở dữ liệu và lý do cho các thủ tục được lưu trữ ở đó là bạn không thực sự muốn ném dữ liệu qua lại vào một chương trình.
Đối với một số chức năng cực kỳ cụ thể về dữ liệu, do đó, nó không chỉ là tính toàn vẹn tham chiếu và xóa tầng và những thứ tương tự, cơ sở dữ liệu đã xử lý tất cả các chức năng đột ngột của bạn trong cơ sở dữ liệu, điều đó có nghĩa là tất nhiên chức năng cho một ứng dụng có thể được phân chia giữa bộ mã hóa và cơ sở dữ liệu. Và điều đó làm cho công việc thực hiện một số loại chức năng thực sự khá khó khăn và do đó dễ bị lỗi hơn. Vì vậy, đó là một mặt của trò chơi cơ sở dữ liệu, vì điều đó có nghĩa là bạn đã có rất nhiều triển khai, ví dụ như tôi đã tham gia vào cơ sở dữ liệu quan hệ, thực sự có rất nhiều mã nằm trong các thủ tục được lưu trữ được xử lý tách biệt với mã nằm trong các ứng dụng. Và có vẻ như đó là một điều rất kỳ lạ phải có, nó được cho là khá thông minh khi làm nhiều việc khác nhau.
Tôi nghĩ tôi cũng đã nói về hiệu suất cơ sở dữ liệu vì lỗi hiệu năng thường được coi là lỗi, nhưng về cơ bản, bạn có thể có một nút cổ chai ở CPU, tại bộ nhớ, trên đĩa, trên mạng và bạn có thể gặp sự cố về hiệu suất do khóa . Ý tưởng là bộ mã hóa không thực sự cần phải quan tâm đến hiệu năng và trên thực tế cơ sở dữ liệu sẽ hoạt động tốt. Nó được thiết kế để người lập trình không cần biết. Tuy nhiên, bạn nhận được thiết kế cơ sở dữ liệu xấu, bạn nhận được thiết kế chương trình tồi, bạn có được sự đồng thời trong việc trộn khối lượng công việc, điều này cũng có thể dẫn đến các vấn đề về hiệu suất. Bạn có được sự cân bằng tải, bạn có được kế hoạch dung lượng, tăng trưởng dữ liệu - điều đó có thể khiến cơ sở dữ liệu chỉ dừng lại hoặc làm chậm. Đó là một điều thú vị, khi cơ sở dữ liệu gần đầy, chúng chạy chậm lại. Và bạn có thể có vấn đề về lớp dữ liệu về mặt sao chép và nhu cầu sao chép và nhu cầu thực hiện sao lưu và phục hồi. Dù sao, đó là một tổng quan chung.
Điều duy nhất tôi muốn nói là việc gỡ lỗi cơ sở dữ liệu chỉ có thể là khó chịu và không tầm thường - và tôi nói rằng vì tôi đã làm rất nhiều việc - và bạn sẽ thường phát hiện ra nó giống như mọi tình huống khi gỡ lỗi mà tôi từng có kinh nghiệm là, điều đầu tiên mà bạn từng thấy là một mớ hỗn độn. Và bạn phải cố gắng và đi từ mớ hỗn độn để tìm ra cách mà sự lộn xộn xảy ra. Và thông thường khi bạn đang xem xét một vấn đề về cơ sở dữ liệu, tất cả những gì bạn đang xem là dữ liệu bị hỏng và bạn đang nghĩ, Làm thế nào điều đó đã xảy ra?
Dù sao, tôi sẽ truyền lại cho Dez, người có lẽ sẽ nói nhiều lời khôn ngoan hơn tôi đã nói ra. Tôi không biết làm thế nào để chuyền bóng cho bạn, Dez.
Eric Kavanagh: Tôi sẽ vượt qua nó, chờ đợi, chờ đợi.
Giọng nói tự động: Dòng người tham gia tắt tiếng.
Eric Kavanagh: Được rồi, chờ một chút, để tôi đưa bóng cho Dez.
Dez Blanchfield: Cảm ơn bạn, Eric. Vâng, Tiến sĩ Robin Bloor, bạn thực sự đúng nhất: đây là một chủ đề, một lỗi lầm suốt đời nếu bạn tha thứ cho trò chơi chữ, xin lỗi tôi không thể giúp mình về vấn đề đó. Hy vọng bạn có thể thấy màn hình đầu tiên của tôi ở đó, lời xin lỗi của tôi cho vấn đề kích thước phông chữ ở trên cùng. Chủ đề của lỗi là một bài giảng dài ngày, trong nhiều trường hợp theo kinh nghiệm của tôi. Đây là một chủ đề rộng và rộng, vì vậy tôi sẽ tập trung vào hai lĩnh vực chính, cụ thể là khái niệm về những gì chúng ta coi là một lỗi, nhưng là một vấn đề lập trình. Tôi nghĩ rằng những ngày này giới thiệu một lỗi thường được các môi trường phát triển tích hợp chọn, mặc dù chúng có thể là các lỗi chạy dài. Nhưng thường thì đó là một trường hợp mã hồ sơ và có thể viết mã có chức năng, đó là một lỗi. Vì vậy, tiêu đề của tôi trượt ở đây, tôi thực sự đã có một bản sao này ở độ phân giải rất cao A3, nhưng thật không may, nó đã bị phá hủy trong một lần chuyển nhà. Nhưng đây là một ghi chú viết tay trên một tờ lập trình từ khoảng năm 1945, nơi được cho là một số người dân tại Đại học Harvard ở Hoa Kỳ, bản dựng thứ hai của họ về một cỗ máy có tên Mark II. Họ đã gỡ lỗi một số vấn đề, bằng ngôn ngữ chung, nhưng họ đang cố gắng tìm ra lỗi và hóa ra có gì đó hơi khác so với phần cứng và vấn đề được cho là phần mềm xuất hiện.
Vì vậy, huyền thoại đô thị là vào khoảng ngày 9 tháng 9 năm 1945, một nhóm nghiên cứu tại Đại học Harvard đã tách ra một cỗ máy, họ đã bắt gặp một thứ mà họ gọi là rơle Seventy bảy mươi - trong những ngày đó, việc lập trình được thực hiện theo nghĩa vật lý, bạn nghĩ mã xung quanh một cái bảng, và đó là cách bạn lập trình máy một cách hiệu quả - và họ thấy số rơle này bảy mươi có gì đó không ổn, và hóa ra thuật ngữ thực tế là lỗi bug xuất hiện bởi vì nó hoàn toàn là một con sâu bướm - được cho là ở đó là một con sâu bướm nêm vào giữa một đoạn dây đồng đi từ nơi này sang nơi khác. Và câu chuyện kể rằng Grace Hopper huyền thoại là chú thích này, cho slide tiêu đề của tôi, trường hợp thực tế đầu tiên của một lỗi được tìm thấy là trích dẫn không cần thiết.
Nhưng như Robin đã nhấn mạnh trước đó trong slide đầu tiên của mình, khái niệm về một con bọ đã lùi xa đến mức chúng ta có thể tưởng tượng con người đang tính toán, các khái niệm giống như một bản vá. Thuật ngữ bản vá lỗi Cameron xuất phát từ một đoạn băng thực tế được dán trên một lỗ trên thẻ đục lỗ. Nhưng toàn bộ vấn đề này, đó là thuật ngữ gỡ lỗi của Wap xuất phát từ khái niệm tìm lỗi trong máy vật lý. Và kể từ đó, chúng tôi đã sử dụng thuật ngữ đó xung quanh việc cố gắng xử lý các vấn đề, không quá nhiều như các vấn đề mã hóa trong một chương trình không được biên dịch, nhưng là một chương trình không chạy tốt. Và đặc biệt là không có hồ sơ chỉ tìm thấy những thứ như vòng lặp không bao giờ kết thúc mà không đi đến đâu.
Nhưng chúng tôi cũng có một kịch bản và tôi nghĩ rằng tôi đã đặt một vài slide hài hước trước khi tôi có thêm một chút chi tiết. Đây là phim hoạt hình kinh điển, được gọi là XKCD trên web, và họa sĩ truyện tranh có một số quan điểm khá hài hước về thế giới. Và đây là về một đứa trẻ tên là Little Little Bobby Bàn, và được cho là cha mẹ của cậu bé tên là cậu bé Robert '); DROP TABLE Học sinh; - và nó được gọi là, và loại của Hi Hi, đây là trường học của con trai bạn có một số vấn đề về máy tính, Trực và phụ huynh trả lời, chú ơi, nó có làm hỏng cái gì không? theo một cách nào đó, dạy và giáo viên, bạn có thực sự đặt tên cho con trai mình là Robert '); DROP TABLE Học sinh; -? Và Và phụ huynh nói, thì À đúng rồi, bé Bobby Bàn chúng tôi gọi anh ấy. Dù sao đi nữa, họ tiếp tục nói rằng họ đã mất hồ sơ học sinh năm, tôi hy vọng bạn hạnh phúc. Và câu trả lời là, Vâng, bạn nên dọn dẹp và vệ sinh các đầu vào cơ sở dữ liệu của mình. Và tôi sử dụng nhiều lần để nói về một số vấn đề chúng ta gặp phải khi tìm mã, thường là mã không nhìn vào dữ liệu cũng.
Một điều thú vị khác, tôi không biết điều này có thật hay không - tôi nghi ngờ đó là một trò giả mạo - nhưng một lần nữa, nó cũng chạm vào xương hài hước của tôi. Ai đó thay đổi biển số xe ở phía trước xe của họ, thành một tuyên bố tương tự khiến cơ sở dữ liệu rơi vào camera tốc độ và do đó bắt được biển số xe. Và tôi luôn đề cập đến nó vì tôi nghi ngờ bất kỳ lập trình viên nào dự đoán một cú đánh và chạy mã của họ bằng một chiếc xe cơ giới thực sự, nhưng không bao giờ đánh giá thấp điều đó - sức mạnh của một kẻ lập dị tức giận.
(Tiếng cười)
Nhưng điều này dẫn tôi đến điểm chính của tôi, tôi đoán, và đó là một lần, chúng ta có thể gỡ lỗi và mã hồ sơ như là những người bình thường. Nhưng tôi rất quan điểm rằng thời gian đã trôi qua, và giai thoại theo kinh nghiệm của tôi, lần đầu tiên của tôi - và điều này sẽ làm tôi kinh khủng, tôi chắc chắn; Robin rất vui được chọc tôi vì điều này - nhưng theo lịch sử, tôi đến từ một nền tảng ở tuổi 14 lang thang ở cuối thị trấn và gõ cửa một trung tâm dữ liệu có tên là Dữ liệu Com Com ở New Zealand và hỏi liệu tôi có thể kiếm được tiền tiêu vặt ở trường bằng cách đi xe buýt muộn về nhà, khoảng 25 km đi làm mỗi ngày, bằng cách đặt giấy vào máy in, băng từ trong ổ đĩa băng, và chỉ là một quản trị viên nói chung. Và thật tò mò, họ đã cho tôi một công việc. Nhưng theo thời gian, tôi đã xoay sở để tham gia vào đội ngũ nhân viên và tìm các lập trình viên và nhận ra rằng tôi yêu thích viết mã và trải qua quá trình chạy các kịch bản và các công việc hàng loạt, mà cuối cùng vẫn là mã. Bạn phải viết các tập lệnh và các công việc hàng loạt trông giống như các chương trình nhỏ và sau đó trải qua toàn bộ quá trình ngồi trên một thiết bị đầu cuối 3270 viết mã bằng tay.
Trên thực tế, trải nghiệm đầu tiên của tôi là trên một thiết bị đầu cuối teletype, thực sự là máy in vật lý 132 cột. Về cơ bản, hãy nghĩ giống như một máy đánh chữ rất cũ với giấy cuộn qua nó, vì họ không có ống CRT. Và gỡ lỗi mã trên đó là một vấn đề không hề nhỏ, vì vậy bạn có xu hướng viết tất cả mã của mình bằng tay, và sau đó hành động như một người đánh máy, cố gắng hết sức để không mắc lỗi, vì thật khó chịu khi phải nói trình chỉnh sửa một dòng để đi đến một dòng nhất định và sau đó in dòng đó và sau đó nhập lại. Nhưng có một lần, đó là cách chúng tôi viết mã và đó là cách chúng tôi gỡ lỗi, và chúng tôi đã rất giỏi về nó. Và trên thực tế, nó buộc chúng tôi phải có các kỹ thuật lập trình rất tốt, bởi vì đó là một rắc rối thực sự để khắc phục nó. Nhưng hành trình sau đó đã đi qua - và tất cả chúng ta đều quen thuộc với điều này - nó đã đi từ trải nghiệm thiết bị đầu cuối 3270 trong thế giới của tôi, đến Thiết bị kỹ thuật số VT220 nơi bạn có thể nhìn thấy mọi thứ trên màn hình, nhưng một lần nữa, bạn chỉ đang làm điều tương tự bạn đã thực hiện trên loại băng giấy có định dạng in chỉ trên CRT, nhưng bạn có thể xóa dễ dàng hơn và bạn đã không có âm thanh đó dit dit dit dit dit.
Và sau đó bạn biết, các thiết bị đầu cuối Wyse - như Wyse 150, có lẽ là giao diện yêu thích của tôi với máy tính - và sau đó là PC và sau đó là Mac, và ngày nay, GUI và ID hiện đại dựa trên web. Và một loạt các chương trình thông qua đó, lập trình trong một và trình biên dịch và PILOT và Logo và Lisp và Fortran và Pascal và các ngôn ngữ có thể khiến mọi người co rúm lại. Nhưng đây là những ngôn ngữ buộc bạn phải viết mã tốt; họ đã không cho phép bạn thoát khỏi những thực hành xấu. C, C ++, Java, Ruby, Python - và chúng ta sẽ tiến xa hơn đến giai đoạn lập trình đó, chúng ta có nhiều kịch bản hơn, chúng ta tiến gần hơn và gần hơn với Ngôn ngữ truy vấn có cấu trúc và các ngôn ngữ như PHP thực sự được sử dụng để gọi SQL. Quan điểm của bạn là, xuất phát từ nền tảng của tôi, tôi đã tự học theo nhiều cách và những người đã giúp tôi học hỏi, dạy tôi thực hành lập trình rất tốt và thực hành rất tốt về thiết kế và quy trình để đảm bảo tôi đã không giới thiệu mã lỗi.
Các phương pháp lập trình ngày nay, ví dụ như, Ngôn ngữ truy vấn có cấu trúc, SQL, đó là một ngôn ngữ truy vấn đơn giản, rất mạnh mẽ. Nhưng chúng tôi đã biến nó thành ngôn ngữ lập trình và tôi thực sự không tin rằng SQL đã từng được thiết kế để trở thành ngôn ngữ lập trình hiện đại, nhưng chúng tôi đã biến nó thành ngôn ngữ đó. Và điều đó giới thiệu một loạt các vấn đề, bởi vì khi chúng ta nghĩ về hai quan điểm: từ quan điểm mã hóa và từ quan điểm DBA. Rất dễ dàng để xuất hiện và giới thiệu các lỗi cho những thứ như kỹ thuật lập trình kém, lười biếng viết mã, thiếu kinh nghiệm, thú cưng cổ điển mà tôi có ví dụ với người SQL nhảy lên Google và tìm kiếm thứ gì đó và tìm một trang web đó lấy một ví dụ và thực hiện một bản sao và dán mã hiện có. Và sau đó sao chép một mã hóa xấu, sơ suất và đưa nó vào sản xuất, bởi vì nó chỉ xảy ra để mang lại cho họ kết quả mà họ muốn. Bạn đã có những thách thức khác, ví dụ, những ngày này, tất cả chúng ta đều đang lao về phía này, điều mà chúng ta gọi là cuộc đua về số 0: cố gắng làm mọi thứ thật rẻ và nhanh đến mức chúng ta có một kịch bản mà chúng ta không sử dụng thấp hơn nhân viên được trả lương. Và tôi không có nghĩa là theo cách không lịch sự, nhưng chúng tôi không tuyển dụng chuyên gia cho mọi công việc có thể. Ngày xưa, mọi thứ liên quan đến máy tính là khoa học tên lửa; nó liên quan đến những thứ nổ tung và rất ồn ào, hoặc bay vào vũ trụ hoặc các kỹ sư là những người đàn ông và phụ nữ có trình độ cao, những người đã có bằng cấp và có những nền giáo dục nghiêm ngặt khiến họ không làm những điều điên rồ.
Ngày nay, có rất nhiều người dân bắt đầu phát triển và thiết kế và cơ sở dữ liệu, những người không có nhiều năm kinh nghiệm, không nhất thiết phải được đào tạo hoặc hỗ trợ như nhau. Và vì vậy, bạn kết thúc với một kịch bản chỉ là nghiệp dư truyền thống so với chuyên gia. Và có một dòng nổi tiếng, tôi thực sự không thể nhớ ai đã tạo ra câu trích dẫn, dòng đó là, Nếu bạn nghĩ rằng việc thuê một chuyên gia để thực hiện một công việc, hãy đợi cho đến khi bạn thuê một vài người nghiệp dư tạo ra một vấn đề và bạn phải dọn dẹp nó. Và vì thế SQL có vấn đề đó, và nó rất, rất dễ học, rất dễ sử dụng. Nhưng theo tôi, đó không phải là một ngôn ngữ lập trình hoàn hảo. Thật dễ dàng để thực hiện những việc như làm một ngôi sao được chọn từ bất cứ đâu và kéo tất cả những thứ đó thành ngôn ngữ lập trình mà bạn thấy thoải mái hơn như PHP và Ruby hoặc Python và sử dụng ngôn ngữ lập trình mà bạn thực sự quen thuộc để làm thao tác dữ liệu, thay vì thực hiện một truy vấn phức tạp hơn trong SQL. Và chúng tôi thấy điều này rất nhiều, và sau đó mọi người tự hỏi tại sao cơ sở dữ liệu chạy chậm; đó là bởi vì một triệu người đang cố gắng mua vé từ một hệ thống bán vé trực tuyến, nơi nó có một ngôi sao được chọn từ bất cứ đâu.
Bây giờ, đó là một ví dụ thực sự cực đoan, nhưng bạn đã hiểu được tất cả những điều đó. Vì vậy, để thực sự đấm vào nhà, đây là một ví dụ mà tôi mang theo rất nhiều. Tôi là một fan hâm mộ lớn của toán học, tôi yêu lý thuyết hỗn loạn, tôi yêu các bộ Mandelbrot. Ở phía bên tay phải có sự biểu hiện của bộ Mandelbrot, mà tôi chắc chắn chúng ta đều quen thuộc. Và bên tay trái có một đoạn SQL thực sự biểu hiện điều đó. Bây giờ, mỗi khi tôi đặt cái này lên màn hình ở đâu đó, tôi nghe thấy điều này Trời ơi, ai đó đã kết xuất loạt Mandelbrot bằng SQL, bạn có nghiêm túc không? Điều đó thật điên rồ!, Vâng, toàn bộ vấn đề đó là để minh họa những gì tôi vừa phác thảo ở đó, và đó là có, trên thực tế bây giờ bạn có thể lập trình hầu hết mọi thứ trong SQL; đó là một ngôn ngữ lập trình hiện đại, mạnh mẽ, phát triển. Khi ban đầu nó là một ngôn ngữ truy vấn, nó được thiết kế để chỉ lấy dữ liệu. Vì vậy, bây giờ chúng tôi có các cấu trúc rất phức tạp và chúng tôi đã có các quy trình được lưu trữ, chúng tôi đã áp dụng phương pháp lập trình cho một ngôn ngữ và do đó rất dễ thực hành lập trình kém, thiếu kinh nghiệm, mã cắt và dán, nhân viên được trả lương thấp cố gắng trở thành nhân viên được trả lương cao, những người giả vờ họ biết, nhưng họ phải học trong công việc.
Toàn bộ những thứ mà hồ sơ mã và những gì chúng ta gọi là gỡ lỗi, không tìm thấy nhiều lỗi khiến chương trình ngừng hoạt động, nhưng các lỗi chỉ làm tổn thương hệ thống và mã có cấu trúc kém. Khi bạn nhìn vào màn hình này bây giờ và bạn nghĩ, nó thật dễ thương và bạn nghĩ, đó là một đồ họa tuyệt vời, tôi rất thích chạy nó. Nhưng hãy tưởng tượng rằng chạy trên một số logic kinh doanh . Nó trông khá gọn gàng, nhưng nó nói lên một lý thuyết hỗn loạn được vẽ bằng đồ họa toán học, nhưng khi bạn nghĩ về những gì nó có thể được sử dụng cho logic kinh doanh, bạn sẽ có được bức tranh rất nhanh. Và để thực sự minh họa điều đó - và tôi xin lỗi, màu sắc bị đảo ngược, nó được cho là nền đen và văn bản màu xanh lá cây là màn hình màu xanh lá cây, nhưng bạn vẫn có thể đọc được.
Tôi đã đi và xem nhanh một ví dụ về những gì bạn có thể làm nếu bạn thực sự điên và không có kinh nghiệm gì và đến từ một nền tảng lập trình khác và áp dụng C ++ vào SQL, để thực sự minh họa quan điểm của tôi, trước đây Tôi bàn giao cho khách đã học của chúng tôi từ IDERA. Đây là một truy vấn có cấu trúc được viết như C ++, nhưng nó được mã hóa bằng SQL. Và nó thực sự thực thi, nhưng nó thực thi trong khoảng thời gian ba đến năm phút. Và nó rút lại một cách rõ ràng một dòng dữ liệu từ nhiều cơ sở dữ liệu, nhiều liên kết.
Một lần nữa, toàn bộ vấn đề này là nếu bạn không có công cụ chính xác, nếu bạn không có nền tảng và môi trường chính xác để có thể nắm bắt những thứ này, và chúng được đưa vào sản xuất, và sau đó bạn có 100.000 người đánh vào một hệ thống mỗi ngày, hoặc giờ, hoặc phút, rất nhanh bạn sẽ kết thúc với trải nghiệm Chernobyl nơi sắt lớn bắt đầu tan chảy và chôn vùi vào lõi của hành tinh, bởi vì đoạn mã đó sẽ không bao giờ được đưa vào sản xuất. Các hệ thống và công cụ của bạn, xin lỗi, tôi nên chọn nó trước khi nó đi đến bất cứ nơi nào gần gần ngay cả trong quá trình thử nghiệm, thậm chí thông qua tích hợp hệ thống và UAT, đoạn mã đó nên được chọn và tô sáng và ai đó nên được đưa sang một bên và nói, Nhìn Nhìn, đó là một mã rất đẹp, nhưng hãy nhờ một DBA giúp bạn xây dựng truy vấn có cấu trúc đó một cách chính xác, bởi vì thật lòng mà nói, điều đó thật khó chịu. Và Và URL ở đó, bạn có thể xem và gọi nó là truy vấn SQL phức tạp nhất bạn từng viết. Vì tôi tin rằng, nó thực sự biên dịch, nó chạy. Và nếu bạn cắt và dán nó và chỉ giả lập cơ sở dữ liệu, thì đó là thứ khá đáng để xem; nếu bạn có các công cụ để xem cơ sở dữ liệu, hãy thử và làm tan chảy trong khoảng thời gian ba đến năm phút, để gọi lại một dòng văn bản là gì.
Vì vậy, để tóm tắt, với ý nghĩ đó, toàn bộ nền tảng về mã hóa của tôi đã dạy tôi rằng bạn có thể đưa cho mọi người một khẩu súng và nếu không cẩn thận, họ sẽ tự bắn vào chân mình; Bí quyết là chỉ cho họ biết cơ chế an toàn ở đâu. Với các công cụ phù hợp và phần mềm phù hợp trong tầm tay, sau khi bạn thực hiện mã hóa, bạn có thể xem lại mã của mình, bạn có thể tìm thấy các vấn đề bằng cách cấu hình mã, bạn có thể tìm thấy các lỗi không mong muốn có hiệu quả là các vấn đề về hiệu năng và như tôi đã nói trước đó, ngày xưa, bạn có thể làm điều đó khi nhìn vào màn hình màu xanh lá cây. Bạn không thể nữa; có hàng trăm ngàn dòng mã, có hàng chục nghìn ứng dụng được triển khai, có hàng triệu cơ sở dữ liệu trong một số trường hợp và thậm chí siêu nhân thực sự không thể làm điều này bằng tay nữa. Bạn thực sự cần phần mềm phù hợp và công cụ phù hợp trong tầm tay và bạn cần nhóm sử dụng những công cụ đó, để bạn có thể tìm thấy những vấn đề này và giải quyết chúng rất, rất nhanh, trước khi bạn hiểu rõ, trong khi Dr. Robin Bloor nhấn mạnh, mọi thứ trở nên thảm khốc, và mọi thứ nổ tung, hoặc thông thường hơn, chúng chỉ bắt đầu tiêu tốn của bạn rất nhiều đô la và rất nhiều thời gian và công sức và phá hủy tinh thần và công cụ, khi chúng không thể giải thích được tại sao mọi thứ lại mất Một thời gian dài để chạy.
Và với ý nghĩ đó, tôi sẽ bàn giao cho khách của chúng tôi và tôi mong muốn được nghe họ giải quyết vấn đề này như thế nào. Và đặc biệt là bản demo tôi nghĩ rằng chúng tôi sắp nhận được. Eric, tôi sẽ qua lại.
Eric Kavanagh: OK, Bert, mang nó đi.
Bert Scalzo: OK, cảm ơn bạn. Bert Scalzo ở đây từ IDERA, tôi là người quản lý sản phẩm cho các công cụ cơ sở dữ liệu của chúng tôi. Và tôi sẽ nói về gỡ lỗi. Tôi nghĩ rằng một trong những điều quan trọng nhất mà Robin đã nói trước đó - và rất đúng là việc gỡ lỗi là không hợp lý và không tầm thường, và khi bạn vào cơ sở dữ liệu gỡ lỗi, đó là một trật tự lớn hơn và không tầm thường hơn - vì vậy, đó là là một trích dẫn quan trọng
ĐỒNG Ý. Tôi muốn bắt đầu với lịch sử lập trình, bởi vì nhiều lần tôi thấy những người không gỡ lỗi, họ không sử dụng trình gỡ lỗi, họ chỉ lập trình với bất kỳ ngôn ngữ nào họ đang sử dụng và rất nhiều lần họ sẽ nói với tôi, Thưa Chà, những thứ gỡ lỗi đó là mới, và chúng tôi chưa bắt đầu sử dụng chúng. Tôi đã cho chúng xem biểu đồ dòng thời gian này, loại tiền sử, tuổi già, trung niên, thật tốt nói rằng chúng ta đã ở đâu về ngôn ngữ lập trình. Và chúng tôi đã có những ngôn ngữ rất cũ bắt đầu từ năm 1951 với mã lắp ráp, và Lisp và FACT và COBOL. Sau đó, chúng tôi vào nhóm tiếp theo, Pascals và Cs và sau đó là nhóm tiếp theo, C ++ và xem dấu hỏi đó ở đâu - dấu hỏi đó xấp xỉ vào khoảng năm 1978 đến có thể là 1980. Ở đâu đó trong phạm vi đó chúng tôi đã có Trình gỡ lỗi có sẵn cho chúng tôi, và có thể nói, Hey Hey, tôi không sử dụng trình gỡ lỗi, vì đó là một trong những điều mới, nên sau đó bạn phải bắt đầu lập trình, từ những năm 1950, vì đó là cách duy nhất bạn thoát khỏi yêu cầu đó.
Bây giờ một điều thú vị khác về biểu đồ này là Dez vừa đưa ra nhận xét về Grace Hopper, tôi thực sự biết Grace, vì vậy thật là buồn cười. Và sau đó, một điều khác tôi đã cười là anh ấy đã nói về teletypes và tôi đang ngồi đó, Man Man, đó là bước nhảy vọt lớn nhất mà chúng tôi từng có về năng suất, khi chúng tôi chuyển từ thẻ sang teletypes, đó là bước nhảy lớn nhất từ trước đến nay. Vì vậy, và tôi đã lập trình tất cả các ngôn ngữ ở đây, bao gồm SNOBOL, mà chưa ai từng nghe thấy trước đây, đó là CDC, Control Data Corporation, vì vậy tôi đoán rằng tôi đã hơi già đối với ngành này .
Dez Blanchfield: Tôi sẽ nói, bạn đã già chúng tôi ở đó rất nhiều.
Bert Scalzo: Vâng, tôi đang nói với bạn, tôi cảm thấy như ông nội Simpson. Vì vậy, tôi nhìn vào gỡ lỗi và có nhiều cách khác nhau để gỡ lỗi. Bạn có thể nói về những gì tất cả chúng ta nghĩ về truyền thống vào một trình gỡ lỗi và bước qua mã. Nhưng mọi người cũng sẽ sử dụng mã của họ; đó là nơi bạn dán các câu lệnh vào mã của mình và có thể bạn tạo ra một tệp đầu ra, một tệp theo dõi hoặc một cái gì đó, và do đó bạn sử dụng mã của mình. Tôi sẽ coi đó là gỡ lỗi, nó khó hơn một chút, một cách làm, nhưng nó có giá trị. Nhưng ngoài ra, chúng tôi đã có câu lệnh in nổi tiếng: bạn xem và mọi người thực sự đưa câu lệnh in vào và tôi thực sự đã thấy một công cụ trong đó - và đó là một công cụ cơ sở dữ liệu - nơi bạn không biết cách sử dụng trình gỡ lỗi, bạn nhấn một nút và nó sẽ dán các câu lệnh in trong suốt mã của bạn cho bạn và sau đó khi bạn hoàn thành, bạn nhấn một nút khác và nó sẽ loại bỏ chúng ra. Bởi vì đó là cách nhiều người gỡ lỗi.
Và lý do chúng tôi gỡ lỗi có hai mặt: trước hết, chúng tôi phải tìm những thứ khiến mã của chúng tôi không hiệu quả. Nói cách khác, thông thường điều đó có nghĩa là có lỗi logic hoặc chúng tôi đã bỏ lỡ một yêu cầu kinh doanh, nhưng đó là gì, mã không hiệu quả; nó không làm những gì chúng ta mong đợi nó sẽ làm. Lần khác chúng tôi đi và chúng tôi gỡ lỗi, đó là hiệu quả và đó có thể là một lỗi logic, nhưng đó là, tôi đã làm đúng, nó không trở lại đủ nhanh. Bây giờ, tôi đưa ra quan điểm đó bởi vì một trình biên dịch có lẽ tốt hơn cho kịch bản thứ hai đó và chúng ta sẽ nói về cả trình gỡ lỗi và trình lược tả. Ngoài ra, có khái niệm về gỡ lỗi từ xa; điều này rất quan trọng vì rất nhiều lần nếu bạn ngồi trên máy tính cá nhân và bạn đang sử dụng trình gỡ lỗi, nó truy cập vào cơ sở dữ liệu nơi mã thực sự được thực thi trên cơ sở dữ liệu, bạn thực sự đang thực hiện cái gọi là gỡ lỗi từ xa. Bạn có thể không nhận ra nó, nhưng đó là những gì đang xảy ra. Và sau đó, rất phổ biến với những trình sửa lỗi này để có điểm dừng, điểm xem, bước vào và bước qua và một số điều phổ biến khác, rằng tôi sẽ hiển thị những thứ đó trên ảnh chụp màn hình trong giây lát.
Bây giờ, hồ sơ: bạn có thể thực hiện hồ sơ theo một vài cách khác nhau. Một số người sẽ nói rằng khối lượng công việc nắm bắt và phát lại nơi nó nắm bắt mọi thứ, điều đó được tính là hồ sơ. Kinh nghiệm của tôi đã tốt hơn nếu lấy mẫu xong. Không có lý do để nắm bắt từng câu lệnh, bởi vì một số câu lệnh có thể chạy quá nhanh đến nỗi bạn không quan tâm, điều bạn thực sự đang cố gắng nhìn thấy, đó là những câu lệnh cứ lặp đi lặp lại, bởi vì họ chạy quá lâu Vì vậy, đôi khi hồ sơ có thể có nghĩa là lấy mẫu hơn là chạy toàn bộ. Và thông thường, bạn sẽ nhận được một số loại đầu ra mà bạn có thể sử dụng, bây giờ có thể là hình ảnh bên trong môi trường phát triển IDE, nơi nó có thể cung cấp cho bạn như một biểu đồ về hiệu suất của các dòng mã khác nhau, nhưng nó vẫn có thể có thể nó tạo ra một tập tin dấu vết.
Profilers xuất hiện lần đầu tiên vào năm 1979. Vì vậy, những thứ đó cũng đã xuất hiện từ lâu. Tuyệt vời cho việc tìm kiếm tiêu thụ tài nguyên, hoặc các vấn đề hiệu suất, nói cách khác là điều hiệu quả. Nói chung, nó tách biệt và khác biệt với trình gỡ lỗi, mặc dù tôi đã làm việc với các trình gỡ lỗi làm cả hai cùng một lúc. Và trong khi các trình biên dịch tôi nghĩ là thú vị hơn trong hai công cụ, nếu tôi cảm thấy rằng không đủ người gỡ lỗi, thì chắc chắn không đủ hồ sơ người, bởi vì một trong mười trình gỡ lỗi sẽ hồ sơ, có vẻ như vậy. Và đó là một sự xấu hổ, bởi vì hồ sơ thực sự có thể tạo ra một sự khác biệt lớn. Bây giờ, các ngôn ngữ cơ sở dữ liệu, như chúng ta đã nói trước đó, bạn đã có SQL - và chúng tôi đã buộc chốt tròn vào lỗ vuông ở đây và buộc nó trở thành ngôn ngữ lập trình - và Oracle. Đó là PL / SQL - đó là ngôn ngữ thủ tục SQL - và SQL Server, đó là Transact-SQL, đó là SQL-99, là SQL / PSM - vì, tôi nghĩ, đó là Mô-đun lưu trữ thủ tục. Postgres đặt cho nó một tên khác, DB2 còn một tên khác, Informix, nhưng vấn đề là mọi người đã buộc các cấu trúc kiểu 3GL; nói cách khác, các vòng lặp FOR, tại các khai báo biến và tất cả các nội dung khác xa lạ với SQL hiện là một phần của SQL trong các ngôn ngữ đó. Và vì vậy, bạn cần có khả năng gỡ lỗi PL / SQL hoặc Transact-SQL giống như chương trình Visual Basic.
Bây giờ, các đối tượng cơ sở dữ liệu, điều này rất quan trọng vì mọi người sẽ nói, đó là, tôi phải gỡ lỗi gì trong cơ sở dữ liệu? Và câu trả lời là, bất cứ điều gì bạn có thể lưu trữ trong cơ sở dữ liệu dưới dạng mã - nếu tôi đang làm T-SQL, hoặc PL / SQL - và tôi đang lưu trữ các đối tượng trong cơ sở dữ liệu, đó có thể là một thủ tục được lưu trữ hoặc chức năng được lưu trữ. Nhưng cũng có các trình kích hoạt: một trình kích hoạt giống như một thủ tục được lưu trữ, nhưng nó kích hoạt một loại sự kiện nào đó. Bây giờ, một số người trong trình kích hoạt của họ sẽ đặt một dòng mã và gọi một thủ tục được lưu trữ để họ giữ tất cả các mã và quy trình được lưu trữ của họ, nhưng đó là cùng một khái niệm: đó vẫn là trình kích hoạt có thể khởi tạo toàn bộ. Và sau đó là Oracle, họ có một thứ gọi là gói, giống như một thư viện nếu bạn muốn. Bạn đặt 50 hoặc 100 thủ tục được lưu trữ vào một nhóm, được gọi là một gói, vì vậy nó giống như một thư viện. Vì vậy, đây là trình gỡ lỗi theo cách cũ; đây thực sự là một công cụ sẽ thực sự đi vào và gắn tất cả các câu lệnh gỡ lỗi này vào mã của bạn cho bạn. Vì vậy, ở mọi nơi bạn thấy khối gỡ lỗi, không xóa, trình gỡ lỗi tự động bắt đầu và theo dõi, tất cả đều bị kẹt bởi một số công cụ. Và các dòng bên ngoài đó, vốn là thiểu số của mã, đó là phương pháp gỡ lỗi không thủ công.
Và lý do tôi đưa ra điều này là, nếu bạn đang cố gắng làm điều này bằng tay, thì thực tế bạn sẽ gõ nhiều mã gỡ lỗi hơn để đưa vào tất cả các câu lệnh in này hơn là với mã. Vì vậy, trong khi điều này có thể hoạt động, và trong khi nó tốt hơn không có gì, thì đây là một cách rất khó để gỡ lỗi, đặc biệt là, nếu nó mất 10 giờ để điều này chạy, và nó có vấn đề gì ở dòng ba? Nếu tôi đang thực hiện một phiên gỡ lỗi tương tác, tôi sẽ biết ở dòng ba - năm phút vào đó - này, có một vấn đề ở đây, tôi có thể bỏ. Nhưng với điều này, tôi đã phải đợi nó chạy, trong suốt quá trình hoàn thành và sau đó tôi phải xem một số tệp theo dõi có thể có tất cả các câu lệnh in này trong đó, và thử và tìm kim trong đống cỏ khô. Một lần nữa, điều này tốt hơn không có gì, nhưng nó sẽ không phải là cách tốt nhất để làm việc. Bây giờ, đây là những gì tập tin đó sẽ trông giống như đến từ slide trước; nói cách khác, tôi đã chạy chương trình và nó chỉ có một loạt các câu lệnh in trong tệp theo dõi này và tôi có thể hoặc không thể tìm kiếm thông tin này và tìm thấy những gì tôi cần tìm. Vì vậy, một lần nữa, tôi không chắc chắn rằng đây là cách bạn muốn làm việc.
Bây giờ, trình gỡ lỗi tương tác - và nếu bạn đã sử dụng một cái gì đó như Visual Studio để viết chương trình hoặc Eclipse, bạn đã có trình gỡ lỗi và bạn đã sử dụng chúng với các ngôn ngữ khác của mình - chỉ không nghĩ sử dụng chúng ở đây với cơ sở dữ liệu của bạn. Và có các công cụ ngoài đó, như DB Artisan và Rapid SQL của chúng tôi, đây là Rapid SQL ở đây, có trình gỡ lỗi và bạn có thể thấy ở phía bên trái, tôi có một quy trình được lưu trữ có tên là kiểm tra trùng lặp. Về cơ bản, nó sẽ đi và xem và xem liệu tôi có nhiều hàng trong bảng có cùng tiêu đề phim hay không. Vì vậy, cơ sở dữ liệu là dành cho phim. Và bạn có thể thấy ở phía bên tay phải, ở phần ba trên cùng, tôi đã có mã nguồn ở giữa, tôi có cái được gọi là biến đồng hồ và khay ngăn xếp cuộc gọi của tôi, và ở phía dưới tôi ' đã có một số tin nhắn đầu ra. Và điều quan trọng ở đây là, nếu bạn nhìn qua mũi tên màu đỏ đầu tiên đó, nếu tôi di chuột qua một biến, tôi thực sự có thể thấy giá trị nào trong biến đó tại thời điểm đó, khi tôi bước qua mã. Và điều đó thực sự hữu ích, và sau đó tôi có thể bước từng dòng một qua mã, tôi không phải nói thực thi, tôi có thể nói bước một dòng, để tôi xem điều gì đã xảy ra, bước một dòng khác, để tôi xem điều gì đã xảy ra và tôi đang làm điều này trong cơ sở dữ liệu. Và mặc dù tôi đang ngồi trên Rapid SQL trên PC và cơ sở dữ liệu của tôi đã ở trên đám mây, tôi vẫn có thể thực hiện việc gỡ lỗi từ xa đó và xem nó và điều khiển nó từ đây, và gỡ lỗi giống như bất kỳ ngôn ngữ nào khác.
Bây giờ, mũi tên tiếp theo ở đó - bạn có thể thấy mũi tên giống như chỉ vào bên phải, hướng tới đầu ra DBMS, đó là nơi con trỏ của tôi đang ở hiện tại - vì vậy nói cách khác, tôi đã bước và đó là nơi tôi đang ở khoảnh khắc. Vì vậy, nếu tôi nói, một lần nữa, Bước tôi sẽ đi đến dòng tiếp theo. Bây giờ ngay bên dưới bạn sẽ thấy chấm đỏ. Chà, đó là một điểm dừng, nói rằng Này Hey, tôi không muốn bước qua những dòng này. Nếu tôi chỉ muốn nhảy qua mọi thứ và đến nơi chấm đỏ đó, tôi có thể nhấn nút chạy và nó sẽ chạy từ đây đến cuối hoặc đến một điểm dừng, nếu có bất kỳ điểm dừng nào được đặt, và sau đó nó sẽ dừng lại và để tôi thực hiện lại bước đó. Và lý do điều này rất quan trọng và mạnh mẽ là bởi vì khi tôi làm tất cả những điều này, những gì xảy ra ở giữa và thậm chí dưới cùng - nhưng quan trọng nhất là giữa - sẽ thay đổi và tôi có thể thấy các giá trị từ các biến của mình, Tôi có thể thấy dấu vết ngăn xếp cuộc gọi của tôi, và vì vậy tất cả thông tin đó được hiển thị ở đó khi tôi đang xem mã, vì vậy tôi thực sự có thể nhìn thấy và cảm nhận và hiểu được những gì đang diễn ra và cách mã thực sự làm việc tại thời điểm thực hiện. Và thông thường tôi có thể tìm thấy một vấn đề, nếu có một vấn đề, hoặc nếu tôi đủ tốt để nắm bắt nó.
OK, bây giờ tôi sẽ nói về một hồ sơ, và trong trường hợp này, đây là một hồ sơ mà tôi có thể nhìn thấy thông qua một trình gỡ lỗi. Hãy nhớ tôi đã nói đôi khi họ tách biệt và đôi khi họ có thể ở bên nhau? Trong trường hợp này và một lần nữa, tôi ở Rapid SQL và tôi có thể thấy có một lề, ở phía bên trái, bên cạnh các số dòng. Và đó là, đó là số giây hoặc micro giây mà nó cần để thực thi từng dòng mã và tôi có thể thấy rõ điều đó, tất cả thời gian của tôi dành cho vòng lặp FOR này khi tôi chọn mọi thứ từ một bảng . Và vì vậy, bất cứ điều gì xảy ra bên trong vòng lặp FOR đó có lẽ là điều tôi cần xem xét và nếu tôi có thể làm cho nó tốt hơn, nó sẽ trả cổ tức. Tôi sẽ không nhận được bất kỳ cải tiến nào bằng cách làm việc trên các dòng có 0, 90 hoặc 0, 86; Không có nhiều thời gian ở đó. Bây giờ, trong trường hợp này và một lần nữa, tôi đang ở Rapid SQL, bạn đang thấy cách tôi có thể thực hiện hồ sơ xen kẽ với việc gỡ lỗi của mình. Bây giờ, những gì tốt đẹp là Rapid SQL cũng cho phép bạn làm điều đó theo cách khác. Rapid SQL cho phép bạn nói, Bạn có biết gì không? Tôi không muốn ở trong trình gỡ lỗi, tôi chỉ muốn chạy cái này và sau đó tôi muốn xem xét đồ họa hoặc trực quan cùng loại thông tin.
Và bạn có thể thấy rằng tôi không còn trong trình gỡ lỗi và nó chạy chương trình và sau khi thực hiện xong, nó đưa cho tôi các biểu đồ để cho tôi biết mọi thứ để tôi có thể thấy rằng tôi đã nhận được một tuyên bố giống như nó đang diễn ra Hầu hết các biểu đồ hình tròn và nếu tôi nhìn, tôi thấy trên lưới đó ở phía dưới, dòng 23, lại có vòng lặp FOR: anh ấy chiếm nhiều thời gian nhất, thực tế là anh ấy đang nhai tất cả các biểu đồ hình tròn. Và vì vậy, đây là một cách khác để làm hồ sơ. Chúng tôi tình cờ gọi đó là Nhà phân tích mã Code trong công cụ của chúng tôi. Nhưng về cơ bản, nó chỉ là một trình lược tả tách khỏi trình gỡ lỗi. Một số người thích làm theo cách thứ nhất, một số người thích làm theo cách thứ hai.
Tại sao chúng ta làm gỡ lỗi và định hình? Không phải vì chúng tôi muốn viết mã lớn nhất thế giới và được tăng lương - đó có thể là lý do của chúng tôi, nhưng đó không thực sự là lý do bạn làm điều đó - bạn đã hứa với doanh nghiệp bạn sẽ làm điều gì đó chính xác, rằng chương trình của bạn sẽ hiệu quả. Đó là những gì bạn sẽ sử dụng trình gỡ lỗi cho. Ngoài ra, người dùng cuối kinh doanh; họ không kiên nhẫn lắm: họ muốn có kết quả ngay cả trước khi họ nhấn phím. Chúng ta phải đọc suy nghĩ của họ và làm mọi thứ ngay lập tức. Nói cách khác, nó phải hiệu quả. Và vì vậy, đó là những gì chúng ta sẽ sử dụng trình hồ sơ cho. Bây giờ, không có những công cụ này, tôi thực sự tin rằng bạn là anh chàng này trong bộ đồ công sở với cung và mũi tên và bạn đang bắn vào mục tiêu và bạn bị bịt mắt. Bởi vì làm thế nào bạn sẽ tìm thấy cách một chương trình thực thi bằng cách chỉ nhìn vào mã tĩnh và làm thế nào bạn sẽ tìm ra dòng nào là nơi nó thực sự sẽ dành nhiều thời gian nhất để thực hiện, một lần nữa, chỉ bằng cách nhìn vào mã tĩnh? Đánh giá mã có thể hoặc không thể bật lên một số trong những điều này, nhưng không có gì đảm bảo rằng đánh giá mã sẽ tìm thấy tất cả. Sử dụng trình gỡ lỗi và trình lược tả, bạn sẽ có thể tìm thấy tất cả các lỗi đó.
OK, tôi sẽ thực hiện một bản demo nhanh thực sự ở đây. Đây không phải là ý định của tôi để đẩy sản phẩm, tôi chỉ muốn cho bạn thấy một trình gỡ lỗi trông như thế nào 'vì nhiều lần mọi người sẽ nói, trước đây tôi chưa bao giờ nhìn thấy một trong những điều này., nhưng nó trông như thế nào khi nó chuyển động? Vì vậy, ở đây trên màn hình của tôi, tôi đang chạy sản phẩm DB Artisan của chúng tôi; chúng tôi có một trình sửa lỗi trong đó là tốt. DB Artisan có ý nghĩa nhiều hơn đối với các DBA, Rapid SQL dành cho các nhà phát triển hơn, nhưng tôi đã thấy các nhà phát triển sử dụng DB Artisan và tôi đã thấy các DBA sử dụng Rapid. Vì vậy, đừng để bị cuốn vào sản phẩm. Và ở đây, tôi có quyền lựa chọn thực hiện gỡ lỗi, nhưng trước khi tôi khởi chạy gỡ lỗi, tôi sẽ trích xuất mã này để bạn có thể thấy mã trông như thế nào trước khi tôi bắt đầu chạy nó. Vì vậy, đây là cùng một mã chính xác trong ảnh chụp màn hình, đây là kiểm tra của tôi cho các bản sao. Và tôi muốn gỡ lỗi này, vì vậy tôi nhấn gỡ lỗi. Và bây giờ, phải mất một lúc và bạn nói, ồ, tại sao phải mất một chút thời gian? Hãy nhớ gỡ lỗi từ xa: việc gỡ lỗi thực sự xảy ra trên máy chủ cơ sở dữ liệu của tôi chứ không phải trên PC của tôi. Vì vậy, nó đã phải đi qua và tạo một phiên ở đó, tạo một thứ gỡ lỗi từ xa, nối phiên của tôi với phiên gỡ lỗi từ xa đó và thiết lập một kênh liên lạc.
Vì vậy, bây giờ, đây là mũi tên của tôi, nó ở trên đầu, ở dòng một, đó là nơi tôi đang ở trong mã. Và nếu tôi nhấn biểu tượng thứ ba ở đó, đó là một bước vào, bạn sẽ thấy mũi tên đó vừa di chuyển, và nếu tôi tiếp tục nhấn nó, bạn sẽ thấy nó tiếp tục di chuyển. Bây giờ, nếu tôi muốn đi hết vòng lặp FOR này, bởi vì tôi biết đó là vấn đề ở đâu, tôi có thể đặt điểm dừng. Tôi nghĩ rằng tôi đặt điều đó. Ôi chao, tôi đã có một trong những phím chụp màn hình của mình được ánh xạ tới cùng khóa với trình gỡ lỗi, đó là điều gây ra sự nhầm lẫn. OK, vì vậy tôi chỉ cần thiết lập một điểm dừng ở đó một cách thủ công, vì vậy bây giờ thay vì thực hiện một bước, bước, bước, bước cho đến khi tôi đến đó, thực sự tôi chỉ có thể nói, Đi về phía trước và chạy điều này, và nó sẽ dừng lại. Lưu ý rằng nó đã di chuyển tôi đến tận điểm dừng, vì vậy bây giờ tôi đang ở trong bối cảnh chạy vòng lặp này, tôi có thể thấy tất cả các biến của mình được đặt là gì, điều này không gây ngạc nhiên, vì tôi đã khởi tạo tất cả chúng đến không. Và bây giờ, tôi có thể bước vào vòng lặp này và bắt đầu xem xét những gì đang diễn ra bên trong vòng lặp này.
Vì vậy, bây giờ nó sẽ thực hiện một số lựa chọn từ các dịch vụ cho thuê của tôi và tôi có thể di chuột qua anh chàng đó và xem, anh ta hai, hai lớn hơn một, vì vậy có lẽ nó sẽ thực hiện đoạn mã tiếp theo. Nói cách khác, nó tìm thấy một cái gì đó. Tôi sẽ đi trước và để cho chạy. Tôi không muốn đi qua tất cả mọi thứ ở đây; những gì tôi muốn cho bạn thấy là khi trình gỡ lỗi hoàn thành, nó kết thúc giống như một chương trình bình thường. Tôi đã thiết lập điểm dừng, vì vậy khi tôi nói chạy, nó chỉ quay trở lại điểm dừng tiếp theo. Tôi cho phép nó chạy đến cùng, bởi vì điều tôi muốn bạn thấy là trình gỡ lỗi không thay đổi hành vi của chương trình: khi chạy xong, tôi sẽ nhận được kết quả chính xác nếu tôi không chạy nó bên trong một trình sửa lỗi.
Và với điều đó, tôi sẽ tạm dừng bản demo và quay lại vì chúng tôi muốn đảm bảo có thời gian cho câu hỏi và câu trả lời. Và vì vậy, tôi sẽ mở nó ra cho câu hỏi và câu trả lời.
Eric Kavanagh: Được rồi, Robin, có thể là một câu hỏi từ bạn và sau đó là một cặp vợ chồng từ Dez?
Robin Bloor: Vâng, chắc chắn, tôi thấy điều này hấp dẫn, tất nhiên. Tôi đã làm việc với những thứ như thế này, nhưng tôi chưa bao giờ làm việc với bất cứ thứ gì như thế này trong cơ sở dữ liệu. Bạn có thể cho tôi một số ý tưởng về những gì mọi người sử dụng hồ sơ cho? Bởi vì nó giống như, họ đang xem xét - vì tôi cho rằng họ - họ đang xem xét các vấn đề về hiệu năng, liệu nó có giúp bạn phân biệt được khi nào cơ sở dữ liệu mất thời gian và khi mã mất thời gian không?
Bert Scalzo: Bạn biết đấy, đó là một câu hỏi tuyệt vời. Giả sử tôi đang làm việc trong Visual Basic và tôi, bên trong Visual Basic, tôi sẽ gọi Transact-SQL hoặc PL / SQL. Hãy để tôi thực hiện PL / SQL, vì Oracle không chơi tốt với các công cụ của Microsoft. Tôi có thể đang lược tả mã Visual Basic của mình và hồ sơ có thể nói, Hey Hey, tôi đã gọi thủ tục được lưu trữ này và mất quá nhiều thời gian. Sau đó tôi có thể đi vào thủ tục được lưu trữ và tôi có thể thực hiện một hồ sơ cơ sở dữ liệu trên kho được lưu trữ thủ tục và nói, OK OK, trong số 100 câu lệnh có ở đây, đây là năm câu gây ra sự cố. Và vì vậy, bạn có thể phải thực hiện một nhóm gắn thẻ, trong đó bạn phải sử dụng nhiều trình biên dịch.
Ý tưởng là nếu bạn nhận được vấn đề về hiệu năng trong cơ sở dữ liệu của mình, thì cấu hình cơ sở dữ liệu có thể giúp bạn tìm kim trong đống cỏ khô trên đó các câu lệnh thực sự là vấn đề mà bạn gặp vấn đề. Tôi nói với bạn một điều khác xuất hiện với hồ sơ: nếu bạn có một đoạn mã được gọi là một triệu lần, nhưng chỉ mất một phần triệu giây mỗi triệu lần, nhưng nó được gọi là một triệu lần, những gì trình biên dịch sẽ hiển thị, điều đó chạy trong nhiều đơn vị thời gian. Và vì vậy, trong khi mã có thể có hiệu quả cao, bạn có thể nhìn và nói rằng, Ooh, chúng tôi thực hiện cuộc gọi này đến đoạn mã này quá thường xuyên. Có lẽ chúng ta chỉ nên gọi nó thường xuyên, thay vì mỗi lần chúng ta xử lý một bản ghi, LỚN hoặc một cái gì đó. Và vì vậy, bạn thực sự có thể tìm thấy nơi có mã hiệu quả được gọi là quá thường xuyên và đó thực sự là một vấn đề về hiệu năng.
Robin Bloor: Vâng, thật tuyệt vời. Tôi chưa bao giờ làm điều này. Tất nhiên, bạn thấy, khi tôi gặp vấn đề về cơ sở dữ liệu, giống như tôi bằng cách này hay cách khác hoặc là xử lý cơ sở dữ liệu hoặc xử lý mã; Tôi không bao giờ có thể đối phó với cả hai cùng một lúc. Nhưng ở đó, một lần nữa, tôi đã không thực hiện một trò chơi điện tử mà tôi chưa bao giờ thực sự tham gia vào việc xây dựng các ứng dụng nơi chúng tôi đã lưu trữ các thủ tục, vì vậy tôi đoán rằng tôi chưa bao giờ thực sự gặp phải những vấn đề khiến tôi phát điên, ý tưởng rằng bạn Sẽ chia mã giữa cơ sở dữ liệu và chương trình. Nhưng vì vậy, hãy làm tất cả những gì tôi đang nghĩ rằng câu trả lời sẽ là có, nhưng đây là một phần của hoạt động nhóm phát triển, khi bạn bằng cách này hay cách khác đang cố gắng khắc phục điều gì đó bị hỏng hoặc có thể đang cố gắng mang lại một cái mới ứng dụng cùng nhau. Nhưng điều này có phù hợp với tất cả các thành phần khác mà tôi mong đợi trong môi trường không? Tôi có thể hy vọng rằng tôi có thể cắt clip này cùng với tất cả các gói thử nghiệm của tôi và tất cả những thứ khác mà tôi sẽ làm và với công cụ quản lý dự án của tôi, đó có phải là tất cả các clip này cùng nhau không?
Bert Scalzo: Vâng, nó có thể trở thành một phần của bất kỳ quy trình có cấu trúc nào để thực hiện các nỗ lực lập trình hoặc phát triển của bạn. Và thật buồn cười, tuần trước tôi có một khách hàng đang xây dựng một ứng dụng web và cơ sở dữ liệu của họ rất nhỏ, theo lịch sử, và thực tế là họ không phải là những lập trình viên giỏi không bao giờ làm tổn thương họ. Chà, cơ sở dữ liệu của họ đã phát triển qua nhiều năm, và bây giờ phải mất 20 giây trong một trang web, giữa lúc bạn nói, Đăng nhập cho tôi và cung cấp cho tôi một số dữ liệu để xem và khi màn hình thực sự xuất hiện, và bây giờ nó đã xuất hiện một vấn đề hiệu suất. Và họ biết rằng vấn đề không nằm ở bất kỳ Java nào của họ hoặc bất kỳ nơi nào khác. Nhưng họ có hàng ngàn thủ tục được lưu trữ và vì vậy họ phải bắt đầu lập hồ sơ các thủ tục được lưu trữ để tìm hiểu lý do tại sao trang web này mất 20 giây để đưa ra? Và chúng tôi thực sự thấy rằng họ có một người Cartesian tham gia vào một trong những tuyên bố được chọn của họ và không biết điều đó.
Robin Bloor: Wow.
Bert Scalzo: Nhưng có ai đó đã nói với tôi một lần, về việc làm thế nào họ có thể có một người Cartesian tham gia và không biết điều đó? VI Và điều này nghe có vẻ rất kinh khủng; đôi khi một lập trình viên không thoải mái với SQL sẽ làm điều gì đó như cho tôi tham gia Cartesian, nhưng sau đó chỉ trả lại cho tôi bản ghi đầu tiên, vì vậy tôi biết tôi đã có thứ gì đó và tôi chỉ cần cái đầu tiên. Và vì vậy, họ không nhận ra rằng họ vừa mang về một tỷ hồ sơ hoặc họ xem qua một tỷ hồ sơ, vì họ có được thứ họ quan tâm.
Robin Bloor: Wow, tôi biết, đó là những gì được gọi là tốt, đó là những gì Dez đang diễn ra, về mặt những người không chính xác như có lẽ họ nên biết, bạn biết đấy. Nếu bạn là một lập trình viên, bạn nên biết ý nghĩa của việc ban hành bất kỳ lệnh nào. Ý tôi là, thực sự, không có lý do gì cho mức độ ngu ngốc đó. Tôi cũng cho rằng bạn, bằng cách này hay cách khác, chỉ là bất khả tri ngôn ngữ liên quan đến điều này, bởi vì tất cả đều tập trung vào phía cơ sở dữ liệu. Tôi có đúng trong đó không? Có phải giống nhau không, bất cứ thứ gì bạn đang sử dụng ở phía mã hóa?
Bert Scalzo: Hoàn toàn có thể, bạn có thể làm điều này trong Fortran hoặc C hoặc C ++. Trong thực tế, trên một số Unix bạn thậm chí có thể làm điều đó cho các ngôn ngữ script của chúng; họ thực sự cung cấp các công cụ tương tự. Và sau đó tôi muốn quay lại một giây cho những gì bạn nói không có lý do. Tôi sẽ cho các lập trình viên nghỉ ngơi một lần, vì tôi không thích ném các lập trình viên xuống xe buýt. Nhưng vấn đề thực sự là môi trường học thuật bởi vì khi bạn học cách trở thành một lập trình viên, bạn sẽ được dạy về tư duy kỷ lục. Bạn không được dạy về tư duy tập hợp và đó là những gì Ngôn ngữ truy vấn có cấu trúc hoặc SQL hoạt động với các tập hợp; đó là lý do tại sao chúng ta có liên minh, giao điểm và toán tử trừ. Và đôi khi rất khó đối với một người không bao giờ nghĩ về các bộ, bỏ việc, từ bỏ việc xử lý kỷ lục và làm việc với các bộ.
Robin Bloor: Vâng, tôi với bạn về điều đó. Ý tôi là, tôi hiểu rồi, đó là một vấn đề giáo dục; Tôi nghĩ đó hoàn toàn là một vấn đề giáo dục, tôi nghĩ rằng việc các lập trình viên suy nghĩ theo thủ tục là điều tự nhiên. Và SQL không phải là thủ tục, nó là khai báo. Bạn thực sự chỉ đang nói rằng, Đây là những gì tôi muốn và tôi không quan tâm làm thế nào bạn làm điều đó, bạn có biết không? Trong khi đó với các ngôn ngữ lập trình, bạn thường xắn tay áo lên và bạn rơi vào những chi tiết vụn vặt thậm chí là quản lý số lượng, trong khi bạn thực hiện một vòng lặp. Tôi sẽ tiếp tục với
Bert Scalzo: Không. OK, tiếp tục.
Vâng, tôi sẽ nói rằng bạn đã đưa ra một ví dụ khác rằng một trình hồ sơ sẽ nắm bắt tốt, kiểu này sẽ tiếp tục với quá trình xử lý kỷ lục này. Đôi khi, một lập trình viên giỏi về logic ghi lại tại một thời điểm, không thể tìm ra cách thực hiện chương trình SQL. Chà, giả sử anh ta tạo hai vòng lặp FOR và về cơ bản là tham gia, nhưng anh ta làm điều đó ở phía khách hàng. Vì vậy, anh ta làm hiệu ứng tương tự như tham gia, nhưng anh ta tự làm điều đó và một hồ sơ sẽ nắm bắt được điều đó, bởi vì bạn có thể sẽ dành nhiều thời gian hơn để thực hiện việc tham gia bằng tay thay vì để máy chủ cơ sở dữ liệu làm điều đó cho bạn.
Robin Bloor: Vâng, đó sẽ là một thảm họa. Ý tôi là, bạn sẽ chỉ quậy phá xung quanh. Đập luôn xấu.
Dù sao, tôi sẽ truyền lại cho Dez; Tôi chắc rằng anh ấy có một số câu hỏi thú vị.
Dez Blanchfield: Cảm ơn bạn, vâng, tôi làm. Tôi sẽ tham gia cùng bạn trong việc không ném các lập trình viên dưới xe buýt. Ý tôi là, tôi đã dành quá nhiều năm trong cuộc đời mình để trở thành một lập trình viên, ở mọi cấp độ, bạn biết đấy, như bạn đã nói, ngồi trên dòng lệnh của máy Unix, và trong một số trường hợp, tôi thậm chí còn tham gia trong một vài cổng khác nhau của Unix từ nền tảng phần cứng này sang nền tảng khác. Và bạn có thể tưởng tượng những thách thức chúng tôi đã có ở đó. Nhưng thực tế là đây là thẻ thoát ra cho mọi lập trình viên và người viết kịch bản trên thế giới. Đó là một khoa học tên lửa, theo đúng nghĩa đen, để viết thực sự chặt chẽ mọi lúc, mọi lúc, là một khoa học tên lửa. Và những câu chuyện nổi tiếng về những người như Dennis Ritchie và Brian Kernahan làm việc độc lập với một số đoạn mã và sau đó chuyển sang một bài đánh giá mã qua một tách cà phê và phát hiện ra họ đã viết chính xác cùng một đoạn mã, trong cùng một chương trình, theo cùng một cách Và họ đã làm điều đó trong C. Nhưng mức độ lập trình thuần túy đó hiếm khi tồn tại.
Thực tế là trên cơ sở hàng ngày, chỉ có 24 giờ trong một ngày, bảy ngày trong một tuần và chúng ta chỉ cần hoàn thành công việc. Và vì vậy, khi nói đến không chỉ các lập trình viên truyền thống, các DBA, và các lập trình viên, và các nhà viết kịch bản, và sysadmin, và các quản trị viên mạng, và nhân viên an ninh, và tất cả mọi thứ liên quan đến phía dữ liệu công dân ngày nay; Chúng tôi nghe thấy, mọi người chỉ đang cố gắng làm công việc của họ. Và vì vậy tôi nghĩ rằng sự hấp dẫn tuyệt vời từ toàn bộ điều này là tôi yêu bản demo của bạn và tôi yêu sự mang đi mà bạn đã để lại cho chúng tôi ở đó, chỉ một lúc trước, nói với Robin về thực tế rằng điều này có một điều đặc biệt - có thể không quá nhiều một phân khúc thích hợp - nhưng một không gian rộng mà nó áp dụng, cho đến khi sửa mã và SQL và cơ sở dữ liệu. Nhưng tôi thực sự phấn khích khi nghe bạn nói rằng bạn có thể chọc nó vào một kịch bản shell và tìm thấy một số vấn đề, bởi vì bạn biết, trong thời đại ngày nay, chúng ta luôn làm việc với chi phí thấp nhất cho mọi thứ.
Lý do bạn có thể mua một chiếc áo 6 đô la ở đâu đó, là bởi vì ai đó đã xây dựng một hệ thống đủ rẻ để thực sự sản xuất và vận chuyển và giao dịch và bán lẻ một cách hợp lý và thực hiện thanh toán trực tuyến để có được chiếc áo 6 đô la đó. Và điều đó không xảy ra nếu bạn có người được trả 400.000 đô la một năm để viết mã theo cách hoàn hảo; nó chỉ là toàn bộ sự phát triển. Vì vậy, thời điểm đó, tôi đoán một trong những câu hỏi tôi thực sự yêu bạn là hãy cho chúng tôi hiểu thêm, đó là chiều rộng và tầm với của loại người bạn đang thấy hiện đang triển khai các loại công cụ này để lập hồ sơ một mã và tìm kiếm các vấn đề hiệu suất? Ban đầu, trong lịch sử, họ đến từ đâu? Họ đã từng là những nhà kỹ thuật lớn? Và sau đó, về phía trước, liệu có đúng không, tôi có đúng không khi nghĩ rằng ngày càng có nhiều công ty triển khai công cụ này, hoặc những công cụ này, để thử và giúp các lập trình viên, những người mà họ biết những người vừa hoàn thành công việc để hoàn thành công việc và lấy nó ra khỏi cửa? Và đôi khi chúng ta cần một thẻ ra tù? Tôi có đúng không khi nghĩ rằng trong lịch sử chúng ta có sự tập trung và phát triển kỹ thuật hơn? Bây giờ, chúng ta đang giảm dần, như Robin nói, cách tiếp cận học thuật, và bây giờ nó là tự học, hoặc cắt và dán mã, hoặc chỉ cần xây dựng mọi thứ? Và điều đó có phù hợp với loại người đang dùng sản phẩm bây giờ không?
Bert Scalzo: Vâng, chính xác. Và tôi sẽ cho bạn một ví dụ rất cụ thể, chúng tôi chỉ muốn hoàn thành công việc, vì những người kinh doanh không muốn sự hoàn hảo. Nó giống như một trò chơi cờ vi tính: trò chơi cờ vua không tìm kiếm câu trả lời hoàn hảo; nó tìm kiếm một câu trả lời đủ tốt trong một khoảng thời gian hợp lý, vì vậy đó là cách chúng tôi lập trình. Nhưng những gì tôi tìm thấy bây giờ là, hầu hết mọi người thay vì nói rằng họ muốn một trình hồ sơ như là một phần của thử nghiệm đơn vị của họ - đó là cách tôi sẽ làm điều đó, vì tôi không thấy nó là một sự lãng phí thời gian - những gì đang xảy ra là bây giờ điều đó được thực hiện sau đó, đôi khi, trong quá trình kiểm tra tích hợp hoặc kiểm tra căng thẳng, nếu chúng ta may mắn. Nhưng hầu hết các lần nó là một phần của sự leo thang, nơi một thứ gì đó được đưa vào sản xuất, nó đã chạy trong một thời gian, thậm chí có thể chạy trong nhiều năm, và bây giờ nó không chạy tốt, và bây giờ chúng ta sẽ mô tả nó. Và đó dường như là kịch bản phổ biến hơn bây giờ.
Dez Blanchfield: Vâng, và tôi nghĩ thuật ngữ Nợ kỹ thuật có thể là một người bạn quen thuộc hơn; Tôi biết Robin và tôi chắc chắn là như vậy. Tôi nghĩ rằng những ngày này, đặc biệt là trong các cách tiếp cận nhanh để phát triển và xây dựng hệ thống, với tôi, khái niệm nợ kỹ thuật bây giờ là một điều rất thực tế và chúng tôi thực sự tính đến nó trong các dự án. Tôi biết, ý tôi là, chúng tôi đã có các dự án của riêng mình như Media Lens và các dự án khác, nơi chúng tôi đã có mã hóa xảy ra hàng ngày và nhiều thứ khác nhau trong Nhóm Bloor. Và bất cứ khi nào chúng tôi xây dựng một cái gì đó, chúng tôi nhìn vào, tôi nhìn vào nó, và luôn luôn nhìn từ quan điểm về những gì nó sẽ khiến tôi phải trả giá để khắc phục điều này ngay bây giờ, so với việc tôi có thể đưa nó vào có thể và đưa nó ra khỏi đó, và sau đó xem và xem điều này sẽ phá vỡ. Và thừa hưởng khoản nợ kỹ thuật này mà tôi biết tôi sẽ phải quay lại sau và sửa.
Và ý tôi là, tôi đã làm điều đó trong bảy ngày qua: Tôi đã viết một vài công cụ và tập lệnh, tôi đã viết một vài mẩu ngôn ngữ Python và tôi đã triển khai nó cho Mongo back end, thực hiện chắc chắn rằng nó đẹp và sạch sẽ và an toàn, nhưng nó chỉ nhận được truy vấn tôi cần, biết rằng tôi cần chức năng đó để hoạt động, để đi đến câu đố lớn hơn; đó là nỗi đau thực sự của tôi Và vì vậy, bạn phải gánh chịu khoản nợ kỹ thuật này, và tôi nghĩ rằng đây không chỉ là một điều thỉnh thoảng, tôi nghĩ rằng đây là một phần của DNA phát triển bây giờ. Mọi người chỉ - không rõ ràng - họ chỉ chấp nhận nợ kỹ thuật là một loại vấn đề bình thường, và họ phải chịu nó. Đó là nơi bạn phải gánh chịu khoản nợ kỹ thuật. Và tôi nghĩ điều tuyệt vời về những gì bạn đã cho chúng tôi thấy trong bản demo là bạn có thể định nghĩa theo nghĩa đen và xem một cái gì đó sẽ mất bao lâu để chạy. Và đó có lẽ là một trong những điều yêu thích của tôi. Ý tôi là, tôi thực sự đã xây dựng các công cụ định hình - chúng tôi đã từng xây dựng các công cụ trong Sed và Lex và Orc để chạy mã của chúng tôi và xem các vòng lặp ở đâu, trước khi các công cụ như thế này có sẵn - và khi bạn đã xây dựng mã và xem lại mã của riêng bạn, bạn sẽ rất giỏi khi không phải xem lại mã của riêng mình. Nhưng đó không phải là trường hợp bây giờ. Với ý nghĩ đó, có một phân khúc thị trường cụ thể nào chiếm lĩnh điều này hơn bất kỳ phân khúc nào khác không? Nhìn giống như một khối lượng lớn
Bert Scalzo: Ồ vâng, tôi đã nhận được Tôi sẽ vẽ một sự tương tự cho bạn, và cho bạn thấy rằng những người không phải lập trình viên làm điều đó mọi lúc. Bởi vì nếu tôi từng dạy một trình gỡ lỗi và cấu hình lớp hoặc phiên, tôi sẽ hỏi mọi người, thì OK, có bao nhiêu người ở đây vào Microsoft Word và cố tình không bao giờ sử dụng trình kiểm tra chính tả? bởi vì để viết tài liệu, tất cả chúng ta đều biết mình có thể mắc lỗi tiếng Anh và vì vậy mọi người đều sử dụng trình kiểm tra chính tả. Và tôi đã nói, thưa Chà, tại sao khi bạn viết văn bản trong IDE của bạn như Visual Basic, bạn không sử dụng trình gỡ lỗi? Đó là điều tương tự, nó giống như một công cụ kiểm tra chính tả.
Dez Blanchfield: Vâng, thực sự, đó là một sự tương tự tuyệt vời. Tôi đã không thực sự nghĩ về, tôi phải thừa nhận rằng tôi thực sự làm điều gì đó tương tự với một vài công cụ tôi sử dụng. Trong thực tế, một, ODF, yêu thích của tôi với Eclipse chỉ là cắt và dán mã vào đó và tìm kiếm những thứ vừa làm nổi bật ngay lập tức và nhận ra tôi đã mắc lỗi đánh máy trong một số cuộc gọi lớp. Và, nhưng bây giờ thật thú vị với công cụ như thế này, bạn có thể làm điều đó trong thời gian thực thay vì quay lại và nhìn vào nó sau, thật tuyệt khi bắt kịp nó. Nhưng vâng, đó là một sự tương tự tuyệt vời của việc đưa văn bản vào trình xử lý văn bản, bởi vì đó là một cuộc gọi đánh thức thú vị, chỉ cần nhận ra rằng bạn đã mắc một số lỗi chính tả hoặc thậm chí là một lỗi ngữ pháp, phải không?
Bert Scalzo: Chính xác.
Dez Blanchfield: Vì vậy, bây giờ bạn có thấy nhiều sự tăng giá hơn từ tôi đoán không, ý tôi là, câu hỏi cuối cùng từ tôi, trước khi tôi gửi câu hỏi và trả lời cho những người tham dự của chúng tôi. Nếu bạn định đưa ra một số khuyến nghị xung quanh cách tiếp cận để thực hiện điều này - tôi cho rằng đây là biện pháp tu từ - đó có phải là trường hợp bạn nhận được sớm và thực hiện điều này khi bạn đang phát triển, trước khi bạn phát triển? Hoặc đó là trường hợp bạn chủ yếu được xây dựng, di chuyển, xây dựng một cái gì đó sau đó đến và hồ sơ nó sau? Tôi nghi ngờ đó là trường hợp nhận được sớm và đảm bảo mã của bạn được trả trước. Hay đó là một trường hợp mà họ nên xem xét phần này trong quá trình hậu triển khai của họ?
Bert Scalzo: Lý tưởng nhất là họ sẽ làm điều đó ngay lập tức, nhưng vì mọi người đang ở trong thế giới ồn ào, náo nhiệt, nơi họ phải hoàn thành công việc, họ có xu hướng không làm điều đó cho đến khi họ gặp phải vấn đề về hiệu suất mà họ không thể giải quyết thêm nhiều CPU và bộ nhớ vào máy ảo.
Dez Blanchfield: Vâng. Vì vậy, thực sự bạn đã đề cập đến một cái gì đó thú vị, nếu tôi có thể nhanh chóng? Bạn đã đề cập trước đó rằng điều này có thể được chạy từ bất cứ đâu và có thể nói chuyện với cơ sở dữ liệu ở phần cuối. Vì vậy, điều này thật thoải mái với loại khái niệm lưỡng kim mà chúng ta đang nói đến bây giờ, về đám mây tại chỗ / ngoài cơ sở, bởi vẻ ngoài của mọi thứ, vào cuối ngày, nếu nó có thể nói chuyện với mặt sau và xem Mã, nó không thực sự quan tâm, phải không?
Bert Scalzo: Chính xác, yeah, bạn có thể chạy cái này trong đám mây.
Dez Blanchfield: Tuyệt vời, vì tôi nghĩ đó là nơi thế giới dũng cảm mới của chúng ta sẽ đến. Vì vậy, Eric. Bây giờ tôi sẽ trả lời bạn và thấy rằng chúng tôi có một vài câu hỏi ở đây và tôi muốn những người tham dự của chúng tôi vẫn ở lại với chúng tôi, mặc dù chúng tôi đã đi qua một giờ.
Eric Kavanagh: Vâng, có một vài người ngoài kia, tôi sẽ chỉ đưa ra một nhận xét nhanh: Bert, tôi nghĩ rằng phép ẩn dụ, sự tương tự mà bạn đưa ra khi sử dụng kiểm tra chính tả thật tuyệt vời. Điều đó xứng đáng với một hoặc hai blog, khá thẳng thắn, bởi vì đó là một cách tốt để đóng khung bối cảnh của những gì bạn đang làm, và nó có giá trị như thế nào và cách thực sự tốt nhất để sử dụng trình gỡ lỗi một cách thường xuyên, phải không? Tôi cá là bạn sẽ nhận được vài cái gật đầu khi bạn ném nó ra, phải không?
Bert Scalzo: Hoàn toàn, vì những gì tôi nói với họ là, Tại sao tôi lại kiểm tra chính tả trên các tài liệu của mình? Tôi không muốn xấu hổ vì những lỗi chính tả ngu ngốc. Chà, họ không muốn xấu hổ vì những lỗi mã hóa ngu ngốc!
Eric Kavanagh: Phải. Vâng, thực sự. Chà, mọi người, chúng ta đã bị đốt cháy suốt một giờ năm phút ở đây, rất cảm ơn tất cả các bạn ngoài kia vì đã dành thời gian và sự chú ý của bạn. Chúng tôi lưu trữ tất cả các cuộc trò chuyện trên web này, vui lòng quay lại bất cứ lúc nào và kiểm tra chúng. Nơi tốt nhất để tìm các liên kết đó có lẽ là techopedia.com, vì vậy chúng tôi sẽ thêm liên kết này vào danh sách này ngay tại đây.
Và với điều đó, chúng tôi sẽ chào tạm biệt bạn, thưa các bạn. Một lần nữa, công việc tuyệt vời, Bert, nhờ những người bạn của chúng tôi từ IDERA. Thực tế, chúng tôi sẽ nói chuyện với bạn vào lần tới, thực tế là chúng tôi sẽ nói chuyện với bạn vào tuần tới. Bảo trọng! Tạm biệt.
