чем труднее задачи, которые решаешь, тем больше хочется иметь инструментов со временем, а не изобретать свои.
конечно, нужно потратить время на изучение инструментария. но извините, если вы хотите решать сложнейшие задачи в мире — то, как говорится, мы за ценой не постоим.
а если такой цели нет — не нужно и брать набор инструментов для огранки статуи с точностью до микронов. возьмите обычный топор и им ебашьте в свое удовольствие.
с++ рулит.
Я вот не понимаю. Если мне нужно развлечься — я пишу на Джанге. Если нужно, чтобы было быстро и надежно — на плюсах. Если тупо и кондово, и чтобы потом легко найти разработчика на поддержку — на ПХП.
Каждый язык, технология, фреймворк — для своей цели. И для одной цели можно выбрать несколько решений, причем часто это вопрос вкуса (вот меня прет Джанго и Питон, а Руби на Рельсах я просто уважаю, но выбрал не его).
А тут — блевать их тянет, бля. Пипец, просто. А меня блевать тянет от тех, кто хорошо знает одну технологию и остальные из-за этого презирает, потому что писать на них нормально не умеет. А то говнокодеры есть и на питоне, и на яве — велкам ту говнокод.ру или thedailywtf, убедиться в этом.
Автор молодец. Написал велосипед, получил опыт, и неплохо поржал, думаю, над своим приколом. Ждем теперь пхп в перле, яве и плюсах.
теперь допустим, менеджер идет на поводу у программиста, и дает делать долго и правильно.
смотрите, я юзер — я придумал таблицу.
заказал ее — делали ее мне две недели.
за эти две недели сто раз уже передумал, как именно мне нужно, и получил СТО ПРОЦЕНТОВ не то, что нужно. и еще и долго. сказал, как нужно — опять две недели. ппц, я зол — долго и не то, программист зол — все вечно переделывать.
теперь второй вариант.
говорю — таблицу. в тот же день показали. пощупал реальные данные, покрутил — говорю, вот сюда фильтр, сюда сортировку. окей, завтра еще раз показали. мое видение эволюционирует вместе с результатами, и я счастлив — делают быстро и результат налицо. окей, наконец все окей. даю время переписать нормально — и все, отрефакторят сразу в нужный функционал, потому что видение сформировано конечное функционала. программист счастлив — его хвалят, дали переписать нормально, все востребовано.
В общем, у любой задачи есть три важных момента, которыми можно управлять.
1. Сама формулировка задачи, постановка
2. Что требуется сделать в первую очередь
3. Минимальное допустимое качество.
Вот профессиональный программист, с которым легко и хорошо работать — это тот, кто думает о всех трех. Если не думает — должен думать менеджер.
Смысл в том, что задачи менеджера и программиста в «классической» ситуации противоположны — менеджеру нужно быстро и дешево, а программисту чаще важнее правильно и качественно.
Соответственно, нужно просто находить консенсус.
Но в целом. задачи менеджера важнее, и вот почему.
Во-первых, менеджер лучше знает то, что нужно. Во-вторых, он общается с людьми, шарит в предметной области, обладает видением функционала с кучи моментов. Программист же зачастую не утруждает себя погружением в детали области и связанности (и менеджер также не доносит до него важность этих моментов).
В-третьих, за счет быстрой разработки можно в единицу времени (неделя условно) проитерировать больше раз — и следовательно, приблизиться гораздо ближе к тому, что нужно, чем если делать долго. Потому что по опыту — нихера не дают бумаги и юзкейсы так, как дают реальные данные и реальные пользователи (или очень близкое к этому).
Поэтому в идеале управление разработкой функционала простое
— сначала переформулировать задачу, чтобы уменьшить сроки
— затем получить этапы по задаче. аыбрать самое важное вперед. уменьшить сроки.
— указать, что можно сделать говнокодом первые этапы (не делать таблицу в БД — просто массив в коде, к примеру, для простых списков, и т.д.)
— заверить, что будет дано время на рефакторинг
— показать, как доводить функционал до конца.
— проитерировать сначала быстро, чтобы получить МАКСИМАЛЬНО ТОЧНОЕ НУЖНОЕ в плане функционала, затем отрефакторить.
чем труднее задачи, которые решаешь, тем больше хочется иметь инструментов со временем, а не изобретать свои.
конечно, нужно потратить время на изучение инструментария. но извините, если вы хотите решать сложнейшие задачи в мире — то, как говорится, мы за ценой не постоим.
а если такой цели нет — не нужно и брать набор инструментов для огранки статуи с точностью до микронов. возьмите обычный топор и им ебашьте в свое удовольствие.
с++ рулит.
сорри, просто не гуглил, и дописал в качестве шутки тот абзац.
Каждый язык, технология, фреймворк — для своей цели. И для одной цели можно выбрать несколько решений, причем часто это вопрос вкуса (вот меня прет Джанго и Питон, а Руби на Рельсах я просто уважаю, но выбрал не его).
А тут — блевать их тянет, бля. Пипец, просто. А меня блевать тянет от тех, кто хорошо знает одну технологию и остальные из-за этого презирает, потому что писать на них нормально не умеет. А то говнокодеры есть и на питоне, и на яве — велкам ту говнокод.ру или thedailywtf, убедиться в этом.
Автор молодец. Написал велосипед, получил опыт, и неплохо поржал, думаю, над своим приколом. Ждем теперь пхп в перле, яве и плюсах.
www.1c-bitrix.ru/blog/alexander_serbul/
он как бы был в плане, но в итерациях ЯВНО выбираем.
а если нужно — и в другие дни.
подход быстро сделать=>отрефакторить не нужен везде, но он часто помогает на этапе рывка.
смотрите, я юзер — я придумал таблицу.
заказал ее — делали ее мне две недели.
за эти две недели сто раз уже передумал, как именно мне нужно, и получил СТО ПРОЦЕНТОВ не то, что нужно. и еще и долго. сказал, как нужно — опять две недели. ппц, я зол — долго и не то, программист зол — все вечно переделывать.
теперь второй вариант.
говорю — таблицу. в тот же день показали. пощупал реальные данные, покрутил — говорю, вот сюда фильтр, сюда сортировку. окей, завтра еще раз показали. мое видение эволюционирует вместе с результатами, и я счастлив — делают быстро и результат налицо. окей, наконец все окей. даю время переписать нормально — и все, отрефакторят сразу в нужный функционал, потому что видение сформировано конечное функционала. программист счастлив — его хвалят, дали переписать нормально, все востребовано.
все гениальное — просто.
1. Сама формулировка задачи, постановка
2. Что требуется сделать в первую очередь
3. Минимальное допустимое качество.
Вот профессиональный программист, с которым легко и хорошо работать — это тот, кто думает о всех трех. Если не думает — должен думать менеджер.
Смысл в том, что задачи менеджера и программиста в «классической» ситуации противоположны — менеджеру нужно быстро и дешево, а программисту чаще важнее правильно и качественно.
Соответственно, нужно просто находить консенсус.
Но в целом. задачи менеджера важнее, и вот почему.
Во-первых, менеджер лучше знает то, что нужно. Во-вторых, он общается с людьми, шарит в предметной области, обладает видением функционала с кучи моментов. Программист же зачастую не утруждает себя погружением в детали области и связанности (и менеджер также не доносит до него важность этих моментов).
В-третьих, за счет быстрой разработки можно в единицу времени (неделя условно) проитерировать больше раз — и следовательно, приблизиться гораздо ближе к тому, что нужно, чем если делать долго. Потому что по опыту — нихера не дают бумаги и юзкейсы так, как дают реальные данные и реальные пользователи (или очень близкое к этому).
Поэтому в идеале управление разработкой функционала простое
— сначала переформулировать задачу, чтобы уменьшить сроки
— затем получить этапы по задаче. аыбрать самое важное вперед. уменьшить сроки.
— указать, что можно сделать говнокодом первые этапы (не делать таблицу в БД — просто массив в коде, к примеру, для простых списков, и т.д.)
— заверить, что будет дано время на рефакторинг
— показать, как доводить функционал до конца.
— проитерировать сначала быстро, чтобы получить МАКСИМАЛЬНО ТОЧНОЕ НУЖНОЕ в плане функционала, затем отрефакторить.
Баланс между скоростью и качеством.
просто не знают этого :)
к примеру, если каждую неделю вы пьете по бутылке пива — у вас уже — хуяк — алкоголизм!
вполне себе медицинский диагноз.
А что, звучит
Честное слово, лучше бы взяли пример и спиздили гмейл интеорфейс
В тему — я поддерживаю Тинькова больше.
Дурова не видел, но также уважаю.
У них у обоих просто нужно взять для себя лучшее.