Здравствуйте, FDSC, Вы писали:

FDS>Здравствуйте, Dr.Gigabit, Вы писали:

DG>>Здравствуйте, minorlogic, Вы писали:


M>>>Моя логика из того же места , что и "надежность системы определяется самым СЛАБЫМ местом". Т.е. увеличивая надежность слабых мест мы увеличиваем надежность системы ( в нашем случае процесса разработки).

DG>>К слову, психологи говорят, что мужчина выбирает спутницу жизни по самому большому ее недостатку

FDS>Это как?

В том смысле что определяющим фактором является не самое лучшее достоинсто, а самый худший недостаток. Если его переносить можно -- значит жить можно

Здравствуйте, minorlogic, Вы писали:

M>6. Решайте самое непонятное в первую очередь, это снижает риски.
M>16. Далее ваши пункты в порядке приоритета! (следствие : этот текст плох, он противоречит пункту 14)

17. Старайтесь определить критические места в первую очередь и постарйтесь их решить эффективно.
Если это не удастся сделать с самого начала — дальше продолжать нецелесообразно.
18. "Щательнее..." Пишите новый код как на всегда. Потом возвращаться не будет ни времени ни желания ни памяти.
Изначально эффективный код также устраняет массу проблем с определением напрвлений оптимизации в будущем.

И последняя максима (три смысловых слоя):

19. Если можешь не программировать — не программируй.

Здравствуйте, Dr.Gigabit, Вы писали:

DG>>>К слову, психологи говорят, что мужчина выбирает спутницу жизни по самому большому ее недостатку

FDS>>Это как?

DG>В том смысле что определяющим фактором является не самое лучшее достоинсто, а самый худший недостаток. Если его переносить можно -- значит жить можно

А, понял. Наверное они правы

Здравствуйте, c-smile, Вы писали:

CS>17. Старайтесь определить критические места в первую очередь и постарйтесь их решить эффективно.
CS>Если это не удастся сделать с самого начала — дальше продолжать нецелесообразно.

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

CS>18. "Щательнее..." Пишите новый код как на всегда. Потом возвращаться не будет ни времени ни желания ни памяти.
CS>Изначально эффективный код также устраняет массу проблем с определением напрвлений оптимизации в будущем.

Если писать изначально эффективный код, можно не написать вообще ничего (обсуждение в форуме здесь

Автор: FDSC
Дата: 16.08.06

). Тут лучше сказать "пишите качественный код, который не работает убойно медленно".

CS>19. Если можешь не программировать — не программируй.

Или, переформулируя, настоящий программист не тот, кто программирует, а тот кто не может не программировать.

Здравствуйте, FDSC, Вы писали:

CS>>19. Если можешь не программировать — не программируй.

FDS>Или, переформулируя, настоящий программист не тот, кто программирует, а тот кто не может не программировать.

Может речь шла о том чтобы 7 раз подумать , а потом опять подумать ? и если уже не остается других вариантов, писать код ? Автор изречения прокомментируйте плиз !

Здравствуйте, minorlogic, Вы писали:

M>16. Далее ваши пункты в порядке приоритета! (следствие : этот текст плох, он противоречит пункту 14)

Еще до того, как Вы стали писать программу продумайте систему ошибок, и как ошибки
взаимодействуют друг с другом. Сформулировано прикольно, но действительно об этом надо думать.

Здравствуйте, FDSC, Вы писали:

FDS>Здравствуйте, minorlogic, Вы писали:

M>>Здравствуйте, Андрей Хропов, Вы писали:

M>>>>6. Решайте самое непонятное в первую очередь, это снижает риски.
АХ>>>Не соглашусь. Часто бывает лучше наоборот, сначала сделать простую, понятную часть системы. Так хотя бы она будет сделана.
АХ>>>А то начав копать сложную часть можно застрять так, что вообще ничего сделано не будет.

M>>Ну это довольно принципиально.
M>>Представим что мы делаем автомобиль. Мы умеем делать все кроме двигателей. Мы можем сделать 90 проценто , но не сделать двигателя. В итоге получившийся автомобиль никому не нужен.

FDS>Возможно, мы получим прекрасную подвеску, прекрасную трансмиссию, прекрасный кузов и оформление салона. А двигатель можно будет купить или заказать. На крайний случай, всё это можно продать.

Вот так Поликарпов и угробил свой И-180.
А Королев свою Н1.

Здравствуйте, FDSC, Вы писали:

FDS>Здравствуйте, minorlogic, Вы писали:

FDS>С другой:
M>>13. Восхищайтесь людям которые умеют создать проблему и ГЕРОИЧЕСКИ ее решить ! Это великие люди ! (следствие : держитесь от них подальше , предмет восхищения должен быть недосягаем !!!)

