долгожданный костыль к Postgresql

Проблема down time при смене версий Postgresql похоже начала решаться.
Надо будет пощупать и возможно это снимет все наши вопросы.

Code review check-list

Честно спизжены из O'Reilly, Applied Software Project Management. Перевод на русский выполнен мной.

1. Ясность
   
   
   
   1. Ясен ли код и просто ли его понимать?
   
   
   2. Усложнил ли программист неоправданно часть кода?
   
   
   3. Может ли код быть подвергнут рефакторингу для его ясности.
   
   
   
   



2. Управляемость
   
   
   
   1. Будут ли другие программисты способны поддерживать этот код?
   
   
   2. Хорошо ли код откомментирован/документирован?
   
   
   
   


3. Точность
   
   
   
   1. Решает ли код поставленную задачу?
   
   
   
   2. Если реализован алгоритм, реализован ли он корректно?
   
   
   
   


4. Надежность и Устойчивость
   
   
   
   1. Устойчив ли код к проблемам? Устойчив ли он к ошибкам?
   
   
   2. Способен ли он обрабатывать предельные условия и плохой ввод?
   
   
   3. Способен ли он корректно аварийно завершаться при возникновении неожиданных условий?
   
   
   
   
   


5. Безопасность
   
   
   
   1. Подвержен ли этот код рискам неавторизованного доступа, неправильного использования и модификации?
   
   
   
   


6. Масштабируемость
   
   
   
   
   1. Может ли этот код быть «иголочным ушком» препятствующим устойчивости системы при росте нагрузки, данных, пользователей и ввода данных?
   
   
   
   


7. Повторное использование
   
   
   
   1. Может ли код быть повторно использован в других модулях и системах?
   
   
   2. Можно ли его сделать более общим?
   
   
   
   
   


8. Эффективность
   
   
   
   1. Может ли этот код более эффективно использовать системные ресурсы?
   
   
   2. Может ли он быть оптимизирован?
   
   
   
   

Завтра думаю пройтись по коду ничего не подозревающих программистов. Боюсь, правда, что будет 2 из 16 :)

к вопросу о менеджменте

Не побежит капитан тушить пожар в машинном отделении. Не пойдет он затыкать пробоину в днище. Но знать обо всем этом, увязать, соотнести, выделить главное, оценить, принять решение и дать главную, решающую команду исполнителю, который лучше умеет и должен справиться, — вот роль капитана.

И в любом случае капитан воздушного судна обязан быть личностью, умеющей оценить обстановку — и не только в воздухе, — взять на себя ответственность и известный риск, принять решение, дать команду, проконтролировать ее, исправить руками, если подчиненный ошибся, — и решить задачу так, чтобы люди, сидящие за его спиной, ничего не почувствовали, кроме восхищения.

Командир экипажа должен организовать его работу. По возможности так, чтобы эта работа вызывала у экипажа, скажем, чувство удовлетворения.

© Василий Васильевич Ершов. Раздумья ездового пса

Очень близко к требованиям выдвигаемым к IT-менеджеру. Правда вот беда, не всегда господа it-менеджеры это понимают.

Попробуем еще раз

В прошлый раз я пытался вести эти записки на WordPress.com. С учетом того, что они режут по живому и неаккуратно, теперь они будут вестись здесь.