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>9. Тестер — друг твой , а не враг твой !!! Возлюби тестера своего! (следствие : Идеальный тестер — симпатишная девушка после 18 лет ).
Вот с этим не согласен. Тестер должен быть страшен как моя жизнь. И настырно противен — не менее.
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]: Многое что я хотел сказать о программировании , но бо
Здравствуйте, 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: Многое что я хотел сказать о программировании , но боялс
Здравствуйте, minorlogic, Вы писали:
M>14. Психологи говорят , что нормальный человек может одновременно в голове держать 3 -5 сущностей. (следствие : расщитывайте на среднего убогого человека, если ваша функция делает 10 вещей одновременно, и работает с 20 сущностями , то скорее всего большинство ее не поймут) (следствие2 : а если убогий человек будет планировать вашу зарплату ? никто не любит чувствовать себя дураком) (следствие3: А если этот убогий вы САМИ , через год ?)
Семь плюс/минус две сущности — это известная фраза Джорджа Миллера. По результатам исследования Матараззо, 90% взрослых людей могут держать в кратковременной памяти между пятью и восемью сущностями.Прошу прощение за занудство.
Ce n'est que pour vous dire ce que je vous dis.
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]: Многое что я хотел сказать о программировании , но бо
Здравствуйте, Андрей Хропов, Вы писали:
M>>6. Решайте самое непонятное в первую очередь, это снижает риски.
АХ>Не соглашусь. Часто бывает лучше наоборот, сначала сделать простую, понятную часть системы. Так хотя бы она будет сделана. АХ>А то начав копать сложную часть можно застрять так, что вообще ничего сделано не будет.
Я думаю, что более-менее оптимальный вариант — это сначала решить задачу простенькую, но завязанную на общую логику системы (чтобы "войти в контекст" системы), а потом заняться какой-нибудь сложной задачей (предлагаю вариант — самой сложной из тех, для которых ясна общая логика выполнения) — для уменьшения рисков.
--
Бесчастнов Евгений
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[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>Здравствуйте, Андрей Хропов, Вы писали:
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[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[4]: Многое что я хотел сказать о программировании , но бо
FDS>В таком случае, лучше изначально предусмотреть варианты нестабильных архитектурных решений, так что бы спроектировать остальную часть программы исходя из того, что они будут меняться в определённых рамках. Иначе получится, что к уже готовой части программы нужно будет присоединять совершенно недружественную архитектуру.
Именно. Просто у меня не получилось сформулировать кратко и с юмором.
FDS>Я то же. Пункт FDSC.1 противоречит ему. Просто я высказал своё мнение, которое частично подкрепляется утверждениями Макконнелла. А про девушек уже возражений нет?
Неее, тему девушек — чувствую лучше не развивать ! Уж очень она в сторону уводит от программирования !
... << 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>К слову, психологи говорят, что мужчина выбирает спутницу жизни по самому большому ее недостатку
.
! А раз любовь должна быть несчастной, то эта девушка врядли будет твоим другом, так как она героически решает проблемы, созданные тобой 
. В общем девушки не создают себе столько проблем одновременно: и встречатся с глючным программистом, и тестировать его глючный код 
, они слишком умны для этого...
