Ощущаю себя регулярно последние годы ассенизатором — количество говнокода от зеленых человечков просто запредельное. Т.е. зачастую человек написал проект для кого-то и потом нанимает других(в т.ч. меня) править его багофичи в его говнокоде. Последней каплей терпения стал класс на 6к строчек кода. И он не один такой терминатор (целая армия апокалипсиса) в этом творении из говна и палок. Когда-то я считал, что за вызовы бд из обработчиков UI надо убивать, но теперь даже это кажется не таким злом.
Собственно вопрос, куда податься от этого цирка уродства? Или может быть самому стать зелененьким? Где это наилучшим образом оплачивается?
Здравствуйте, IncremenTop, Вы писали:
IT>Собственно вопрос, куда податься от этого цирка уродства? Или может быть самому стать зелененьким? Где это наилучшим образом оплачивается?
А почему зелёненькие? Я явно какой то мем упустил.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>А почему зелёненькие? Я явно какой то мем упустил.
Когда этот человек приходил на проект — он был зеленым.
Очень часто такие люди прыгают по зеленым проектам всю жизнь(или сидят всю жизнь на своем) и совершенно не понимают, как код может быть нечитаемым. Они же всегда понимают свой код, а чужой отродясь не брали в руки.
Здравствуйте, IncremenTop, Вы писали:
IT>Собственно вопрос, куда податься от этого цирка уродства? Или может быть самому стать зелененьким? Где это наилучшим образом оплачивается?
Единственный вариант: прийти на проект, начинающийся с нуля. Да и тут надо, чтобы вы с коллегами были на одной волне.
Самый верный путь: расслабиться и понять, что правка устаревшнего говнокода — тоже работа.
Здравствуйте, IncremenTop, Вы писали:
CC>>А почему зелёненькие? Я явно какой то мем упустил.
IT>Когда этот человек приходил на проект — он был зеленым.
Школьник Студент.
IT>Очень часто такие люди прыгают по зеленым проектам всю жизнь(или сидят всю жизнь на своем) и совершенно не понимают, как код может быть нечитаемым.
Вечный студент.
IT>Они же всегда понимают свой код, а чужой отродясь не брали в руки.
Здравствуйте, IncremenTop, Вы писали:
IT>зачастую человек написал проект для кого-то и потом нанимает других(в т.ч. меня) править его багофичи в его говнокоде.
И какие проблемы? Взялись за работу — делайте, Вам за нее платят. Хуже код -> сложнее поддержка -> больший объем работы -> дороже стоит.
Не нравится этим заниматься — не беретесь за такую работу.
IT>Собственно вопрос, куда податься от этого цирка уродства? Или может быть самому стать зелененьким? Где это наилучшим образом оплачивается?
Научить, подсказать, передать опыт, если авторы работают вместе. Кстати, где гарантия, что Вы сам не "зелененький", и глядя на Ваш код люди не ужасаются?
IT>Собственно вопрос, куда податься от этого цирка уродства? Или может быть самому стать зелененьким? Где это наилучшим образом оплачивается?
Новые проекты разрабатываются под жестким прессом времени у многих в такой ситуации паттерны испаряются из головы как вода на раскаленной сковородке и пишут в итоге как могут.
Здравствуйте, Stanislaw K, Вы писали:
IT>>Очень часто такие люди прыгают по зеленым проектам всю жизнь(или сидят всю жизнь на своем) и совершенно не понимают, как код может быть нечитаемым. SK>Вечный студент. IT>>Они же всегда понимают свой код, а чужой отродясь не брали в руки. SK>Эх, молодежжжж!..
Эх, если б это было так. Некоторым шестой десяток пошел (и лет, и написанных книжек).
Недавно слышал тезис от одного довольно авторитетного человека. Дескать, юнит-тесты не приносят никакого value. Зал одобрительно закивал.
Я же это услышал как "мне в жизни не пришлось вносить потенциально ломающие логику изменения в код, написанный более чем несколько недель назад". Иными словами "я в жизни не работал на реальных проектах".
Как-то так
L>Эх, если б это было так. Некоторым шестой десяток пошел (и лет, и написанных книжек). L>Недавно слышал тезис от одного довольно авторитетного человека. Дескать, юнит-тесты не приносят никакого value. Зал одобрительно закивал. L>Я же это услышал как "мне в жизни не пришлось вносить потенциально ломающие логику изменения в код, написанный более чем несколько недель назад". Иными словами "я в жизни не работал на реальных проектах". L>Как-то так
Какое value от юнит-тестов в динамичном стартапе у которого архитектура меняется каждый день и актуальность тестов все время протухает, а релиз нужно срочно выкатить к концу месяца?
IT>Собственно вопрос, куда податься от этого цирка уродства? Или может быть самому стать зелененьким?
Приходи преподавать.
Я вот практикую с первого занятия по ООП на 2 курсе:
1. Написать тестовые данные для проверки лабы (и включить в отчет)
2. Написать функцию с ассертами — для проверки реализованных методов.
Плавно переходим к unit-тестированию.
3. На 3 курсе я в курсе системного ПО просто перемешиваю лабы и они вынуждены копаться в чужом коде, да еще и работать парами.
Например, написали интерпретатор виртуальной машины.
Варианты перемешал — пишут ассемблер для другой машины.
А для проверки — подключить чужой интерпретатор, чтоб после трансляции с ассемблера можно было убедиться, что правильно работает.
Еще на 2-3 курсе Code review обязательно по курсовым устраиваю пару раз.
Тыкаю носом как раз в отделение интерфейса проги от реализации сути.
4. Еще в курсе СПО пишем сначала отладчик виртуальной машины командный.
А потом прикручиваем к нему диалоговый интерфейс.
Причем — к чужому, а не своему.
Учить надо народ.
Оплачивается эта работа плохо по сравнению с программерами.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, turbocode, Вы писали:
L>>Как-то так T>Какое value от юнит-тестов в динамичном стартапе у которого архитектура меняется каждый день и актуальность тестов все время протухает, а релиз нужно срочно выкатить к концу месяца?
Здравствуйте, turbocode, Вы писали:
L>>Давай ты не будешь сертифицированному по самые помидоры скрам мастеру рассказывать про скрам? L>>Это не скрам, это бардак. T>Поменялась архитектура (не все учли) что в таком случае делает скрам-мастер?
А ты точно уверен, что понимаешь, что такое скрам и какая роль у скрам мастера?
С прищуром
L>>Скрам, кстати, без юнит-тестов вообще не работает. T>Бугага. Работает еще и как.
Здравствуйте, turbocode, Вы писали:
T>Новые проекты разрабатываются под жестким прессом времени у многих в такой ситуации паттерны испаряются из головы как вода на раскаленной сковородке и пишут в итоге как могут.
Однажды в подобной ситуации разработчики обратились к руководителю проекта с вопросом: а как же качество кода? Ответом было: вы в какой реальности находитесь? Ваша гланая задача — выдавать в срок запланированные фичи.
T>>Поменялась архитектура (не все учли) что в таком случае делает скрам-мастер? L>А ты точно уверен, что понимаешь, что такое скрам и какая роль у скрам мастера? L>С прищуром
Здравствуйте, turbocode, Вы писали:
T>>>Поменялась архитектура (не все учли) что в таком случае делает скрам-мастер? L>>А ты точно уверен, что понимаешь, что такое скрам и какая роль у скрам мастера? L>>С прищуром T>А ты точно скрам-мастер?
T>>>>Поменялась архитектура (не все учли) что в таком случае делает скрам-мастер? L>>>А ты точно уверен, что понимаешь, что такое скрам и какая роль у скрам мастера? L>>>С прищуром T>>А ты точно скрам-мастер?
L>То есть не понимаешь. В общем, как я и думал
У тебя роль свадебного генерала на проекте? Тогда понятно почему изменение архитектуры ставит тебя в тупик.
Или гибкие методологии разработки ПО сегодня не учитывают изменение архитектуры на проекте? Тогда какие они нахрен гибкие?
Здравствуйте, turbocode, Вы писали:
T>У тебя роль свадебного генерала на проекте? Тогда понятно почему изменение архитектуры ставит тебя в тупик.
Переход на личности, слив защитан.
T>Или гибкие методологии разработки ПО сегодня не учитывают изменение архитектуры на проекте? Тогда какие они нахрен гибкие?
Рекомендую все же почитать что-то про скрам. В частности, следует поподробнее почитать о роли скрам мастера и emergency процедуре.
Ежедневное изменение архитектуры есть бардак и указывает на полную некомпетентность лиц, принимающих решения.
Вне зависимости от подхода к разработке.
L>Ежедневное изменение архитектуры есть бардак и указывает на полную некомпетентность лиц, принимающих решения. L>Вне зависимости от подхода к разработке.
Не обязательно ежедневное, можно поставить еженедельное, ежемесячное. Суть одна — архитектура поменялась. Что делает скрам-мастер в таком случае?
Бизнес осознал что вчера/на прошлой неделе/прошлом месяце напорол фигни, нужно делать по новому. А новое не совсем вписывается в старое.
Зачем делать в текущем спринте то что уже больше не нужно?
Здравствуйте, IncremenTop, Вы писали:
IT>Собственно вопрос, куда податься от этого цирка уродства?
Открывай компанию и делай свой продукт где всё будет по феншую.
Здравствуйте, turbocode, Вы писали:
L>>Такой стартап закапывать можно сразу. T>Ты не модный это Scrum.
Как ловко подменил понятия и затролил собеседника.
Здравствуйте, turbocode, Вы писали:
L>>Ежедневное изменение архитектуры есть бардак и указывает на полную некомпетентность лиц, принимающих решения. L>>Вне зависимости от подхода к разработке. T>Не обязательно ежедневное, можно поставить еженедельное, ежемесячное. Суть одна — архитектура поменялась. Что делает скрам-мастер в таком случае?
Суть в том, что архитектура изначально должна предусматривать определенную гибкость. И изменение хотелок бизнеса или приоритетов не должно приводить к необходимости ее изменения. Не благодари.
(Я предполагаю что под понятием "архитектура" мы видим одно и то же. Если ты изменением архитектуры называешь добавление параметра в функцию, то у меня для тебя есть две новости)
T>Бизнес осознал что вчера/на прошлой неделе/прошлом месяце напорол фигни, нужно делать по новому. А новое не совсем вписывается в старое.
Если бизнес решил вместо трамваев производить носки, то возникает вопрос — как вообще в таком бардаке мог появиться скрам мастер?
Во всех остальных случаях процесс ставится именно так, чтобы подстраиваться под требования бизнеса.
T>Зачем делать в текущем спринте то что уже больше не нужно?
Хинт — а в следующем спринте выясняется, что все-таки было нужно. Дальше продолжать, или все же почитаешь про скрам?
L>Суть в том, что архитектура изначально должна предусматривать определенную гибкость.
Например? А если эта гибкость затянет лишний месяц(ы) разработки? Заказчик не обрадуется платить за какую то мифическую гибкость.
L>И изменение хотелок бизнеса или приоритетов не должно приводить к необходимости ее изменения.
Что это у тебя за гибкие методологии разработки ПО такие, которые не позволяют делать изменения?
Здравствуйте, IncremenTop, Вы писали:
IT>Собственно вопрос, куда податься от этого цирка уродства?
Напиши сам успешный продукт и отдай его на поддержку нанятым программистам
Здравствуйте, turbocode, Вы писали:
L>>Суть в том, что архитектура изначально должна предусматривать определенную гибкость. T>Например? А если эта гибкость затянет лишний месяц(ы) разработки? Заказчик не обрадуется платить за какую то мифическую гибкость.
А если наоборот?
Все можно сделать двумя способами — правильно и через жопу. Ты за какой способ?
L>>И изменение хотелок бизнеса или приоритетов не должно приводить к необходимости ее изменения. T>Что это у тебя за гибкие методологии разработки ПО такие, которые не позволяют делать изменения?
Не "не повзоляют", а "отвечают изменяющимся требованиям бизнеса". Почувствуй разницу (с).
Здравствуйте, turbocode, Вы писали:
L>>Все можно сделать двумя способами — правильно и через жопу. Ты за какой способ? T>Это как спросить: вы за мир или за войну? Все за мир, но реальность другая и войну не отменяет.
Иными словами, ты привык создавать ядерную войну по ничтожному поводу...
L>>>Все можно сделать двумя способами — правильно и через жопу. Ты за какой способ? T>>Это как спросить: вы за мир или за войну? Все за мир, но реальность другая и войну не отменяет. L>Иными словами, ты привык создавать ядерную войну по ничтожному поводу...
Причем я?
Ты можешь выбрать делать правильно долго и дорого, а заказчик выбрать делать дешево и быстро. Но так как деньги платит заказчик поэтому ему решать c кем работать.
Здравствуйте, turbocode, Вы писали:
L>>Иными словами, ты привык создавать ядерную войну по ничтожному поводу... T>Причем я? T>Ты можешь выбрать делать правильно долго и дорого,
Я делаю быстро и правильно.
А вот твоя рефлексия как бы намекает, как делаешь ты
Здравствуйте, DiPaolo, Вы писали:
DP>Не нравится этим заниматься — не беретесь за такую работу.
Вот и спросил выше — как меньше на такую работу попадать. Может область сменить?
DP>Научить, подсказать, передать опыт, если авторы работают вместе. Кстати, где гарантия, что Вы сам не "зелененький", и глядя на Ваш код люди не ужасаются?
Может быть, но на практике они в этом коде могут исправить багофичу за разумное время, что в процессе работы подтверждалось. Кстати, я не перфекционист и в данном случае говнокодом называю истинный говнокод.
IT>Вот и спросил выше — как меньше на такую работу попадать. Может область сменить?
Нет универсального решение. В качестве вариантов:
Каким-то образом заранее оценивать качество кода. Например, попросить прислать какой-то кусок.
В случае, если есть основания полагать, что код некачественный, вводить коэффициент для стоимости своей работы.
Продавать услуги рефакторинга за отдельную плату. При этом предварительно объяснив, чем это выгодно клиенту. Если весомых аргументов не найдется, значит это не так уж важно -> забить, смириться или искать другой выход.
P>Однажды в подобной ситуации разработчики обратились к руководителю проекта с вопросом: а как же качество кода? Ответом было: вы в какой реальности находитесь? Ваша гланая задача — выдавать в срок запланированные фичи.
Здравствуйте, IncremenTop, Вы писали:
IT>Ощущаю себя регулярно последние годы ассенизатором — количество говнокода от зеленых человечков просто запредельное. Т.е. зачастую человек написал проект для кого-то и потом нанимает других(в т.ч. меня) править его багофичи в его говнокоде. Последней каплей терпения стал класс на 6к строчек кода. И он не один такой терминатор (целая армия апокалипсиса) в этом творении из говна и палок. Когда-то я считал, что за вызовы бд из обработчиков UI надо убивать, но теперь даже это кажется не таким злом.
IT>Собственно вопрос, куда податься от этого цирка уродства? Или может быть самому стать зелененьким? Где это наилучшим образом оплачивается?
Хуже говнкодера только говнокодер, который еще тебя же пытается учить, как правильно.
недавно работал с таким. он думал, что надо обязательно код из одной функции поразмазывать по другим функция, потому как "слишком большие". Ага, аж 10 строчек. И еще менял учил говнокодить в таком же стиле -- "да ты не бойся, мы так уже делали в другой команде".
Здравствуйте, landerhigh, Вы писали:
IT>>>Очень часто такие люди прыгают по зеленым проектам всю жизнь(или сидят всю жизнь на своем) и совершенно не понимают, как код может быть нечитаемым. SK>>Вечный студент. IT>>>Они же всегда понимают свой код, а чужой отродясь не брали в руки. SK>>Эх, молодежжжж!..
L>Эх, если б это было так. Некоторым шестой десяток пошел (и лет, и написанных книжек).
да хоть сто шестой. студент не возраст, студент это состояние.
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, turbocode, Вы писали:
T>>Новые проекты разрабатываются под жестким прессом времени у многих в такой ситуации паттерны испаряются из головы как вода на раскаленной сковородке и пишут в итоге как могут.
P>Однажды в подобной ситуации разработчики обратились к руководителю проекта с вопросом: а как же качество кода? Ответом было: вы в какой реальности находитесь? Ваша гланая задача — выдавать в срок запланированные фичи.
Обычно такое приводит к тому что первая треть функционала делается более-менее укладываясь в сроки, а дальше начинается пляска по костылям и велосипедам с постоянными факапами
D>Обычно такое приводит к тому что первая треть функционала делается более-менее укладываясь в сроки, а дальше начинается пляска по костылям и велосипедам с постоянными факапами
Проблемы негров как правило никого не волнуют: бесплатно работайте всю ночь до утра.
Здравствуйте, Stanislaw K, Вы писали:
L>>Эх, если б это было так. Некоторым шестой десяток пошел (и лет, и написанных книжек). SK>да хоть сто шестой. студент не возраст, студент это состояние.
В общем, да. Даже если у этого студента уже есть phD...
Здравствуйте, IncremenTop, Вы писали:
IT>Ощущаю себя регулярно последние годы ассенизатором — количество говнокода от зеленых человечков просто запредельное. IT>Собственно вопрос, куда податься от этого цирка уродства? Или может быть самому стать зелененьким?
В твоём зелёном проекте будет то же самое. Чтобы избавиться от говнокода в проекте, его надо сначала написать, а потом отрефакторить. Наверное кто-то умеет пропускать эти шаги, но я таких людей не встречал и сам им не являюсь.
_>недавно работал с таким. он думал, что надо обязательно код из одной функции поразмазывать по другим функция, потому как "слишком большие". Ага, аж 10 строчек. И еще менял учил говнокодить в таком же стиле -- "да ты не бойся, мы так уже делали в другой команде".
Я в форуме по вебу приводил код из Симфонии на РНР. Чуваки, типа, разложили все по полочкам там. Задача определить является ли строка имейл адресом разбита как минимум на три класса со своими файлами. Там и наследование и делегейшн и лишнее чтение файлов с диска из-за этого разбиения. И это даже не Джава! Тоже не понимают что этот код плох по-своему.
IT>Собственно вопрос, куда податься от этого цирка уродства? Или может быть самому стать зелененьким? Где это наилучшим образом оплачивается?
Вообще-то это работа программиста. Таковы реалии. Хочешь ты этого или нет. Поэтому учись работать с плохим кодом.
Да, я бы понял твои стенания если бы ты сказал, что в проекте функции по 6К строчек кода. А класс на 6К строчек это фигня. Главное чтобы по функциям хорошо все разбито было.
D>>Обычно такое приводит к тому что первая треть функционала делается более-менее укладываясь в сроки, а дальше начинается пляска по костылям и велосипедам с постоянными факапами
T>Проблемы негров как правило никого не волнуют: бесплатно работайте всю ночь до утра.
Все верно, но тут есть еще и такой момент. Большинство программистов любят переусложнять все в коде, что тоже занимает время. И во время разработки и во время поддержки.
Здравствуйте, IncremenTop, Вы писали:
IT>Спасибо за совет. Стану праноедом.
Ты зарабатываешь деньги тем, что берешься доделывать откровенное говно. И спрашиваешь на форме как этого избежать, но при этом продолжать зарабатывать деньги. Очевидный ответ — зарабатывать деньги чем-то другим ты отметаешь.
Здравствуйте, Dziman, Вы писали:
D>Обычно такое приводит к тому что первая треть функционала делается более-менее укладываясь в сроки, а дальше начинается пляска по костылям и велосипедам с постоянными факапами
В какой-то момент руководитель проекта обращает внимание, что починка багов занимает слишком много времени. Не особо пытаясь вникнуть, почему так происходит, он устанавливает норматив: квалифицированному разработчику 2 часа на баг. И рассказывает, что надо больше усилий вкладывать в разработку, а не поддержку.
У меня был в такой обстановке только один провал. Я умудрился пропустить проверку на null. Правда, это практически сразу обнаружилось. В общем, масштабы не очень былинные.
Здравствуйте, Vladek, Вы писали:
V>В твоём зелёном проекте будет то же самое. Чтобы избавиться от говнокода в проекте, его надо сначала написать, а потом отрефакторить. Наверное кто-то умеет пропускать эти шаги, но я таких людей не встречал и сам им не являюсь.
Говнокод бывает разным. Можно даже мерять в количесте рефакторингов и вообще возможности их проведения, а можно в том, насколько понимаешь код, мерять.
Здравствуйте, Олег К., Вы писали:
ОК>Ты говоришь так, будто юнит тесты это какая-то панацея.
Как же вы задолбали граждане-ненавистники любого подхода.
Есть средства, которые при правильном подходе дают выхлоп даже самой концепцией, потому что внезапно тестируемый код легче читаем и лучше понимается даже самим разработчиком. Даже для этого уже это хорошо. Безусловно вы можете сказать, что вы-то пишите всегда такой код, но большинство — нет.
Не говоря уже о главном назначении юнит-тестов, но это уже просто мелочь.
L>Я тебе могу с выражением прочитать скрам манифест. Пять раз, до наступления просветления. При оплате по почасовой ставке, конечно.
Неоднократно встречал такой тип людей в ИТ которые при виде что пахнет жареным начинают прикрываться своими сертификатами, давить на авторитет — запомни это жалкое зрелище мерзко выглядит со стороны.
Здравствуйте, turbocode, Вы писали:
L>>Я тебе могу с выражением прочитать скрам манифест. Пять раз, до наступления просветления. При оплате по почасовой ставке, конечно. T>Неоднократно встречал такой тип людей в ИТ которые при виде что пахнет жареным начинают прикрываться своими сертификатами, давить на авторитет — запомни это жалкое зрелище мерзко выглядит со стороны.
Неоднократно замечал такой тип людей, которые с умным видом несут чушь. Запомни, это зрелище производит впечатление на неокрепшие умы.
Далее обсуждать нонсенс "что делает скрам мастер" не намерен. Приходи, когда почитаешь что-нибудь про скрам и поймешь, что вопрос не имеет смысла.
L>Неоднократно замечал такой тип людей, которые с умным видом несут чушь. Запомни, это зрелище производит впечатление на неокрепшие умы. L>Далее обсуждать нонсенс "что делает скрам мастер" не намерен. Приходи, когда почитаешь что-нибудь про скрам и поймешь, что вопрос не имеет смысла.
Тебе задали вполне конкретные практические вопросы, а ты начал прикрываться теоретическими манифестами, сертификатами и отмазками вида: "почитай книгу".
T>>Проблемы негров как правило никого не волнуют: бесплатно работайте всю ночь до утра. ОК>Все верно, но тут есть еще и такой момент. Большинство программистов любят переусложнять все в коде, что тоже занимает время. И во время разработки и во время поддержки.
Когда сроки очень сжатые то не видел желающих все переусложнять скорее начнут писать логику прямо в обработчиках событий.
Здравствуйте, turbocode, Вы писали:
L>>Далее обсуждать нонсенс "что делает скрам мастер" не намерен. Приходи, когда почитаешь что-нибудь про скрам и поймешь, что вопрос не имеет смысла. T>Тебе задали вполне конкретные практические вопросы, а ты начал прикрываться теоретическими манифестами, сертификатами и отмазками вида: "почитай книгу".
Извини, но этот вопрос перефразированно звучит как "Сколько тонн клевера от каждой курицы несушки будет засыпано в инкубаторы после обмолота зяби?"
Учитывая твои предыдущие высказывания, о скраме ты знаешь чуть менее, чем ничего. Иначе бы знал, что твой вопрос не имеет смысла. Пересказывать то, что описано в 100500 источниках, я не буду.
Не говоря уже о том, что скрам как раз отвечает на вопрос, как строить процесс при гибких и постоянно меняющихся требованиях.
L>Извини, но этот вопрос перефразированно звучит как "Сколько тонн клевера от каждой курицы несушки будет засыпано в инкубаторы после обмолота зяби?" L>Учитывая твои предыдущие высказывания, о скраме ты знаешь чуть менее, чем ничего. Иначе бы знал, что твой вопрос не имеет смысла. Пересказывать то, что описано в 100500 источниках, я не буду. L>Не говоря уже о том, что скрам как раз отвечает на вопрос, как строить процесс при гибких и постоянно меняющихся требованиях.
Здравствуйте, turbocode, Вы писали:
L>>Не говоря уже о том, что скрам как раз отвечает на вопрос, как строить процесс при гибких и постоянно меняющихся требованиях. T>На это я уже отвечал здесь
Здравствуйте, turbocode, Вы писали:
T>Тебе задали вполне конкретные практические вопросы, а ты начал прикрываться теоретическими манифестами, сертификатами и отмазками вида: "почитай книгу".
Один дурак может задать столько вопросов, что и сто мудрецов не ответят...
Это вопрошающий может, конечно, потом бегать сколько угодно с тем фактом, что ему поленились отвечать, но как это выглядит
со стороны и какое из этого выходит зрелище — ты сам уже написал.
_AB>Один дурак может задать столько вопросов, что и сто мудрецов не ответят... _AB>Это вопрошающий может, конечно, потом бегать сколько угодно с тем фактом, что ему поленились отвечать, но как это выглядит _AB>со стороны и какое из этого выходит зрелище — ты сам уже написал.
Скрам давно превратили в какую то религию и почуяв неладное на конфе
(ощутил как зашаталось его теплое пригретое кресло скрам-мастера) поднял вой что мол старец на конфе еретик дескать не участвовал в реальных проектах.
Высказывание скрам-мастера касалось лишь юнит-тестов, точнее весьма спорного утверждения, что они не несут никакой ценности,
а вовсе не скрама. Заметь, даже не того, что пользы от них меньше, чем та цена, в которую они обходятся (тут дискутировать можно долго),
а того, что они вообще никакой пользы не несут в принципе.
Причем, по поводу скрама первым начал говорить ты, приводя его как положительный пример ненужности юнит-тестов.
Когда оказалось, что ты в скраме понимаешь хуже, чем апологет юнит-тестов (точнее, совсем не понимаешь, в отличие от),
ты начал переходить на личности, а теперь заговорил уже и о том, что скрам — это религия. Может быть, ты оставишь скрам
скрам-мастерам (они в своей "религии" всяко больше понимают) и вернешься к доказательству того, что unit tests bring no value?
Здравствуйте, Олег К., Вы писали:
ОК>Да, я бы понял твои стенания если бы ты сказал, что в проекте функции по 6К строчек кода. А класс на 6К строчек это фигня. Главное чтобы по функциям хорошо все разбито было.
Функции — это фигня, главное, чтобы по регионам внутри функций было все хорошо разбито.
Регионы — это фигня, главное, чтобы по блокам было все хорошо разбито.
Блоки — это фигня, главное, чтобы по строчки с пробелами между кодом хорошо разбивали.
и тд тп.
Уважаемый, я понимаю, что вы — савант и легко держите в уме классы с гигантским контрактом и кучей обязанностей, но большинство людей вроде меня не обладает столь выдающимися способностями. Пожалейте нас. Не пишите так.
Здравствуйте, _ABC_, Вы писали:
_AB>Когда оказалось, что ты в скраме понимаешь хуже, чем апологет юнит-тестов (точнее, совсем не понимаешь, в отличие от)
Вот то, что я приверженец секты свидетелей юнит (и прочих) тестов, отрицать не буду.
Но объективно, скрам в частности и аджайл в общем подразумевают короткие итерации и постоянный рефакторинг. Коий без автоматических тестов просто невозможен.
_AB>Причем, по поводу скрама первым начал говорить ты, приводя его как положительный пример ненужности юнит-тестов. _AB>Когда оказалось, что ты в скраме понимаешь хуже, чем апологет юнит-тестов (точнее, совсем не понимаешь, в отличие от), _AB>ты начал переходить на личности, а теперь заговорил уже и о том, что скрам — это религия. Может быть, ты оставишь скрам _AB>скрам-мастерам (они в своей "религии" всяко больше понимают) и вернешься к доказательству того, что unit tests bring no value?
Ты вообще читал мои сообщения? У тебя смешались люди и кони в одну кучу.
Твои фантазии и бред мне лень обсуждать.
Здравствуйте, turbocode, Вы писали:
T>Ты вообще читал мои сообщения? У тебя смешались люди и кони в одну кучу.
Читал. А ты, видимо, свои сообщения не читал...
T>Твои фантазии и бред мне лень обсуждать.
И не надо.
Я с удовольствием почитаю твои доказательства того, что юнит-тесты не несут пользы.
Здравствуйте, landerhigh, Вы писали:
L>Но объективно, скрам в частности и аджайл в общем подразумевают короткие итерации и постоянный рефакторинг. Коий без автоматических тестов просто невозможен.
Я это понимаю. Не являясь членом ни одной из "сект", тем не менее, с методологией agile в общем и scrum в частности знаком не
по перепевам Рабиновича.
Здравствуйте, Олег К., Вы писали:
L>>Недавно слышал тезис от одного довольно авторитетного человека. Дескать, юнит-тесты не приносят никакого value. Зал одобрительно закивал.
ОК>Ты говоришь так, будто юнит тесты это какая-то панацея.
Это, конечно же, не панацея — но удобное и простое средство проверки как алгоритма, так (зачастую) и его реализации.
В сложном проекте юнит-тесты дают удобство при поиске ошибок, которые просто под дебаггером было бы очень сложно выявить.
Так, например, выполнить 1000000 итераций в одном цикле for — просто не хватит жизни
Здравствуйте, turbocode, Вы писали:
T>Я спрашивал какая польза от них в динамических стартапах. Усёк?
1. Не в "динамических стартапах", а в "динамических стартапах, где архитектура приложения меняется каждый день".
2. Тебе сказали, что стартап, где архитектура меняется каждый день, обречен изначально.
3. Ты заявил, что "архитектура меняется каждый день" == "скрам".
_AB>2. Тебе сказали, что стартап, где архитектура меняется каждый день, обречен изначально.
А где через неделю/месяц/квартал меняется? Тоже провал? Какой минимально допустимый период чтобы не было провала?
_AB>3. Ты заявил, что "архитектура меняется каждый день" == "скрам".
Скрам не позволяет менять архитектуру через неделю/месяц/квартал?
Здравствуйте, _ABC_, Вы писали:
_AB>Я это понимаю. Не являясь членом ни одной из "сект", тем не менее, с методологией agile в общем и scrum в частности знаком не _AB>по перепевам Рабиновича.
Несколько раз наблюдал разработку "по напевам Рабиновича".
Один раз руководитель считал, что раз аджайл, то достаточно раз в день собираться в кружочек, где каждый будет рассказывать, что он делал вчера (на что остальным откровенно было пофигу, ибо каждый работал над своим проектом). Документация, планирование — побоку, у нас же аджайл!
В другом примере проект официально ушел на двухмесячный этап "рефакторинга". Который в отсутствие самых минимальных юнит-тестов выразился в замене одного говнокода другим говнокодом по известным только одному макаронному монстру критериями и привел к дикому батхерту (и кажется даже, увольнением по собственному) в отделе QA, которым по сути пришлось проделывать всю работу заново. Пользуясь случаем, кстати, хочу передать пламенный привет нашем турбокодеру. Если он поймет, о чем я гворю, конечно.
Здравствуйте, turbocode, Вы писали:
_AB>>2. Тебе сказали, что стартап, где архитектура меняется каждый день, обречен изначально. T>А где через неделю/месяц/квартал меняется? Тоже провал? Какой минимально допустимый период чтобы не было провала?
Твоя цитата:
актуальность тестов все время протухает
Мой ответ зависит от того, что ты подразумеваешь под "протуханием" уже написанных тестов.
Означает ли это, что уже написанные тесты требуется переписать с нуля? Или что к уже написанным
тестам нужно добавлять новые? Может быть, это означает что-то еще?
_AB>Мой ответ зависит от того, что ты подразумеваешь под "протуханием" уже написанных тестов. _AB>Означает ли это, что уже написанные тесты требуется переписать с нуля? Или что к уже написанным _AB>тестам нужно добавлять новые? Может быть, это означает что-то еще?
L>В другом примере проект официально ушел на двухмесячный этап "рефакторинга". Который в отсутствие самых минимальных юнит-тестов выразился в замене одного говнокода другим говнокодом по известным только одному макаронному монстру критериями и привел к дикому батхерту (и кажется даже, увольнением по собственному) в отделе QA, которым по сути пришлось проделывать всю работу заново. Пользуясь случаем, кстати, хочу передать пламенный привет нашем турбокодеру. Если он поймет, о чем я гворю, конечно.
Здравствуйте, turbocode, Вы писали:
T>могут не компилится или фейлится
При чем тут актуальность-то? Ни то, ни другое не имеет отношения к актуальности.
Здравствуйте, turbocode, Вы писали:
T>А что ты понимаешь под рефакторингом? Костыли?
Очень хорошо, темерь мы знаем, что ты понимаешь под скрамом обыкновенный бардак, под рефакторингом перестановку костылей, а под "неактуальными юнит-тестами" тесты, которые ломаются из-за внесенной регрессии (что есть их предназначение).
А тебе бы неплохо понять, что тут общаются взрослые люди, и школолольный троллинг, рефлексия и прочие подростковые приемы вроде приписывания своих фантазий собеседникам тут не проходят. Впрочем, учитывая дату регистрации, ты должен это и сам знать.
T>>А что ты понимаешь под рефакторингом? Костыли? L>Очень хорошо, темерь мы знаем, что ты понимаешь под скрамом обыкновенный бардак, под рефакторингом перестановку костылей, а под "неактуальными юнит-тестами" тесты, которые ломаются из-за внесенной регрессии (что есть их предназначение). L>А тебе бы неплохо понять, что тут общаются взрослые люди, и школолольный троллинг, рефлексия и прочие подростковые приемы вроде приписывания своих фантазий собеседникам тут не проходят. Впрочем, учитывая дату регистрации, ты должен это и сам знать.
Все уже поняли что твой вклад в реальном проекте == 0.0, поэтому ты не можешь здесь ответить ни на один практический вопрос, а только махать здесь своим манифестом && сертификатом.
Здравствуйте, IncremenTop, Вы писали:
IT>Ощущаю себя регулярно последние годы ассенизатором — количество говнокода от зеленых человечков просто запредельное. Т.е. зачастую человек написал проект для кого-то и потом нанимает других(в т.ч. меня) править его багофичи в его говнокоде. Последней каплей терпения стал класс на 6к строчек кода. И он не один такой терминатор (целая армия апокалипсиса) в этом творении из говна и палок. Когда-то я считал, что за вызовы бд из обработчиков UI надо убивать, но теперь даже это кажется не таким злом.
IT>Собственно вопрос, куда податься от этого цирка уродства? Или может быть самому стать зелененьким? Где это наилучшим образом оплачивается?
Зуб даю Предположу, что вы беретесь за любой или почти любой проект, от конторы X с зарплатой Y, к-ая вероятно ниже рынка, но вас вполне устраивает. Где, про котору X — вероятно никто не слышал, а Y — вас устраивает. Еще есть Z — это сам проект над которым вам работать, узнать про него подробности — мы опускаем. Другими словами, вы сами выбираете это хауноу, кота в мешке, когда приходит оффер. Получается что вы ищете на поверхности, а там плавает понятно что. В любую компанию, к-ая на слуху — 200-300 человек на место. Я бы предпочел прокачайть скиллы, найти какие вопросы и задачи дают в такую компаниию (она ж на слуху), долго и усердно готовится, но попасть именно в Топ-компанию, где зеленые человечки отсеиваются еще на этапе резюме.
По существу вопроса:
Я такое проходил, в том же фрилансе.
Кейс #1. Проект на 11$/hr — адский ад от обдолбанного индуса, править баги и чтобы еще оно оставалось в рабочем состоянии. После месяца, сказал — что неосилю. Попросил переписать. Создали отдельный брэнч и неспешно переписывал полтора года, попутно узнавая не понятные требования у CTO, никто в шею не гнал. срубил 30к$ за это время.
Кейс #2. Проект на 34$/hr — почти идеально организованы процессы контроля качества кода, команда из девелоперов с опытом 10+, которые в код-ревью секции расскажут и покажут вещи, про которые ты еще не знал. Итог — прокачены скиллы не только в .NET, но и Java, OOP, понят Agile и git на уровне advanced. За год — 62k$.
Выводы делайте сами, какой кейс вам больше по душе, исходя из нынешней ситуации.
Здравствуйте, turbocode, Вы писали:
T>Все уже поняли что твой вклад в реальном проекте == 0.0, поэтому ты не можешь здесь ответить ни на один практический вопрос
Вообще-то, "все"(с) уже "поняли"(с), что ты не совсем понимаешь ни что такое юнит-тесты, ни скрам, ни даже что означает слово "актуальность".
Есть подозрение, что нет также понимания того, что такое архитектура.
T>>Все уже поняли что твой вклад в реальном проекте == 0.0, поэтому ты не можешь здесь ответить ни на один практический вопрос _AB>Вообще-то, "все"(с) уже "поняли"(с), что ты не совсем понимаешь ни что такое юнит-тесты, ни скрам, ни даже что означает слово "актуальность". _AB>Есть подозрение, что нет также понимания того, что такое архитектура.
Здравствуйте, turbocode, Вы писали:
T>А у тебя почему пригорает?
Пригорает у тебя. Мне любопытно наблюдать как ты извиваешься, вместо того, чтобы просто признать свою неправоту.
Еще любопытнее мне было бы читать интересную дискуссию, но ты её вести не хочешь.
T>Он твой срам-мастер?
Нет. Я его не знаю. Но твои попытки постоянно перейти на обсуждение личностей вполне красноречивы.
T>>А у тебя почему пригорает? _AB>Пригорает у тебя. Мне любопытно наблюдать как ты извиваешься, вместо того, чтобы просто признать свою неправоту.
В чем?
L>В любую компанию, к-ая на слуху — 200-300 человек на место. Я бы предпочел прокачайть скиллы, найти какие вопросы и задачи дают в такую компаниию (она ж на слуху), долго и усердно готовится, но попасть именно в Топ-компанию, где зеленые человечки отсеиваются еще на этапе резюме.
С таким конкурсом можно ЗП вообще не платить.
L>Кейс #1. Проект на 11$/hr L>Кейс #2. Проект на 34$/hr
Подозреваю что ты пропустил этап адового треша для Кейс #2. и влился когда уже компания поднялась, навела порядок и наладила процессы.
Почти правы, но:
L>Зуб даю Предположу, что вы беретесь за любой или почти любой проект, от конторы X с зарплатой Y, к-ая вероятно ниже рынка, но вас вполне устраивает. Где, про котору X — вероятно никто не слышал, а Y — вас устраивает.
Я удаленщик, а на российском рынке известные игроки не любят на удаленку отправлять что-то достойное. Аккаунт на одеске(а теперь уже апворке), увы, был не мой в свое время(трудились по сути 3 чела), а новый нереально раскрутить и даже получить первый заказ. Только если уговаривать кого-то из старых, чтобы симулировали, но это попахивает известной субстанцией.
Хотел взять недавно за проект более-менее известной фирмы, но зп слишком низкая — уровня сисадмина на заводе.
L> долго и усердно готовится, но попасть именно в Топ-компанию, где зеленые человечки отсеиваются еще на этапе резюме.
В РФ много известных компаний, где такие человечки еще и в топах
Здравствуйте, turbocode, Вы писали:
L>>В любую компанию, к-ая на слуху — 200-300 человек на место. Я бы предпочел прокачайть скиллы, найти какие вопросы и задачи дают в такую компаниию (она ж на слуху), долго и усердно готовится, но попасть именно в Топ-компанию, где зеленые человечки отсеиваются еще на этапе резюме.
T>С таким конкурсом можно ЗП вообще не платить.
L>>Кейс #1. Проект на 11$/hr L>>Кейс #2. Проект на 34$/hr T>Подозреваю что ты пропустил этап адового треша для Кейс #2. и влился когда уже компания поднялась, навела порядок и наладила процессы.
Дело в том, что обе компании, были образованы в середине 2000-ых. Т.е. на момент найма им было >5 лет. То что одна не промасштабировалась, и не наладила процессы — говорят их рейты, сотрудники и в целом бизнес модель. 2-ая компания может позволить себе сеньоров, за счет модели — подписка на месяц, у первой — фиксед-прайс и толпа индусов в штате.
Незнаю как было изначально в кейсе 2, но код оставшийся с тех времен — живет до сих пор.
Здравствуйте, IncremenTop, Вы писали:
IT>Здравствуйте, licedey, Вы писали:
IT>Почти правы, но:
IT>Я удаленщик, а на российском рынке известные игроки не любят на удаленку отправлять что-то достойное. Аккаунт на одеске(а теперь уже апворке), увы, был не мой в свое время(трудились по сути 3 чела), а новый нереально раскрутить и даже получить первый заказ. Только если уговаривать кого-то из старых, чтобы симулировали, но это попахивает известной субстанцией.
IT>Хотел взять недавно за проект более-менее известной фирмы, но зп слишком низкая — уровня сисадмина на заводе.
С апворком лучше не шутить, строго все там. По 3 чела с одного акка — низя, теперь то вы знаете.
Вы хотя бы загляните в раздел rsdn/предложения от работодателей, там куча достойных фирм и удаленки. Вторым вариантом выкладываем резюме на любой hh-подобный сайт,
с пометкой "удаленную работу". Да сейчас столько всяких сервисов, линкединов всяких, что отговорка может быть только одна — лень.
L>> долго и усердно готовится, но попасть именно в Топ-компанию, где зеленые человечки отсеиваются еще на этапе резюме. IT>В РФ много известных компаний, где такие человечки еще и в топах
Газпром? Дети гендира? Незнаю таких...
L>Дело в том, что обе компании, были образованы в середине 2000-ых. Т.е. на момент найма им было >5 лет. То что одна не промасштабировалась, и не наладила процессы — говорят их рейты, сотрудники и в целом бизнес модель. 2-ая компания может позволить себе сеньоров, за счет модели — подписка на месяц, у первой — фиксед-прайс и толпа индусов в штате.
Тяжело сказать что лучше: с одной стороны первая компания может позволить 3-их человек вместо одного.
Все же склоняюсь к мысли что вторая компания не совсем правильно распределяет свои ресурсы потому что иметь в штате одних 10+ синьоров с точки зрения бизнеса не совсем эффективно, если это не какой то космический софт.
Здравствуйте, licedey, Вы писали:
L>С апворком лучше не шутить, строго все там. По 3 чела с одного акка — низя, теперь то вы знаете.
Его не закрыли, просто акк узурпирован человеком. Год назад организовал новый — на каждый отлик непривычная тишина.
L>Вы хотя бы загляните в раздел rsdn/предложения от работодателей, там куча достойных фирм и удаленки. Вторым вариантом выкладываем резюме на любой hh-подобный сайт,
На рсдне 2 подходящие вакансии в квартал, в большинстве случаев с бомж-зп.
L>с пометкой "удаленную работу". Да сейчас столько всяких сервисов, линкединов всяких, что отговорка может быть только одна — лень.
На хх как раз в основном бомж-зарплаты и говноконторы. На линкедине нужны обычно нормальные нэтивы(знаю, но нэтива изобразить не могу), а ненормальные — привет ХХ.
L>Газпром? Дети гендира? Незнаю таких...
Много, на раннем этапе говнокод не критичен. Т.е. я множество продуктов видел с говнищем внутри, но которое реально приносит деньги тому, кто это написал.
Здравствуйте, landerhigh, Вы писали:
CEM>>Т.е. стартапов нет. Откуда тогда выводы, как надо делать правильно?
L>Надо же, два предложения, два утверждения, и оба абсолютно неправильные.
А я, с теми же доказательствами, говорю, что абсолютно правильные
Не, я не против agile и я использую в работе юнит-тесты и очень рад, они сэкономили мне и другим кучу времени. Меня просто насторожило упорное (заученное?) цитирование "как надо" делать, в том месте, где юнит-тесты не нужны, даже просто из соображений здравого смысла. Поэтому я спросил про реальный опыт стартапов.
Здравствуйте, CEMb, Вы писали:
L>>Надо же, два предложения, два утверждения, и оба абсолютно неправильные. CEM>А я, с теми же доказательствами, говорю, что абсолютно правильные
И где же?
Вот два моих утверждения:
T>Какое value от юнит-тестов в динамичном стартапе у которого архитектура меняется каждый день и актуальность тестов все время протухает, а релиз нужно срочно выкатить к концу месяца?
Такой стартап закапывать можно сразу.
Это доказательства не требует.
И второе:
Скрам, кстати, без юнит-тестов вообще не работает.
А больше я ничего не утверждал. Особенно в части "как делать правильно".
Ты все сам додумал.
Здравствуйте, IncremenTop, Вы писали:
IT>Здравствуйте, licedey, Вы писали:
L>>С апворком лучше не шутить, строго все там. По 3 чела с одного акка — низя, теперь то вы знаете.
IT>Его не закрыли, просто акк узурпирован человеком. Год назад организовал новый — на каждый отлик непривычная тишина.
L>>Вы хотя бы загляните в раздел rsdn/предложения от работодателей, там куча достойных фирм и удаленки. Вторым вариантом выкладываем резюме на любой hh-подобный сайт,
IT>На рсдне 2 подходящие вакансии в квартал, в большинстве случаев с бомж-зп.
L>>с пометкой "удаленную работу". Да сейчас столько всяких сервисов, линкединов всяких, что отговорка может быть только одна — лень.
IT>На хх как раз в основном бомж-зарплаты и говноконторы. На линкедине нужны обычно нормальные нэтивы(знаю, но нэтива изобразить не могу), а ненормальные — привет ХХ.
L>>Газпром? Дети гендира? Незнаю таких...
IT>Много, на раннем этапе говнокод не критичен. Т.е. я множество продуктов видел с говнищем внутри, но которое реально приносит деньги тому, кто это написал.
В вас говорит отчаяние, как у меня было неделю назад в ветке "Куда уходят фрилансеры". Отдохнуть надо и видимо поискать что-то другое. Я на том же рсдн'e на 2 интервью уже подписался, в хорошие компании на удаленку.
Да и все аргументы выше, потому что вы вероятно не знаете, что такое хорошая компания, большой рейт и контроль качества на любых этапах.
Здравствуйте, turbocode, Вы писали:
L>>Дело в том, что обе компании, были образованы в середине 2000-ых. Т.е. на момент найма им было >5 лет. То что одна не промасштабировалась, и не наладила процессы — говорят их рейты, сотрудники и в целом бизнес модель. 2-ая компания может позволить себе сеньоров, за счет модели — подписка на месяц, у первой — фиксед-прайс и толпа индусов в штате.
T>Тяжело сказать что лучше: с одной стороны первая компания может позволить 3-их человек вместо одного. T>Все же склоняюсь к мысли что вторая компания не совсем правильно распределяет свои ресурсы потому что иметь в штате одних 10+ синьоров с точки зрения бизнеса не совсем эффективно, если это не какой то космический софт.
Co. #1. 3-х индусов с глючным софтом и потерей репутации как компания. Оборот ~500к $. Системный софт — антималваре.
Co. #2. Может и не совсем правильно, много погоняйла было про бюджет и в какой мы ж.. сейчас, поэтому ушел. Но с точки зрения девелопера, зарплаты — это был отличный кейс. Оборот >60mln$. Софт — обычный энтерпрайз, для малого-среднего бизнеса.
L>Co. #1. 3-х индусов с глючным софтом и потерей репутации как компания. Оборот ~500к $. Системный софт — антималваре.
В системниках обычно зверские отделы QA и там кумарам бессонные ночи обеспечены на 100%.
L>Co. #2. Может и не совсем правильно, много погоняйла было про бюджет и в какой мы ж.. сейчас, поэтому ушел. Но с точки зрения девелопера, зарплаты — это был отличный кейс. Оборот >60mln$. Софт — обычный энтерпрайз, для малого-среднего бизнеса.
Для энтерпрайза качество кода редкость, а плач о бюджетах это своего рода ритуал в бизнесе — так что зря ты ушел.
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, CEMb, Вы писали:
L>>>Надо же, два предложения, два утверждения, и оба абсолютно неправильные. CEM>>А я, с теми же доказательствами, говорю, что абсолютно правильные
L>И где же?
Там же где и твои, ты их не привёл, я их тоже не привёл. Почему ты думаешь, что то, что ты говоришь — сразу правда?
L>Вот два моих утверждения: L>
T>>Какое value от юнит-тестов в динамичном стартапе у которого архитектура меняется каждый день и актуальность тестов все время протухает, а релиз нужно срочно выкатить к концу месяца?
L>Такой стартап закапывать можно сразу.
L>Это доказательства не требует.
Ясно. Ты не прав, и это точно так же доказательства не требует.
И страртапов у тебя не было
L>И второе:
L>
L>Скрам, кстати, без юнит-тестов вообще не работает.
L>А больше я ничего не утверждал. Особенно в части "как делать правильно". L>Ты все сам додумал.
Я ничего не додумывал, у меня не было вопросов к скраму и юнит-тестам, это ты сам додумал.
У меня вопрос был и остался к: "Такой стартап закапывать можно сразу", т.е. такой стартап получается "неправильный"? Почему? Где твой опыт по ведению стартапов, чтобы это утверждать. Априори: чтение и цитирование книг по agile — не есть опыт по ведению стартапов. Что сложного? Я просто прошу пример: "мы делали то-то и так-то, стартап завалился, причина в том, что архитектура менялась каждый день, потому что: <список последствий>".
IT>Функции — это фигня, главное, чтобы по регионам внутри функций было все хорошо разбито. IT>Регионы — это фигня, главное, чтобы по блокам было все хорошо разбито. IT>Блоки — это фигня, главное, чтобы по строчки с пробелами между кодом хорошо разбивали. IT>и тд тп.
Если ты хочешь продолжать работать программистом, то мозги так или иначе напрягать прийдется. Пока что у меня сложилось впечатление, что ты хочешь прийти и начать писать с нуля int main()... В большинстве случаев так не будет.
IT>Уважаемый, я понимаю, что вы — савант и легко держите в уме классы с гигантским контрактом и кучей обязанностей, но большинство людей вроде меня не обладает столь выдающимися способностями.
Читай выше. Более того, у меня опять складывается впечатление, что ты не умеешь сконцентрироваться на какой-то конкретной задаче в рамках существующего кода.
IT>Пожалейте нас. Не пишите так.
Все хорошо в меру. Я там выше привел пример из реального фреймворка где чуваки разбили код, определяющий является ли строка имйелом, как минимум на три класса. Поэтому скажу тебе твоими же словами: пожалей нас. Не пиши так.
L>>>Это доказательства не требует. CEM>>Ясно. Ты не прав, и это точно так же доказательства не требует.
L>Я прав и это знает любой, кто работал на реальных проектах.
На самом деле и здесь ты не прав, как то работал на заре карьеры в не ИТ компании (когда еще слова скрам не знали) где требования бизнеса часто менялись (писали код считай с колес), а бизнес аналитиков не было (и времени не было) в итоге все сваливалось на программистов (ну ты ж программист!) — могу сказать что было очень сложно работать, но провала никакого не было.
Здравствуйте, turbocode, Вы писали:
T>На самом деле и здесь ты не прав, как то работал на заре карьеры в не ИТ компании (когда еще слова скрам не знали)
Исходя из даты регистрации, в выделенное поверить сложно.
T>где требования бизнеса часто менялись (писали код считай с колес), а бизнес аналитиков не было (и времени не было) в итоге все сваливалось на программистов (ну ты ж программист!) — могу сказать что было очень сложно работать, но провала никакого не было.
Это лишь означает, что твой начальник был достаточно опытным. И вы не меняли архитектуру каждый день (месяц, год). Вы ее вообще не меняли.
Здравствуйте, landerhigh, Вы писали:
CEM>>Ясно. Ты не прав, и это точно так же доказательства не требует.
L>Я прав и это знает любой, кто работал на реальных проектах.
1. Ты видишь разницу между реальными проектами и стартапами? При чём тут реальные проекты? Речь про стартапы.
2. Пока не вижу ни одного человека, работавшего над реальными проектами, который знает, что ты прав. Если найдётся такой человек, я задам ему этот вопрос.
3. Ты не прав, говорю, как человек, работающий над реальными проектами, которые работают на реальных предприятиях.
L>Переходы на личности поскипаны.
Где там переходы на личности? Есть только отсылка к опыту, который к личности отношения не имеет.
Я задал тебе простейший вопрос: приведи пример провала стартапа, где архитектура меняется каждый день? Если такого примера нет, твоё утверждение про то, что такой стартап надо закапывать — ложно и непонятно, на чём основано.
В общем, пока вижу у тебя какие-то отговорки. Не надо ссылаться на любых людей, которые работали над реальными проектами, но ничего про тебя не слышали и эту тему не читали, поэтому мнение их неизвестно. И другие странные доводы тоже не надо. Просто пример, если есть. Если нету примера, скажи: "нету", и у меня не будет вопросов. В чём сложность-то?
Здравствуйте, CEMb, Вы писали:
L>>Я прав и это знает любой, кто работал на реальных проектах. CEM>1. Ты видишь разницу между реальными проектами и стартапами? При чём тут реальные проекты? Речь про стартапы.
Демагогия.
CEM>2. Пока не вижу ни одного человека, работавшего над реальными проектами, который знает, что ты прав. Если найдётся такой человек, я задам ему этот вопрос.
Демагогия.
CEM>3. Ты не прав, говорю, как человек, работающий над реальными проектами, которые работают на реальных предприятиях.
Пальцы. И демагогия.
L>>Переходы на личности поскипаны. CEM>Где там переходы на личности? Есть только отсылка к опыту, который к личности отношения не имеет. CEM>Я задал тебе простейший вопрос: приведи пример провала стартапа, где архитектура меняется каждый день? Если такого примера нет, твоё утверждение про то, что такой стартап надо закапывать — ложно и непонятно, на чём основано.
За доказательством отсутсвия бога — в соседний форум.
За примерами стартапов, пожалуйста, к кодеру с турбонаддувом.
T>>На самом деле и здесь ты не прав, как то работал на заре карьеры в не ИТ компании (когда еще слова скрам не знали) L>Исходя из даты регистрации, в выделенное поверить сложно.
в те далекие времена здесь можно было писать без регистрации.
L>Это лишь означает, что твой начальник был достаточно опытным. И вы не меняли архитектуру каждый день (месяц, год). Вы ее вообще не меняли.
Здравствуйте, turbocode, Вы писали:
L>>Это лишь означает, что твой начальник был достаточно опытным. И вы не меняли архитектуру каждый день (месяц, год). Вы ее вообще не меняли. T>Меняли часто но тогда это не казалось трагедией.
Ты перестань называть обычную итеративную разработку с постоянной адаптацией к меняющимся требованиям "изменениями архитектуры" и непонятки исчезнут.
Изменение архитектуры — это когда ввалившийся с мороза тимлид молвит человеческим голосом, что реляционную субд выбрасываем и пишем свою объектную. Впрочем, при правильном изначальном выборе абстракции вам будет пофиг, где данные хранятся.
Или вместо локального Windows UI заказчик резко возжелает вебморду. При правильном подходе архитектура основной части системы не изменится.
Арзхитектуру в корне приходится менять лишь в одном случае — когда полностью провафлили задачу и выбрали изначально неработоспособный подход. Все остальное — мелкие рабочие вопросы.
L>Арзхитектуру в корне приходится менять лишь в одном случае — когда полностью провафлили задачу и выбрали изначально неработоспособный подход.
Это был работоспособный подход на вчера но уже не работоспособный подход сегодня (потому что бизнес ушел вперед, а ПО уже старое не отвечающее потребностям бизнеса на сегодня и тем более никто не мог предвидеть какие бизнес потребности будут завтра).
Здравствуйте, turbocode, Вы писали:
T>Это был работоспособный подход на вчера но уже не работоспособный подход сегодня (потому что бизнес ушел вперед, а ПО уже старое не отвечающее потребностям бизнеса на сегодня и тем более никто не мог предвидеть какие бизнес потребности будут завтра).
Ага. Бизнес вчера строил ракеты, а сегодня решил делать туалетную бумагу.
L>Ага. Бизнес вчера строил ракеты, а сегодня решил делать туалетную бумагу.
Это сейчас сформировавшийся четко сегментированный рынок где каждый занимается своим определенным делом, а тогда бизнес брался за все куда дотянутся руки.
Здравствуйте, turbocode, Вы писали:
T>Это сейчас сформировавшийся четко сегментированный рынок где каждый занимается своим определенным делом, а тогда бизнес брался за все куда дотянутся руки.
Только процесс разработки при этом называется не "меняем архитектуру", а "закрываем проект и начинаем новый".
L>Только процесс разработки при этом называется не "меняем архитектуру", а "закрываем проект и начинаем новый".
Пока ты будешь начинать новый проект этот бизнес 100 раз успеет умереть и родится в новом виде, а деньги ушли к другим.
В реале же босс приходит с пачкой уже подписанных контрактов на совещание и говорит: ура-ура господа ИТ-шники у нас новый бизнес надо это дело быстро внедрить в нашу существующую систему.
Здравствуйте, turbocode, Вы писали:
L>>Только процесс разработки при этом называется не "меняем архитектуру", а "закрываем проект и начинаем новый". T>Пока ты будешь начинать новый проект этот бизнес 100 раз успеет умереть и родится в новом виде
Извини, но когда вчера строим ракеты, а сегодня делаем туалетную бумагу — это вот это вот самое и есть.
Здравствуйте, turbocode, Вы писали:
L>>Извини, но когда вчера строим ракеты, а сегодня делаем туалетную бумагу — это вот это вот самое и есть. T>Твое предложение отказаться боссу от денег потому что ИТ-шникам будет не по феншую (скраму)?
Ты лучше имя компании-то назови. Чтобы стороной обходить. Кто знает, в какое еще место они сначала ракетные, а потом туалетнобумажные технологии внедрили.
L>Ты лучше имя компании-то назови. Чтобы стороной обходить. Кто знает, в какое еще место они сначала ракетные, а потом туалетнобумажные технологии внедрили.
Здравствуйте, turbocode, Вы писали:
L>>Ты лучше имя компании-то назови. Чтобы стороной обходить. Кто знает, в какое еще место они сначала ракетные, а потом туалетнобумажные технологии внедрили. T>Не ИТ-шная ж, так что не ссы.
Вот это меня и напрягает. Вчера туалетную бумагу, сегодня колбасу, завтра что?
Здравствуйте, turbocode, Вы писали:
T>Твое предложение отказаться боссу от денег потому что ИТ-шникам будет не по феншую (скраму)?
Как предложение называть вещи своими именами вынуждает босса отказаться от денег?
И да, как внедрение нового проекта в уже существующую систему затрагивает то, что было внедрено
до этого?
L>Вот это меня и напрягает. Вчера туалетную бумагу, сегодня колбасу, завтра что?
завтра аутстаф, после завтра аутсорс и дальше к звездам на своем ИТ продукте. Почему нет, если несут деньги?
Здравствуйте, turbocode, Вы писали:
L>>Вот это меня и напрягает. Вчера туалетную бумагу, сегодня колбасу, завтра что? T>завтра аутстаф, после завтра аутсорс и дальше к звездам на своем ИТ продукте. Почему нет, если несут деньги?
Ну раз к звездам, значит должна быть гордость за продукт. Так как копания-то называется, что весь мир своими продуктами ощасливила?
L>Ну раз к звездам, значит должна быть гордость за продукт. Так как копания-то называется, что весь мир своими продуктами ощасливила?
Зачем тебе, вероятность что ты туда пройдешь около 0.0, так что спи спокойно и молись на свой скрам дальше.
Здравствуйте, turbocode, Вы писали:
L>>Ну раз к звездам, значит должна быть гордость за продукт. Так как копания-то называется, что весь мир своими продуктами ощасливила? T>Зачем тебе, вероятность что ты туда пройдешь около 0.0, так что спи спокойно и молись на свой скрам дальше.
Меня исключительно риск невзначай стать потребителем их продукции напрягает.
L>Меня исключительно риск невзначай стать потребителем их продукции напрягает.
Тогда тебе на необитаемый остров, потому что бизнес это тебе не розовые слоники c радужными мыльными пузырями вокруг, а тяжелая работа где от перенапряжения бывает что люди умирают (конечно никто об этом не скажет вслух ни google, ни apple, ни MS ни другая няшная по твоему мнению ИТ компания c большим логотипом).
Здравствуйте, turbocode, Вы писали:
L>>Меня исключительно риск невзначай стать потребителем их продукции напрягает. T>Тогда тебе на необитаемый остров, потому что бизнес это тебе не розовые слоники c радужными мыльными пузырями вокруг, а тяжелая работа где от перенапряжения бывает что люди умирают (конечно никто об этом не скажет вслух ни google, ни apple, ни MS ни другая няшная по твоему мнению ИТ компания c большим логотипом).
Здравствуйте, Олег К., Вы писали:
ОК>Если ты хочешь продолжать работать программистом, то мозги так или иначе напрягать прийдется. Пока что у меня сложилось впечатление, что ты хочешь прийти и начать писать с нуля int main()... В большинстве случаев так не будет.
Пока что научись читать.
ОК>Читай выше. Более того, у меня опять складывается впечатление, что ты не умеешь сконцентрироваться на какой-то конкретной задаче в рамках существующего кода.
Советую осилить пару-тройку книг по нейрофизиологии человека и понять, что большинство людей не умеет держать в голове слишком много информации в принципе. Это, кстати, потом поможет проектировать более-менее нормальные интерфейсы.
ОК>Поэтому скажу тебе твоими же словами: пожалей нас. Не пиши так.
А я не оправдывал этот пример, это ты кинулся оправдывать говнокод, так что мимо, увы.
Здравствуйте, IncremenTop, Вы писали:
IT>Не поверишь — я реально спросил, куда податься, но большинство либо не читает до конца, либо не знает ответа
Ну вот я тебе сказал, а ты начал ехидничать. Во первых далеко не все проекты настолько ужасны, как ты описываешь, во вторых — можно создавать новые. Выбор за тобой.
Я умудрился пропустить проверку на null. Правда, это практически сразу обнаружилось. В общем, масштабы не очень былинные.
