Pull to refresh
0
0
Дмитрий Федорович @AlThar

User

Send message
Не могу сказать, что статья была для меня чем-нибудь полезна, но за труд спасибо.
Статью читал. А комментарий мой — это не более чем наблюдение. Он не связан с тем, что я «ненавижу» эппл. Честно говоря, спокойно к нему отношусь. Не пользуюсь из-за высокой стоимости.
Совершенно согласен с вами. Но такова уж природа человека. Он пытается навязать свое мнение другим так или иначе. Не буду писать, что эппл объективно зажрались. Каждый решает сам стоит ли удовольствие от использования продуктов эппл, потраченных на них денег.
Нет не заметил. Я никогда не пользовался яблочными продуктами. Основная причина в том, что я не вижу (кроме пожалуй симпатичного дизайна) явных преимуществ перед другими подобными продуктами. А цена яблок всегда была высока.
Честно говоря я вообще не понял вашего комментария.
На вопрос «где надо хранить логику данных?» может ответить здравый смысл. Им можно пользоваться не опасаясь, что это «не лучший подход».
Яблочный барон (вы поняли о ком я), все отлично спланировал и блестяще исполнил. Он играет на стадном чувстве малосознательных людей. Но я не вижу в этом ничего плохого (для себя например). Всегда существовало стадо, идущее беспрекословно за колокольчиком.
Писал приложение для этой системы. Хочу отметить (это только мое мнение), что API работает весьма медленно. Встречаются косяки. К примеру при получении списка item`ов продавца (а мне надо было сменить програмно их описания) я в одном случае из 200-300 получал странный ответ, в котором было написано, что верификация подписи неверна. При повтором посыле такого-же запроса возвращался нормальный ответ. Мелоч, а неприятно. Так же сайт очень расстроил. Часто ссылки из писочницы ведут на ресурсы вне ее, а бывает наоборот (ссылки перепутали). Очень медленный и практически бесполезный сапорт по ticket`ам. Хотя на форуме он намного лучше и (как ни странно) оперативнее.
Проекты бывают разные. Мы к тому же возвращаемся:). Не для всех проектов нужна спека. Есть проекты, где без нее никуда не деться. Но это далеко не необходимость.
Да, конечно. Если кого-то переедет трактор — стартап развалится, хоть со спекой, хоть без. На то он и стартап.
Не соглашусь. В нашем конкретном проекте ТЗ очень затормозило бы проект. Чтобы все не забыть — есть листик над ноутом на стенке, где все написано :) (карандашиком).
Дело в том, что продукт, который мы делаем — наш личный. Это стартап, выигравший ни один конкурс. Функционал мы сами себе устанавливаем необходимый. Что получается — совершенно очевидно. Мы же не сходу садимся писать систему, а обговариваем все и обдумываем. Мы знаем, что должно получиться. Сроки прогнозируются вполне простым способом — каждый просто расчитывает срок своей части (+время на интеграцию и отладку\правку). Спецификация НИКАК не помогает определиться со сроками. В любом случае конечный программист говорит сколько ему надо на решение его задачи (в случае со спекой тоже).
Так клиент у нас мы сами — то «платим» мы себе именно за то, что получается. Ведь результат виден. В конечном итоге нет разницы со спекой пишешь или без нее.
Вообще я частично объяснил как происходит работа у нас.
В общем система, которую надо сделать, делится на N частей, минимально друг с другом взаимодействующих. В нашем случае — медиасервер, биллинг, пользовательское приложение (web-сайт), система отчетов. Каждый разработчик вникает в задачу и делает ее не обращая внимание на остальные модули (принимает их за черные ящики). В целом можно описать документально протоколы взаимодействия модулей, но у мы этого не делали. Просто когда пришло время интеграции — сели и продумали формат взаимодействия (написав карандашиком на бумажке). Потом кивнули друг другу и сели писать. Потом интеграция в кежиме extreme-debugging. Пара дней отладки + пару недель тестирования (кстати модульное тестирование тоже не является у нас частью процесса. Каждый тестит свою часть как считает нужным). И собственно продукт готов. Конечно — такой подход довольно негибок в том смысле, что подойдет не любой команде, однако у нас он работает на ура. Можете убедиться zingaya.com
Протокол следующий.
1). Андрюха говорит — «что за ересь происходит, звонки не проходят на американские номера».
2). Я — «Хм… Ща посмотрю (смотрю БД, логи). Ааа понятно короче, ща починю (чиню). Пробуй»
3). Андрюха — «Нормал — терь работает»

Вот примерно такой. Такая система жизнеспособна на 100%.
Так или иначе — есть звено, которое дает конечному программисту возможность узнавать требования и задачи, то же аналитик.

Главное различие в подходах видимо в том — есть ли возможность разработчику погрузится в специфику бизнеса и понять задачу самостоятельно.
Вообще такого рода дискуссии — типичный «holy war». Все зависит от задачи и от команды в целом. Главное — здравый смысл в подходе к задаче — все остальное блаж.
1. Эта система наш личный проект — не отдадут (если отдадут, придется документировать, но делать это заранее считаю глупостью запредельной)
2. В сумме (проект длился около года) часов 10-15
3. Нет. Скажу даже больше. По всей системе нет ни одного документа вообще

Дело в том, что каждый программист пишет свой, совершенно автономный модуль (я писал биллинговую систему). При таком подходе, все, что нужно знать о других частях системы — это интерфейс взаимодействия. На его обсуждение (и запись на бумажке, которую повесил над ноутом на стенке) мы потратили 10-15 часов.
В России развитию стартапов мешают многие факторы. Главный из них (по моему мнению) я уже назвал.
Перспективных проектов у нас хватает. Могу привести в пример проект в котором с данный момент работаю. Мы победили на нескольких стартап конкурсах. При поиске инвесторов (а общались и с госпожой Дайсен и с высшим начальством вКонтакте и многими другими людьми) было принято решение, что отечественные инвесторы — не вариант. По тем же причинам все, уже писал.
Последняя фраза — очень правильная, мне кажется.
Не надо ставить себе догм. Руководствоваться надо здравым смыслом. Нужна спека (и какая конкретно) — пишем. Не нужна, не пишем.

Information

Rating
Does not participate
Location
Железнодорожный (Московск.), Москва и Московская обл., Россия
Date of birth
Registered
Activity