Мда, плохо новичкам - поправить после опубликования даже опечатки не получается :(
Ссылка (которую не видно в предыдущем топике). http://bp2.blogger.com/_5kkrX0oNbF4/SEw2…
Почитаю инструкцию, может получится ее показать как картинку :)
Хотя несколько роботов я сам узнал, в основном из "Звездных войн", я немного запутался в объянениях, кто есть где на картинке и решил на их пронумеровать, чтобы лече было ориентироваться мне и все остальным.
Итак, вот чать списка, найденного всеми (если ошибся - пишите).
2- Марвин, "Автостопом по Галактике"
3 - Робокот, «Том и джерри»
28- T1000, "Терминатор"
31 - R2RD2
36 - C3PIO, "Звезные войны"
44 - ED-209, “Робот-полицейский”
48 – Робот из фильма "Звезные войны"
ЗЫ. Если кому-то интересно, почему 10-й справа внизу - сразу отвечу. Я когда нумеровал, 10 случайно пропустил, и обнаружил это только на 48-м роботе. Откатавать 39 записей и потом вносить их снова, мне не захотелось :)
В начале проекта - поезд и ходит по рельсам а в конце - у него есть крылья и летает. Бывают и такие "незначительные изменения" :))
То, что закладывать в контракт надо, как именно доролнительные изменения оплачиваются - бесспорно. Я лишь хотел сказать, что дает лучший результат для самомого же заказчика.
Ну а контракт, и что в него нужно писать - наверное, отдельная тема.
Не сталкивался ни с одним заказчиком, который в конце проекта хотел того-же, что и в начале. Как только новая функциональность становится доступной, заказчик лучше понимает что именно он хочет. Если контракт позволяет, то именно итеративный подход (согласовываем, делаем, поставляем и снова по кругу) с часто и рано поставляемыми результатами работает лучше всего. К концу проекта тот ТЗ, который вначале смотрелся здорово, просто устаревает. Так что это время, как правило, лучше потратить на прототип
Наверное, как в этом и есть разница в подходах - лично я считаю что код пишется именно для ЛЮДЕЙ, чтобы им было быстро и удобно в нем разбираться при его поддержке, компьютеру все равно какой именно код обрабатывать, понятный или нет (даже исходный код в статье был не так уж плох, но, думаю, каждый сталкивался с кодом, который читать очень трудно). Так что продолжать дискуссию бессмысленно - мы просто хотим достичь разных целей.
Если надо, попрошу и у МакКоннела ;). Доводы, почему нужно в if заносить более короткий код, приведены, а вот в подкрепление противоположного подхода отсутствует :). Если нет объяснения, но Code Rules можно и не показывать - смысла в них нет. Люди, которые их писали, возможно (опять-таки, мы точно не знаем) понимали, о чем пишут, но не факт, что понимают те, кто сейчас их читают. Так что - прочтите еще раз, попробуйте их понять, и прикинуть, может, есть лучше варианты. Многие люди, кто сейчас в топике высказывается, тоже имеют достаточные опыт разработки и некоторые тоже писали Code Rules.
Давайте - мухи- отдельно, котлеты - отдельно.
Никто же не говорил, что 100 строк - это хорошо, и насчет того, что короткие методы в целом лучше длинных, тоже спорить глупо. Но все-таки если есть достаточное количество строк в одной ветке, и только одна - в другой, все-таки именно if лучше подходит для короткой (т.е. поддерживаю denver-а в этом). По крайней мере, сколько приходилось просматривать код, именно такой код читался лучше - не надо скроллить и смотреть "а что за за условие было изначально", чтобы понять else блок. Ссылки на Code Rules (тем более если их нет)- доказательство слабое ;). Бывает, что там написаны и правильные вещи (а в основном это так и есть), только их нужно понимать, а не просто применять, как написано. Насчет применения - это лично мое мнение, я думаю, что думающий разработчик именно этим и отичается от кодера. Если есть логическое объяснение этого правила в Code Rules - в студию :)
Если мне память не изменяет, методология называется Crystal Clear. Clear Case - это система контроля кода компании Rational.
А в целом - гибкие методологии позволяют получить продукт на порядок быстрей и качественнее, чем следуя тяжеловесным методология аля RUP. Документация, как и любой артефакт, требует времени на поддержание и модификацию, причем чем ее больше тем ситуация хуже. Все указанные в статье документы помогают проекту достигнуть запланированного результата, но не гарантируют успеха проекта в целом. Так что выпуск проекта за 3 месяца по быстрым методологиям в большинстве случаев гораздо лучше, чем когда релиз происходит в том же объеме, но через год, зато следуя "тяжелым" методологиям. У Коберна есть чудная книга "Быстрая разработка", где подробно объясняется с чем это связано
Опцион (в случае с раздачей, из существует много типов) - это право приобрести акции по фиксированной цене. Например, сотрудник имеет право приобрести 100 акций по цене 10$. Реально стоимость опцион пробретает тогда (ну специалисты, конечно, знают больше) когда реальная стоимость акции выше чем указанная в опционе. Например, если за акции дают 20$ то понятно, что опцион имеет реальную цену (Если цена акции 1$ - то опцион, который позволяет купить их по 10$ ничего не стоит ;))
Опционы для компании обходятся гораздо дешевле чем акции (самими акциями до выполнения опциона владеет компания), и могут выпускаться до того, как акции реально будут выпущены в оборот.И только с того момента как опцион будет выполнен сотрудник будет реально владеть акциями, конечно, для этого ему надо уплатить их стоимость в опционе. Сотрудник, опять-таки при получении опциона ничего не может потерять, поскольку своих денег он не вкладывает, и есть смысл ждать пока он вырастет в цене. Но это так, сноска, а в целом - выдача опционов – весьма интересный способ материальной мотивации, но чтобы он работал, сотрудник должен понимать что он с этого может реально получить, и чтобы это его стимулировал работать , что как и с деньгами, происходит не всегда
Ссылка (которую не видно в предыдущем топике). http://bp2.blogger.com/_5kkrX0oNbF4/SEw2…
Почитаю инструкцию, может получится ее показать как картинку :)
Итак, вот чать списка, найденного всеми (если ошибся - пишите).
2- Марвин, "Автостопом по Галактике"
3 - Робокот, «Том и джерри»
28- T1000, "Терминатор"
31 - R2RD2
36 - C3PIO, "Звезные войны"
44 - ED-209, “Робот-полицейский”
48 – Робот из фильма "Звезные войны"
ЗЫ. Если кому-то интересно, почему 10-й справа внизу - сразу отвечу. Я когда нумеровал, 10 случайно пропустил, и обнаружил это только на 48-м роботе. Откатавать 39 записей и потом вносить их снова, мне не захотелось :)
То, что закладывать в контракт надо, как именно доролнительные изменения оплачиваются - бесспорно. Я лишь хотел сказать, что дает лучший результат для самомого же заказчика.
Ну а контракт, и что в него нужно писать - наверное, отдельная тема.
Никто же не говорил, что 100 строк - это хорошо, и насчет того, что короткие методы в целом лучше длинных, тоже спорить глупо. Но все-таки если есть достаточное количество строк в одной ветке, и только одна - в другой, все-таки именно if лучше подходит для короткой (т.е. поддерживаю denver-а в этом). По крайней мере, сколько приходилось просматривать код, именно такой код читался лучше - не надо скроллить и смотреть "а что за за условие было изначально", чтобы понять else блок. Ссылки на Code Rules (тем более если их нет)- доказательство слабое ;). Бывает, что там написаны и правильные вещи (а в основном это так и есть), только их нужно понимать, а не просто применять, как написано. Насчет применения - это лично мое мнение, я думаю, что думающий разработчик именно этим и отичается от кодера. Если есть логическое объяснение этого правила в Code Rules - в студию :)
А в целом - гибкие методологии позволяют получить продукт на порядок быстрей и качественнее, чем следуя тяжеловесным методология аля RUP. Документация, как и любой артефакт, требует времени на поддержание и модификацию, причем чем ее больше тем ситуация хуже. Все указанные в статье документы помогают проекту достигнуть запланированного результата, но не гарантируют успеха проекта в целом. Так что выпуск проекта за 3 месяца по быстрым методологиям в большинстве случаев гораздо лучше, чем когда релиз происходит в том же объеме, но через год, зато следуя "тяжелым" методологиям. У Коберна есть чудная книга "Быстрая разработка", где подробно объясняется с чем это связано
Опционы для компании обходятся гораздо дешевле чем акции (самими акциями до выполнения опциона владеет компания), и могут выпускаться до того, как акции реально будут выпущены в оборот.И только с того момента как опцион будет выполнен сотрудник будет реально владеть акциями, конечно, для этого ему надо уплатить их стоимость в опционе. Сотрудник, опять-таки при получении опциона ничего не может потерять, поскольку своих денег он не вкладывает, и есть смысл ждать пока он вырастет в цене. Но это так, сноска, а в целом - выдача опционов – весьма интересный способ материальной мотивации, но чтобы он работал, сотрудник должен понимать что он с этого может реально получить, и чтобы это его стимулировал работать , что как и с деньгами, происходит не всегда