— Зачем писать свой тулкит, если купили вот уже, готовый, работающий?!
— Ну так он глючный, не гибкий, вы напишите свой, крутой, знаменитыми станете.
— Да поспорю на лимон, что то, что здесь напишем, всё равно будет голимее!
— Зато так досконально разберётесь в теме, что сможете спорить с разработчиками “того” тулкита обоснованно! Типа… “а мы знаем, почему у вас там-то не работает! У нас там тоже поэтому же не работает…”
— И всё равно не понимаю, зачем изобретать велосипед…
— Ну дык! Тот же 2-х колёсный. А этот — 2,5 колёсный!
—
P.S. Предыдущие – “Программеры-6“
Рубрики:
Метки
art art-director blog css designer designers dialogue flash google html image images interface interview IT job kharkov lj ornament pen photo programmer seo usability web-design wordpress yandex аналитика блог блогосфера веб-дизайн веб-дизайнер верстальщик вёрстка дизайн дизайнер интерфейс конкурс конференция офисное рассылка собеседование статистика эскиз юзабилити-
Последние записи
Последние комментарии
- Gesund Leben на Привет, мир!
- Ирина на Про портфолио верстальщика
- Иван на Привет, мир!
- Иван на Привет, мир!
- AdsenSe Devvver на Привет, мир!
а кто из собеседников кто? на самом деле одна из отличительных особенностей “сурового” профессионала АКА честного сеньйора в том, что он не загорается идеей написать заново все фрэймворки, которые уже существуют. дивесификация рисков и распределение отвественности, так сказать.
Да это я с программером, перед которым стояла эта задача (тимлидера постановщика задачи не было в офисе), разговор ессно не серьёзный, и я к этому проекту (пока) отношения не имею.
Это “смена ролей”?
Очень похоже
иногда проще/быстрее написать свое, чем разбираться в чужем
сколько времени и ресурсов Вы потратите в дальнешем, на поддержку и улучшение этого “своего”?
также всегда следует помноить, что в случае использования строннего фреймворка все риски, связанные с недостаточным функционалом или ошибками в продукте несет разработчик стронней библиотеки, в случае “своего ” — только сама контора. тоже верно и для рисков, связанных с поддержкой и улучшением.
так как, по-прежнему проще/быстрее?
Хе… Я бы рискнул именно свой написать…
Ну вот, горячая тема велосипедостроения..
На самом деле это вопрос неоднозначный – и решается ТОЛЬКО через учет всех факторов, взвешивание рисков как самостоятельной разработки, так и использования продукта “со стороны”, и никак иначе; смотреть на все с одной стороны ни к чему хорошему не приведет.
>>иногда проще/быстрее написать свое, чем разбираться в чужем
>> Хе… Я бы рискнул именно свой написать…
Мотивация? Тогда и c++ stdlib не используйте – пишите свой. В любой ситуации правильное решение – взвешенное решение, а не первое попавшееся. Программеры – как жеребцы – молодые, горячие, и рвутся в карьер. Я не против писать свое, но сначала – извольте обосновать. Для примера – в нашей фирме переписана с нуля реализации MFC и COM – это было вполне оправданным, т.к. проекты длятся по 5-10 лет, и самостоятельное сопровождение по расчетам менее затратно и более предсказуемо – но только в этом случае; никто и не думал писать свою реализацию JPA или Hibernate, например – оценки не в сторону “велосипеда”
Ну что все прям так серьёзно к теме диалога относятся
Я думаю мотив у тимлида один: сишники набираются под большой проект, тестовые модули как подчасти этого проекта пока обозначить невозможно, проект ещё на стадии проектирования, а люди, дабы не в пустую зарплату получают, тренируются на учебных заданиях, близких по теме. Обычное дело. И у моих дизайнеров бывают такие задачи, пусть и не столько глобальные.
верно подмечено, я сам постоянно пишу проги, аналоги которых уже есть, но зато свое родное
Если компания не маленькая, то можно писать свой компонент и использовать его, вместо того, чтобы докупать лицензии с каждым новым проектом. Хотя тут еще и от вида лицензий зависит.