Не упомянуто ещё одно очень важно обстоятельство, о котором говорил недавно в Киеве парень, рассказывавший об успехе AngryBirds (т.е. инфа из первых рук): среднее время игровой сессии должно быть не более нескольких минут.
Они у себя стремились к 2-3 минутам.
Всё, что дольше — банально неудобно в условиях применения мобильных игр (транспорт, школьная перемена, туалет, другое кратковременное ожидание).
Так что имхо любая, даже мега-простая в управлении стратегия, обречена на провал именно поэтому.
Равно как и квест-рпг.
Совершенно согласен.
Поэтому в разных командах бывают свои, командные, гайдлайны.
Которые стараются от проекта к проекту не менять, чтобы, например, легче было перебрасывать людей из проекта в проект.
Вот при переходе из команды в команду (из компании в компанию) бывает, что приходится тратить некоторое время на подстраивание под принятый там стиль кодирования.
В то же время, гайдлайны эти если и различаются, то всё же их разнообразие вполне конечно и может быть легко изучено в краткие сроки.
Так что внутренние гайдлайны, хотя и принимаются вразнобой, но имеют гораздо более положительный эффект, чем добавляют трудностей. :)
Спасибо за конструктивную критику. Действительно, этот момент у меня немного выбивается из общей канвы.
С другой стороны, текст писался, как обрамление бесплатным курсам чистого кода, которые я собираюсь проводить в ближайшее время.
И третья часть скорее объясняет — почему вообще я считаю, что такие курсы нужны. И почему я хочу вкладывать в это своё время и свой, пусть не самый богатый, опыт.
Очень рад, что текст сам по себе тоже может приносить пользу. Пожалуйста, реализуйте-таки своё намерение — от этого будет только польза и Вам лично, и окружающим :)
Ещё раз спасибо — за внимание, за понимание и за критику. :)
Полностью согласен.
Более того — именно об этом я пишу в третьем и четвёртом примерах.
Просто разница в том, что, работая с собственным говнокодом, человек может не замечать всех связанных с этим проблем.
А в команде это становится очень хорошо видно, на контрастах. В хорошей команде, само собой.
Если в команде говнокодят чуть менее, чем все и каждый — то никто ничего не заметит.
Тоже вполне жизненная ситуация, к сожалению.
Спасибо, я очень старался, чтобы статья понравилась :)
Можно, конечно, написать и на английском.
Но получится несколько хуже.
Притом, что трудозатрат будет больше.
В общем — к сожалению, это для меня сейчас вряд ли возможно. :(
Если я правильно понял, программа получает число, спит это число секунд, потом сдвигает это число в конец массива.
т.е. в данном случае первым будет сдвинуто число 1, потом — три раза 3, потом 4, 5, 6, 6, 7
решение оригинальное, да. ))
Нет, я немного о другом.
Числа-то запоминать — в принципе дело полезное.
Телефоны там… адреса… явки, пароли… ))
Меня пугают слова программиста. который в контексте «индусского говнокода» спокойно так заявляет — ребята, я вот всегда готов написать нечто подобное и ничего страшного в этом не вижу.
Ну, во всяком случае Ваши слова прозвучали как-то так. ))
Очень надеюсь, что на самом деле (с) в виду имелось нечто иное ;)
Я тоже не берусь.
Просто высказываю соображения, которые, в зависимости от ситуации, могут быть важны — а могут быть и НЕ важны.
Об этом в посте говорится, но несколько вскользь.
Тут дело в частице «лишь».
Которая подразумевает, что юнит-тестирование не применимо.
Пример: программа, которая делает что угодно, используя лишь одну функцию. Юнит-тестирование попросту невозможно.
Да, пожалуй, надо было уточнить, что под автоматизированным подразумеваются прежде всего юнит-тесты.
Если претензия к этому — то принимаю и посыпаю голову пеплом. :)
Они у себя стремились к 2-3 минутам.
Всё, что дольше — банально неудобно в условиях применения мобильных игр (транспорт, школьная перемена, туалет, другое кратковременное ожидание).
Так что имхо любая, даже мега-простая в управлении стратегия, обречена на провал именно поэтому.
Равно как и квест-рпг.
Поэтому в разных командах бывают свои, командные, гайдлайны.
Которые стараются от проекта к проекту не менять, чтобы, например, легче было перебрасывать людей из проекта в проект.
Вот при переходе из команды в команду (из компании в компанию) бывает, что приходится тратить некоторое время на подстраивание под принятый там стиль кодирования.
В то же время, гайдлайны эти если и различаются, то всё же их разнообразие вполне конечно и может быть легко изучено в краткие сроки.
Так что внутренние гайдлайны, хотя и принимаются вразнобой, но имеют гораздо более положительный эффект, чем добавляют трудностей. :)
С другой стороны, текст писался, как обрамление бесплатным курсам чистого кода, которые я собираюсь проводить в ближайшее время.
И третья часть скорее объясняет — почему вообще я считаю, что такие курсы нужны. И почему я хочу вкладывать в это своё время и свой, пусть не самый богатый, опыт.
Очень рад, что текст сам по себе тоже может приносить пользу. Пожалуйста, реализуйте-таки своё намерение — от этого будет только польза и Вам лично, и окружающим :)
Ещё раз спасибо — за внимание, за понимание и за критику. :)
Кому нужен массив ))
Хотя буквально сегодня довелось поразгребать вполне себе волнового говнеца )))
Более того — именно об этом я пишу в третьем и четвёртом примерах.
Просто разница в том, что, работая с собственным говнокодом, человек может не замечать всех связанных с этим проблем.
А в команде это становится очень хорошо видно, на контрастах. В хорошей команде, само собой.
Если в команде говнокодят чуть менее, чем все и каждый — то никто ничего не заметит.
Тоже вполне жизненная ситуация, к сожалению.
Можно, конечно, написать и на английском.
Но получится несколько хуже.
Притом, что трудозатрат будет больше.
В общем — к сожалению, это для меня сейчас вряд ли возможно. :(
То есть Вы ратуете за использование этого числа, как зафиксированной данности.
А не за фееричное решение задачи с его помощью. :)
т.е. в данном случае первым будет сдвинуто число 1, потом — три раза 3, потом 4, 5, 6, 6, 7
решение оригинальное, да. ))
Числа-то запоминать — в принципе дело полезное.
Телефоны там… адреса… явки, пароли… ))
Меня пугают слова программиста. который в контексте «индусского говнокода» спокойно так заявляет — ребята, я вот всегда готов написать нечто подобное и ничего страшного в этом не вижу.
Ну, во всяком случае Ваши слова прозвучали как-то так. ))
Очень надеюсь, что на самом деле (с) в виду имелось нечто иное ;)
Просто высказываю соображения, которые, в зависимости от ситуации, могут быть важны — а могут быть и НЕ важны.
Об этом в посте говорится, но несколько вскользь.
Насколько получилось — судить не мне. Сам я слишком самокритичен. ))
Которая подразумевает, что юнит-тестирование не применимо.
Пример: программа, которая делает что угодно, используя лишь одну функцию. Юнит-тестирование попросту невозможно.
Да, пожалуй, надо было уточнить, что под автоматизированным подразумеваются прежде всего юнит-тесты.
Если претензия к этому — то принимаю и посыпаю голову пеплом. :)
А можно написать грязно.
В том и дело, что в данном конкретном случае говнокод в принципе допустим.
Если Вы этого тезиса не поняли — печально.