Я так понимаю, что под «Терпеть дальше» Вы подразумеваете «сидеть на попе ровно»? Да нет вроде, не сидим.
Как изменить ситуацию?
— Общение непосредственно с менеджером результатов не приносит. Заниматься улучшением «жизни» его подчиненных он не хочет. Сидеть и ковырять в носу — да;
— Иди к начальству рангом выше? Пробовали, ходили. Толку мало. Компания большая, пока до кого-нибудь достучишься пройдет уйма времени. В результате работа не сделана, а время потеряно;
— Устраивать бунт и проваливать проект? Ни к чему хорошему это не приведет;
— Увольняться? Все к этому и идет. Да вот только хороших коллег-товарищей не хочется терять.
Может я со своей «программерской» колокольни не вижу очевидных вещей. Укажите, пожалуйста.
Сейчас сам попал в описанную ситуацию.
Проект отстает от графика примерно на 4 месяца. Разработчикам приходится сидеть по 11-12 часов в день на работе. В организации проекта (инфраструктурной и управленческой) — полный провал со стороны менеджмента. Клиенту пишутся письма о том, что все хорошо, а на самом деле — кот наплакал. Попытки со стороны менеджмента спихнуть всю вину на разработчиков (мол, это ваша задача общаться с заказчиками, собирать с них требования, решать организационные вопросы (!)). Команда на грани бунта.
Однако, нашел в этом один плюс — вся команда (разработчки + тестеры) очень сильно сдружились и сплотились за это время (время противостояния врагу :)).
С точки зрения АйТи — сам продукт, мягко говоря, не айс. Поэтому среди айтишников не пользуется популярностью. Внедрения в основном происходят в довольно крупных компаниях и стоят ну очень дорого (ценник можно на их сайте посмотреть). Дорого — имею в виду соотношение цены/качества.
Из семи конкурсантов две первые фирмы — “Промышленные информационные системы” и “Базовые технологии” — никому из тех, с кем мы обсуждали этот конкурс, неизвестны.
Промышленные информационные системы довольно известная в Питере фирма. Занимается разработкой и внедрением системы документооборота «Globus Professional».
Примерно год работал в компании, которая занимается разработкой документооборота. Т. к. вот виндовый клиент (замечу — довольно «толстый») там написан полностью на перл с использованием Wx::Widgets.
Почему не переносим? Очень даже, проверено опытом. ;)
Как правильно было сказано — переносим со своими контрактами (важна документация данных контрактов). Кроме того, переносимость наоборот облегчается за счет снижения связанности модулей.
А уж использовать такой модуль или нет (со всеми контрактами) — решать клиенту. См. мой комментарий про пирожки ;)
так я об этом и писал чуть выше. возможны вызовы различными клиентами, соответственно, возможны и различные поведения в случае ошибки. Или вы предлагаете создать несколько типов объектов-исключений для описанного выше примера?
Кроме того, г-н Blackened написал хорошее замечание чуть выше.
>Кроме того контрактное программирование без документации, имхо, это смерть.
вот это самое главное замечание, которое я, к своему стыду, забыл упомянуть.
согласен, появляется соблазн сделать проверку внутри подпрограммы. Приведу классический пример с функцией вычисления квадратного корня (назовем ее CalcSqrt(), т.е. это будет наша функция (абстрагируясь от реализации для различных языков)).
Данная функция имеет предусловие — ее аргумент не должен быть отрицательным. Если, к примеру, пользователь вводит отрицательное, то это забота вызывающей программы проверить это число.
Одна вызывающая программа завершит работу аварийно, другая выдаст предупреждение и заставит пользователя вводить еще раз значение. А третья программа вообще схитрит — она сделает это число положительным, а потом, когда получит результат, то прибавит мнимую единицу.
Поэтому, это не забота функции CalcSqrt() обрабатывать предусловия.
//обеспечиваем предусловия для вызываемого метода
if(String.IsNullOrEmpty(objectName) || objectName.Contains(«@»))
{
//выводим сообщение об ошибке, прекращаем выполнение программы или передаем управление куда-либо
}
SomeObject some = GetSomeObject(objectName);
//т.к. мы выполнили предусловия по нашему контракту, то можем смело дергать методы объекта
//не боясь «object reference» исключения
Console.WriteLine(some.Name);
Console.WriteLine(some.Description);
...
//вызываемая программа
//нет необходимости выполнять проверку на пустую строку или еще на что-нибудь
//полагаемся на контракт
public SomeObject GetSomeObject(string objectName)
{
//по условиям контракта должны вернуть объект
SomeObject result = new SomeObject();
try
{
//собираем объект
}
catch(SomeException ex)
{
//не удалось собрать объект
//но условия контракта выполнить надо
result.Name = «Unknown name»;
result.Description = «Can't find object»;
}
Лекций, к сожалению, нет :(
Могу посоветовать вам почитать его книгу «Object-Oriented Software Construction», Bertrand Meyer, Prentice Hall, 2nd edition 1997.
Да, валидацию я выкинул. Это как раз и есть основа принципа проектирования по контракту.
Очень много литературы учит нас использовать так называемое «защитное программирование» (defensive programming) (в следующих статьях постараюсь сделать сравнение обоих подходов).
Оно и говорит, что лучше на всякий случай перестраховаться и проверить (доверяй, но проверяй ;)).
А проектирование по контракту предлагает использовать некое соглашение, контракт, чтобы убрать лишние проверки (тем самым уменьшив объем кода и упростив читабельность программы).
Попробую привести пример из реальной жизни.
Допустим, наша компания производит слоеное тесто для выпечки пирогов. С конечным покупателем (читай, пользователем) мы заключаем такой контракт:
Если покупатель предварительно 15 минут разморозит наше тесто, затем сдобрит его маслом и будет выпекать в течении 10 минут, то у него получатся вкусные пирожки.
Т.е. мы обязуемся предоставить покупателю готовый продукт при выполнении некоторых условий.
Но тут другая компания (ООО «СкоростьНашеВсе») решила помочь покупателям и продавать уже готовые горячие пирожки.
Она решила не тратить время на разморозку и выпекала всего 7 минут. В итоге, пирожки ее приготовления получились не очень вкусными и несовсем готовыми.
А вот тут уже конечному покупателю выбирать: покупать пирожки этой фирмы, обратится к другой или сделать все самому по инструкции (читай, контракту).
Также и в случае программирования. Мы всю ответственность по передачи входных данных для нашей функции возлагаем на вызывающую программу.
При этом мы обязуемся ей вернуть валидные данные (если обещали вернуть double, то вернем double, а не null).
Надеюсь, что теперь стал более понятен этот принцип.
Как изменить ситуацию?
— Общение непосредственно с менеджером результатов не приносит. Заниматься улучшением «жизни» его подчиненных он не хочет. Сидеть и ковырять в носу — да;
— Иди к начальству рангом выше? Пробовали, ходили. Толку мало. Компания большая, пока до кого-нибудь достучишься пройдет уйма времени. В результате работа не сделана, а время потеряно;
— Устраивать бунт и проваливать проект? Ни к чему хорошему это не приведет;
— Увольняться? Все к этому и идет. Да вот только хороших коллег-товарищей не хочется терять.
Может я со своей «программерской» колокольни не вижу очевидных вещей. Укажите, пожалуйста.
Проект отстает от графика примерно на 4 месяца. Разработчикам приходится сидеть по 11-12 часов в день на работе. В организации проекта (инфраструктурной и управленческой) — полный провал со стороны менеджмента. Клиенту пишутся письма о том, что все хорошо, а на самом деле — кот наплакал. Попытки со стороны менеджмента спихнуть всю вину на разработчиков (мол, это ваша задача общаться с заказчиками, собирать с них требования, решать организационные вопросы (!)). Команда на грани бунта.
Однако, нашел в этом один плюс — вся команда (разработчки + тестеры) очень сильно сдружились и сплотились за это время (время противостояния врагу :)).
Очень часто бывает так, что не звонят, не берут трубку. А через несколько дней звонит курьер и говорит, что ждет внизу.
Если это статья для начинающих, то зачем тогда Вы засоряете им мозг изначально неправильными формулировками?
На странице Unity прочитал следующее:
Added .NET 2.1 support via the Mono 2.6 runtime.
Промышленные информационные системы довольно известная в Питере фирма. Занимается разработкой и внедрением системы документооборота «Globus Professional».
Так кубка УЕФА уже не существует.
Как правильно было сказано — переносим со своими контрактами (важна документация данных контрактов). Кроме того, переносимость наоборот облегчается за счет снижения связанности модулей.
А уж использовать такой модуль или нет (со всеми контрактами) — решать клиенту. См. мой комментарий про пирожки ;)
Кроме того, г-н Blackened написал хорошее замечание чуть выше.
вот это самое главное замечание, которое я, к своему стыду, забыл упомянуть.
Данная функция имеет предусловие — ее аргумент не должен быть отрицательным. Если, к примеру, пользователь вводит отрицательное, то это забота вызывающей программы проверить это число.
Одна вызывающая программа завершит работу аварийно, другая выдаст предупреждение и заставит пользователя вводить еще раз значение. А третья программа вообще схитрит — она сделает это число положительным, а потом, когда получит результат, то прибавит мнимую единицу.
Поэтому, это не забота функции CalcSqrt() обрабатывать предусловия.
Могу посоветовать вам почитать его книгу «Object-Oriented Software Construction», Bertrand Meyer, Prentice Hall, 2nd edition 1997.
Очень много литературы учит нас использовать так называемое «защитное программирование» (defensive programming) (в следующих статьях постараюсь сделать сравнение обоих подходов).
Оно и говорит, что лучше на всякий случай перестраховаться и проверить (доверяй, но проверяй ;)).
А проектирование по контракту предлагает использовать некое соглашение, контракт, чтобы убрать лишние проверки (тем самым уменьшив объем кода и упростив читабельность программы).
Попробую привести пример из реальной жизни.
Допустим, наша компания производит слоеное тесто для выпечки пирогов. С конечным покупателем (читай, пользователем) мы заключаем такой контракт:
Если покупатель предварительно 15 минут разморозит наше тесто, затем сдобрит его маслом и будет выпекать в течении 10 минут, то у него получатся вкусные пирожки.
Т.е. мы обязуемся предоставить покупателю готовый продукт при выполнении некоторых условий.
Но тут другая компания (ООО «СкоростьНашеВсе») решила помочь покупателям и продавать уже готовые горячие пирожки.
Она решила не тратить время на разморозку и выпекала всего 7 минут. В итоге, пирожки ее приготовления получились не очень вкусными и несовсем готовыми.
А вот тут уже конечному покупателю выбирать: покупать пирожки этой фирмы, обратится к другой или сделать все самому по инструкции (читай, контракту).
Также и в случае программирования. Мы всю ответственность по передачи входных данных для нашей функции возлагаем на вызывающую программу.
При этом мы обязуемся ей вернуть валидные данные (если обещали вернуть double, то вернем double, а не null).
Надеюсь, что теперь стал более понятен этот принцип.