Cord

Только что подумал,
Что Боб Мартин просто показал высший пилотаж тонкого троллинга. Такое мог сделать только Мастер.

Заодно многие подумают о переходе на tdd, что есть гуд

Работающий код — это самое первое требование, конечно

Про тесты. Я считаю, критические места должны быть покрыты тестами (отправка заказа, логи платежей и тд), а на каждый чих тест на первом этапе не нужен — YAGNI. Но не всегда это возможно.

То есть я согласен, что нужно думать

Но если вы в состоянии неопределенности — а это в бизнесе реалии, а не фантазии, думать не над чем, нет инфы из практики. А практика, опыт придут тем быстрее и больше, чем чаще вы поначалу релизите и используете обратную связь, improvement.
А как критическую массу накопили, переварили, перевели дух, выделили основные неизменяемые куски — тут и надо рефакторить. Показатель — это самодостаточность раздела на проекте, оставил на месяц без изменений в функционале, а цифровые показатели достигаются

Пример — циан.ру
Долгое время был плохой дизайн, но проект решал задачи. Деньги шли, квартиры добавлялись. А потом наняли Лебедева отрефакторить дизайн.

Это трудно сразу принять, меня год учили этому хорошие учителя, спасибо им.

Вообще, это очень многогранная проблема. Мой опыт отличается от вашего, обычно либо «правильно и долго», либо «неправильно и долго». Поэтому для решения бизнес-задач и появилось чередование «быстро и неправильно» с «долго и правильно».

А аспекта два. Первый — это заблуждение людей, что они могут сделать правильно. Простой пример — на собеседовании спрашиваю, что такое инкапсуляция. Человек уверен в себе и читает определение. Теперь прошу пример из жизни — молчит. Вы рулите машиной, не видя деталей ее реализации, а имея только интерфейс. И человек смущается, понимания нет. И добиваю — ну окей, разобрались что это, а зачем оно? и вот ответ осмысленный, типа чтобы не порождать неявных зависимостей и кривой граф циклический, или чтобы состояние объекта кто угодно извне не менял (вечный спор геттеры и сеттеры против паблик), способны дать немногие

Так и паттерн. Ну окей, стратегия, а где она нужна, зачем, как без нее обойтись, как она в этом коде решит проблемуи какие метрики архитектуры улучшит или ухудшит, думают немногие.

То есть имеют инструмент, но все за и против не взвешивают, что дает overengineeering, а потом нежелание менять слишком рано усложненный код.

Вторая проблема еще раньше, в проджект менеджере и ведущих, в техзадании. Даже если у вас крутые программисты, важны исходные задачи. Они всегда меняются, мы не дети, это ясно. Но глупо писать одинаково как редко меняющиеся задачи, так и меняющиеся каждый день.

Если вы объяснили разработчикам, что нужно меню версткой потестить, а они ушли на неделю делать компонент в библиотеку, то в консерватории что-то надо менять.

И обратно, если вы уже нашли нужный функционал и попросили запилить стабильно, чтобы оно работало, а люди тестами не покрыли и оставили говнокод, это писец

Так что на сотой итерации должен быть крутой код

Если его нет, вопрос qa

Согласен.

Но часто это в целях скорости близкие вещи. Сто классов и сто тестов против одного класса — уже разница во времени.
Если вы думаете, это шутка, то не видели проекты, где на каждый чих новый класс, два интерфейса и тесты уровня «умножает ли оно дважды два». Потому что чем больше про изменения говоришь, тем больше программист через ООП старается себя обезопасить. И убедить написать говнокодом можно, только пообещав дать время отрефакторить

Эффект при том, что люди считали себя умнее, чем на самом деле, и уверенность в своем уме и уровне ослепляет, что ведет к ошибкам

Говорят, он стал лучше.

Но чем прет Симфони — бери и юзай отдельные куски. Философия Юникс в действии. SOLID, low coupling, high cohesion — все давно известно.

А когда мне нужен один кэш зенда был, а нужно ставить весь фреймворк — потому что вдруг где-то оно цепляет кучу вспомогательной фигни и валится — имхо не круто.

Хотя фреймворк, если на нем все писать, достойный

Роберт опытен и многое предвидит.

Но в стартапа с большой долей неопределенности вам сначала нужно быть быстрым. Сначала надо тупо взлететь. Так как вариантов много, то вероятность сразу просчитать сто ходов низка.

