Программеры-7

— Зачем писать свой тулкит, если купили вот уже, готовый, работающий?!
— Ну так он глючный, не гибкий, вы напишите свой, крутой, знаменитыми станете.
— Да поспорю на лимон, что то, что здесь напишем, всё равно будет голимее!
— Зато так досконально разберётесь в теме, что сможете спорить с разработчиками “того” тулкита обоснованно! Типа… “а мы знаем, почему у вас там-то не работает! У нас там тоже поэтому же не работает…”
— И всё равно не понимаю, зачем изобретать велосипед…
— Ну дык! Тот же 2-х колёсный. А этот — 2,5 колёсный!

P.S. Предыдущие – “Программеры-6

RSS feed | Trackback URI

10 Comments »

Comment by Anton Naumov
2008-08-16 08:43:35

а кто из собеседников кто? на самом деле одна из отличительных особенностей “сурового” профессионала АКА честного сеньйора в том, что он не загорается идеей написать заново все фрэймворки, которые уже существуют. дивесификация рисков и распределение отвественности, так сказать.

Comment by nundesign
2008-08-16 15:22:01

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

 
 
Comment by scratch613
2008-08-16 10:31:05

Это “смена ролей”?
Очень похоже :)

 
Comment by kolya
2008-08-20 13:21:52

иногда проще/быстрее написать свое, чем разбираться в чужем

Comment by Anton Naumov
2008-08-20 23:54:22

сколько времени и ресурсов Вы потратите в дальнешем, на поддержку и улучшение этого “своего”?
также всегда следует помноить, что в случае использования строннего фреймворка все риски, связанные с недостаточным функционалом или ошибками в продукте несет разработчик стронней библиотеки, в случае “своего ” — только сама контора. тоже верно и для рисков, связанных с поддержкой и улучшением.
так как, по-прежнему проще/быстрее?

 
 
Comment by Dexter
2008-08-24 22:39:20

Хе… Я бы рискнул именно свой написать…

 
Comment by yuri veretelnikov
2008-09-01 15:50:46

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

На самом деле это вопрос неоднозначный – и решается ТОЛЬКО через учет всех факторов, взвешивание рисков как самостоятельной разработки, так и использования продукта “со стороны”, и никак иначе; смотреть на все с одной стороны ни к чему хорошему не приведет.

>>иногда проще/быстрее написать свое, чем разбираться в чужем
>> Хе… Я бы рискнул именно свой написать…

Мотивация? Тогда и c++ stdlib не используйте – пишите свой. В любой ситуации правильное решение – взвешенное решение, а не первое попавшееся. Программеры – как жеребцы – молодые, горячие, и рвутся в карьер. Я не против писать свое, но сначала – извольте обосновать. Для примера – в нашей фирме переписана с нуля реализации MFC и COM – это было вполне оправданным, т.к. проекты длятся по 5-10 лет, и самостоятельное сопровождение по расчетам менее затратно и более предсказуемо – но только в этом случае; никто и не думал писать свою реализацию JPA или Hibernate, например – оценки не в сторону “велосипеда”

Comment by nundesign
2008-09-01 15:57:39

Ну что все прям так серьёзно к теме диалога относятся :)
Я думаю мотив у тимлида один: сишники набираются под большой проект, тестовые модули как подчасти этого проекта пока обозначить невозможно, проект ещё на стадии проектирования, а люди, дабы не в пустую зарплату получают, тренируются на учебных заданиях, близких по теме. Обычное дело. И у моих дизайнеров бывают такие задачи, пусть и не столько глобальные.

 
 
Comment by Фёдор
2008-10-29 12:55:38

верно подмечено, я сам постоянно пишу проги, аналоги которых уже есть, но зато свое родное

 
Comment by dmodeus Subscribed to comments via email
2009-02-05 17:10:55

Если компания не маленькая, то можно писать свой компонент и использовать его, вместо того, чтобы докупать лицензии с каждым новым проектом. Хотя тут еще и от вида лицензий зависит.

 
Name (required)
E-mail (required - never shown publicly)
URI
Subscribe to comments via email
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> in your comment.