FDS>Следовательно: любовь должна быть несчастной ! А раз любовь должна быть несчастной, то эта девушка врядли будет твоим другом, так как она героически решает проблемы, созданные тобой . В общем девушки не создают себе столько проблем одновременно: и встречатся с глючным программистом, и тестировать его глючный код , они слишком умны для этого...

"любовь должна быть несчастной"
Поздравляю. Догнал самого Шекспира.
Тот сказал примерно тоже самое — "Настоящая любовь должна быть несчастной".
Он имел в виду, что только несчастная любовь напрягает ВСЕ интелектуальные
и душевные силы, только такая любовь позволяет душе совершенствоваться.

Здравствуйте, minorlogic, Вы писали:

M>Здравствуйте, FDSC, Вы писали:

CS>>>19. Если можешь не программировать — не программируй.

FDS>>Или, переформулируя, настоящий программист не тот, кто программирует, а тот кто не может не программировать.

M>Может речь шла о том чтобы 7 раз подумать , а потом опять подумать ? и если уже не остается других вариантов, писать код ? Автор изречения прокомментируйте плиз !

Используйте труд других программистов (предшественников) (с) Керниган и Ричи.
Деталь, которой нет в ракете, сломаться не может (с) Королев.

Здравствуйте, minorlogic, Вы писали:

M>4. Ленивое принятие решений , принимайте решение тольо тогда когда оно очевидно , до тех пор затягивайте ... Бойтесь принятия решений , в большинстве они ошибочны !!! (следствие , дайте возможность совершать как можно большее к-во ошибочных решений) (следствие2: ВСЕГДА можно придумать решение получше !!! )
M>6. Решайте самое непонятное в первую очередь, это снижает риски.

А как же пункт 4?
Иногда бывает так, что самое сложное и непонятное настолько сложно и непонятно, что даже не знаешь, что собственно надо решать, и в какую сторону думать и что вообще надо и с чего вообще начать.
В таких случаях мне лично помогает решить несколько более мелких задач, даже если их решишь неправильно, но хотя бы становится видно, в какую сторону дамать и что вообще надо сделать. Тогда уже можно переходить к самому сложному и непонятному.
Например, думаешь вот сейчас спроектирую интерфейс самого центрового класса и потом всё пойдёт как по маслу. Сидишь, тупишь пару часов выжимаешь какой-то надуманный интерфейс, а потом начинаешь писать остальные классики и понимаешь, что от главного-то класса нужно было совсем другое и совсем не с таким интерфейсом.

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


з.ы. сам подборку составлял?

Здравствуйте, minorlogic, Вы писали:

M>16. Далее ваши пункты в порядке приоритета! (следствие : этот текст плох, он противоречит пункту 14)

17. Концептуальная целостность!
Делайте одинаковые вещи одинаковым способом. Гораздо более выгодно выглядит стройная, целостная система, пусть даже немного за счёт этого ограниченная в возможностях, чем система, являющаяся пёстрым сборищем разнородных "фич".
(вольный пересках Фреда Брукса, который писал это ещё в 60-е годы, к сожалению многие разработчики и сейчас не дошли до этого)
(правда, он писал это про UI, но это не в меньшей степени относится к внутренней организации программы)
(я бы этот пункт переместил значительно ближе к началу списка)

Здравствуйте, alpha21264, Вы писали:

A>А Королев свою Н1.

Спорно. Объективных фактов о том, что в последнем полете виноват был НК-15, нет, хотя конечно ОКБ-1 косило на них. А в остальных авариях были виноваты другие причины — ошибки в системе управления, проблемы с трубопроводами и т.п.

Здравствуйте, alpha21264, Вы писали:

A>Здравствуйте, FDSC, Вы писали:

FDS>>Здравствуйте, minorlogic, Вы писали:

M>>>Здравствуйте, Андрей Хропов, Вы писали:

M>>>>>6. Решайте самое непонятное в первую очередь, это снижает риски.
АХ>>>>Не соглашусь. Часто бывает лучше наоборот, сначала сделать простую, понятную часть системы. Так хотя бы она будет сделана.
АХ>>>>А то начав копать сложную часть можно застрять так, что вообще ничего сделано не будет.

M>>>Ну это довольно принципиально.
M>>>Представим что мы делаем автомобиль. Мы умеем делать все кроме двигателей. Мы можем сделать 90 проценто , но не сделать двигателя. В итоге получившийся автомобиль никому не нужен.

FDS>>Возможно, мы получим прекрасную подвеску, прекрасную трансмиссию, прекрасный кузов и оформление салона. А двигатель можно будет купить или заказать. На крайний случай, всё это можно продать.

A>Вот так Поликарпов и угробил свой И-180.
A>А Королев свою Н1.

Там были проблемы чисто управленческого плана (если вы про аутсорсинг), а в СССР их не умели решать. Для интереса, узнайте, сколько боинг заказывает, а сколько производит сам.