Поэтому нужна эволюция. Полно хороших приложений, делавшихся долго и не взлетевших. Потому что программисты молодцы и красавцы, все сделали красиво и по ТЗ. Но само ТЗ было неверным, так как обычно рождается одним-двумя людьми. А вовсе не той тысячей клиентов, которые хотят дать вам денег за верную реализацию верного ТЗ.

Другое дело, если вы сами шарите в задачах ваших клиентов, и можете описать до кончика ногтей, как дышит тысяча таких же, как вы. Но право, в большей части стартапов аудитория прописана общими словами, как я видел.

А лучший способ влезть в шкуру клиента и понять его задачи — дать ему пластелин, чтобы он сваял макет. А потом вы ему из золота (чуть не написал «гранита») отольете его протип.

Но тратить золото (время программистов и других специалистов) на задачи, которые решает пластилиновый протип, имхо неверно.

Да, модульность крутая тема. Но иногда бывает, не знаешь, какие модули завтра будешь делить, какие объединять. Поэтому декомпозицию ИМХО стоит делать после пары итерации уже, когда ясно, что сделали нужное. А то начали соцсеть, пришли к инет-магазину, потому что остальное юзерам, кроме товаров, бывших одним из 10 разделов, нафиг не уперлось.

В комментах пошла тема, вот гады, не дают написать нормально.
В этой статье я хотел показать пример, почему иногда нужно писать сначала криво. А также добавил, что думать о себе как об архитекторе, и реально переписать уметь нужное вовремя и хорошо — разные вещи.

Как пример, нам достался проект считалки хайлоад. Разработчики там хранили уникальные айди юзеров как комбинацию куки и еще других вещей хз где, а потом для повышения производительности «отрефакторили», что записываться айди стал в мемкешд. А че, типа быстро работает. То, что такое ACID и что мемкешд стирает ключи в процессе работы — ну не бд это, как, видимо, думали — это не про наших парней.

В итоге юзер зашел, ходит по сайту, мы видим один его айди. Потом мемкешд стер, у него теперь айди снова сгенерился и уже другой. А юзер-то один.

И таких примеров море. Эффект Даннига-Крюгера в действии

Просто в шоке.

Какой открытый человек.

I see you, Amanda.

Думаю о такой штуке уже три года

не хочется писать велосипед.

Недостаточно серьезно. Чтобы все догадались, имхо нужно больше пафоса, чтобы жир аж стекал с монитора

Даже если прочитать наоборот, ваши советы неоднозначны

Так, совета думать головой не было.
А без головы дитятко воткнет кэш результатов отработки и потом будет кушать все проблемы поддержки и масштабирования, вместо оптимизации запросов к бд, что являлось первопричиной.

Или же полезет оптимизировать алгоритмы с умным видом всезнайки, в то время как проблема в железе и чудо-юдо просто не могло предположить такой баттлнэк из-за узкого кругозора.

Ум и опыт, опыт и ум. И поэтому да, нельзя просто так взять и поднять производительность, если ты дядя Вася, даже с набором вредных советов, но без опыта и ума

Млять, дороги в городах сравните
У zyalt есть посты с фоткаии Европы и нашими

И станет ясно сразу все про порядки.

Критики мля

И достаточным? Не думаю, что Тиньков и Лебедев полагаются только на одно чутье и больше ничего. Банк Тиньков делал после расчета хорошего, и тд

А даже если и так, исключение подтверждает правило

Битрикс до продажи Рыжиков тоже развивал сам, к примеру

Какая разница, если клиенты платят, вместо инвесторов есть кредиты в банках, если уверенность в бизнесе и его потенциальном ускорении роста при вливании денег есть.

Ок

Без 15 минут коммент неполон был для меня

1. найди мне десятерых, кто даст тебе денег за эту бизнес-идею :)
2. если серьезно, даже блог раньше был такой на хабре, идеи для стартапов.
думаю, такой проект пополнит очередной список «ста клонов %PROJECT%», как с твиттер-клиентами из статьи

Без обид, интонации в интернете не передаются, не очень понял — это серьезно или шутка? :) Серьезно, так и напрашивается

