1. Целесообразность.
2. Архитектура нужна разработчикам, архитектуре нужны разработчики. (это важно !!! очень!!! )
3. a: Итерационность, b: Итерационность, c: Итерационность ...
4. Ленивое принятие решений , принимайте решение тольо тогда когда оно очевидно , до тех пор затягивайте ... Бойтесь принятия решений , в большинстве они ошибочны !!! (следствие , дайте возможность совершать как можно большее к-во ошибочных решений) (следствие2: ВСЕГДА можно придумать решение получше !!! )
5. Целесообразность (не забывайте пункт 1).
6. Решайте самое непонятное в первую очередь, это снижает риски.
7. Автоматизируйте ВСЕ что возможно. Не доверяйте человеку то , что может сделать компьютер. Человек часто ошибается (любой) (намного чаще компьютера!!!). (следствие : проверяйте все что можно проверить)
8. Целесообразность. (да да , опять она)
9. Тестер — друг твой , а не враг твой !!! Возлюби тестера своего! (следствие : Идеальный тестер — симпатишная девушка после 18 лет ).
10. Делай как можно проще, но не проще, чем нужно"
11. Не стоит делать много ошибок, можно сделать одну и потом вызывать ее из разных мест программы. (следствие , избегайте дублирования кода)
12. Программу иногда читает человек. (следствие : хорошая программа — небольшая программа, кратость сестра таланта) (следствие 2 : идлеальная программаа это — NOP, все остальное не идеально , а только стремится... ).
13. Восхищайтесь людям которые умеют создать проблему и ГЕРОИЧЕСКИ ее решить ! Это великие люди ! (следствие : держитесь от них подальше , предмет восхищения должен быть недосягаем !!!)
14. Психологи говорят , что нормальный человек может одновременно в голове держать 3 -5 сущностей. (следствие : расщитывайте на среднего убогого человека, если ваша функция делает 10 вещей одновременно, и работает с 20 сущностями , то скорее всего большинство ее не поймут) (следствие2 : а если убогий человек будет планировать вашу зарплату ? никто не любит чувствовать себя дураком) (следствие3: А если этот убогий вы САМИ , через год ?)
(притча: Однажды я целый час переписывал самый убогий на свете код , из тех что я встречал , через 2 часа я вспомнил , я что этот код писал Я )
15. Целесообразность. ( я опять увлекся и забыл про пункт 1)
16. Далее ваши пункты в порядке приоритета! (следствие : этот текст плох, он противоречит пункту 14)
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re: Многое что я хотел сказать о программировании , но боялс
Здравствуйте, minorlogic, Вы писали:
M>6. Решайте самое непонятное в первую очередь, это снижает риски. M>16. Далее ваши пункты в порядке приоритета! (следствие : этот текст плох, он противоречит пункту 14)
17. Старайтесь определить критические места в первую очередь и постарйтесь их решить эффективно.
Если это не удастся сделать с самого начала — дальше продолжать нецелесообразно.
18. "Щательнее..." Пишите новый код как на всегда. Потом возвращаться не будет ни времени ни желания ни памяти.
Изначально эффективный код также устраняет массу проблем с определением напрвлений оптимизации в будущем.
И последняя максима (три смысловых слоя):
19. Если можешь не программировать — не программируй.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, Dr.Gigabit, Вы писали:
DG>>Здравствуйте, minorlogic, Вы писали:
M>>>Моя логика из того же места , что и "надежность системы определяется самым СЛАБЫМ местом". Т.е. увеличивая надежность слабых мест мы увеличиваем надежность системы ( в нашем случае процесса разработки).
DG>>К слову, психологи говорят, что мужчина выбирает спутницу жизни по самому большому ее недостатку
FDS>Это как?
В том смысле что определяющим фактором является не самое лучшее достоинсто, а самый худший недостаток. Если его переносить можно -- значит жить можно
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re: Многое что я хотел сказать о программировании , но боялс
Здравствуйте, minorlogic, Вы писали:
M>16. Далее ваши пункты в порядке приоритета! (следствие : этот текст плох, он противоречит пункту 14)
И не только 14-ому:
С одной стороны M>9. Тестер — друг твой , а не враг твой !!! Возлюби тестера своего! (следствие : Идеальный тестер — симпатишная девушка после 18 лет ).
С другой: M>13. Восхищайтесь людям которые умеют создать проблему и ГЕРОИЧЕСКИ ее решить ! Это великие люди ! (следствие : держитесь от них подальше , предмет восхищения должен быть недосягаем !!!)
Следовательно: любовь должна быть несчастной ! А раз любовь должна быть несчастной, то эта девушка врядли будет твоим другом, так как она героически решает проблемы, созданные тобой . В общем девушки не создают себе столько проблем одновременно: и встречатся с глючным программистом, и тестировать его глючный код , они слишком умны для этого...
M>3. a: Итерационность, b: Итерационность, c: Итерационность ...
Да, особенно на последних этапах Инкрементальность, конечно, не нужна, зачем?
M>4. Ленивое принятие решений , принимайте решение тольо тогда когда оно очевидно , до тех пор затягивайте ... Бойтесь принятия решений , в большинстве они ошибочны !!! (следствие , дайте возможность совершать как можно большее к-во ошибочных решений) (следствие2: ВСЕГДА можно придумать решение получше !!! )
Цитирую Стива Макконнела: "Вы сможете избавиться от первого типа лени [затягивания — прим. FDSC], если выработаете привычку выполнять эти задачи сразу. Эта привычка соответствует второму типу лени — "просвещённому". Вы всё так же ленитесь, но решаете неприятные проблемы, тратя на них как можно меньше времени".
В общем, смысл в том, что вы предлагаете "аналитический паралич". К тому же противоречие со следствием дайте возможность совершать как можно большее к-во ошибочных решений. Тут или затягивание решений или принятие большего их количества — вы уж определитесь.
M>14. Психологи говорят , что нормальный человек может одновременно в голове держать 3 -5 сущностей. (следствие : расщитывайте на среднего убогого человека, если ваша функция делает 10 вещей одновременно, и работает с 20 сущностями , то скорее всего большинство ее не поймут) (следствие2 : а если убогий человек будет планировать вашу зарплату ? никто не любит чувствовать себя дураком) (следствие3: А если этот убогий вы САМИ , через год ?)
Тот же Стив Макконнелл советует писать метод, предназначенный только для ОДНОЙ цели, хотя при этом и говорит, что человек может держать в голове 7[+-]2.
Тогда лучше сказать про иерархии и "взрывное" использование совершенно непонятных по предназначению классов данных в программе (т.е. когда читаешь, и не понимаешь зачем создан класс, начинаешь разбираться в исходниках этого класса, а там ещё 3 таки .. ещё 3 таких ... всего 243 таких )
То же про количество публичных методов в классе.
M>(притча: Однажды я целый час переписывал самый убогий на свете код , из тех что я встречал , через 2 часа я вспомнил , я что этот код писал Я )
Тот же Макконнел (уже надоел!) советует спроектировать метод заново, а не исправлять старый.
FDSC.1: МЕНЬШЕ комментариев в коде, больше комментариев над методом
FDSC.2: не скажу
FDSC.3: показывайте свой код тому, кто его может конструктивно покритиковать. Я думаю, это не ваша девушка.
И ещё, просьба: граждане, пишите как можно меньше... кажется кто-то это уже говорил
Re: Многое что я хотел сказать о программировании , но боялс
Здравствуйте, minorlogic, Вы писали:
M>14. Психологи говорят , что нормальный человек может одновременно в голове держать 3 -5 сущностей. (следствие : расщитывайте на среднего убогого человека, если ваша функция делает 10 вещей одновременно, и работает с 20 сущностями , то скорее всего большинство ее не поймут) (следствие2 : а если убогий человек будет планировать вашу зарплату ? никто не любит чувствовать себя дураком) (следствие3: А если этот убогий вы САМИ , через год ?)
Семь плюс/минус две сущности — это известная фраза Джорджа Миллера. По результатам исследования Матараззо, 90% взрослых людей могут держать в кратковременной памяти между пятью и восемью сущностями.Прошу прощение за занудство.
Ce n'est que pour vous dire ce que je vous dis.
Re[4]: Многое что я хотел сказать о программировании , но бо
FDS>В таком случае, лучше изначально предусмотреть варианты нестабильных архитектурных решений, так что бы спроектировать остальную часть программы исходя из того, что они будут меняться в определённых рамках. Иначе получится, что к уже готовой части программы нужно будет присоединять совершенно недружественную архитектуру.
Именно. Просто у меня не получилось сформулировать кратко и с юмором.
FDS>Я то же. Пункт FDSC.1 противоречит ему. Просто я высказал своё мнение, которое частично подкрепляется утверждениями Макконнелла. А про девушек уже возражений нет?
Неее, тему девушек — чувствую лучше не развивать ! Уж очень она в сторону уводит от программирования !
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re: Многое что я хотел сказать о программировании , но боялс
Здравствуйте, minorlogic, Вы писали:
M>4. Ленивое принятие решений , принимайте решение тольо тогда когда оно очевидно , до тех пор затягивайте ... Бойтесь принятия решений , в большинстве они ошибочны !!! (следствие , дайте возможность совершать как можно большее к-во ошибочных решений) (следствие2: ВСЕГДА можно придумать решение получше !!! ) M>6. Решайте самое непонятное в первую очередь, это снижает риски.
А как же пункт 4?
Иногда бывает так, что самое сложное и непонятное настолько сложно и непонятно, что даже не знаешь, что собственно надо решать, и в какую сторону думать и что вообще надо и с чего вообще начать.
В таких случаях мне лично помогает решить несколько более мелких задач, даже если их решишь неправильно, но хотя бы становится видно, в какую сторону дамать и что вообще надо сделать. Тогда уже можно переходить к самому сложному и непонятному.
Например, думаешь вот сейчас спроектирую интерфейс самого центрового класса и потом всё пойдёт как по маслу. Сидишь, тупишь пару часов выжимаешь какой-то надуманный интерфейс, а потом начинаешь писать остальные классики и понимаешь, что от главного-то класса нужно было совсем другое и совсем не с таким интерфейсом.
Хотя, конечно, я согласен, что самое главное нужно решать как можно раньше, как толькл стало реально это решить. В этом контексте решение вначале второстепенных проблем идёт как подготовка и анализ к решению самой главной проблемы.
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, FDSC, Вы писали:
CS>>>19. Если можешь не программировать — не программируй.
FDS>>Или, переформулируя, настоящий программист не тот, кто программирует, а тот кто не может не программировать.
M>Может речь шла о том чтобы 7 раз подумать , а потом опять подумать ? и если уже не остается других вариантов, писать код ? Автор изречения прокомментируйте плиз !
Используйте труд других программистов (предшественников) (с) Керниган и Ричи.
Деталь, которой нет в ракете, сломаться не может (с) Королев.
Течёт вода Кубань-реки куда велят большевики.
Re[3]: Многое что я хотел сказать о программировании , но бо
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, Андрей Хропов, Вы писали:
M>>>6. Решайте самое непонятное в первую очередь, это снижает риски. АХ>>Не соглашусь. Часто бывает лучше наоборот, сначала сделать простую, понятную часть системы. Так хотя бы она будет сделана. АХ>>А то начав копать сложную часть можно застрять так, что вообще ничего сделано не будет.
M>Ну это довольно принципиально. M>Представим что мы делаем автомобиль. Мы умеем делать все кроме двигателей. Мы можем сделать 90 проценто , но не сделать двигателя. В итоге получившийся автомобиль никому не нужен.
Возможно, мы получим прекрасную подвеску, прекрасную трансмиссию, прекрасный кузов и оформление салона. А двигатель можно будет купить или заказать. На крайний случай, всё это можно продать.
M>1. Мы делаем вначале двигатель M> а. Говорим заказчику что не в состоянии его сделать (и не тратим сил на остальные 90% работы)
Мы не говорим этого заказчику, мы выносим двигатель на аутсорсинг, оставляя под него определённое место исходя из опыта работы.
M> б. Двигатель получается и дальше мы прогонозируемо делаем оставшуюся работу.
И в итоге срываем сроки, так как пока не сделали двигатель, всё остальное стоит.
M>2. Мы делаем вначале 90% автомобиля M> а. Говорим заказчику что не в состоянии его сделать (но уже проработали год над 90%)
И сразу идём покупать готовый или выносим на аутсорсинг. Если мы не в состоянии спроектировать двигатель, мы это поймём гораздо раньше.
M> б. Двигатель получается и дальше мы пытаемся его вставить в автомобиль , и только теперь понимаем что он туда не влезет и придется перебирать 50% автомобиля чтобы впихнуть движок.
Это итеративное проектирование. Кстати, я учился по конструкторской специальности 4 года и могу сказать: если ты что-то конструируешь, то всегда есть возможность оставить побольше места для того, в чём не уверен, собственно, в этом и заключается талант конструктора: оставить столько сколько надо и там где надо. Конечно, при проектировании сложных мехатронных систем может оказаться. что часть системы придётся перепроектировать, но какую часть — зависит от мастерства проектирования этой части и того, спроектирована ли она с учётом возможности замены двигателя или других важных параметров или без. См. концепцию модульного проектирования. Мы декомпозируем систему для того, чтобы снизить влияние изменения одной части сложной системы на другую.
Вы забыли вариант:
M>1. Мы делаем вначале двигатель M> а. Говорим заказчику что не в состоянии его сделать (и не тратим сил на остальные 90% работы)
б. Двигатель не получается.
И мы успешно проваливаем проект и теряем заказчика.
Второй вариант:
M>2. Мы делаем вначале 90% автомобиля M> а. Говорим заказчику что не в состоянии его сделать
(но уже проработали над большей частью проекта, но далеко не над 90%, мы же не лохи всё-таки)
б. Двигатель не получается.
Мы идём к заказчику и говорим: так и так, всё получается прекрасно, но двигатель придётся заказать у другой фирмы, мы предусмотрели данный вариант, поэтому если вы согласитесь, то закончим проект вовремя и спроектированная часть системы останется такой, какая она есть. Заказчику нравится уже разработанная часть системы и он выдаёт доп. ресурсы на заказ разработки двигателя. Заказчик доволен, мы тоже.
Так что с точки зрения управления рисками второй вариант предпочтительней.
M>>>9. Тестер — друг твой , а не враг твой !!! Возлюби тестера своего! (следствие : Идеальный тестер — симпатишная девушка после 18 лет ). АХ>>Нет, тестер (как и другие коллеги) желательно должен обладать ничем не примечательной внешностью. Чтобы не отвлекаться.
M>А я люблю отвлекаться Мне это не мешает , а наоборот стимулирует !!!
Ну, значит для вас девушка-тестировщик оптимальный вариант, а для меня нет. Если мы будем работать в одной конторе, то я буду вам завидовать и это будет сильно ухудшать социальный микроклимат в отделе. К тому же, это значит, что девушка-тестировщик должна тестировать только ваши задания, а другой тестировщик — мои. Иначе вообще класс получится: я прихожу к вашей девушке, которая бесит меня своими голыми ногами и глупостью, а вы приходите к моему тестировщику, который бесит вас тем, что он не девушка и открыто заявляет что тут и вот тут вы написали полное г.
Re: Многое что я хотел сказать о программировании , но боялс
Здравствуйте, minorlogic, Вы писали:
M>16. Далее ваши пункты в порядке приоритета! (следствие : этот текст плох, он противоречит пункту 14)
Еще до того, как Вы стали писать программу продумайте систему ошибок, и как ошибки
взаимодействуют друг с другом. Сформулировано прикольно, но действительно об этом надо думать.
Течёт вода Кубань-реки куда велят большевики.
Re[2]: Многое что я хотел сказать о программировании , но бо
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, minorlogic, Вы писали:
M>>9. Тестер — друг твой , а не враг твой !!! Возлюби тестера своего! (следствие : Идеальный тестер — симпатишная девушка после 18 лет ).
CS>Вот с этим не согласен. Тестер должен быть страшен как моя жизнь. И настырно противен — не менее.
Вот именно ! Встречу с тестером надо ждать как встречу с любимым ! Встреча с тестером должна быть редкая (как с любовницей а не с женой) и продуктивная ! Тестер и вы должны быть удовлетворены от общения !!!
Не забывайте у тестера и у вас должна быть ода и ОБЩАЯ цель , иначе это сбои в системе ...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[2]: Многое что я хотел сказать о программировании , но бо
Здравствуйте, Андрей Хропов, Вы писали:
M>>6. Решайте самое непонятное в первую очередь, это снижает риски.
АХ>Не соглашусь. Часто бывает лучше наоборот, сначала сделать простую, понятную часть системы. Так хотя бы она будет сделана. АХ>А то начав копать сложную часть можно застрять так, что вообще ничего сделано не будет.
Я думаю, что более-менее оптимальный вариант — это сначала решить задачу простенькую, но завязанную на общую логику системы (чтобы "войти в контекст" системы), а потом заняться какой-нибудь сложной задачей (предлагаю вариант — самой сложной из тех, для которых ясна общая логика выполнения) — для уменьшения рисков.
--
Бесчастнов Евгений
Re[2]: Многое что я хотел сказать о программировании , но бо
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, minorlogic, Вы писали:
FDS>С другой: M>>13. Восхищайтесь людям которые умеют создать проблему и ГЕРОИЧЕСКИ ее решить ! Это великие люди ! (следствие : держитесь от них подальше , предмет восхищения должен быть недосягаем !!!)
FDS>Следовательно: любовь должна быть несчастной ! А раз любовь должна быть несчастной, то эта девушка врядли будет твоим другом, так как она героически решает проблемы, созданные тобой . В общем девушки не создают себе столько проблем одновременно: и встречатся с глючным программистом, и тестировать его глючный код , они слишком умны для этого...
"любовь должна быть несчастной"
Поздравляю. Догнал самого Шекспира.
Тот сказал примерно тоже самое — "Настоящая любовь должна быть несчастной".
Он имел в виду, что только несчастная любовь напрягает ВСЕ интелектуальные
и душевные силы, только такая любовь позволяет душе совершенствоваться.
Течёт вода Кубань-реки куда велят большевики.
Re[5]: Многое что я хотел сказать о программировании , но бо
Здравствуйте, alpha21264, Вы писали:
A>А Королев свою Н1.
Спорно. Объективных фактов о том, что в последнем полете виноват был НК-15, нет, хотя конечно ОКБ-1 косило на них. А в остальных авариях были виноваты другие причины — ошибки в системе управления, проблемы с трубопроводами и т.п.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, alpha21264, Вы писали:
A>>Здравствуйте, FDSC, Вы писали:
FDS>>>Здравствуйте, alpha21264, Вы писали:
A>>Двигатель всегда делает другая организация. Но я про другое. A>>И Королев и Поликарпов положили в основу двигатели, которых на тот A>>момент еще не было, и не было известно получатся ли они.
A>>Ну почитал я про Чертока. Там действительно проблемы были в управлении. A>>Вот только возникли они ровно потому, что нужно было отключать A>>сломавшиеся в полете двигатели. Такой блок был только на Н1. A>>Ни до ни после такое устройство не применялось (не нужно было).
A>>А от наземных тестов Королев отказался из-за экономии. В итоге вышло дороже.
FDS>Это пример неграмотного управления и проектирования. Пусть даже Королёвым. На некоторые самолёты можно поставить несколько совершенно различных марок двигателей: и ничего. Потому что они так спроектированы. Проще говоря, если у кого-то не получилось, это ешё не значит, что не получиться у всех остальных.
Это сильно некоторые самолеты. Как Боинг (медленный дозвуковой сарай).
Такие двигатели научились делать пятьдесят лет назад, и вопрос получится-неполучится не стоит.
Мы тут программирование обсуждаем. Авиация только аналогия.
Понимаешь... Вот есть Промт. У него есть классный юзер-интерфейс,
интегрированность в операционную систему, возможность переводить клипборд
и содержимое html-страниц, импорт/экспорт в Ворд-формат.
Одна беда — переводить он не может. Движка (программного) нет.
То же самое с FineReader. Был бы он кому-то нужен если бы его движок не работал?
Программы распознавания речи. К ним можно приделывать любые красивые обертки, но
пока распознают по 100-200 слов — они никому не нужны.
Течёт вода Кубань-реки куда велят большевики.
Re: Многое что я хотел сказать о программировании , но боялс
Здравствуйте, minorlogic, Вы писали:
M>9. Тестер — друг твой , а не враг твой !!! Возлюби тестера своего! (следствие : Идеальный тестер — симпатишная девушка после 18 лет ).
Вот с этим не согласен. Тестер должен быть страшен как моя жизнь. И настырно противен — не менее.
Re[2]: Многое что я хотел сказать о программировании , но бо
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, minorlogic, Вы писали:
M>>9. Тестер — друг твой , а не враг твой !!! Возлюби тестера своего! (следствие : Идеальный тестер — симпатишная девушка после 18 лет ).
CS>Вот с этим не согласен. Тестер должен быть страшен как моя жизнь. И настырно противен — не менее.
P.S. Стремление в этом случае — освободить тестера от лишней работы , дать время на отдых , на зуму , на флирт и т.д. Если девушка 18 лет тратит свое драгоценное время на воспроизведение и описание , и документирование ошибок — это непродуктивно!
Лучший тестер — девушка старше 18 !
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[2]: Многое что я хотел сказать о программировании , но бо
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, minorlogic, Вы писали:
M>>9. Тестер — друг твой , а не враг твой !!! Возлюби тестера своего! (следствие : Идеальный тестер — симпатишная девушка после 18 лет ).
CS>Вот с этим не согласен. Тестер должен быть страшен как моя жизнь. И настырно противен — не менее.
P.S. Стремление в этом случае — освободить тестера от лишней работы , дать время на отдых , на зуму , на флирт и т.д. Если девушка 18 лет тратит свое драгоценное время на воспроизведение и описание , и документирование ошибок — это непродуктивно!
Лучший тестер — девушка старше 18 !
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[2]: Многое что я хотел сказать о программировании , но бо
Здравствуйте, Дон Рэба, Вы писали:
ДР>Здравствуйте, minorlogic, Вы писали:
M>>14. Психологи говорят , что нормальный человек может одновременно в голове держать 3 -5 сущностей. (следствие : расщитывайте на среднего убогого человека, если ваша функция делает 10 вещей одновременно, и работает с 20 сущностями , то скорее всего большинство ее не поймут) (следствие2 : а если убогий человек будет планировать вашу зарплату ? никто не любит чувствовать себя дураком) (следствие3: А если этот убогий вы САМИ , через год ?)
ДР>Семь плюс/минус две сущности — это известная фраза Джорджа Миллера. По результатам исследования Матараззо, 90% взрослых людей могут держать в кратковременной памяти между пятью и восемью сущностями.Прошу прощение за занудство.
Ну дык это максимум , а я говорю про ОПТИМУМ! , спасибо за коррекцию !
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re: Многое что я хотел сказать о программировании , но боялс
Здравствуйте, minorlogic, Вы писали:
M>1. Целесообразность.
Цели разными бывают. Бывают, побольше LOC выдать .
M>2. Архитектура нужна разработчикам, архитектуре нужны разработчики. (это важно !!! очень!!! )
ага
M>6. Решайте самое непонятное в первую очередь, это снижает риски.
Не соглашусь. Часто бывает лучше наоборот, сначала сделать простую, понятную часть системы. Так хотя бы она будет сделана.
А то начав копать сложную часть можно застрять так, что вообще ничего сделано не будет.
M>9. Тестер — друг твой , а не враг твой !!! Возлюби тестера своего! (следствие : Идеальный тестер — симпатишная девушка после 18 лет ).
Нет, тестер (как и другие коллеги) желательно должен обладать ничем не примечательной внешностью. Чтобы не отвлекаться.
M>11. Не стоит делать много ошибок, можно сделать одну и потом вызывать ее из разных мест программы. (следствие , избегайте дублирования кода)
Эхх. Напарывался на это .
M>(притча: Однажды я целый час переписывал самый убогий на свете код , из тех что я встречал , через 2 часа я вспомнил , я что этот код писал Я )
Да это все по-моему недовольны своим старым кодом.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: Многое что я хотел сказать о программировании , но бо
Здравствуйте, FDSC, Вы писали:
M>>9. Тестер — друг твой , а не враг твой !!! Возлюби тестера своего! (следствие : Идеальный тестер — симпатишная девушка после 18 лет ).
К тому же, сразу начнётся: "а ты не можешь делать меньше ошибок?", "может ты протестируешь этот код за меня, ведь тебе легче его протестировать: ты его написал" и т.п.
К тому же тестеров практически никогда не бывает больше программистов, насколько я понимаю, значит, кому-то не достанется.
Re[2]: Многое что я хотел сказать о программировании , но бо
M>>4. Ленивое принятие решений , принимайте решение тольо тогда когда оно очевидно , до тех пор затягивайте ... Бойтесь принятия решений , в большинстве они ошибочны !!! (следствие , дайте возможность совершать как можно большее к-во ошибочных решений) (следствие2: ВСЕГДА можно придумать решение получше !!! )
FDS>Цитирую Стива Макконнела: "Вы сможете избавиться от первого типа лени [затягивания — прим. FDSC], если выработаете привычку выполнять эти задачи сразу. Эта привычка соответствует второму типу лени — "просвещённому". Вы всё так же ленитесь, но решаете неприятные проблемы, тратя на них как можно меньше времени". FDS>В общем, смысл в том, что вы предлагаете "аналитический паралич". К тому же противоречие со следствием дайте возможность совершать как можно большее к-во ошибочных решений. Тут или затягивание решений или принятие большего их количества — вы уж определитесь.
Имеется ввиду оставлять архитектуру в том состоянии , чтобы иметь возможность поменять некие архитектурные решения как можно позже — другими словами гибкость архитектуры
M>>14. Психологи говорят , что нормальный человек может одновременно в голове держать 3 -5 сущностей. (следствие : расщитывайте на среднего убогого человека, если ваша функция делает 10 вещей одновременно, и работает с 20 сущностями , то скорее всего большинство ее не поймут) (следствие2 : а если убогий человек будет планировать вашу зарплату ? никто не любит чувствовать себя дураком) (следствие3: А если этот убогий вы САМИ , через год ?)
FDS>Тот же Стив Макконнелл советует писать метод, предназначенный только для ОДНОЙ цели, хотя при этом и говорит, что человек может держать в голове 7[+-]2. FDS>Тогда лучше сказать про иерархии и "взрывное" использование совершенно непонятных по предназначению классов данных в программе (т.е. когда читаешь, и не понимаешь зачем создан класс, начинаешь разбираться в исходниках этого класса, а там ещё 3 таки .. ещё 3 таких ... всего 243 таких )
FDS>То же про количество публичных методов в классе.
M>>(притча: Однажды я целый час переписывал самый убогий на свете код , из тех что я встречал , через 2 часа я вспомнил , я что этот код писал Я )
FDS>Тот же Макконнел (уже надоел!) советует спроектировать метод заново, а не исправлять старый.
FDS>
FDS>FDSC.1: МЕНЬШЕ комментариев в коде, больше комментариев над методом FDS>FDSC.2: не скажу FDS>FDSC.3: показывайте свой код тому, кто его может конструктивно покритиковать. Я думаю, это не ваша девушка.
FDS>И ещё, просьба: граждане, пишите как можно меньше... кажется кто-то это уже говорил
P.S. Я не ставил своей целью конспектировать Макконнел.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[2]: Многое что я хотел сказать о программировании , но бо
Здравствуйте, Андрей Хропов, Вы писали:
M>>6. Решайте самое непонятное в первую очередь, это снижает риски. АХ>Не соглашусь. Часто бывает лучше наоборот, сначала сделать простую, понятную часть системы. Так хотя бы она будет сделана. АХ>А то начав копать сложную часть можно застрять так, что вообще ничего сделано не будет.
Ну это довольно принципиально.
Представим что мы делаем автомобиль. Мы умеем делать все кроме двигателей. Мы можем сделать 90 проценто , но не сделать двигателя. В итоге получившийся автомобиль никому не нужен.
1. Мы делаем вначале двигатель
а. Говорим заказчику что не в состоянии его сделать (и не тратим сил на остальные 90% работы)
б. Двигатель получается и дальше мы прогонозируемо делаем оставшуюся работу.
2. Мы делаем вначале 90% автомобиля
а. Говорим заказчику что не в состоянии его сделать (но уже проработали год над 90%)
б. Двигатель получается и дальше мы пытаемся его вставить в автомобиль , и только теперь понимаем что он туда не влезет и придется перебирать 50% автомобиля чтобы впихнуть движок.
M>>9. Тестер — друг твой , а не враг твой !!! Возлюби тестера своего! (следствие : Идеальный тестер — симпатишная девушка после 18 лет ). АХ>Нет, тестер (как и другие коллеги) желательно должен обладать ничем не примечательной внешностью. Чтобы не отвлекаться.
А я люблю отвлекаться Мне это не мешает , а наоборот стимулирует !!!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[3]: Многое что я хотел сказать о программировании , но бо
Здравствуйте, minorlogic, Вы писали:
M>Имеется ввиду оставлять архитектуру в том состоянии , чтобы иметь возможность поменять некие архитектурные решения как можно позже — другими словами гибкость архитектуры
В таком случае, лучше изначально предусмотреть варианты нестабильных архитектурных решений, так что бы спроектировать остальную часть программы исходя из того, что они будут меняться в определённых рамках. Иначе получится, что к уже готовой части программы нужно будет присоединять совершенно недружественную архитектуру.
FDS>>
FDS>>FDSC.1: МЕНЬШЕ комментариев в коде, больше комментариев над методом FDS>>FDSC.2: не скажу FDS>>FDSC.3: показывайте свой код тому, кто его может конструктивно покритиковать. Я думаю, это не ваша девушка.
FDS>>И ещё, просьба: граждане, пишите как можно меньше... кажется кто-то это уже говорил
M>P.S. Я не ставил своей целью конспектировать Макконнел.
Я то же. Пункт FDSC.1 противоречит ему. Просто я высказал своё мнение, которое частично подкрепляется утверждениями Макконнелла. А про девушек уже возражений нет?
Re[4]: Многое что я хотел сказать о программировании , но бо
Это утопия , если рассуждать таким образом про аутсорсинг (как про волшебную палочку), то возникает вопрос, а зачем вообще что то делать , может сразу весь проект на аутсорсинг ?
Моя логика из того же места , что и "надежность системы определяется самым СЛАБЫМ местом". Т.е. увеличивая надежность слабых мест мы увеличиваем надежность системы ( в нашем случае процесса разработки).
Ну например разрабатывая систему постороения 3д объекта по серии снимков, я бы первым делом отработал все алгоритмы , убедился в работоспособнеости , создал рабочий прототип , и только после этого брался за создание GUI и т.п.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[5]: Многое что я хотел сказать о программировании , но бо
Здравствуйте, minorlogic, Вы писали:
M>Это утопия , если рассуждать таким образом про аутсорсинг (как про волшебную палочку), то возникает вопрос, а зачем вообще что то делать , может сразу весь проект на аутсорсинг ?
Нет, весь проект не надо: на чём-то твоя фирма ведь специализируется. Но посмотри, например, на самолёты: очень не многие компании сами конструируют двигатели. Фирма в твоём примере сделала ВЕСЬ автомобиль, этого вполне достаточно что бы заказать двигатель на стороне или выбрать стандартный. Аутсорсинг не волшебная палочка, но это не значит, что им стоит пренебрегать и писать всё самому и с нуля, не исп. уже написанные продукты.
M>Моя логика из того же места , что и "надежность системы определяется самым СЛАБЫМ местом". Т.е. увеличивая надежность слабых мест мы увеличиваем надежность системы ( в нашем случае процесса разработки).
Она определяется всеми местами и меньше надёжности самой ненадёжной системы. Вы предлагаете неправильный подход к управлению рисками: я показал вам, что в случае неудачи проектирования двигателя ваш подход не даст хороших результатов. Перечитайте ещё раз и поразмыслите, так как я написал делают в реальной жизни многие крупные компании.
M>Ну например разрабатывая систему постороения 3д объекта по серии снимков, я бы первым делом отработал все алгоритмы , убедился в работоспособнеости , создал рабочий прототип , и только после этого брался за создание GUI и т.п.
Совершенно верный подход. Только прототип может не решить всех проблем: самое непонятное может доставить кучу хлопот уже при полномасштабном внедрении и тут поможет проектирование с учётом того, что некоторые части программы нестабильны. Если проект делает не один человек, то это поможет не ждать решения проблем, а делать весь проект.
Re[5]: Многое что я хотел сказать о программировании , но бо
M>Моя логика из того же места , что и "надежность системы определяется самым СЛАБЫМ местом". Т.е. увеличивая надежность слабых мест мы увеличиваем надежность системы ( в нашем случае процесса разработки).
К слову, психологи говорят, что мужчина выбирает спутницу жизни по самому большому ее недостатку
Здравствуйте, Dr.Gigabit, Вы писали:
DG>Здравствуйте, minorlogic, Вы писали:
M>>Моя логика из того же места , что и "надежность системы определяется самым СЛАБЫМ местом". Т.е. увеличивая надежность слабых мест мы увеличиваем надежность системы ( в нашем случае процесса разработки).
DG>К слову, психологи говорят, что мужчина выбирает спутницу жизни по самому большому ее недостатку
Здравствуйте, Dr.Gigabit, Вы писали:
DG>>>К слову, психологи говорят, что мужчина выбирает спутницу жизни по самому большому ее недостатку
FDS>>Это как?
DG>В том смысле что определяющим фактором является не самое лучшее достоинсто, а самый худший недостаток. Если его переносить можно -- значит жить можно
А, понял. Наверное они правы
Re[2]: Многое что я хотел сказать о программировании , но бо
Здравствуйте, c-smile, Вы писали:
CS>17. Старайтесь определить критические места в первую очередь и постарйтесь их решить эффективно. CS>Если это не удастся сделать с самого начала — дальше продолжать нецелесообразно.
Об этом уже спорили в другой ветке. Хотя этот совет — одно из стандартных решений планирования разработки системы.
В любом случае, может оказаться, что эффективное решение критических проблем проекта невозможно без решения некоторых других проблем, возможно, кажущихся второстепенными. Это уже вопросы техники инкрементальной интеграции проекта и они различны для каждого проекта.
CS>18. "Щательнее..." Пишите новый код как на всегда. Потом возвращаться не будет ни времени ни желания ни памяти. CS>Изначально эффективный код также устраняет массу проблем с определением напрвлений оптимизации в будущем.
Если писать изначально эффективный код, можно не написать вообще ничего (обсуждение в форуме здесь
Здравствуйте, FDSC, Вы писали:
CS>>19. Если можешь не программировать — не программируй.
FDS>Или, переформулируя, настоящий программист не тот, кто программирует, а тот кто не может не программировать.
Может речь шла о том чтобы 7 раз подумать , а потом опять подумать ? и если уже не остается других вариантов, писать код ? Автор изречения прокомментируйте плиз !
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[4]: Многое что я хотел сказать о программировании , но бо
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, minorlogic, Вы писали:
M>>Здравствуйте, Андрей Хропов, Вы писали:
M>>>>6. Решайте самое непонятное в первую очередь, это снижает риски. АХ>>>Не соглашусь. Часто бывает лучше наоборот, сначала сделать простую, понятную часть системы. Так хотя бы она будет сделана. АХ>>>А то начав копать сложную часть можно застрять так, что вообще ничего сделано не будет.
M>>Ну это довольно принципиально. M>>Представим что мы делаем автомобиль. Мы умеем делать все кроме двигателей. Мы можем сделать 90 проценто , но не сделать двигателя. В итоге получившийся автомобиль никому не нужен.
FDS>Возможно, мы получим прекрасную подвеску, прекрасную трансмиссию, прекрасный кузов и оформление салона. А двигатель можно будет купить или заказать. На крайний случай, всё это можно продать.
Вот так Поликарпов и угробил свой И-180.
А Королев свою Н1.
Здравствуйте, minorlogic, Вы писали:
M>16. Далее ваши пункты в порядке приоритета! (следствие : этот текст плох, он противоречит пункту 14)
17. Концептуальная целостность!
Делайте одинаковые вещи одинаковым способом. Гораздо более выгодно выглядит стройная, целостная система, пусть даже немного за счёт этого ограниченная в возможностях, чем система, являющаяся пёстрым сборищем разнородных "фич".
(вольный пересках Фреда Брукса, который писал это ещё в 60-е годы, к сожалению многие разработчики и сейчас не дошли до этого)
(правда, он писал это про UI, но это не в меньшей степени относится к внутренней организации программы)
(я бы этот пункт переместил значительно ближе к началу списка)
Здравствуйте, alpha21264, Вы писали:
A>Здравствуйте, FDSC, Вы писали:
FDS>>Здравствуйте, minorlogic, Вы писали:
M>>>Здравствуйте, Андрей Хропов, Вы писали:
M>>>>>6. Решайте самое непонятное в первую очередь, это снижает риски. АХ>>>>Не соглашусь. Часто бывает лучше наоборот, сначала сделать простую, понятную часть системы. Так хотя бы она будет сделана. АХ>>>>А то начав копать сложную часть можно застрять так, что вообще ничего сделано не будет.
M>>>Ну это довольно принципиально. M>>>Представим что мы делаем автомобиль. Мы умеем делать все кроме двигателей. Мы можем сделать 90 проценто , но не сделать двигателя. В итоге получившийся автомобиль никому не нужен.
FDS>>Возможно, мы получим прекрасную подвеску, прекрасную трансмиссию, прекрасный кузов и оформление салона. А двигатель можно будет купить или заказать. На крайний случай, всё это можно продать.
A>Вот так Поликарпов и угробил свой И-180. A>А Королев свою Н1.
Там были проблемы чисто управленческого плана (если вы про аутсорсинг), а в СССР их не умели решать. Для интереса, узнайте, сколько боинг заказывает, а сколько производит сам.
Здравствуйте, FDSC, Вы писали:
FDS>Там были проблемы чисто управленческого плана (если вы про аутсорсинг), а в СССР их не умели решать. Для интереса, узнайте, сколько боинг заказывает, а сколько производит сам.
А вы думаете, сухой сам двигатели проектирует? И сам их изготавливает? И ведь ничего плохого не происходит — летают, вроде.
Re[2]: Многое что я хотел сказать о программировании , но бо
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, alpha21264, Вы писали:
A>>Вот так Поликарпов и угробил свой И-180. A>>А Королев свою Н1.
FDS>Там были проблемы чисто управленческого плана (если вы про аутсорсинг), а в СССР их не умели решать. Для интереса, узнайте, сколько боинг заказывает, а сколько производит сам.
Двигатель всегда делает другая организация. Но я про другое.
И Королев и Поликарпов положили в основу двигатели, которых на тот
момент еще не было, и не было известно получатся ли они.
Ну почитал я про Чертока. Там действительно проблемы были в управлении.
Вот только возникли они ровно потому, что нужно было отключать сломавшиеся в полете двигатели. Такой блок был только на Н1.
Ни до ни после такое устройство не применялось (не нужно было).
А от наземных тестов Королев отказался из-за экономии. В итоге вышло дороже.
Течёт вода Кубань-реки куда велят большевики.
Re[3]: Многое что я хотел сказать о программировании , но бо
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, remark, Вы писали:
R>>з.ы. сам подборку составлял?
M>Угу , это то что накипело в последнее время. Возможно не самое главное , но довольно актуально лично для меня.
А что за такие личные, серьёзные проблемы с целесообразностью? За предприятии любят вначале делать, а потом думать зачем?
Здравствуйте, alpha21264, Вы писали:
A>Здравствуйте, FDSC, Вы писали:
FDS>>Здравствуйте, alpha21264, Вы писали:
A>>>Вот так Поликарпов и угробил свой И-180. A>>>А Королев свою Н1.
FDS>>Там были проблемы чисто управленческого плана (если вы про аутсорсинг), а в СССР их не умели решать. Для интереса, узнайте, сколько боинг заказывает, а сколько производит сам.
A>Двигатель всегда делает другая организация. Но я про другое. A>И Королев и Поликарпов положили в основу двигатели, которых на тот A>момент еще не было, и не было известно получатся ли они.
A>Ну почитал я про Чертока. Там действительно проблемы были в управлении. A>Вот только возникли они ровно потому, что нужно было отключать A>сломавшиеся в полете двигатели. Такой блок был только на Н1. A>Ни до ни после такое устройство не применялось (не нужно было).
A>А от наземных тестов Королев отказался из-за экономии. В итоге вышло дороже.
Это пример неграмотного управления и проектирования. Пусть даже Королёвым. На некоторые самолёты можно поставить несколько совершенно различных марок двигателей: и ничего. Потому что они так спроектированы. Проще говоря, если у кого-то не получилось, это ешё не значит, что не получиться у всех остальных.
Re[7]: Многое что я хотел сказать о программировании , но бо
Здравствуйте, alpha21264, Вы писали:
A>Двигатель всегда делает другая организация. Но я про другое. A>И Королев и Поликарпов положили в основу двигатели, которых на тот A>момент еще не было, и не было известно получатся ли они.
Во-первых это тоже нормальная ситуация. У нас некоторые самолеты даже взлетали с чужими двигателями, пока движки доводили. Во-вторых в случае Королева у него просто выхода не было.
A>Ну почитал я про Чертока. Там действительно проблемы были в управлении. A>Вот только возникли они ровно потому, что нужно было отключать A>сломавшиеся в полете двигатели. A> Такой блок был только на Н1. A>Ни до ни после такое устройство не применялось (не нужно было).
И это тоже нормально. В Сатурн-5 было то же самое. И сейчас так многие ракеты умеют, например Протон тот же успешно завершает полет при отказе одного из шести двигателей первой ступени.
A>А от наземных тестов Королев отказался из-за экономии. В итоге вышло дороже.
Совершенно не факт, что наземные тесты чем либо помогли. Отказы системы управления они бы не выявили.
Вон УКСС когда использовали, главная задача была чтобы взрыв движков не разнес стенд к чертовой бабушке. Ну разнесло бы в случае Н-1 вместо старта стенд, чем бы это помогло?
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Здравствуйте, remark, Вы писали:
R>Здравствуйте, minorlogic, Вы писали:
M>>Здравствуйте, remark, Вы писали:
R>>>з.ы. сам подборку составлял?
M>>Угу , это то что накипело в последнее время. Возможно не самое главное , но довольно актуально лично для меня.
R>А что за такие личные, серьёзные проблемы с целесообразностью? За предприятии любят вначале делать, а потом думать зачем?
R>
Если бы ! даже делать не пытаются
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[9]: Многое что я хотел сказать о программировании , но бо
alpha21264 wrote: > Программы распознавания речи. К ним можно приделывать любые красивые > обертки, но пока распознают по 100-200 слов — они никому не нужны.
Неправда. Очень даже нужны, причем всего с парой-тройкой десятков
команд. Например, для голосового управления.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[9]: Многое что я хотел сказать о программировании , но бо
Здравствуйте, alpha21264, Вы писали:
A>Здравствуйте, FDSC, Вы писали:
FDS>>Здравствуйте, alpha21264, Вы писали:
A>>>Здравствуйте, FDSC, Вы писали:
FDS>>>>Здравствуйте, alpha21264, Вы писали:
A>>>Двигатель всегда делает другая организация. Но я про другое. A>>>И Королев и Поликарпов положили в основу двигатели, которых на тот A>>>момент еще не было, и не было известно получатся ли они.
A>>>Ну почитал я про Чертока. Там действительно проблемы были в управлении. A>>>Вот только возникли они ровно потому, что нужно было отключать A>>>сломавшиеся в полете двигатели. Такой блок был только на Н1. A>>>Ни до ни после такое устройство не применялось (не нужно было).
A>>>А от наземных тестов Королев отказался из-за экономии. В итоге вышло дороже.
FDS>>Это пример неграмотного управления и проектирования. Пусть даже Королёвым. На некоторые самолёты можно поставить несколько совершенно различных марок двигателей: и ничего. Потому что они так спроектированы. Проще говоря, если у кого-то не получилось, это ешё не значит, что не получиться у всех остальных.
A>Это сильно некоторые самолеты. Как Боинг (медленный дозвуковой сарай). A>Такие двигатели научились делать пятьдесят лет назад, и вопрос получится-неполучится не стоит.
A>Мы тут программирование обсуждаем. Авиация только аналогия.
В программировании гораздо легче оставить запас, если грамотно спроектировать.
A>Понимаешь... Вот есть Промт. У него есть классный юзер-интерфейс, A>интегрированность в операционную систему, возможность переводить клипборд A>и содержимое html-страниц, импорт/экспорт в Ворд-формат. A>Одна беда — переводить он не может. Движка (программного) нет.
A>То же самое с FineReader. Был бы он кому-то нужен если бы его движок не работал?
A>Программы распознавания речи. К ним можно приделывать любые красивые обертки, но A>пока распознают по 100-200 слов — они никому не нужны.
Ваш пример неправилен. Мы говорим о том, что фирма сделала то, что она умеет, а заказала то, что не умеет. Если она делает переводчик, то она сделает движок, а что не получится (доп. функции какие-нибудь изощрённые) — отдаст на аутсорсинг. Именно так, а не иначе
Re[7]: Многое что я хотел сказать о программировании , но бо
Здравствуйте, alpha21264, Вы писали:
A>Здравствуйте, FDSC, Вы писали:
FDS>>Здравствуйте, alpha21264, Вы писали:
A>>>Вот так Поликарпов и угробил свой И-180. A>>>А Королев свою Н1.
FDS>>Там были проблемы чисто управленческого плана (если вы про аутсорсинг), а в СССР их не умели решать. Для интереса, узнайте, сколько боинг заказывает, а сколько производит сам.
A>Двигатель всегда делает другая организация. Но я про другое. A>И Королев и Поликарпов положили в основу двигатели, которых на тот A>момент еще не было, и не было известно получатся ли они.
A>Ну почитал я про Чертока. Там действительно проблемы были в управлении. A>Вот только возникли они ровно потому, что нужно было отключать A>сломавшиеся в полете двигатели. Такой блок был только на Н1. A>Ни до ни после такое устройство не применялось (не нужно было).
Третий испытательный пуск ракеты-носителя Н-1. Ракета подверглась существенным доработкам с учетом прошлых аварий. Полезной нагрузкой служили макеты лунного корабля и лунной кабины. С момента отрыва от стартового комплекса и до конца полета все 30 двигателей первой ступени работали устойчиво. Однако из-за неучтенных газодинамических процессов возникло вращение, с которым пыталась справиться система управления. Огневые струи двигателей складывались в общий факел так, что вокруг продольной оси ракеты создавался крутящий момент. Уже к восьмой секунде полета, на высоте около 250 метров рулевые сопла встали на упоры, так и не сумев парировать возмущение по крену. К 15 секунде отклонение достигло 8 градусов. Скорость и угол поворота постоянно возрастали. Начиная с 39 секунды система управления была уже не в состоянии стабилизировать носитель по осям. На 48 секунде из-за выхода на закритические углы атаки началось разрушение ракеты в области стыка блока "В" и головного обтекателя. Головной блок отделился от ракеты и начал разрушаться. На 51 секунде полета, когда угол поворота достиг 60 градусов, по команде от концевых контактов гироплатформы наконец выключились все ЖРД первой ступени. Ракета была подорвана по команде с Земли, ее остатки упали в 20 км от стартовых сооружений, которые не пострадали. Работа системы аварийного спасения не планировалась.
Четвертый и последний испытательный пуск ракеты-носителя Н-1. Многие системы ракеты были доработаны. В частности, для улучшения управляемости по крену на первой и второй ступенях вместо выхлопных рулевых сопел были установлены рулевые ЖРД. Полезной нагрузкой был корабль "Союз-7К-ЛОК" (лунный орбитальный корабль). До 107 секунды полет проходил нормально. В этот момент, за 7 секунд до отделения первой ступени, для уменьшения ускорения по программе должны были быть выключены шесть центральных двигателей. Сразу после этого взорвался двигатель номер 4. Практически сразу же стала разрушаться первая ступень. Ракета была подорвана по команде с Земли до отделения и запуска второй ступени. Причины аварии до конца не ясны. Главный конструктор Мишин винил двигателистов. Конструктор двигателей Кузнецов утверждал, что двигатели тут ни при чем: из-за резкого прекращения подачи топлива произошел гидравлический удар, повлекший разрыв трубопровода и взрыв двигателя. Все сходились на том, что полет мог бы закончиться успешно, если бы первая ступень была бы немедленно выключена и отделена. Однако система управления не предусматривала подобного отделения.
В мае 1974 года программа Н-1 была окончательно свернута.
Re[4]: Многое что я хотел сказать о программировании , но бо
Здравствуйте, minorlogic, Вы писали:
M>Давайте немного проясним ситуацию
M>Определить задачу на аутсорс == решить задачу. И опять все становится на свои места.
M>Решайте самое сложное в первую очередь.
Не так. Определить задачу на аутсорс — значит определить задачу на параллельное выполнение с другими процессами проектирования. Мы же не будем сидеть сложа руки и ждать, пока нам поставят полностью готовый компонент — лишь некоторую часть более сложной системы. Поэтому получается что самую сложную задачу мы решаем отложенно, решаем вовсе не мы, а мы под неё просто место резервируем
Re[5]: Многое что я хотел сказать о программировании , но бо
Здравствуйте, minorlogic, Вы писали:
R>>А что за такие личные, серьёзные проблемы с целесообразностью? За предприятии любят вначале делать, а потом думать зачем?
M>Если бы ! даже делать не пытаются
Ну тогда всё нормально, по крайней мере ни одного нецелесообразного действия не делается
Здравствуйте, Cyberax, Вы писали:
C>alpha21264 wrote: >> Программы распознавания речи. К ним можно приделывать любые красивые >> обертки, но пока распознают по 100-200 слов — они никому не нужны. C>Неправда. Очень даже нужны, причем всего с парой-тройкой десятков C>команд. Например, для голосового управления.
Это значит, что решается ДРУГАЯ задача (управление).
А с той задачей (например диктовкой) Вы не справились.
Течёт вода Кубань-реки куда велят большевики.
Re[10]: Многое что я хотел сказать о программировании , но б
Здравствуйте, FDSC, Вы писали:
FDS>В программировании гораздо легче оставить запас, если грамотно спроектировать.
Кхм... Че-то не понимаю. Программа не распознает (или не переводит).
Как сделать запас?
A>>Понимаешь... Вот есть Промт. У него есть классный юзер-интерфейс, A>>интегрированность в операционную систему, возможность переводить клипборд A>>и содержимое html-страниц, импорт/экспорт в Ворд-формат. A>>Одна беда — переводить он не может. Движка (программного) нет.
A>>То же самое с FineReader. Был бы он кому-то нужен если бы его движок не работал?
A>>Программы распознавания речи. К ним можно приделывать любые красивые обертки, но A>>пока распознают по 100-200 слов — они никому не нужны.
FDS>Ваш пример неправилен. Мы говорим о том, что фирма сделала то, что она умеет, а заказала то, что не умеет. Если она делает переводчик, то она сделает движок, а что не получится (доп. функции какие-нибудь изощрённые) — отдаст на аутсорсинг. Именно так, а не иначе
Ну... Исходный тезис был:
6. Решайте самое непонятное в первую очередь, это снижает риски.
В данном случае "самое непонятное" — ядро переводчика.
Дополнительные функции — это только "бантики". Их можно вообще не делать.
По этому их "не страшно" отдать на аутсорсинг.
В данном случае ядро переводчика это не только самое непонятное.
Это и есть продукт (то, что продается), вокруг которого строится фирма.
А если "бантик" становится больше и сложнее чем "ядро", то именно он и начинает продаваться
как самостоятельный продукт. Так в свое время ПО отделилось от стоимости железа.
. В общем девушки не создают себе столько проблем одновременно: и встречатся с глючным программистом, и тестировать его глючный код 
, они слишком умны для этого...
)
