Comments 53
Статья написана для форсирования собственного авторитета. Прием сравнивания себя с идолами часто работает. Но автор этой статьи перебрал помоему)
Спасибо за перевод
Спасибо за перевод
Jason Cohen умничка, давно почитываю его блог.
Хотя именно эта статья местам это скорее очередное рассуждение о том быть здоровым и богатым гораздо лучше чем бедным и больным.
Хотя именно эта статья местам это скорее очередное рассуждение о том быть здоровым и богатым гораздо лучше чем бедным и больным.
Алгоритм Гугла вместо с софтом и железом для его реализации, осуществляющий поиск по триллионам сайтов за 0.2 секунды
За 0.2 секунды, алгоритм Гугла осуществляет поиск по разложенным по полочкам данным, который называют индексом, который и сделан именно с той целью, чтобы не искать в триллионе, умноженном на количество страниц каждого из сайтов.
Основная производительность софта и железа растрачивается на то, чтобы обходить сайты и обновлять на основе полученной информации индекс. Например Яндекс, не имея таких ресурсов как у гугла, не может обходить такое количество сайтов, и соответственно так же быстро обновлять индекс, поэтому индексация сайтов Яндексом происходит дольше. Причем заметьте, Яндексу ни что не мешает выдавать результаты поиска за те же 0.2 секунды.
И вы будете очень удивлены, если хотя бы один раз попробуете просмотреть все результаты выдачи Гугла, по практически любому поисковому запросу до конца.
Например по запросу «создание сайтов» Гугл пишет:
Результатов: примерно 58 800 000 (0,24 сек.)
Но при попытке перейти на 101 страницу выдачи (вручную в адресной строке выставить параметрe start значение 1010) появляется надпись:
Извините, но Google не выдает более 1000 результатов, а вы запросили результаты с номера 1010.
Пятьдесят восемь с лишним миллионов совпадений — это большой большой понт от Гугла.
За 0.2 секунды, алгоритм Гугла осуществляет поиск по разложенным по полочкам данным, который называют индексом, который и сделан именно с той целью, чтобы не искать в триллионе, умноженном на количество страниц каждого из сайтов.
Основная производительность софта и железа растрачивается на то, чтобы обходить сайты и обновлять на основе полученной информации индекс. Например Яндекс, не имея таких ресурсов как у гугла, не может обходить такое количество сайтов, и соответственно так же быстро обновлять индекс, поэтому индексация сайтов Яндексом происходит дольше. Причем заметьте, Яндексу ни что не мешает выдавать результаты поиска за те же 0.2 секунды.
И вы будете очень удивлены, если хотя бы один раз попробуете просмотреть все результаты выдачи Гугла, по практически любому поисковому запросу до конца.
Например по запросу «создание сайтов» Гугл пишет:
Результатов: примерно 58 800 000 (0,24 сек.)
Но при попытке перейти на 101 страницу выдачи (вручную в адресной строке выставить параметрe start значение 1010) появляется надпись:
Извините, но Google не выдает более 1000 результатов, а вы запросили результаты с номера 1010.
Пятьдесят восемь с лишним миллионов совпадений — это большой большой понт от Гугла.
Статья не об этом.
UFO just landed and posted this here
Понты тут не причем, подобное решение очевидно для любого приличного разработчика. Результаты запроса кешируются, чтобы не искать по всей базе каждый раз при запросе следующей страницы и этот кеш занимает какое-то количество памяти, учитывая что пользователь редко идет дальше 2 страницы хранить все 58 миллионов напрасная трата ресурсов, 1000 более чем достаточно.
Разумеется ресурсы нужно беречь. Но почему бы не писать честно о том, что показаны 1000 самых релевантных запросу сайтов?
Хабрахабр честно пишет — найдено 1000 топиков, 1000 комментариев, хотя материалов явно больше. habrahabr.ru/search/?q=java
Хабрахабр честно пишет — найдено 1000 топиков, 1000 комментариев, хотя материалов явно больше. habrahabr.ru/search/?q=java
это потому что сфинкс, которого они используют для поиска, по-умолчанию имеет ограничение в 1000 результатов максимум:
sphinxsearch.com/docs/2.0.4/api-func-setlimits.html
но в целом да, все равно никто не просматривает столько результатов — гораздо лучше правильнее составлять поисковые запросы
sphinxsearch.com/docs/2.0.4/api-func-setlimits.html
но в целом да, все равно никто не просматривает столько результатов — гораздо лучше правильнее составлять поисковые запросы
С одной стороны не важны сами результаты, но с другой стороны количество этих результатов может быть важно, я знаю один сайт проверки орфографии, который принимает решение о правильности написания слова по результатам количества результатов в выдаче гугла. Так что гугл все правильно делает.
> Но почему бы не писать честно о том, что показаны 1000 самых релевантных запросу сайтов?
Потому что это абсолютно никого не интересует.
Потому что это абсолютно никого не интересует.
UFO just landed and posted this here
Сдается мне что показывать 1000 когда найдено 100500 ничем не лучше чем показывать 100500 когда найдено 1000 :)
у многих серч енжинов есть такие ограничения на кол-во. На это есть свои, вполне понятные причины.
К слову о Яндексе: у них есть другая «убийственная фича», которую Гуглу пока не удаётся достичь (да и пытается ли?) — это учёт морфологии русского языка. Они нашли своё (:
Не порите чушь, морфология русского языка учитывается гуглом много лет. Посмотрите, например, какие слова выделены при запросе "индия код".
К чему столько злобы?
«Учитывается» и «поддерживается в полной мере» — совершенно разные вещи, не находите?
Яндекс намного лучше поддерживает морфологию русского языка.
Это общепризнанный факт, если не верите — интернет вам в помощь.
p.s. И дело то в том, что у Яндекса свои фичи — это главная мысль.
«Учитывается» и «поддерживается в полной мере» — совершенно разные вещи, не находите?
Яндекс намного лучше поддерживает морфологию русского языка.
Это общепризнанный факт, если не верите — интернет вам в помощь.
p.s. И дело то в том, что у Яндекса свои фичи — это главная мысль.
На прибыли Google это никак не сказывается (то, что они пишут про миллионы, а показывают, на самом деле, всего 1000). Понты не важны, важны деньги.
Правильно пишет. Все, что может быть скопировано, будет скопировано.
Интеллектуальной собственности не бывает — как говорили в зАиБи и также говорит Ричард. И рассчитывать на интеллектуальную собственность в стартапе, имхо, не особо стоит.
Однако — внутренний мир СУБД Oracle и MS SQL храниться за семью печатями и договорами о неразглашении. И это вообщем помогает им сохранять нехилое преимущество перед глубокоуважаемыми и любимыми postgers и mysql.
Как говорится — jedem das siene…
Однако — внутренний мир СУБД Oracle и MS SQL храниться за семью печатями и договорами о неразглашении. И это вообщем помогает им сохранять нехилое преимущество перед глубокоуважаемыми и любимыми postgers и mysql.
Как говорится — jedem das siene…
Перешли с Оракла и MsSql на Постгре.
БД 7 миллиардов записей, highload (10,000 запросов в секунду), в кластере десятки серверов.
Постгре как минимум не хуже, а ИМХО лучше. Во-первых, он бесплатный.
Во-вторых, Оракл имеет свойство выдавать говенные ошибки (к примеру, нет прав на таблицу — он выдает, что ее нет).
В-третьих, оракл слишком бюрократизирован. ИМХО
Хотя несомненно, Оракл — высокоточная, мощная БД, не просто так использующаяся. Но в чем-то ее можно сравнить с тем, что у нас любят ставить везде Винду. Типа, лицензии есть, Бренд, хуе-мое.
При этом Постгре реально не хуже для кучи задач.
БД 7 миллиардов записей, highload (10,000 запросов в секунду), в кластере десятки серверов.
Постгре как минимум не хуже, а ИМХО лучше. Во-первых, он бесплатный.
Во-вторых, Оракл имеет свойство выдавать говенные ошибки (к примеру, нет прав на таблицу — он выдает, что ее нет).
В-третьих, оракл слишком бюрократизирован. ИМХО
Хотя несомненно, Оракл — высокоточная, мощная БД, не просто так использующаяся. Но в чем-то ее можно сравнить с тем, что у нас любят ставить везде Винду. Типа, лицензии есть, Бренд, хуе-мое.
При этом Постгре реально не хуже для кучи задач.
Постгре не хуже для кучи задач, mysql хорош — я их люблю и использую, НО:
1. Разрабов mysql ~150, разрабов оракла — думаю в 50-100 раз больше, разрабы мускула признают, что опыт в оракл несравнимо больше.
К тому же, имхо, качество реально сложного софта достигается потом и кровью и большим количеством времени…
2. Enterprise сектор, база ~400 таблиц, по размеру небольшая 3-4Гб, вариант на посгре на в среднем(на различных операциях) на 30% медленнее, на бесплатной версии DB2 где-то те же результаты.
3. Mysql, innodb движок, таблица 80млн записей — а попробуйте удалить из них 55млн — на это может уйти неделя! А в MS SQL — в пределах минут…
А по поводу Бренда и лицензий — как повергала меня в ужас политика лицензирования MS, Oracle и (особенно!) Cisco так и будет повергать…
Еще раз — каждому свое — Photoshop несравнимо лучше GIMP для полиграфии, RHEL несравнимо лучше всех кластерных изысков виндов для HPC, Oracle лучшая СУБД в корпоративном секторе, а SSH лучшее впн решение для тех кто умеет им пользоваться…
1. Разрабов mysql ~150, разрабов оракла — думаю в 50-100 раз больше, разрабы мускула признают, что опыт в оракл несравнимо больше.
К тому же, имхо, качество реально сложного софта достигается потом и кровью и большим количеством времени…
2. Enterprise сектор, база ~400 таблиц, по размеру небольшая 3-4Гб, вариант на посгре на в среднем(на различных операциях) на 30% медленнее, на бесплатной версии DB2 где-то те же результаты.
3. Mysql, innodb движок, таблица 80млн записей — а попробуйте удалить из них 55млн — на это может уйти неделя! А в MS SQL — в пределах минут…
А по поводу Бренда и лицензий — как повергала меня в ужас политика лицензирования MS, Oracle и (особенно!) Cisco так и будет повергать…
Еще раз — каждому свое — Photoshop несравнимо лучше GIMP для полиграфии, RHEL несравнимо лучше всех кластерных изысков виндов для HPC, Oracle лучшая СУБД в корпоративном секторе, а SSH лучшее впн решение для тех кто умеет им пользоваться…
Постгре у нас тоже корпоративный сектор :)
Быстрее или нет оракла – сложно сказать, зависит от серверов, запросов, структуры бд, рук разработчиков
Я бы сказал, оракл равен пг. Это охуенные бд
Одна лучше в одном, другая в другом, в целом кул
Мускул требует тонких рук.я в нем не спец, багов в триггерах таблиц и хранимках хватило. Имхо без допилки это плюшевая бд
Мс скл не знаю, чтобы судить. Судя по ее мизеру, бд так себе, но это имхо
Быстрее или нет оракла – сложно сказать, зависит от серверов, запросов, структуры бд, рук разработчиков
Я бы сказал, оракл равен пг. Это охуенные бд
Одна лучше в одном, другая в другом, в целом кул
Мускул требует тонких рук.я в нем не спец, багов в триггерах таблиц и хранимках хватило. Имхо без допилки это плюшевая бд
Мс скл не знаю, чтобы судить. Судя по ее мизеру, бд так себе, но это имхо
В Oracle всего 34 тысячи «developers and engineers», на все их продукты, включая БД, Java, Middleware, Solaris и т.д., и т.п.)
www.oracle.com/technetwork/indexes/downloads/index.html#middleware
www.oracle.com/technetwork/indexes/downloads/index.html#middleware
БД 7 миллиардов записей, highload (10,000 запросов в секунду), в кластере десятки серверов.на посгре внушает уважение и интерес. А 10К запросов — это именно запросов к базе или кликов и проект интернет или корпоративный?
Я думал, намного будет… Намного хуже будет это все. И очень хороший перевод, просто очень хороший перевод! Я думал, намного хуже это все будет. Сколько раз сюда ходииил — было намного хуже, но на этот раз как-то удалось.
Но вот два последних абзаца, они как-то тяжело дались вам, видимо :)
Но вот два последних абзаца, они как-то тяжело дались вам, видимо :)
Из перевода понравилось:
Эппл жертвует всем во имя дизайна.
«Эппл, эппл, эппл, аааа Apple!»
Честно, завис на минуту читая эту строчку.
Эппл жертвует всем во имя дизайна.
«Эппл, эппл, эппл, аааа Apple!»
Честно, завис на минуту читая эту строчку.
Что-то я от обилия пафоса даже статью не осилил
Пафос пафосом, а основной посыл очень хороший и правильный м
Правильного посыла там две строчки, которые, как мне кажется, очевидны, а остальное — пафосная вода, которая сводит на нет полезную инфорацию
Воля ваша, но мне статья понравилась. И посыл хороший, и примеры живые, и обои нескучные. Сам сталкивался с проблемой, описанной автором, и как раз такого матерала не хватало, когда руки опускались от того, что видел на рынке. Пафос же возможно и с особенностями перевода и разницы в менталитетах связан.
Пафос — это хорошо, это цепляет.
Пафос, когда чувак был нулем, а построил компанию в сфере кодревью, где продает самый дорогой продукт среди аналогов. Причем есть опенсорс конкуренты.
При этом посещает кучу конференций, помогает новичкам, и делает другие компании.
Self-made man. Он имеет основания быть пафосным.
Пафос, когда чувак был нулем, а построил компанию в сфере кодревью, где продает самый дорогой продукт среди аналогов. Причем есть опенсорс конкуренты.
При этом посещает кучу конференций, помогает новичкам, и делает другие компании.
Self-made man. Он имеет основания быть пафосным.
Из психологов в тимлиды разработчиков, ага. Уперёд!
Яркая фантазия у автора.
Яркая фантазия у автора.
В чём содержание статьи помимо того, что «правильные люди — главное»? *где правильные = настойчивые взаимодополняющие друг друга специалисты в определенной тематике, умело набирающие авторитет, а также знающие свой рынок
окей, давайте тезисами.
1. выбор сферы. нишевый фокус. вы не обязательно должны иметь опыт в сфере или человека с опытом. но вы выбираете сферу и фокусируетесь на ней. в отличие от 99% говностартапов-конкурентов, рассчитанных «на всех»
2. выбор команды. не работаете с п@здоболами, работаете с профи. целенаправленно собираете команду, а не из друзей по пиву. см. пункт про 99% процентов конкурентов
3. клиенты и продажи как ОСНОВА. производство — следствие. вы не делаете того, что делает 99%. простите за злоупотребление, как говорит автор :) вы думаете по-западному, а не по советскому образцу. в СССР как — барыга спекулянт это козел, а производитель — все. сейчас — ритейл и сети это говно, а производитель — все.
на деле — наоборот. продажи без производства — легко. делать деньги на (пере)продажах можно — Эппл прекрасно это делает, Микрософт и т.д. Айфоны ФИЗИЧЕСКИ делают в Китае, напоминаю.
а вот производителей, которые делают говнопродукт за миллионы инвесторов и них@я не могут продать — тысячи.
поэтому начните продавать завтра. вы увидите продукт глазами клиентов и сразу получите обратную связь. прочитайте мою статью про это.
у нас пытаются сделать СРАЗУ КРУТО. запомните — вы ВСЕГДА будете ПЕРЕДЕЛЫВАТЬ. что бы вам не пели программисты. то есть вы будете 100% переделывать. поэтому лучший способ начать ПЕРЕДЕЛЫВАТЬ правильно — сделать просто и быстро. говнокодом. и уже через месяц (а не год) продать.
можно делать иначе, но только если у тебя команда мечты (Стив Джобс, вечна тебе память). делать год охуенный айпад 3.
4. хороший маркетинг и пиар. в виде присутствия знаменитых людей. самый простой способ — сделать продукт с Главной Фичей (С), а потом отправить его посмотреть тем Авторитетам (С), которые варятся в этой сфере и он им понравится. т.е. главная фича => правильный отзыв знаменитости.
5. Главный абзац статьи
Плохая новость: почти никто, с кем я говорю, не имеет правильных ответов, но они думают, что имеют. И это фатально, потому что это значит, что они не работают на опережение для предотвращения критических ситуаций. Это значит, когда один из вышеописанных сценариев претворится в жизнь, будет слишком поздно.
В моем переводе — помните фон Клаузевица? «Стратегические просчеты невозможно компенсировать тактическими успехами». Или, как любит Потапенко после этой фразы дополнять, сифилис присыпками не лечат.
Большая часть стартаперов думает, как бы получить бабла. Потом — на какие конференции сходить, и какие п@здатые айпады купить. Как ДИЗАЙН ДОЛЖЕН БЫТЬ ИДЕАЛЕН. ПРОДУКТ ДОЛЖЕН БЫТЬ ИДЕАЛЕН. ДАВАЙТЕ ДЕЛАТЬ ЕГО ДВА ГОДА. И КОНКУРЕНТОВ У НАС НЕТ И НЕ МОЖЕТ БЫТЬ.
Реально, поспрашивайте их. О том, что съ@бется ведущий программер, никто не думает вообще.
То есть люди реально не понимают, что стартапы — это бизнес. Высокорисковый. См. пиплваре — управление проектом начинается с управления рисками.
А они считают себя профи, ни разу не запустив стартап, и спорят со мной, епт, что знают.
Например, что не нужно делать говнопродукт, что не нужно брать идеальных супер-спецов, а нужно урезать расходы по максимуму на первый этап, отсечь лишнее вроде маков для разрабов (А лучше вообще аутсорс) и т.д.
и все деньги на Главную Фичу, которая продается прямо завтра.
К примеру, у меня есть проект, который мы с другом сделали за 2 часа, а у него 2000 людей в день ходит.
Просто на коленке. Нет дизайна (не было первые полгода).
Проект for fun, анонимная благотворительность.
Косвенные конкуренты раскручивали свой форум 3 года с кучей денег и т.д. А потом просто слизали БД у нас. Ток не учли инсайдерской инфы.
1. выбор сферы. нишевый фокус. вы не обязательно должны иметь опыт в сфере или человека с опытом. но вы выбираете сферу и фокусируетесь на ней. в отличие от 99% говностартапов-конкурентов, рассчитанных «на всех»
2. выбор команды. не работаете с п@здоболами, работаете с профи. целенаправленно собираете команду, а не из друзей по пиву. см. пункт про 99% процентов конкурентов
3. клиенты и продажи как ОСНОВА. производство — следствие. вы не делаете того, что делает 99%. простите за злоупотребление, как говорит автор :) вы думаете по-западному, а не по советскому образцу. в СССР как — барыга спекулянт это козел, а производитель — все. сейчас — ритейл и сети это говно, а производитель — все.
на деле — наоборот. продажи без производства — легко. делать деньги на (пере)продажах можно — Эппл прекрасно это делает, Микрософт и т.д. Айфоны ФИЗИЧЕСКИ делают в Китае, напоминаю.
а вот производителей, которые делают говнопродукт за миллионы инвесторов и них@я не могут продать — тысячи.
поэтому начните продавать завтра. вы увидите продукт глазами клиентов и сразу получите обратную связь. прочитайте мою статью про это.
у нас пытаются сделать СРАЗУ КРУТО. запомните — вы ВСЕГДА будете ПЕРЕДЕЛЫВАТЬ. что бы вам не пели программисты. то есть вы будете 100% переделывать. поэтому лучший способ начать ПЕРЕДЕЛЫВАТЬ правильно — сделать просто и быстро. говнокодом. и уже через месяц (а не год) продать.
можно делать иначе, но только если у тебя команда мечты (Стив Джобс, вечна тебе память). делать год охуенный айпад 3.
4. хороший маркетинг и пиар. в виде присутствия знаменитых людей. самый простой способ — сделать продукт с Главной Фичей (С), а потом отправить его посмотреть тем Авторитетам (С), которые варятся в этой сфере и он им понравится. т.е. главная фича => правильный отзыв знаменитости.
5. Главный абзац статьи
Плохая новость: почти никто, с кем я говорю, не имеет правильных ответов, но они думают, что имеют. И это фатально, потому что это значит, что они не работают на опережение для предотвращения критических ситуаций. Это значит, когда один из вышеописанных сценариев претворится в жизнь, будет слишком поздно.
В моем переводе — помните фон Клаузевица? «Стратегические просчеты невозможно компенсировать тактическими успехами». Или, как любит Потапенко после этой фразы дополнять, сифилис присыпками не лечат.
Большая часть стартаперов думает, как бы получить бабла. Потом — на какие конференции сходить, и какие п@здатые айпады купить. Как ДИЗАЙН ДОЛЖЕН БЫТЬ ИДЕАЛЕН. ПРОДУКТ ДОЛЖЕН БЫТЬ ИДЕАЛЕН. ДАВАЙТЕ ДЕЛАТЬ ЕГО ДВА ГОДА. И КОНКУРЕНТОВ У НАС НЕТ И НЕ МОЖЕТ БЫТЬ.
Реально, поспрашивайте их. О том, что съ@бется ведущий программер, никто не думает вообще.
То есть люди реально не понимают, что стартапы — это бизнес. Высокорисковый. См. пиплваре — управление проектом начинается с управления рисками.
А они считают себя профи, ни разу не запустив стартап, и спорят со мной, епт, что знают.
Например, что не нужно делать говнопродукт, что не нужно брать идеальных супер-спецов, а нужно урезать расходы по максимуму на первый этап, отсечь лишнее вроде маков для разрабов (А лучше вообще аутсорс) и т.д.
и все деньги на Главную Фичу, которая продается прямо завтра.
К примеру, у меня есть проект, который мы с другом сделали за 2 часа, а у него 2000 людей в день ходит.
Просто на коленке. Нет дизайна (не было первые полгода).
Проект for fun, анонимная благотворительность.
Косвенные конкуренты раскручивали свой форум 3 года с кучей денег и т.д. А потом просто слизали БД у нас. Ток не учли инсайдерской инфы.
При этом почему я против проектирования сразу крутого.
Я напишу скоро статью.
Это не я придумал. Роберт Мартин, Uncle Bob, который подписал Agile Manifest, круто пропиарил TDD, сформулировал SOLID принципы (IoC это оттуда, если что), об этом писал еще в 1994 (!!!) году.
Поэтому мы делаем так
1. итерация один. до стадии самодостаточности проекта, когда его можно бросить на полгода и он проработает.
— первая версия. говнокод. заглушки.
— вы выясняете ТРЕБОВАНИЯ, показывая рабочие прототипы. и ЖИВЫЕ данные. любые таблицы, любые верстки, дизайны и тд, любая логика только на ЖИВЫХ данных проверяется. и никак иначе. факт жизни.
к примеру, самолеты только упав, говорят нам, где ошиблись теоретики теории турбулентностей и т.д
на компах у инженеров самолеты не падают.
и проекты на макетах не падают, и на компах программеров. ток когда я использую (а не ТЕСТИРУЮ мля) проект, он падает и получается фидбэк.
— как программист вы лучше уясняете себе сущности. выделяете главное.
— в итоге эволюций за 5-15 требования устаканиваются. проект работает процентов на 20%, реализован главный функционал.
замораживаем его, если надо.
и внедряем окончательно.
2. итерация два. до логической завершенности
— уже юзают проект живые юзеры
— формирует списки самого важного функционала
— логически завершаем проект. условно, доделывает из 100% процентов 80% оставшегося.
— грязновато, юзабилити неидеально. просто проект логичен и все, что горит людям повседневно, сделаон
— так как стадия самодостаточности позади, в любой момент его можно заморозить.
3. итерация три — визуальный тюнинг
— отрисовываем все красиво
— яваскрипты, силверлайты, флэши, Qt-навороты, у кого что.
— тюнингуем всякие штуки.
4. итерация четыре — бесконечности
— выделяем новые разделы в проекте, и делаем их по тем же самым итерациям.
— так как проект ветвится, как дерево, развивать его можно бесконечно. любой проект. секрет — БЫТЬ В СФЕРЕ ПРОЕКТА, смотреть глазами пользователя
— если исходное дерево проект засралось, рефакторим структуру. рефакторить нужно регулярно, закон суров: любой порядок стремиться к хаосу, если его не поддерживать.
Я напишу скоро статью.
Это не я придумал. Роберт Мартин, Uncle Bob, который подписал Agile Manifest, круто пропиарил TDD, сформулировал SOLID принципы (IoC это оттуда, если что), об этом писал еще в 1994 (!!!) году.
Поэтому мы делаем так
1. итерация один. до стадии самодостаточности проекта, когда его можно бросить на полгода и он проработает.
— первая версия. говнокод. заглушки.
— вы выясняете ТРЕБОВАНИЯ, показывая рабочие прототипы. и ЖИВЫЕ данные. любые таблицы, любые верстки, дизайны и тд, любая логика только на ЖИВЫХ данных проверяется. и никак иначе. факт жизни.
к примеру, самолеты только упав, говорят нам, где ошиблись теоретики теории турбулентностей и т.д
на компах у инженеров самолеты не падают.
и проекты на макетах не падают, и на компах программеров. ток когда я использую (а не ТЕСТИРУЮ мля) проект, он падает и получается фидбэк.
— как программист вы лучше уясняете себе сущности. выделяете главное.
— в итоге эволюций за 5-15 требования устаканиваются. проект работает процентов на 20%, реализован главный функционал.
замораживаем его, если надо.
и внедряем окончательно.
2. итерация два. до логической завершенности
— уже юзают проект живые юзеры
— формирует списки самого важного функционала
— логически завершаем проект. условно, доделывает из 100% процентов 80% оставшегося.
— грязновато, юзабилити неидеально. просто проект логичен и все, что горит людям повседневно, сделаон
— так как стадия самодостаточности позади, в любой момент его можно заморозить.
3. итерация три — визуальный тюнинг
— отрисовываем все красиво
— яваскрипты, силверлайты, флэши, Qt-навороты, у кого что.
— тюнингуем всякие штуки.
4. итерация четыре — бесконечности
— выделяем новые разделы в проекте, и делаем их по тем же самым итерациям.
— так как проект ветвится, как дерево, развивать его можно бесконечно. любой проект. секрет — БЫТЬ В СФЕРЕ ПРОЕКТА, смотреть глазами пользователя
— если исходное дерево проект засралось, рефакторим структуру. рефакторить нужно регулярно, закон суров: любой порядок стремиться к хаосу, если его не поддерживать.
Мартин сказал — нельзя спроектировать сверху вниз, только снизу вверх.
Писать качественный кодж и говнокод — это почти одинкаковые затраты. Вы наверно путаете overengineering с качественным преоктирование. Качественное проектирование позволяет делать большее меньшим количеством строк. Особенно это будет заметно, если захотите значителньо изменить структуру. Хорошо организованый код надо будет либо донастроить, говнокод — переписать.
>Писать качественный кодж и говнокод — это почти одинкаковые затраты.
O RLY?
у меня есть ООП задача, в лоб она решается одним классом с ПХП+ХТМЛ, и все нарушается: IoC, SOLID etc.
и ровно в 5 раз медленнее делается нормальное ООП, если писать реализацию.
интерфейсы, абстрактные классы, фабрики, прокси и тд.; причем МИНИМАЛЬНО необходимые для нормального масштабирования под требования.
O RLY?
у меня есть ООП задача, в лоб она решается одним классом с ПХП+ХТМЛ, и все нарушается: IoC, SOLID etc.
и ровно в 5 раз медленнее делается нормальное ООП, если писать реализацию.
интерфейсы, абстрактные классы, фабрики, прокси и тд.; причем МИНИМАЛЬНО необходимые для нормального масштабирования под требования.
2ой абзац — это overengeneering, то есть излишнее усложнение.
Все перечисленное там тебе не надо, если все можно сделать в одном классе. А что бы не нарушались твои IoC просто надо грамотно продумать код.
>Писать качественный кодж и говнокод — это почти одинкаковые затраты.
Написав это я подразумевал что, в конечном итоге с учетом последующих исправлений багов, выигрыш по времени будет все таки на стороне нормального кода.
Все перечисленное там тебе не надо, если все можно сделать в одном классе. А что бы не нарушались твои IoC просто надо грамотно продумать код.
>Писать качественный кодж и говнокод — это почти одинкаковые затраты.
Написав это я подразумевал что, в конечном итоге с учетом последующих исправлений багов, выигрыш по времени будет все таки на стороне нормального кода.
В конечном итоге нормальный код, боюсь, никогда себя не окупит, потому что проект не стартанет, или не будет достаточно быстро меняться.
В одном классе — это антиООП. Задача конкретная — есть алгоритм. Он должен одинаково работать под консоль, под веб — I/O объекты и хранилища разные, а алгоритм один. Необходимо обеспечить легкость добавления новых реализаций I/O объектов и хранилищ в виде новых «сред» (контекстов) так, чтобы исходный алгоритм не изменялся вообще.
Отличная ООП задача, выявляет все и сразу.
Впрочем, о чем мы спорим? :) Если бы можно было измерить overengeneering точно и сразу, моя работа архитектора была бы просто формальным применением матмодели.
В одном классе — это антиООП. Задача конкретная — есть алгоритм. Он должен одинаково работать под консоль, под веб — I/O объекты и хранилища разные, а алгоритм один. Необходимо обеспечить легкость добавления новых реализаций I/O объектов и хранилищ в виде новых «сред» (контекстов) так, чтобы исходный алгоритм не изменялся вообще.
Отличная ООП задача, выявляет все и сразу.
Впрочем, о чем мы спорим? :) Если бы можно было измерить overengeneering точно и сразу, моя работа архитектора была бы просто формальным применением матмодели.
Наверное надо уточнить — быстрый запуск тяп-ляп допустим, когда ниша не занята, чтобы сразу получать фидбек (+ пресловутый traction) и быстро дополнять/пилить функционал. Если ниша конкурентная — такая тактика не прокатит.
как утверждает фонд Джоэла Спольски (Joel Spolsky), «их софт — всего лишь набор текстовых полей»)
А что за фонд у Джоэля? Помощи молодым геям-программистам?
В оригинале:
as Joel Spolsky is fond of saying, “Their software is just a bunch of text fields!”
Google Translate:
как Джоэл Спольски любит говорить: «Их программное обеспечение просто набор текстовых полей!»
статья — во многом клон или размазанный повтор книги «22 непреложных закона маркетинга». И, да, статья подтвердила последний или предпоследний тезис книги «даже самая плохая идея с хорошим количеством денег лучше, чем самая хорошая идея без них» (если брать кисметрикс с мощной «спиной» информационной поддержки гуру «той страны»
Sign up to leave a comment.
Настоящие нечестные конкурентные преимущества