… начать рабочий день с прочтения нескольких страниц (глав) интересной техничекой книги, статьи, пообщаться на форуме, немного поработать с каким нибудь своим побочным проектом и т.д., почитать Хабр, пообщаться на форуме, статьи, еще немного поработать со своим проектом, закончить рабочий день и пойти домой

Согласен, но для начала хотя бы людей, готовых в теории купить услуги стартапа.

А так, да, как и Феррис говорил — спросите у десяти людей, купят ли они десять дисков фигни. Ответят да 80%. Тут же достаешь из рюкзака — купят 0%

Статья чисто практическая, если даже 0.1% воли нет, то это не поможет.
Мне нравится сайт Психологос, там много чего написано, как тренировать волю в том числе.
www.psychologos.ru/articles/view/volya

Не считайте за рекламу, это не Вики, где написано, ЧТО, а еще и написано КАК.
Хотя они там продвигают свои тренинги, кое-какие приемы есть.

Так вот, пост изначально я писал, обобщая для себя свои подходы. Они на автомате работают, и объяснить их не всегда просто. А иногда бывает нужно, и каждый раз повторять смысла нет.

Когда-нибудь, возможно, у меня будет книга из статей. Но пока нет такого успеха в жизни, чтобы под книгой стояло не просто какой-нибудь очередной бизнес-тренер, а более авторитетное типа «CEO» или «успешный предприниматель».

Спасибо

Несколько причин, почему свой велосипед иногда нужен.

1. Чужой велосипед — это внешняя зависимость.
Зависит от догадки или расчетов лица принимающего решения, но кто вам сказал, что лучше платить за свои Google Docs,
чем однажды проснуться и узнать, что все ваши расчеты либо недоступны (заблокированы), либо вы должны платить абонентку (в лучшем случае).

Если еще не стало жарко, представьте, что так сильно нахваливаемые облачные сервисы и SaaS продукты стали один за другим накрываться. В одном обыск прошел, второй обанкротился, третий взломали хакеры, в четвертом главный разработчик уволился и выложил в инет все данные ваших платежей и клиентов?

И поймете, почему в РФ многие не доверяют свои данные онлайн-системам.

Если вы думаете, что это только у нас — представьте, что на небольшую CRM, в которой у вас все,
вдруг подал какой-нибудь монстр или тролль в суд, и ее заблокировали по решению суда.

Про пожар у хостера MсХост все знают.

2. Свой велосипед — это ноу-хау. Хотите вы того или нет,
свое производство позволяет получать такие продукты, которые никогда не были возможны в природе.
Опять же речь о целесообразности и принятии такого решения.

Пример из практики. Где я сейчас работаю, почти все свое — счетчик, баннерокрутилка, и так далее.
Счетчик собирает информацию о клиентах, которые ходят по сайтам, и эта информация бесценна. Для таргетинга рекламы, разумеется, и много чего еще. Думаете, просто так у Гугла все бесплатное? Нет, они собирают информацию о вас своими велосипедами — то, что никто не даст чужой собрать.

Или баннерокрутилка. Она за время работы на наших highload сайтах уже давно себя окупила, и позволила создать такие рекламные места, которые потом у нас копировали.

Если бы мы сидели на Adriver, к примеру, то платили бы бешеные деньги сейчас, а те самые рекламные места вряд ли бы нам реализовали так просто.

Вспомните, что Google платит Apple миллиард долларов, чтобы быть поисковиком №1 в Safari.
И поймите силу инновации (не могу назвать велосипедом, но по сути — iPhone есть телефон, iPad есть планшет, принципиально нового нет, кроме интерфейса).

3. Свой велосипед — это при верном подходе конкурентное преимущество.
При неверном — ваша слабость.

Добавил disclaimer, о том, что не для всех заработает :)

Насчет холодный и свежий — есть большая разница. В прохладном, но душном помещении может не работать, а в теплом и свежем — отлично.

И просто холодный vs прохладный. Если реально холодно телу (по мне это не всегда сразу заметно, только после того, как тело перестает справляться само с поддержанием температуры, или же температура в помещении реально опустилась ниже 20 и ты это ощутил) — хочется спать. А просто прохлада даже в ГОСТ, по-моему, заложена, 23 градуса (или 25, точно не помню). Это же не 30 :)

И потому у нас все так

За сайты не хотят платить;
За софт;
За науку;
Просто за труд.

