Archive for the ‘Код и программистское’ Category

Код — это зло!!!

Среда, Июнь 9th, 2010

Поглядите какая тут архитектура — вот тут мы выделили в отдельный сервер логирование, тут у нас развязка которая позволяет легко подменять БД, тут мы применили шаблоны — декоратор, мост и фасад. Плюс, у нас для всех классов выведены отдельно интерфейсы и только от них уже наследуются классы, плюс все у нас построено по MVC, все это само собой настроено поверх распоследего framework’а и заточенно под распределенное выполнение. Правда красота?

Э…. Позвольте, и вся эта хренотень вам нужна для того, чтобы показать пользователю Hello World? Может быть очень крутой и расширяемый, но именно Hello World?

Так вот, товарищи, КОД — ЭТО ЗЛО. Больше кода — больше возможных ошибок, сложнее читать код и понимать, что же он конкретно делает, больше зависимостей, больше документации, больше диаграм, больше принятых решений как делать и в конечном итоге больше денег потраченных на реализацию функциональности.

Пишите меньше и наступит вам счастье.

Максимальное количество строк кода.

Среда, Май 26th, 2010

После прочтения двух книг от 37signals, появилась у меня забавная мысль для блога (Да, кстати, вторую их книгу (Reworks) я НЕ рекомендую, если вы читали первую. Те же байты только в профиль. Взята первая книга и залита сладким сиропом).

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

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

Так вот, идея, которая мне пришла в голову, что нужно вывести формулу зависимости количества строк от объема продаж. А-ля, в год продается продукт на $1000, в нем может быть 3000 строк, продается на $100000 — в нем может быть 10000 строк. Продается на миллион, в нем может быть 50000 строк.

Моя формула примерно такова.

Максимально кол-во строк = (((Продажи за год) / (Средняя зарплата программиста за год)) ^ 3/4) * 10000

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

Ну и пожалуй, при очень маленьких значениях продаж, формула откровенно глючит.

Принимаю критику и предложения по улучшению 🙂

Считалочки.

Пятница, Март 5th, 2010

Эники Беники ели вареники
Эники Бэники клёц!
Вышел зеленый матрос.

Знакомо? 🙂

Пока я крапаю длинную статью на тему как научиться НЕ делать все самому, решил набросать коротенькую статейку/задачку. Задачка аналогично такой, которая дается на олимпиадах по программированию.

Слегка формализированные правила считалочки.

1) Пусть у нас есть N человек

2) И у нас есть считалка длинной в M слов.

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

4) Человек на котором считалка закончилась выбывает.

5) Считалка продолжает считаться с следующего после выбывшего, повторяя пункт 4 и 5.

6) Оставшийся последним человек — выигрывает.

Задача:

Написать программу, которая считает порядковый номер человека который выигрывает. Входные данные N и M.

5 баллов — программа может рассчитать выигрывающего при N и M < 20.

10 баллов — программа может рассчитать при N < 20, а M порядка 1 триллиона (не фига себе считалочка), за разумное время.

25 баллов — программа может рассчитать при N порядка 1 миллиарда, M < 20, за разумное время.

50 баллов — программа может рассчитать при N и M порядка триллиона.

Если вы знаете/придумали решение на 50 баллов, прошу сразу его не бросать в комментарии, а просто написать что вы его знаете (чтобы дать остальным подумать).

Остальные решения вполне welcome в комментариях 😉

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

P.S.  Как оказалось, задача классическая (просто я с ней не сталкивался). На момент написания статьи, я знал решение на 5 и 10 баллов, примерно имел идею на 25 баллов и не знал, как решить на 50 баллов.

Agile и автоматизированное тестирование

Четверг, Декабрь 3rd, 2009

После года работы в Agile режиме (в нескольких их видоизменениях) осознал, что Agile НЕ может нормально работать для без автоматизированного тестирования.

Пойду доказательством от противного. Пусть мы работаем в Agile и у нас нету автоматизированного тестирования. У нас есть пять user story, которые мы делаем. Внутри каждой из них у нас есть какие-то разумные критерии по которой мы определяем, что user story сделана — они обычно включают ручное тестирование измененной/новой функциональности.

По окончанию скажем 6 Sprint’ов, мы решает, что пора выпустить новую версию и тут мы обнаруживаем, что оттестированная каждая user story не значит оттестированный весь продукт. Соответственно, мы стартуем большое регрессионное тестирование всего продукта. Исправляем баги (для них можно даже сделать отдельные user story), потом опять проходимся и делаем регрессионное тестирование (так как исправленные баги могли внести другие). Надеюсь это знакомо? Итого, нам понадобилось еще 3 Sprint’а, чтобы привести все к виду, в котором можно выпускать.

Итого, на самом деле мы похерили пару принципов из Agile
а) То что продукт постоянно близок по качеству к выпускаемому.
На самом деле, чем дольше мы работаем без release тем общее качество у него будет хуже и хуже
б) То, что заранее НЕ нужно планировать отдельные фазы (разработка/тестирование).
Теперь нам заранее надо таки планировать, что на каждые 6 sprint’ов разработки — 3 sprint’а тестирования и стабилизации.
Ой… А это случайно мы не в waterfall возвращаемся, когда мы делаем сначала разработку, а потом тестирование?
в) То, что по ходу, можно и нужно улучшать код рефакторингом.
Рефакторинг кода, становится делать опасно, так как зачастую только через месяца (во время большего тестирования) становится видно какие проблемы он добавил.

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

P.S. Да, основная идея — автоматизировать регрессию или большую ее часть. Это позволит, во первых раньше поймать баги, которые внесены внутри user story, но которые лежат в функциональности вне ее. Во вторых — это резко сокращает период на ретестирование продукта и его стабилизацию.