Comments 18
Все это конечно просто ужасно, и индусы, не ставящие комментариев в коде, достойны самой мучительной смерти, но, с другой стороны, не может ли быть в этой истории мораль: «не знаешь — не лезь, или, как минимум, согласуй свои действия»?
Уже после внесенных модификаций, ваш друг сам сообщил об этом? Устройство тестировали? Ведь как не крути, модификация достаточно серьезная.
Уже после внесенных модификаций, ваш друг сам сообщил об этом? Устройство тестировали? Ведь как не крути, модификация достаточно серьезная.
У меня в практике достаточно давно был случай. Делал я тогда программы для станков с ЧПУ фрезереных, программы были достаточно большими — бывало и сутки напролет станок одну выполнял. Сами они хранились на сервере, а на станки попадали с управляющих компов. И вот нашолся у меня там доморощенный оператор — «Кулибин», который поправил одну программу — уменьшил в программе величину отскока на безопасное расстояние (сделать то это достаточно просто в принципе было обычным replace в текстовом редакторе). Все здорово у него прошло, на его станке, но одного не учел доморощенный Кулибин, что способ крепления деталей к станку не везде одинаков. Вобщем пришлось мне потом искать с чего бы вдруг у меня на другом станке на бешеной скорости дорогущая японская фреза расхреначила в драбадан приспособление на станке и грохот стоял аж на трех этажах было слышно.
Самая основная мораль: инициатива наказуема. Очень и очень во многих случаях :)
А провести испытания на тестовом образце перед выпуском в продакшн можно было? =)
Не сломано — не чини.
Вспомнился анекдот:
Сидит программист далеко в отладке.
Подходит сынишка:
— Папа, почему солнышко каждый день встает на востоке, а садится на западе?
— А ты это проверял?
— Проверял.
— Хорошо проверял?
— Хорошо.
— Работает?
— Работает.
— Каждый день работает?
— Да, каждый день.
— Тогда, ради бога, сынок, ничего не трогай, ничего не меняй!
Сидит программист далеко в отладке.
Подходит сынишка:
— Папа, почему солнышко каждый день встает на востоке, а садится на западе?
— А ты это проверял?
— Проверял.
— Хорошо проверял?
— Хорошо.
— Работает?
— Работает.
— Каждый день работает?
— Да, каждый день.
— Тогда, ради бога, сынок, ничего не трогай, ничего не меняй!
Увидев картинку, подумал что речь пойдет об оптимизации генетического кода :(
Интересно, а кто так спроектировал *собственное* устройство, что его можно было перегреть, составив должным образом *собственную* программу? Ежу понятно, что программа не останется неизменной и рано или поздно будет риск более высокого перегрева. Я убежден что девайс должен держать любую нагрузку, которая потенциально может возникнуть. Можно было и алюминиевую плашку на микросхему прицепить из осторожности. Второй вариант — описать возможность перегрева в документации и сделать тест для проверки, не делает ли прога лишнего. А индуса — повесить за яйца над входом в офис, чтоб другим неповадно было такую хрень лепить.
В большой конторе должен быть отдел тестирования, да и меняешь что-то серьезное — протестируй хотя бы сам.
Не хотелось бы работать в такой конторе. Пусть даже она будет первой в топе из-за:
1) монтиторинг траффика (казалось бы: занимайся чем хочешь, абы работа была выполнена в сроки и качественно, но нет же)
2) отсутствие права на ошибку. ошибаются все и всегда. для определения ошибок программиста и существуют отделы тестирования.
Раз уж уволили программиста, надо было полконторы разгонять:
* отдел железа: не додумали нормальное охлажение девайса;
* отдел тестирования: не выявили проблему перед выпуском;
* Project Manager нашего программиста: он был в курсе всех изменений, что делаются;
список можно продоложать долго.
1) монтиторинг траффика (казалось бы: занимайся чем хочешь, абы работа была выполнена в сроки и качественно, но нет же)
2) отсутствие права на ошибку. ошибаются все и всегда. для определения ошибок программиста и существуют отделы тестирования.
Раз уж уволили программиста, надо было полконторы разгонять:
* отдел железа: не додумали нормальное охлажение девайса;
* отдел тестирования: не выявили проблему перед выпуском;
* Project Manager нашего программиста: он был в курсе всех изменений, что делаются;
список можно продоложать долго.
1. Не зная брода — не лезь в воду.
А свяжись с тем индусом и узнай — why in that way?
2. Код без комментариев — это плохо.
И всё-таки свяжись с тем индусом и узнай — why in that way?
3. Бюрократическая машина — это ужасно.
Не факт, без неё бы вааще всё могло накрыться мохнаткой. Лучше неё пока ниче люди не придумали.
4. Руководство, которое не дает второго шанса — это кошмар.
Не факт, ибо я бы побоялся такому товарищу давать второй шанс понести убытки в ИКС лимонов.
А свяжись с тем индусом и узнай — why in that way?
2. Код без комментариев — это плохо.
И всё-таки свяжись с тем индусом и узнай — why in that way?
3. Бюрократическая машина — это ужасно.
Не факт, без неё бы вааще всё могло накрыться мохнаткой. Лучше неё пока ниче люди не придумали.
4. Руководство, которое не дает второго шанса — это кошмар.
Не факт, ибо я бы побоялся такому товарищу давать второй шанс понести убытки в ИКС лимонов.
На мой взгляд отвечать должен менеджер, или руководитель разработки, т.к. программист свой участок выполнил правильно, а дальше должен быть человек, чтоб соеденить блоки в одно целое, и проверить что все вместе эффективно и правильно работает (в т.ч. отдав на тестирование), а ту т получилось что свалили вину на программиста.
Я чужой код (отданный на сопровождение) боюсь трогать пока не сломается. ))
Sign up to leave a comment.
Про оптимизацию кода