Добрый день!
Я прекрасно понимаю, что именно надо делать в каждой конкретной ситуации...
Поэтому, пожалуйста, не создавая "лишнего кода", выполните детализацию (ниже дубль с небольшим рефакторингом):
1. Параметры командной строки, или переменных окружения при сборке программы.
Например в каком-то конкретном случае нужно, чтобы PYTHON_PATH содержал дополнительный каталог.
Раздробите эту строку. Перечислите все случаи, имеющие отношение к проекту, когда требуется дополнительный каталог:
1.1. ......................
1.2. ......................
1.3. ......................
1...........................
1.N. ......................
2. Завершите предложения:
2.1. "Поскольку при использовании PowerBuilder не стоит использовать частичную сборку, а надо пересобирать программу целиком, в проекте которым я руковожу .................................................."
2.2. "Поскольку Visual Studio нужно периодически выгружать и снова запускать, в проекте которым я руковожу .................................... "
3. "Программа, неправильно собранная PowerBuilder, может начать работать, но неожиданно начать глючить в самых замысловатых местах".
3.1. Перечислите на примерах, что означает для Вашего проекта (а не вообще) фраза "неправильно собранная":
Пример 1 (неправильной сборки). ....................................................
Пример 2 (неправильной сборки). ....................................................
Пример 3 (неправильной сборки). ....................................................
.............................. и т.д. ....................................................................
Пример N (неправильной сборки). ....................................................
3.2. Приведите 2-3 конкретных примера "замысловатых мест", но не вообще, а имеющих отношения к Вашему проекту.
после 3-х часовой процедуры тщательно описанной в специальном руководстве установки и настройки сложного и дорогого программного пакета он, что характерно, отказывается работать! И отказывается до тех пор, пока при установке (!) ОС (Windows тогда еще 95) (...) и т.д.
Эта история имеет отношение к проекту, которым Вы руководите сейчас? Если имеет, я попрошу детализировать задачу.
...такое происходит повсеместно,..
Нет.
...можете поинтересоваться у разработчиков движка Вашего форума...
Поскольку я сам составлял ТЗ, разрабатывал стандарты описания функций, стандарт на документирование, распределял работы, устанавливал сроки, а также разработал модель зарплаты программистов и упражнения для проверки их квалификации - этот пример "не катит".
Одно из базовых эмпирических правил программирования - "любая непустая программа содержит ошибки. Если вы не обнаружили ошибок - значит, их количество четно".
Фразы о том, что любая программа содержит ошибки обычно используются в следующем контексте: "Будьте скромнее. Как бы Вы (или кто-нибудь еще) высоко не оценили Ваш проект, Вы (как разработчик) должны исходить из предположения, что ошибка, тем не менее, всегда возможна. Нет таких систем, которые нельзя улучшить".
С этой точкой зрения я совершенно согласен. С ней согласен любой разумный человек. И любому разумному руководителю такая позиция по душе. Но совершенно понятно, что это не снимает с Вас задачи: совершенствовать проект так, чтобы минимизировать число ошибок. Более того, о том и речь.
Вы же, сохраняя содержание фразы, меняете контекст её применения. Вы, как бы, говорите: "Поскольку любая программа может содержать ошибки, то и глючность программ - совершенно естественное их состояние". Это не так. Это называется "передвижка тезиса в другой контекст". Не делайте таких "передвижек".
И поэтому в проекте, которым я руководил, и в проектах, которыми я буду руководить, протокол техпроцесса и другие бумажки и/или хитрые цифровые штучки, такие как вики, багтрекеры и так далее, будут играть ту роль, которую они и заслуживают - инструментов, которыми пользуются люди с их уникальными знаниями, способностями и опытом.
И поэтому выводы, которые Вы делаете из ложных посылов (см. выше) - также ложны.
А верный вывод такой: Вы (равно любой разработчик) должны стремиться создать проект, который будет неглючно работать в отсутствие Автора, который будет обладать требуемой функциональностью, но при этом сопровождаться так легко и ясно, что для его сопровождения не потребуются люди с уникальными знаниями, способностями и опытом.
...Продолжая Ваш шаблон - "в проекте, которым я руковожу, " человек, работающий в Кампании только ЗА ДЕНЬГИ, просто не приживется. Не потому, что кто-то специально будет его выживать, нет, ему просто будет неинтересно (деньги не те)...
Послушайте, если "деньги не те", то это надо обсуждать с работодателем - на то и бизнес. Говорить же "мне здесь мало платят, я работаю "за идею" и т.п. - это зачастую лукавство, имеющее целью заложить в будущее самооправдание: "А что Вы хотели за такие деньги" и т.п. или иное аналогичное. По сути, это попытка получить особые привилегии "за альтруизм". Но "любой человек, претендующий на особые полномочия, права или привилегии, исходя из альтруистических, а не эгоистических побуждений, должен вызывать сильное подозрение". (М.Тэтчер)
Иными словами: согласились работать на таких условиях = надо работать ОК и не пенять.
а другим - неинтересно с ним (а чо он техзадания ждет?).
Если техзадания нет, это очень плохо. И если кто-то обязан его сделать, а не сделал, то должен быть наказан. А тот, кто ждет ТЗ, вправе требовать. А Вы, как руководитель, должны позаботиться о том, чтобы ТЗ появилось в срок и было выполнено по стандарту.
Да, такой подход грозит проблемами при смене состава - но это тот подход, который единственный приводит к появлению чего-то нового - а это одна из основных моих задач.
Ни к чему новому это не приводит. Это приводит только к тому бардаку, перед которым Вы стоите.
Так заказчику или компании?
В вышеприведеном сообщении имелась в виду компания-разработчик. Конечный Клиент приобретает объем прав по лицензионному соглашению.
а как считать решения, пришедшие между третьим и четвертым часом ночи? Или их следует забывать по прибытию на рабочее место? Мозг не включается и не выключается по звонку. Можно отсчитывать по техзаданию - но куда девать то полезное, что сделано за его рамками?
Во-первых, эта ситуация гипотетическая и по своему мифологичная. Про нее обычно рассказывают те, кто крепко спит и не хочет заниматься документированием или составлением ТЗ. Во-вторых, существуют бонусы за решения/идеи, в т.ч., не связанные с выполнением текущего задания (например, в компании, которой я руковожу, их выплачивают). Это не избавляет от необходимости в срок и качественно выполнить текущее задание.
Если Ваш работодатель обратится, можем прислать модель.
Понимаете, можно найти любое решение = было бы желание. А разве оно (желание) у Вас есть? Вы ведь когда пишете: как считать решения, пришедшие между третьим и четвертым часом ночи? Или их следует забывать по прибытию на рабочее место и т.п.,
Вы просто кидаете риторические вопросы, полагая, что ответа они не требуют. Равно моделируете ситуацию оправдания недобросовестных поступков (например, распространение оплаченной работы).
Легко быть философом за чужой счет. Вы сначала сами
Отрезать нафиг "лишнюю функциональность", как делают в HP, судя по приведенной вами ссылке? Да, так можно сделать 25-ю версию драйвера, и если я буду заниматься производством драйверов, я так и буду поступать.
Когда Вы достигнете уровня НР, мы с Вами обсудим и этот вопрос.
Всего хорошего,