Не ценят закон.

Страна такая, каков ее народ.

Грустно.

В случае со стаканом мы имеем корпускулярно-волновой дуализм.

Стакан наполовину полон

К СЧАСТЬЮ!

К сожалению — не замечать ни за кем, либо только за другими.

Второе — исправляйтесь, иначе заметили зря.

Даже идея есть, неплохо :) а я думал будет типа история, взял сырцы рар и допилил…

К великим людям, уж простите, вы и себя решили причислить?

Foodik.ru

Не все считают это прогрессом. Особенно когда отличия субъективны / могут существовать несколько вариантов решения проблемы

[irony]да ладно, вон, blitz получился крутым[/irony]

да я ваще пушистая фея:)

ну давайте ничего не делать, не вопрос

Нет, это два несвязанных утверждения.
1. первое «в 90% форк будет несовместим»
потому что в процессе допилки форк уйдет очень далеко. ничто не мешает это сделать, но свое ближе)))

2. «изначальные косяки архитектуры потом вылезут боком»
если взять решение потому, что нужно тупо простое и быстро, и забить на архитектурные кривые моменты, которые МОГУТ ОКАЗАТЬСЯ (а могут ине оказаться), то потом это выходит боком.

чисто выводы из практики

Я считаю немного иначе.

Мне больше представляется модель «вход-выход» (модель черного ящика), если мы говорим про большие приложения со сложной архитектурой.

Это бывает полезно при работе на любых уровнях. Как подход к мышлению.

То есть существуют
— задачи, которые стоят перед какой-либо методологией, подходом, сущностью
— способы решения этих задач
— критерии оценки эффективности этих задач, метрики ПО (см. «Rapid Software Development», Dr. Bob Martin)

К примеру
1. Вход У вас на входе проблема — статическая зависимость одного класса от другого.
2. Выбор способа решения (из нескольких!). Вы выбираете принцип инъекции зависимостей. Берете подходящий паттерн — Strategy. Рефакторите.
3. Смотрите. В итоге получилась инъекция в метод, и первый класс теперь зависит от интерфейса (принимает на вход любую реализую интерфейса), и второй класс также становится зависим от интерфейса, он теперь обязан его реализовывать :)
4. Замеряем, смотрим. Изменилась цикломатическая сложность, связанность уменьшилась, но возросло количество классов и методов :)

Это сильно утрированно. Просто когда вы что-то применяете, вы должны понимать, зачем это делаете, что улучшаете в архитектуре и что ухудшаете. Одно лечит, другое калечит — это воистину так, и балансу посвящен вечный рефакторинг. Несколько god Object — трудно поддерживать, но работает быстро. Миллиард микроклассов — поддерживать легко, но в некоторых языках начинает тормозить. Условно :)

А то просто — «а зачем тебе тут абстрактный класс» — " а лишним не будет, зато красиво",
или там «зачем тут такая высокая связанность между методами? »… невразумительное что-то...". Прямо «а еще я туда ем» (С)

Согласен, но в общем, тапками тоже можно гвозди забивать, как и без ООП писать там, где оно нужно — только зачем?

Каждый инструмент под свои задачи, есть и плюсы и минусы у всего, иначе бы на идеальное все давно перешли. Если взять С++ и Джаву — Джава, как правило, тормознее в силу многих причин (виртуальная машина, сброс мусора — 30 секунд тормозящее IDE-ГУЙ-известная-прога, когда супер «сборщик мусора» работает — это вполне норм), больше железа требует, зато в ней нет такой «клевой» темы, как в плюсах из-за прямой работы с памятью (читай мемори лики и все другие прелести) — когда можно искать утечку inf времени. IMHO!!!

Везде есть и плюсы, и минусы, а если решения схожи — выбирают на вкус. Мне не нравится политика закрытых вещей и привязки к одной платформе, и я юзаю open-source. А многим плевать и они юзают какой-нибудь Дотнет.

Типа того. Называется эффект Даннинга-Крюгера.



[irony]Ведь известно, самые великие программисты — это критики в комментариях, самые великие писатели — рецензенты книг, самые великие режиссеры — кинокритики, и так далее. А сами авторы программ, текстов, постов, книг, фильмов — это так, начинающие вроде Боба Мартина, Кэмерона, Достоевского, куда им до Васи Пупкина![/irony]