Постмортем у програмуванні

Постмор­тем (англ. post-mortem, від лат. post mortem) — це посмер­тна фото­гра­фія, зви­чай фото­гра­фу­ва­н­ня помер­лих людей у XIX сто­літ­ті. Як це спів­і­дно­си­ться з програмуванням?

Зазви­чай їх фото­гра­фу­ва­ли в тако­му одя­зі та позах, немов вони були живи­ми. Помер­лих роз­та­шо­ву­ва­ли на дива­нах, крі­слах тощо. Най­ча­сті­ше фото­гра­фію роби­ли спіль­но з живи­ми родичами.

При­мі­тка від пере­кла­да­ча: post mortem фото дово­лі кри­по­ві. Не раджу гугли­ти якщо у вас слаб­ка психіка.

Однак цей блог про­гра­міст­ський, тому тут ми опи­ше­мо постмор­тем у про­гра­му­ван­ні. У про­гра­му­ван­ні постмор­те­мом нази­ва­є­ться неве­ли­ка ста­т­тя, напи­са­на після яко­їсь вели­кої помил­ки або про­ва­лу. Вона має від­по­від­а­ти на такі запитання:

• Що ста­ло­ся?
• Чому це сталося?
• Що зро­бле­но, щоб цьо­го біль­ше не відбувалося?

Постмор­те­ми можуть писа­ти­ся в Confluence або в систе­мі кон­тро­лю вер­сій. Дуже важли­во в про­це­сі напи­са­н­ня постмор­те­му не шука­ти цапа-від­бу­вай­ла, а про­сто деталь­но і неупе­ре­дже­но нама­га­ти­ся опи­са­ти ситу­а­цію. Зібра­на таким чином інфор­ма­ція має допо­мог­ти запо­біг­ти поді­бним помил­кам і про­ва­лам у майбутньому.

Постмор­те­ми можуть писа­ти­ся, напри­клад, після про­ва­лу вашої соці­аль­ної гри або невда­ло­го при­дба­н­ня сер­ві­су таксі. Основ­ним зав­да­н­ням постмор­те­ма є зов­сім не пошук вин­них, пока­ра­н­ня невин­них і наго­ро­дже­н­ня непри­че­тних, як це часто буває в суча­сній кор­по­ра­тив­ній куль­ту­рі. Нав­па­ки, він має нести кори­сну інфор­ма­цію про подію для май­бу­тніх поко­лінь, яка могла б їм допо­мог­ти не роби­ти поді­бних помилок.

У зви­чай­ної люди­ни пер­шою реа­кці­єю на вели­кий про­вал може бути бажа­н­ня звіль­ни­ти всіх вико­нав­ців, які докла­ли руку до цьо­го. З пси­хо­ло­гі­чно­го погля­ду таке бажа­н­ня ціл­ком зро­зумі­ле. Але тут потрі­бно розу­мі­ти, що про­грам без поми­лок не буває. Усі наші мето­ди­ки, спря­мо­ва­ні на полі­пше­н­ня яко­сті про­грам­но­го забез­пе­че­н­ня, лише під­ви­щу­ють його надій­ність, але ство­ре­н­ня абсо­лю­тно без­по­мил­ко­вої про­гра­ми, іде­аль­ної про­гра­ми, такої про­гра­ми, яка була б позбав­ле­на всіх поми­лок, яка б не місти­ла жодної помил­ки, неможливе.

Отже, при­пу­сти­мо, ви силь­но обла­жа­ли­ся. Нева­жли­во, чи був це ваш пет-про­ект, чи щось комер­цій­не. Важли­во прийня­ти, що про­ва­ли тра­пля­ю­ться. Про­ва­ли неми­ну­чі. Shit happens. Навіть меди­чне обла­дна­н­ня зав­жди містить помил­ки (у таких випад­ках слід зга­ду­ва­ти Therac 25).

Після прийня­т­тя факту, що світ не іде­аль­ний, потрі­бно поду­ма­ти, що ми може­мо зро­би­ти, щоб усу­ну­ти помил­ку, і що ми може­мо зро­би­ти, щоб уне­мо­жли­ви­ти вини­кне­н­ня поді­бних поми­лок у майбутньому.

Не вар­то тисну­ти на сво­їх під­ле­глих, не вар­то шука­ти цапа-від­бу­вай­ла, оскіль­ки в тако­му разі атмо­сфе­ра все­ре­ди­ні вашо­го коле­кти­ву ста­не напру­же­ною. Поси­ля­ться всі полі­ти­чні ігри. До вас пере­ста­нуть дохо­ди­ти відо­мо­сті про справ­жній стан справ, оскіль­ки всі боя­ти­му­ться нега­тив­них наслід­ків. Ви жити­ме­те в яко­мусь вига­да­но­му ілю­зор­но­му сві­ті з роже­ви­ми єди­но­ро­га­ми і хма­ра­ми, тоді як у реаль­но­сті від­бу­ва­ти­ме­ться пов­ний кошмар.

Ваше зав­да­н­ня збе­рег­ти спо­кій, а також, за можли­во­сті, заспо­ко­ї­ти колег. Після чого слід скла­сти план дії щодо виправ­ле­н­ня про­бле­ми, усу­ну­ти про­бле­му, потім вжи­ти захо­дів щодо уне­мо­жлив­ле­н­ня поді­бних ситу­а­цій у майбутньому.