1. Никто не требует от программиста знать код всего проекта, но он должен отвечать за то, что изменил. Если он изменил в одном месте, а в другом из-за этих изменений посыпалось, кто виноват? QA? Кто в первую очередь должен анализировать изменения кода?
2. Если будет в проде найден баг, а разраб скажет, что у него это не воспроизводилось, т.к. среда разработки другая, то что, не чиним баг?
3. Разработчик обязан выполнить юс кейсы из ТЗ по реализуемой задаче на своей среде разработки. Чтобы не было слез умиления или восклицаний типа «Ой...», когда грозный тестировщик поманит пальчиком крутого программиста.
На мой взгляд разработчик должен реализовать ПО по ТЗ и тестировать то, что сотворил в рамках реализации конкретной задачи.
Если разработчик отдал в отдел качества не проверенную задачу, то почти наверняка она вернется к нему со списком багов. Это так называемая «разработка через ошибки» приводит к:
— срыву сроков разработки
— низкому качеству ПО
— росту команды разработки
Понять и простить что? То, что он сделал за неделю то, а ты делаешь за день? Потому что стандартные библиотеки обладают фатальным недостатком, а свои тысячи строк такие родные?
КАК я могу это понять и простить?!
Проблема не в том, чтобы найти причины стать управленцем, а в том, что реально компетентных управленцев весьма мало и лезет в управленцы очень много шлака. Ибо для того, чтобы стать клевым управленцем большинству требуется прочитать одну клевую книжку от Брукса или Демарко, а чтобы стать всего лишь неплохим программистом нужно перелопатить кучу всего сделать.
И еще: рулят профессионалы ой как не везде. И где это видано, чтобы начальнег получал зп меньше подчиненного?
Патамушта постоянные гонки. Вот думаешь, воткну щас костыль, а потом приберусь и будет все круто. А потом… это идет в прод. Патамушта бизнес кричит давай-давай!
1. Говорить о себе в третьем лице — это сильно)))
У меня бойцов бывало и больше и это ни о чем не говорит.
2. У меня на собеседовании бывали специалисты с сертификатами. Из 5-х собеседование прошел один. Фирма на тот момент — Люксофт. Сертификаты не есть показатель…
3. Не буду спорить о целесообразности писания своего фреймворка да еще для крупного интегратора. Возможно она была, но я сильно настораживаюсь, когда говорят в ключе «не имеющий на данный момент аналогов». Еще раз напомню пример из своей жизни, когда люди, работающие на большого системного интегратора, написали свой jms. Наш с ними диалог:
Я: зачем написали свое, а не использовали то, что есть на рынке?
Они, смотрели аналоги и не понравилось.
Я: и чем ваше отличается от jms?
Они: а что это такое?
А еще они это г-внище патентуют.
Так что написание своего фреймворка без большого комьюнити не аргумент крутости. Ну по крайней мере для меня.
4. Spring JDBCTemplate разве является ORM-ом?
Чем вас не устраивают уже написанные ORM? Как много вы их посмотрели? Список не мал.
А минусуют похоже такие же велосипедисты.
Прежде, чем писать свой велосипед, изучите то, что уже сделано.
В каждом проекте находился как минимум один «изобретатель-выдумщик».
Пример №1. люди использовали spring mvc контроллер, не удосужившись изучить документацию. Результат: 2500 строк кода.
Пришел нормальный программист и переписал это. Результат: 200 строк кода при той же функциональности.
Пример №2. Люди взяли и написали свою реализацию jms. Зачем, ответить не могут. Кстати, реализовали с ошибками.
На мой взгляд, изобретать надо тогда, когда существующие решения не устраивают.
В статье описаны новые проблемы, но пути решения мягко выражаясь не новы. Ну может быть за исключением патентной системы, проблемы с которой существуют всего лишь 20 лет.
2. Если будет в проде найден баг, а разраб скажет, что у него это не воспроизводилось, т.к. среда разработки другая, то что, не чиним баг?
3. Разработчик обязан выполнить юс кейсы из ТЗ по реализуемой задаче на своей среде разработки. Чтобы не было слез умиления или восклицаний типа «Ой...», когда грозный тестировщик поманит пальчиком крутого программиста.
Если разработчик отдал в отдел качества не проверенную задачу, то почти наверняка она вернется к нему со списком багов. Это так называемая «разработка через ошибки» приводит к:
— срыву сроков разработки
— низкому качеству ПО
— росту команды разработки
КАК я могу это понять и простить?!
И еще: рулят профессионалы ой как не везде. И где это видано, чтобы начальнег получал зп меньше подчиненного?
Я понимаю, что это звучит как мы молодцы, а все другие… нехорошие. Но это не так.
Если от работы не получаешь удовлетворение, то через некоторое время начинаешь ходить на неё как на каторгу.
У меня бойцов бывало и больше и это ни о чем не говорит.
2. У меня на собеседовании бывали специалисты с сертификатами. Из 5-х собеседование прошел один. Фирма на тот момент — Люксофт. Сертификаты не есть показатель…
3. Не буду спорить о целесообразности писания своего фреймворка да еще для крупного интегратора. Возможно она была, но я сильно настораживаюсь, когда говорят в ключе «не имеющий на данный момент аналогов». Еще раз напомню пример из своей жизни, когда люди, работающие на большого системного интегратора, написали свой jms. Наш с ними диалог:
Я: зачем написали свое, а не использовали то, что есть на рынке?
Они, смотрели аналоги и не понравилось.
Я: и чем ваше отличается от jms?
Они: а что это такое?
А еще они это г-внище патентуют.
Так что написание своего фреймворка без большого комьюнити не аргумент крутости. Ну по крайней мере для меня.
4. Spring JDBCTemplate разве является ORM-ом?
Чем вас не устраивают уже написанные ORM? Как много вы их посмотрели?
Список не мал.
По мне так более логичнее предположить, что он мельком просмотрел, увидел сложность и решился создать свое с блекджеком и дамами.
Прежде, чем писать свой велосипед, изучите то, что уже сделано.
В каждом проекте находился как минимум один «изобретатель-выдумщик».
Пример №1. люди использовали spring mvc контроллер, не удосужившись изучить документацию. Результат: 2500 строк кода.
Пришел нормальный программист и переписал это. Результат: 200 строк кода при той же функциональности.
Пример №2. Люди взяли и написали свою реализацию jms. Зачем, ответить не могут. Кстати, реализовали с ошибками.
На мой взгляд, изобретать надо тогда, когда существующие решения не устраивают.
Мало того, что не подняли, еще и посмотрели как на врага.
Спрашиваю: я чем то не устраиваю? Ответ поразительный: ну ты же знал, на какую зп идешь. А прошло с момента устройства больше года.