Здравствуйте, FDSC, Вы писали:

FDS>Там были проблемы чисто управленческого плана (если вы про аутсорсинг), а в СССР их не умели решать. Для интереса, узнайте, сколько боинг заказывает, а сколько производит сам.

А вы думаете, сухой сам двигатели проектирует? И сам их изготавливает? И ведь ничего плохого не происходит — летают, вроде.

Здравствуйте, remark, Вы писали:

R>з.ы. сам подборку составлял?

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

Здравствуйте, FDSC, Вы писали:

FDS>Здравствуйте, alpha21264, Вы писали:

A>>Вот так Поликарпов и угробил свой И-180.
A>>А Королев свою Н1.

FDS>Там были проблемы чисто управленческого плана (если вы про аутсорсинг), а в СССР их не умели решать. Для интереса, узнайте, сколько боинг заказывает, а сколько производит сам.

Двигатель всегда делает другая организация. Но я про другое.
И Королев и Поликарпов положили в основу двигатели, которых на тот
момент еще не было, и не было известно получатся ли они.

Ну почитал я про Чертока. Там действительно проблемы были в управлении.
Вот только возникли они ровно потому, что нужно было отключать
сломавшиеся в полете двигатели. Такой блок был только на Н1.
Ни до ни после такое устройство не применялось (не нужно было).

А от наземных тестов Королев отказался из-за экономии. В итоге вышло дороже.

Здравствуйте, minorlogic, Вы писали:

M>Здравствуйте, remark, Вы писали:

R>>з.ы. сам подборку составлял?

M>Угу , это то что накипело в последнее время. Возможно не самое главное , но довольно актуально лично для меня.

А что за такие личные, серьёзные проблемы с целесообразностью? За предприятии любят вначале делать, а потом думать зачем?

Здравствуйте, alpha21264, Вы писали:

A>Здравствуйте, FDSC, Вы писали:

FDS>>Здравствуйте, alpha21264, Вы писали:

A>>>Вот так Поликарпов и угробил свой И-180.
A>>>А Королев свою Н1.

FDS>>Там были проблемы чисто управленческого плана (если вы про аутсорсинг), а в СССР их не умели решать. Для интереса, узнайте, сколько боинг заказывает, а сколько производит сам.

A>Двигатель всегда делает другая организация. Но я про другое.
A>И Королев и Поликарпов положили в основу двигатели, которых на тот
A>момент еще не было, и не было известно получатся ли они.

A>Ну почитал я про Чертока. Там действительно проблемы были в управлении.
A>Вот только возникли они ровно потому, что нужно было отключать
A>сломавшиеся в полете двигатели. Такой блок был только на Н1.
A>Ни до ни после такое устройство не применялось (не нужно было).

A>А от наземных тестов Королев отказался из-за экономии. В итоге вышло дороже.

Это пример неграмотного управления и проектирования. Пусть даже Королёвым. На некоторые самолёты можно поставить несколько совершенно различных марок двигателей: и ничего. Потому что они так спроектированы. Проще говоря, если у кого-то не получилось, это ешё не значит, что не получиться у всех остальных.

Здравствуйте, alpha21264, Вы писали:

A>Двигатель всегда делает другая организация. Но я про другое.
A>И Королев и Поликарпов положили в основу двигатели, которых на тот
A>момент еще не было, и не было известно получатся ли они.

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

A>Ну почитал я про Чертока. Там действительно проблемы были в управлении.
A>Вот только возникли они ровно потому, что нужно было отключать
A>сломавшиеся в полете двигатели.
A> Такой блок был только на Н1.
A>Ни до ни после такое устройство не применялось (не нужно было).

И это тоже нормально. В Сатурн-5 было то же самое. И сейчас так многие ракеты умеют, например Протон тот же успешно завершает полет при отказе одного из шести двигателей первой ступени.

A>А от наземных тестов Королев отказался из-за экономии. В итоге вышло дороже.

Совершенно не факт, что наземные тесты чем либо помогли. Отказы системы управления они бы не выявили.
Вон УКСС когда использовали, главная задача была чтобы взрыв движков не разнес стенд к чертовой бабушке. Ну разнесло бы в случае Н-1 вместо старта стенд, чем бы это помогло?

Здравствуйте, remark, Вы писали:

R>Здравствуйте, minorlogic, Вы писали:

M>>Здравствуйте, remark, Вы писали:

R>>>з.ы. сам подборку составлял?

M>>Угу , это то что накипело в последнее время. Возможно не самое главное , но довольно актуально лично для меня.

R>А что за такие личные, серьёзные проблемы с целесообразностью? За предприятии любят вначале делать, а потом думать зачем?

R>

Если бы ! даже делать не пытаются