А мне понравилось. А я проработал системным аналитиком с десяток лет.
Но за упорство респект, я обычно как понимаю, что статья — потерянное время тут же её прекращаю читать. Или дочитываю «по диагонали». На что мне секунд 20 не особо жаль.
По поводу багов, лучше тоже оговаривать сроки. И требования к поддержке прописывать. Иначе вылезает клиент через полтора года после сдачи, а его не помнит уже никто.
Плюс, срок «опытной эксплуатации» подстегивает клиента начать эксплуатацию быстрее. А чем быстрее он ошибки найдёт, тем проще их править.
Кстати в пиндостане можно подавать групповые иски. Скажем собрать от владельцев куроферм разрешения представлять интересы их птичек в суде. Мало не покажется каждой несушке по пакету комбикорма в компенсацию.
Автор из США? Думаю ему уже наяривают 10-50 юристов. В штатах судебные издержки относятся на счёт сторон (и не важно кто выиграет), поэтому судиться по поводу прав на не особо бюджетный и художественный ролик действительно глупо.
Поэтому там баксов 100 за ошибку и баксов 500 за моральный ущерб. Но! У америкосов есть такая фишка, как «не фиг». А именно, если какая злая фирма обижает допропорядочного американца, даже если тот питается травой, то такую фирму надо… наказать. Чтобы в след раз так не делала. И с этим всё хорошо. Наказывают деньгами и очень больно. Притом как ни странно не в счёт государства, а в счёт истца.
Многие юр. фирмы этим и живут. Предлагая наказать нехорошего дядю, особенно крупного и богатого, за долю малую или большую. Даже если наказать больно не получится — скажем, оборот этих копирастеров небольшой (наказывают обычно в пропорции от годовой прибыли), то для юр конторы — это реклама. Поскольку на рынке добрых услуг тоже конкуренция присутутсвует.
В 95 моему знакомом за $35000 предложили домик в посёлке художников на Соколе, он поторговался сбил до 28, но его жаба придушила. Про то сколько сейчас там стоит домик с огородиком…
в 99 году зарплата в 400 грин была очень приличной (мне и не работающей жене хватало и даже долларов 50 откладывали). Чек на двоих в ресторане $50 — считалось дорого. В 95 тренд был примерно таким же. Потом доллар несколько обесценился, но кризис 98года его поднял.
Из той поры были истории как убивали за 200 долларов, и они не вызывали особого удивления — это была средняя зарплата по москве.
А про компьютеры — подрабатывал в институте, в 94 году у нас на два приличных компьютера (386+) было 10 программистов, нам студентам, с низким приоритетом приходилось работать по ночам;) Либо работать на 286 или совсем «древних» 8086, которые отставали от 386 раза в 4 и 40 соответсвенно.
Я пока не готов расстаться с кондиционером управляемым с ИК пультом, только ради того, чтобы его пульт ушёл в историю. Да и смысла менять муз центр и DVD проигрыватель тоже не вижу смысла. Телевизор бы поменял — но его не смотрю почти ;)
Я если пишу ассерты, то чаще после кода который надо проверять, лишь иногда до. В принципе написание раньше — лучше организует, но немного тормозит. Имхо, это зависит от того как человек думает. Когда знаю, что должно получиться, но не знаю как, то сперва пишу условия. Когда знаю, как нужно сделать, но не уверен, что именно получится, то сперва код. Если знаю что и как, то все равно сперва код. Но опять же ассерты — для меня подстраховка в опасном месте. Поэтому — как то не сложилось.
Плюс в контексте статьи я бы предложил писать сразу несколько простых функциональных блоков. И прогонять их после того, как выдыхаешься.
Самое сложное — это договориться и построить так работу. А то начинается, что человеку нужно свой код дописать, ему не до твоего. Или оба под нагрузкой — не до ревью — лишь бы инвестору что-то показать.
Даже если и увеличится — это нестрашно. Код написанный одним куском потребует меньше времени, чем код написанный с «перекурами» на проверку. А время общей отладки будет в большинстве случаев меньше времени на отладку иттерационную.
При использовании ассертов — вообще сильно меньше. Но с ассертами — проблема в том, насколько они привычны программисту. Если написание вживлено на подкорку и пишуться на автомате — это одно. Если тормозят полет мысли — лучше ассерты бить во время ревью. Опять же при это код переосмыслится ещё раз, что не лишне.
Сам я ассерты в том или ином виде использую только в критически важных местах кода. Но это не суть методики — а мои привычки при самостоятельной работе.
При работе в команде, естественно, пишу «как здесь принято». И в конце дня стараюсь сделать ревью написанного за день, а то люблю костыль вбить или идиому новую попробовать. А проблема костыля не в том, что он костыль — системы подпорок и соплей порой успешно живут долгие годы, а в том, что либо он оторван от кода и коллегам не понятно, что это за фигня такая. Либо, что ещё хуже, когда коллегам не понятно, что это костыль. Соберешься потом его прибить, а там из костыля уже цельный емпайр-стейт-билдинг вырос.
Тут моя ошибка — я не написал, что большой кусок кода — это работа по времени от получаса до нескольких часов. Потом небольшой период на холодное ревью и большой период на отладку.
Коммитить неотлаженный код — нельзя. Потому что нельзя никогда, разве что в бранч.
Идея в том, чтобы не перебивать рабочий порыв мелкими итерациями — кусок кода, запуск, отладка, где кусок кода — 5-10 строк. Лучше закончить сразу функциональный блок на одном дыхании. А потом его быстро вылизать.
Я стал мельчить из-за опасений. Что могу ошибаться и потом долго отлаживать большой кусок. Но попробовав работать простынями выяснил, что код получается более стабильный.
В метро я работаю над сценариями, идеально, интернета нет — час ехать, программировать уже/ещё не хочется ;) На работе есть время пока приветствия чай кофе. Как раз поднять записи и наметить план наступления.
Хорошая кстати методика. Перед уходом с работы записать в рабочий блокнот, что хочется (ни в коем случае не планируется) сделать завтра. С утра читая записи, наметить, чем в первую очередь надо заняться и как.
В периоды тотальной разработки выручает сильно:
— план на один день актуален;
— он на тебя не давит;
— есть четкая картина, что делать;
— возможность играть с детализацией;
— есть возможность коррекции плана на свежую голову
Вечером новый план. В конце этапа пробежаться по блокноноту и посмотреть не сделанные или уже неактуальные задания. Перписывать задания не надо — вероятность забыть что-то важное небольшая. А неважное — оно неважное.
Понимаю, что статью надо переписывать. По крайней мере выкидывать начало и конец. А середину дорабатывать напильником;)
Хорошо очень писалось и я зачем-то воткнул два подраздела из задумываемой статьи по гейм-дизайну. Там ситуация немного другая и хотя корреляции тоже есть и я считаю, что они правильные, всё таки аргументации не хватает и сформулировано жестковато.
Это да. В институте предчувствуя приход «полярного куся», выписывал порядок действий по изучению, написанию и сдачи хвостов. И этот магический листочек со спеками — оченно выручал. Поэтому из института меня выгоняли всего два раза;)
Но за упорство респект, я обычно как понимаю, что статья — потерянное время тут же её прекращаю читать. Или дочитываю «по диагонали». На что мне секунд 20 не особо жаль.
var alert_cnt = 0;
function _alert(s){
alert_cnt++;
$('#alert').html(alert_cnt + '. '+s+'
' +$('#alert').html());
}
Консоль тоже хорошо, но иногда хочется подглядеть за процессом.
По поводу багов, лучше тоже оговаривать сроки. И требования к поддержке прописывать. Иначе вылезает клиент через полтора года после сдачи, а его не помнит уже никто.
Плюс, срок «опытной эксплуатации» подстегивает клиента начать эксплуатацию быстрее. А чем быстрее он ошибки найдёт, тем проще их править.
Но это нюансы.
Поэтому там баксов 100 за ошибку и баксов 500 за моральный ущерб. Но! У америкосов есть такая фишка, как «не фиг». А именно, если какая злая фирма обижает допропорядочного американца, даже если тот питается травой, то такую фирму надо… наказать. Чтобы в след раз так не делала. И с этим всё хорошо. Наказывают деньгами и очень больно. Притом как ни странно не в счёт государства, а в счёт истца.
Многие юр. фирмы этим и живут. Предлагая наказать нехорошего дядю, особенно крупного и богатого, за долю малую или большую. Даже если наказать больно не получится — скажем, оборот этих копирастеров небольшой (наказывают обычно в пропорции от годовой прибыли), то для юр конторы — это реклама. Поскольку на рынке добрых услуг тоже конкуренция присутутсвует.
Из той поры были истории как убивали за 200 долларов, и они не вызывали особого удивления — это была средняя зарплата по москве.
А про компьютеры — подрабатывал в институте, в 94 году у нас на два приличных компьютера (386+) было 10 программистов, нам студентам, с низким приоритетом приходилось работать по ночам;) Либо работать на 286 или совсем «древних» 8086, которые отставали от 386 раза в 4 и 40 соответсвенно.
Я если пишу ассерты, то чаще после кода который надо проверять, лишь иногда до. В принципе написание раньше — лучше организует, но немного тормозит. Имхо, это зависит от того как человек думает. Когда знаю, что должно получиться, но не знаю как, то сперва пишу условия. Когда знаю, как нужно сделать, но не уверен, что именно получится, то сперва код. Если знаю что и как, то все равно сперва код. Но опять же ассерты — для меня подстраховка в опасном месте. Поэтому — как то не сложилось.
Плюс в контексте статьи я бы предложил писать сразу несколько простых функциональных блоков. И прогонять их после того, как выдыхаешься.
А так работает замечательно.
При использовании ассертов — вообще сильно меньше. Но с ассертами — проблема в том, насколько они привычны программисту. Если написание вживлено на подкорку и пишуться на автомате — это одно. Если тормозят полет мысли — лучше ассерты бить во время ревью. Опять же при это код переосмыслится ещё раз, что не лишне.
Сам я ассерты в том или ином виде использую только в критически важных местах кода. Но это не суть методики — а мои привычки при самостоятельной работе.
При работе в команде, естественно, пишу «как здесь принято». И в конце дня стараюсь сделать ревью написанного за день, а то люблю костыль вбить или идиому новую попробовать. А проблема костыля не в том, что он костыль — системы подпорок и соплей порой успешно живут долгие годы, а в том, что либо он оторван от кода и коллегам не понятно, что это за фигня такая. Либо, что ещё хуже, когда коллегам не понятно, что это костыль. Соберешься потом его прибить, а там из костыля уже цельный емпайр-стейт-билдинг вырос.
Коммитить неотлаженный код — нельзя. Потому что нельзя никогда, разве что в бранч.
Идея в том, чтобы не перебивать рабочий порыв мелкими итерациями — кусок кода, запуск, отладка, где кусок кода — 5-10 строк. Лучше закончить сразу функциональный блок на одном дыхании. А потом его быстро вылизать.
Я стал мельчить из-за опасений. Что могу ошибаться и потом долго отлаживать большой кусок. Но попробовав работать простынями выяснил, что код получается более стабильный.
Хорошая кстати методика. Перед уходом с работы записать в рабочий блокнот, что хочется (ни в коем случае не планируется) сделать завтра. С утра читая записи, наметить, чем в первую очередь надо заняться и как.
В периоды тотальной разработки выручает сильно:
— план на один день актуален;
— он на тебя не давит;
— есть четкая картина, что делать;
— возможность играть с детализацией;
— есть возможность коррекции плана на свежую голову
Вечером новый план. В конце этапа пробежаться по блокноноту и посмотреть не сделанные или уже неактуальные задания. Перписывать задания не надо — вероятность забыть что-то важное небольшая. А неважное — оно неважное.
Понимаю, что статью надо переписывать. По крайней мере выкидывать начало и конец. А середину дорабатывать напильником;)
Хорошо очень писалось и я зачем-то воткнул два подраздела из задумываемой статьи по гейм-дизайну. Там ситуация немного другая и хотя корреляции тоже есть и я считаю, что они правильные, всё таки аргументации не хватает и сформулировано жестковато.