Какой рейтинг вас больше интересует?
|
Главная / Главные темы / Тэг «программистами»
Типичный программист 2012-05-01 21:43:22
Программист такие люди, что &# ... Мемы про типичного программиста + развернуть текст сохранённая копия
Программист такие люди, что … :D Мемы про типичного программиста 
Тэги: картинка, мемы, программист, типичный
Ищу программиста для нового Бизнес-линча 2012-04-26 13:28:27
Ищу талантливого программиста для новой версии ...
+ развернуть текст сохранённая копия
Ищу талантливого программиста для новой версии Бизнес-линча (http://www.artlebedev.ru/kovodstvo/business-lynch/). Тестовое задание простое. Нужно сделать страничку на HTML+CSS, на которой можно будет создать текстовый пузырь с хвостиком. Пузырь должен масштабироваться и двигаться, хвостик должен перемещаться на любое расстояние.  Результат задания жду по адресу tema@tema.ru. Спасибо.
Тэги: вакансия, линч, программист
Как программисты пишут часы. Опасности общих моделей 2012-04-21 17:15:00
... . Действительно, программисты довольно быстро ... которую построили программисты, соответствовала модели ...
+ развернуть текст сохранённая копия
 | Именно так выглядят часы,
дизайн которых придумал программист |
Не могу не поделиться замечательным случаем, который произошёл у нас в команде несколько дней назад.
В рамках нашего нового продукта ребята разрабатывали интерактивные виджеты для HTML5. И, в какой-то момент, дело дошло до анимации. Естественно, анимация представляла собой красивый и плавный переход между состояниями. Действительно, программисты довольно быстро и аккуратно всё реализовали, и я, вспомнив вебдевную молодость, выпросил недоделанный компонент "поиграться". |
| А может быть - вот так |
Но тут возникла непредвиденная заминка. Часы отлично шли до тех пор, пока секундная стрелка не доходила до отметки 59. А потом... Да, вы правы. Она красиво и плавно обращалась вспять и, пройдя весь циферблат в обратном порядке, возвращалась к отметке 0.
И ведь с точки зрения программистов всё выглядело логично! Действительно, чтобы анимировать переход от значения 59 к значению 0, надо, чтобы стрелка прошла в обратном порядке все числа от 59 до 0. Вот только в реальности никто никогда не видел часы, в которых стрелка возвращалась бы назад...
Итак, что же полезного мы можем вынести из этой ситуации?
- Во-первых: чтобы описать любой объект или явление, программистам приходится строить модель. По определению модели, часть факторов из реальной жизни остаётся "за бортом". И в этот момент особенно важно следить, чтобы модель, которую построили программисты, соответствовала модели, которую строит для себя пользователь. Действительно, когда я отключил анимацию, часы стали вести себя вполне ожидаемо (хотя и не так красиво).
- Во-вторых: тестирование должно обязательно проводиться на реальных данных в условиях, максимально приближенных к тем, который возникают у пользователя. Сейчас это кажется очевидным. Однако иногда, желая досконально протестировать работу продукта в граничных случаях и под нагрузкой, мы можем упустить проверку самых очевидных кейсов, которые, в силу их тривиальности, все просто игнорируют (и забывают).
- В-третьих: обычно программисты пишут программы, а не продукты. Они увлекаются описанием объектной модели, построением архитектуры и алгоритмов, забывая о том, что продукт должен собой представлять в реальности. То есть надо возвращать их с неба на землю. Здесь сильно помогает итеративный подход и частая демонстрация промежуточных результатов владельцу продукта (честно говоря, затрудняюсь более точно перевести скрамовское сочетание product owner).
В-четвёртых: если вы пишите ТЗ на разработку внешней команде, по возможности описывайте исходный объект или процесс из реальной жизни, который лежит в основе создаваемого ПО. Это не только позволит программистам увидеть задачу шире, чем программный код, но и вы сможете более чётко сформулировать ключевые требования.
С другой стороны я с огромным трудом представляю себе ТЗ, которое содержит фрагмент типа "при переходе от 59 к 0 стрелки должны двигаться по часовой стрелке". Такая детализация возможна разве что в системе жизнеобеспечения космического корабля, но мне такие задания, к сожалению, пока читать не доводилось. Поэтому описание реального объекта поможет команде более точно понять задачу.
- В-пятых: идеальный программист всегда немного аналитик. Он мыслит не только интерфейсами, классами и методами, но и объектами предметной области, понимает не только алгоритмы, но и бизнес-логику системы. И это одна из основных черт, которая отличает опытного разработчика от начинающего кодера (каким бы классным он ни был).
В заключение хочу сказать, что никоим образом не пытаюсь посмеяться над "глупыми программистами" или как-то ещё задеть их в профессиональном плане. У меня отличные ребята и классная команда. Просто есть вещи, которые кажутся настолько очевидными, что перестаёшь обращать на них внимание и видеть исключения из общих правил. И поэтому очень важно смотреть на систему с разных сторон: как менеджер по продукту, как аналитик, как программист, как пользователь системы. Попробуйте, и ваши продукты будут великолепны! Как у нас :).
... . Действительно,
довольно быстро ... которую построили
, соответствовала модели ...
|
Именно так выглядят часы,
дизайн которых придумал программист |
Не могу не поделиться замечательным случаем, который произошёл у нас в команде несколько дней назад.
В рамках нашего нового продукта ребята разрабатывали интерактивные виджеты для HTML5. И, в какой-то момент, дело дошло до анимации. Естественно, анимация представляла собой красивый и плавный переход между состояниями. Действительно, программисты довольно быстро и аккуратно всё реализовали, и я, вспомнив вебдевную молодость, выпросил недоделанный компонент "поиграться".
| А может быть - вот так |
Но тут возникла непредвиденная заминка. Часы отлично шли до тех пор, пока секундная стрелка не доходила до отметки 59. А потом... Да, вы правы. Она красиво и плавно обращалась вспять и, пройдя весь циферблат в обратном порядке, возвращалась к отметке 0.
И ведь с точки зрения программистов всё выглядело логично! Действительно, чтобы анимировать переход от значения 59 к значению 0, надо, чтобы стрелка прошла в обратном порядке все числа от 59 до 0. Вот только в реальности никто никогда не видел часы, в которых стрелка возвращалась бы назад...
Итак, что же полезного мы можем вынести из этой ситуации?
- Во-первых: чтобы описать любой объект или явление, программистам приходится строить модель. По определению модели, часть факторов из реальной жизни остаётся "за бортом". И в этот момент особенно важно следить, чтобы модель, которую построили программисты, соответствовала модели, которую строит для себя пользователь. Действительно, когда я отключил анимацию, часы стали вести себя вполне ожидаемо (хотя и не так красиво).
- Во-вторых: тестирование должно обязательно проводиться на реальных данных в условиях, максимально приближенных к тем, который возникают у пользователя. Сейчас это кажется очевидным. Однако иногда, желая досконально протестировать работу продукта в граничных случаях и под нагрузкой, мы можем упустить проверку самых очевидных кейсов, которые, в силу их тривиальности, все просто игнорируют (и забывают).
- В-третьих: обычно программисты пишут программы, а не продукты. Они увлекаются описанием объектной модели, построением архитектуры и алгоритмов, забывая о том, что продукт должен собой представлять в реальности. То есть надо возвращать их с неба на землю. Здесь сильно помогает итеративный подход и частая демонстрация промежуточных результатов владельцу продукта (честно говоря, затрудняюсь более точно перевести скрамовское сочетание product owner).
В-четвёртых: если вы пишите ТЗ на разработку внешней команде, по возможности описывайте исходный объект или процесс из реальной жизни, который лежит в основе создаваемого ПО. Это не только позволит программистам увидеть задачу шире, чем программный код, но и вы сможете более чётко сформулировать ключевые требования.
С другой стороны я с огромным трудом представляю себе ТЗ, которое содержит фрагмент типа "при переходе от 59 к 0 стрелки должны двигаться по часовой стрелке". Такая детализация возможна разве что в системе жизнеобеспечения космического корабля, но мне такие задания, к сожалению, пока читать не доводилось. Поэтому описание реального объекта поможет команде более точно понять задачу.
- В-пятых: идеальный программист всегда немного аналитик. Он мыслит не только интерфейсами, классами и методами, но и объектами предметной области, понимает не только алгоритмы, но и бизнес-логику системы. И это одна из основных черт, которая отличает опытного разработчика от начинающего кодера (каким бы классным он ни был).
В заключение хочу сказать, что никоим образом не пытаюсь посмеяться над "глупыми программистами" или как-то ещё задеть их в профессиональном плане. У меня отличные ребята и классная команда. Просто есть вещи, которые кажутся настолько очевидными, что перестаёшь обращать на них внимание и видеть исключения из общих правил. И поэтому очень важно смотреть на систему с разных сторон: как менеджер по продукту, как аналитик, как программист, как пользователь системы. Попробуйте, и ваши продукты будут великолепны! Как у нас :).
Тэги:
программист,
продукт,
управление
(Ссылка) Задача без сроков не решается
2012-04-16 07:48:00
Неплохой пост по планированию продуктовой разработки. Всё точно ...
+ развернуть текст сохранённая копия
Неплохой пост по планированию продуктовой разработки. Всё точно сказано.Продуктовая разработка, будучи противопоставленной разработке заказной, для меня имеет огромное множество плюсов. Тут и возможность полноценно погрузиться в задачу, и долго и вдумчиво итерация за итерацией совершенствовать и развивать проект, и непосредственное взаимодействие с конечными пользователями, и отсутствие внешнего прописанного в договоре срока, к которому так или иначе, хочешь не хочешь, пусть и ценой недоделок надо запустить проект. Прописанный срок регулярно приводит к гонкам, выкидыванию тестирования и отладки (да, срок и функционал прописан в договоре, а вот тесты... кто ж их кроме программеров видит), запуску откровенно сырого и нежизнеспособного продукта. Зачастую менеджеры творят просто чудеса в убеждении заказчика, что на самом-то деле всё работает.
Читать дальше.
Тэги: программист, продукт, проект, ссылка, управление
