Google Tech TalksJuly, 25 2007ABSTRACTThis talk begins with an overview of software development at Adobe and a look at industry trends towards systems built ...
Nie wiem czemu rozwój oparty na przybliżeniu nie jest ci bliski. Sam deklarowałeś, że dobrze jest widzieć wynik działania jak najszybciej. A potem dążyć do jego ulepszania.
Takie podejście jest poprawne na etapie tworzenia software’u.
Jako developer chcę zobaczyć jak najszybciej wynik, bo łatwiej wtedy znaleźć i poprawić błędy.
Ja mam na myśli przypadki, w której produkcyjna wersja ma wyciętą obsługę pewnych stanów, bo “taka sytuacja nie powinna wystąpić w praktyce”.
Clownstrike też nie powinien wystąpić w praktyce.
Pamiętam jak dziadek z Microsoftu opowiadał historię o debugowaniu stosu USB w Windows.
Mieli jakiś wózek z różnymi urządzeniami podpiętymi do huba i podłączali go losowo do komputera pracowników. W pierwszych wersjach często kończyło się to BSODem i poprawianiem sterownika.
Na tym polega dbałość o szczegóły i jakość software’u. Nieważne, że w praktyce klient prawdopodobnie nie ma 64 urządzeń podłączonych do portu USB.
Pamiętam tę historię. Nie widzę tu dbałości o szczegóły. Raczej widzę, że wózek z donglami był przybliżeniem działania. Dbałość bym widział gdyby kod działał. Coś jak opowieść pana od portowania NT na x86-64. Kiedy zanieśli płytę do AMD i wszystko zadziałało na realnym sprzęcie.
Przypomniałeś mi, że podobny problem z USB stał się exploitem pewnej konsoli.
Takie podejście jest poprawne na etapie tworzenia software’u.
Jako developer chcę zobaczyć jak najszybciej wynik, bo łatwiej wtedy znaleźć i poprawić błędy.
Ja mam na myśli przypadki, w której produkcyjna wersja ma wyciętą obsługę pewnych stanów, bo “taka sytuacja nie powinna wystąpić w praktyce”.
Clownstrike też nie powinien wystąpić w praktyce.
Pamiętam jak dziadek z Microsoftu opowiadał historię o debugowaniu stosu USB w Windows.
Mieli jakiś wózek z różnymi urządzeniami podpiętymi do huba i podłączali go losowo do komputera pracowników. W pierwszych wersjach często kończyło się to BSODem i poprawianiem sterownika.
Na tym polega dbałość o szczegóły i jakość software’u. Nieważne, że w praktyce klient prawdopodobnie nie ma 64 urządzeń podłączonych do portu USB.
Pamiętam tę historię. Nie widzę tu dbałości o szczegóły. Raczej widzę, że wózek z donglami był przybliżeniem działania. Dbałość bym widział gdyby kod działał. Coś jak opowieść pana od portowania NT na x86-64. Kiedy zanieśli płytę do AMD i wszystko zadziałało na realnym sprzęcie.
Przypomniałeś mi, że podobny problem z USB stał się exploitem pewnej konsoli.
Ale przynajmniej mieli świadomość, że problem z USB istnieje i podjęli jakieś działania, zamiast zamiatać go pod dywan.
Istniały inne problemy o których nie mówili. Potem i tak przepisali ten stos na jakiś inny język.
Masz rację. To więcej niż firmy które wcale nie robią realnych testów albo nawet nie robią prototypu i badań.