O>Это свидетельство некомпетентности начальства. На фирме не должно быть незаменимых людей.
неужели? как насчет того, что практически все ставшие великими компании (да и все великие дела, если задуматься) двигали люди, считавшиеся (да и бывшие) не иначе как незаменимыми?
Кто не верит — могу отправить изучать литературу по вопросу. навскидку это например Jim Collins Good to Great — в основе вполне качественное и достаточное научное, с серьезным списком литературы, 5-летнее исследование на тему что есть великая компания и что помогло ей стать не просто хорошей, а великой.
Кстати, любопытно, что например такие компании как Интел, Дженерал Электрик или Кока-Кола даже не вошли в основной список по весьма строгим критериям, выбранным для определения великих компаний. MSFT в списке тоже нет Оказывается существуют настояшие суперзвезды и поярче
Интересно? Читайте книгу, если хорошо поискать можно найти в Сети в свободном доступе — рекомендую.
Убив незаменимого легко убить и все завязанное на него дело. Об этом следует всегда помнить.
Недаром поэтому везде и во все времена в первую голову стараются убить вождя, командира, просто лидера — короче максимально незаменимого человека. Даже если напала шпана и получилось вырубить главного — шансы на спасение становятся сильно выше. Без лидера даже шпана и даже на уровне двора не будет конкурентоспособной и уважаемой и ее быстро подомнут под себя в соседнем дворе. Что уж говорить о конторе... или армии, из которой удалили "незаменимых". Что там говорил Наполеон про стадо баранов?
Так может быть лучше сказать, что до тех пор пока незаменимые люди незаменимы — они не должны желать ухода\терять интерес к делу и своим служебным обязанностям? подчеркну — необходимость уйти может возникнуть всегда, равно как и трамвай из-за угла выскочить. Но выше речь о желании самих незаменимых, в т.ч. и оставаться\чувствовать себя таковыми
Вот это на мой взгляд более решабельная задача — обычно интерес к делу, которое было любимым, пропадает не сразу и не само собой, а по ряду чьих-то демотивационных (без)действий. И вот здесь уже можно соглашаться по поводу некомпетентности (как вариант нечистоплотности) начальства. А со второй половиной отцитированного выше не соглашусь, даже наоборот ибо довелось посмотреть на последствия несвоевременного избавления от незаменимых не раз и не два... результат всегда один. Киллеру скорее всего можно давать отбой
PS часто поминаемую, в т.ч. на этом форуме, незаменимость вида "наворочу-ка код понепонятнее, да еше и никому не буду ничего подсказывать\помогать — пусть-ка попробуют без меня справиться!" за незаменимость не считаю совершенно. А считаю за диверсию, саботаж и профнепригодность (не только выбравшего такую политику исполнителя). Да и просто недальновидность, граничащую с банальной глупостью
... << RSDN@Home 1.2.0 alpha 4 rev. 1138>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Здравствуйте, ononim, Вы писали:
O>Не надо никого убивать
все так говорят, особенно когда намерения самые благие И откуда столько трупов
O>Надо чтоб на достаточно важном проекте не было одного главного человека без которого проект пойдет в ...
кому надо? шефу-интригану, не научившемуся доверять людям?
заменим ли шофер за рулем школьного автобуса в проекте по доставке ребятишек в школу? А если его Кондрат хватит на скорости? Жизни и здоровье кучи детишек — это важный проект для Вас или как? Если да, нужно ли двух шоферов требовать в каждый автобус? Почему до сих пор не требуют?
да и проекты не все такие, что позволяют желаемую замену.
еще пример, важный ли проект — выиграть олимпийское золото или поставить мировой рекорд?
Где второго рекордсмена будем искать, если тут и одного-то вырастить\найти проблема?
O>Если есть такой проект — на нем должно быть не менее двух ключевых людей, т.к. человек может уйти на др работу,
давайте не будем подменять понятия на ходу. ключевой != незаменимый. напомню, речь идет о незаменимых.
Если для Вас это одно и то же — используйте термин незаменимый и посмотрите как интересно станут выглядеть Ваши собственные слова? мне кажется требование "не менее 2х незаменимых" начнет противоречить требованию "отсутствия незаменимых вообще"
O> заболеть, в конце концов его может переехать грузовик. И если изза этого пострадает проект — вина руководства, что не учли такого риска. В конце концов их задача — обеспечивать environment для проекта, а задача исполнителей — реализовывать проект. Риски — это environment.
То, что этот и другие риски нужно учитывать руководству (на всех уровнях), а также что в итоге любую вину можно повесить на него же (мол, должны были предусмотреть) — тоже ежу понятно.
Но это же никак не означает что незаменимых людей не должно быть в принципе, как класс!
Еще скажите, как тут рядом кто-то, что, мол, "все люди [должны быть] одинаковы" — и говорить дальше точно станет не о чем, можно будет предложить начать с азов и отправить читать русские народные сказки про заменимость бабки с дедкой
Ononim, мне кажется, Вы пока не совсем поняли о чем было написано. Замечу лишь, что про трамвай из-за угла у меня было особо оговорено
— ибо предвидел подобное развитие дискуссии. Возможно, это вытекает из непонимания разницы между ключевым и незаменимым, хз.
да, согласен, ключевых людей действительно может быть полный проект — и более того, в хороших проектах\устоявшихся командах в какой-то мере так даже и есть, все на своих местах и все там ключевые. И скорее всего, даже могут подменить соседа в каких-то вещах. Выше речь была о другом.
Для лучшего понимания о чем, вопросы на засып:
— Должны ли быть всегда заменимы: отец-основатель\владелец своего бизнеса\детища, автор идеи\открытия\произведения, конструктор-новатор от Бога, рекордсмен\ведущий игрок, примадонна, вождь\[духовный или еще какой] лидер, гений и т.д.?
— Должно ли их быть минимум два? Где второго брать будем? А если двое вместе уже не живут? А если двое это сверх возможностей бюджета?
Например, что Вы будете делать с Пушкиным и\или Ломоносовым на проекте?
Подозреваю, если не захочется от Пушкина с Ломоносовым зависеть, их придется убить — но Вы же, вроде, против таких методов?
PS вопросы риторические.
... << RSDN@Home 1.2.0 alpha 4 rev. 1138>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, x64, Вы писали:
x64>>А ты это вообще к чему всё?
FDS>Видимо, человек хочет обсудить отсутствие документации у себя в фирме
Здравствуйте, pashzhel, Вы писали:
P>Разработка ПО в наше время уже не требует Пушкиных и Ломоносовых, изобретать ничего не нужно.
Непонятно только, почему у одних выходит качественный продукт, а у других УГ. Учебники не те читают?
P.S. Поучительная история: был у нас по термеху курсовой, в ходе которого мы считали разные детали принтера. По учебнику. И выходили у нас стальные валы диаметром в десятки миллиметров и здоровенные шестеренки. При весьма посредственной скорости движения каретки. Однако достаточно открыть современный струйник, чтобы убедится, что одних учебников недостаточно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1138 on Windows Vista 6.1.7000.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, pashzhel, Вы писали:
P>>Разработка ПО в наше время уже не требует Пушкиных и Ломоносовых, изобретать ничего не нужно.
AVK>Непонятно только, почему у одних выходит качественный продукт, а у других УГ. Учебники не те читают?
То о чем вы говорите , это профессионализм, мастерство, опыт, но это не изобретательность, гением тут быть не нужно, просто нужно хорошо научиться выполнять операции. Это в любой инженерной профессии так и не только в инженерных. Например качественно забивать гвоздь или вкручивать шуруп не все с первого раза хорошо научились. В том же макдональдсе, где по сути вообще можно быть "тупым роботом", в первый день врятли вы сможете делать работу так как делают это люди с опытом, но это не Ломоносовы.
AVK>P.S. Поучительная история: был у нас по термеху курсовой, в ходе которого мы считали разные детали принтера. По учебнику. И выходили у нас стальные валы диаметром в десятки миллиметров и здоровенные шестеренки. При весьма посредственной скорости движения каретки. Однако достаточно открыть современный струйник, чтобы убедится, что одних учебников недостаточно.
Если я правильно понял вы говорите о расхождении теории в учебниках от практики. Только тут вы учтите что в учебниках как правило достаточно грубая модель представляется и достаточно грубые приближения отличающиеся при сложных инженерных расчетах которые бы применялись при создании конечного устройства. Но инженер он сам формулы не изобретает, он пользуется готовыми, просто учитывает больше факторов чем это делается в школе или институте на занятиях.
В компании B из города N, программист решил уволится, приходит к директору и говорит — Я увольняюсь сегодня же...
В продукт над котором работает программист вложено много денег и директор поразмыслив говорит — Дешевле будет киллера нанять, чем переделывать то что ты сделал...
Не будем обсуждать организацию работы и передачу знаний, системы CMMI и т.п. В жизни по разному бывает.
Реально такие слова слышал пока что в полушутку, но и в полусерьез.
ononim пишет: > > > Это свидетельство некомпетентности начальства. На фирме не должно быть > незаменимых людей.
Это хотелось бы, конечно. И таки будет, если фирма — чисто аутсорс,
покодили для очередного заказчика и забыли. А вот если фирма пытается
делать что-то свое, вот тут-то и появятся незаменимые, или не появится
продукта.
VAB>- Должно ли их быть минимум два? Где второго брать будем? А если двое вместе уже не живут? А если двое это сверх возможностей бюджета?
VAB>Например, что Вы будете делать с Пушкиным и\или Ломоносовым на проекте?
VAB>Подозреваю, если не захочется от Пушкина с Ломоносовым зависеть, их придется убить — но Вы же, вроде, против таких методов?
Разработка ПО в наше время уже не требует Пушкиных и Ломоносовых, изобретать ничего не нужно. Нужно просто знать то что уже описано в учебниках, документации и применять на практике. Студенты часто путают незнание и изобретательность. Начинают от незнания изобретать велосипед, считая себя Ломоносовым. Изобретательность в данном случае лежит на тех кто инициирует проект, собственно генерит концепцию программного продукта. В комерческих проектах иметь в штате разработчиков Ломоносовых с Пушкиным не целесообразно, из пушки по воробьям называется.
Конечно есть исследовательские проекты, направленые на разработку новых языков, алгоритмов и.т.п., там генератор идей может оказаться уникальным и незаменимым. Но много ли считающих себя Ломоносовыми работают именно в этом направлении ? Во вторых, даже если человек работает в данном направлении это еще не значит что он может считать Ломоносовым, вот когда получит результат, откроет что-то новое, создаст достижение для человечества вот тогда да, поставим памятник.
Здравствуйте, Micker, Вы писали:
M>Здравствуйте, Micker, Вы писали:
M>>По моему у этой книги выходил перевод на русском. Кто-нибудь помнит?
M>Ну конечно, Джим Коллинз "От хорошего к великому"
Здравствуйте, pashzhel, Вы писали:
AVK>>Непонятно только, почему у одних выходит качественный продукт, а у других УГ. Учебники не те читают? P>То о чем вы говорите , это профессионализм, мастерство, опыт, но это не изобретательность
Это все очень расплывчатые термины. По факту нужно как минимум инженерное чутье, а это не учебники совсем.
P>, гением тут быть не нужно
То есть все, что чуть больше "просто знать то что уже описано в учебниках, документации и применять на практике" это уже гениальность?
P>, просто нужно хорошо научиться выполнять операции. Это в любой инженерной профессии так
Это в любой инженерной профессии не так. Куда не примени твой подход, на выходе получается все то же УГ.
P>Если я правильно понял вы говорите о расхождении теории в учебниках от практики.
Нет, не правильно. Фокус в том, что нет в учебниках единственного правильного ответа. Везде есть trade off между кучей параметров и противоречивых требований. И найти золотую середину — в этом и состоит задача настоящего инженера, а не попки-репитера.
P> Только тут вы учтите что в учебниках как правило достаточно грубая модель представляется и достаточно грубые приближения
Никакое огрубление не способно привести в ошибке на порядок. Дело не в точности модели.
... << RSDN@Home 1.2.0 alpha 4 rev. 1138 on Windows Vista 6.1.7000.0>>
Оглянись вокруг, их масса. Вон, по улице масса стареньких жигуленков бегает. Вот их как раз проектировали люди, которых не взяли в ВПК, по учебникам.
P> То есть по вашему чтобы было не УГ нужно изобретать что-то новое
Повторюсь, "изобретать" термин весьма неопределенный. Но чтобы было не УГ учебников недостаточно, это точно.
P>Скорее это минус для проекта когда программист вместо того чтобы взять готовый алгоритм или паттерн начинает сам что-то "изобретать"
"Алгоритм или паттерн" это самый низкий уровень принятия решения. Но и на нем есть масса вещей, которые в учебниках не описаны. Паттерн, к примеру, это тоже уже принятое решение, а не некая оптимальная данность, выбираемая по учебнику.
А на уровнях повыше все становится намного неопределеннее.
P>, как правило это незнание алгоритма или паттерна приводит только к лишней трате времени и худшему качеству
Это само собой. Проблема в том, что знание алгоритма или паттерна еще ничего не гарантирует.
P>Ну сантехник когда выбирает позицию для унитаза тоже ищет золотую середину
У него пространство решений на два порядка меньшей размерности.
P>Ну надеюсь вы не хотите сказать что принтеры не подчиняются законам механики ?
Нет, я всего лишь хочу сказать, что учебника недостаточно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1138 on Windows Vista 6.1.7000.0>>
Здравствуйте, novako, Вы писали:
N>Реально такие слова слышал пока что в полушутку, но и в полусерьез.
Это он никогда киллера не нанимал. Услуги киллера, если это не подзаборный синяк, который сдаст тебя еще до того как выполнит работу, стоят весьма изрядно. Никакой программист столько не зарабатывает.
Здравствуйте, novako, Вы писали:
N>В компании B из города N, программист решил уволится, приходит к директору и говорит — Я увольняюсь сегодня же... N>В продукт над котором работает программист вложено много денег и директор поразмыслив говорит — Дешевле будет киллера нанять, чем переделывать то что ты сделал... N>Не будем обсуждать организацию работы и передачу знаний, системы CMMI и т.п. В жизни по разному бывает. N>Реально такие слова слышал пока что в полушутку, но и в полусерьез.
N>В компании B из города N, программист решил уволится, приходит к директору и говорит — Я увольняюсь сегодня же... N>В продукт над котором работает программист вложено много денег и директор поразмыслив говорит — Дешевле будет киллера нанять, чем переделывать то что ты сделал... N>Не будем обсуждать организацию работы и передачу знаний, системы CMMI и т.п. В жизни по разному бывает. N>Реально такие слова слышал пока что в полушутку, но и в полусерьез.
Не надо никого убивать
Надо чтоб на достаточно важном проекте не было одного главного человека без которого проект пойдет в ...
Если есть такой проект — на нем должно быть не менее двух ключевых людей, т.к. человек может уйти на др работу, заболеть, в конце концов его может переехать грузовик. И если изза этого пострадает проект — вина руководства, что не учли такого риска. В конце концов их задача — обеспечивать environment для проекта, а задача исполнителей — реализовывать проект. Риски — это environment.
Как много веселых ребят, и все делают велосипед...
VAB>[q]Кто не верит — могу отправить изучать литературу по вопросу. навскидку это например Jim Collins Good to Great — в основе вполне качественное и достаточное научное, с серьезным списком литературы, 5-летнее исследование на тему что есть великая компания и что помогло ей стать не просто хорошей, а великой.
По моему у этой книги выходил перевод на русском. Кто-нибудь помнит?
VAB>PS часто поминаемую, в т.ч. на этом форуме, незаменимость вида "наворочу-ка код понепонятнее, да еше и никому не буду ничего подсказывать\помогать — пусть-ка попробуют без меня справиться!" за незаменимость не считаю совершенно. А считаю за диверсию, саботаж и профнепригодность (не только выбравшего такую политику исполнителя). Да и просто недальновидность, граничащую с банальной глупостью
А что нужно делать что бы быть незаменимым?
Жизнь, как игра —
идея паршивая,
графика обалденная...
Здравствуйте, Micker, Вы писали:
VAB>>[q]Кто не верит — могу отправить изучать литературу по вопросу. навскидку это например Jim Collins Good to Great
M>По моему у этой книги выходил перевод на русском. Кто-нибудь помнит?
так точно. "От хорошего к великому". У автора есть и еще одна книга, про то как строить на века
M>А что нужно делать чтобы быть незаменимым?
Если честно, мне кажется здесь все как в футболе: кто-то берет талантом, кто-то упорством. Кто-то скоростью, а кто-то ростом. кто-то сумасшедшим ударом, а кто-то дриблингом. Кто-то хитростью, а кто-то наглостью. Кто-то жестокостью\грубостью, а кто-то самоотверженностью\отвагой. Кто-то светлой головой.... А кто-то тренеру зять или президенту клуба сын
Нет у меня серебрянного ответа, короче. Да и так ли уж нужно всем быть незаменимыми? Это ведь за собой потянет и определенную ответственность, обязательства, в т.ч. и моральные, и так далее — не каждому это нужно. Многие даже осознанно избегают.
Так что вопросы нужно ставить другие, например, что нужно делать, чтобы стать талантливым? Боюсь, не открою тут секрета — таким просто нужно родиться Но даже родившись очень талантливым, чтобы родить что-то стоящее, предложить что-то людям и убедить их в том что им это нужно и вы знаете как этого добиться — то, как правило, нужно еще и много учиться и честно, на совесть, трудиться. Зато уж это мы все точно можем делать
Есть и еще одна хорошая новость — что большинство из нас на самом деле именно такими, т.е. в достаточной мере талантливыми, и родились! Просто нужно правильно определить свои таланты, к чему лежит душа — и развивать именно их, не идти наперекор себе. Ибо не стоит сажать пальмы в Арктике, а пингвинов выгуливать в Африке — не приживутся.
И тогда при определенном старании и труде все остальное, включая мифическую незаменимость, на определенном этапе приложится и придет, не сомневайтесь!
... << RSDN@Home 1.2.0 alpha 4 rev. 1138>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, novako, Вы писали:
N>>Реально такие слова слышал пока что в полушутку, но и в полусерьез.
M>Это он никогда киллера не нанимал. Услуги киллера, если это не подзаборный синяк, который сдаст тебя еще до того как выполнит работу, стоят весьма изрядно. Никакой программист столько не зарабатывает.
Да фирма разрабатывает что то свое. Да бюджет весьма ограничен. Не получается иметь двух людей на тоже важной задаче, потому они все (задачи) важные. В проект вложены большие деньги за долгое время, так уж получилось.
Здравствуйте, Valery A. Boronin, Вы писали:
O>>Это свидетельство некомпетентности начальства. На фирме не должно быть незаменимых людей. VAB>неужели? как насчет того, что практически все ставшие великими компании (да и все великие дела, если задуматься) двигали люди, считавшиеся (да и бывшие) не иначе как незаменимыми? VAB>[q]Кто не верит — могу отправить изучать литературу по вопросу. навскидку это например Jim Collins Good to Great — в основе вполне качественное и достаточное научное, с серьезным списком литературы, 5-летнее исследование на тему что есть великая компания и что помогло ей стать не просто хорошей, а великой.
Мммм.... а ты точно хорошо понял идею книги? Туда MSFT и прочие не вошли ровно потому, что существуют слишком мало. А долгоживущие компании рассматривались только потому, что хотели смотреть только на те компании, где гарантировано сменились люди просто с течением времени, но при этом компания осталась великой. Т.е. в велчии виновата именно корпкультура, а не конкретные люди. У этого же автора есть книга "построенные навечно" которая этот вопрос обсуждает более углубленно.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, novako, Вы писали:
N>>>Реально такие слова слышал пока что в полушутку, но и в полусерьез.
M>>Это он никогда киллера не нанимал. Услуги киллера, если это не подзаборный синяк, который сдаст тебя еще до того как выполнит работу, стоят весьма изрядно. Никакой программист столько не зарабатывает.
N>Да фирма разрабатывает что то свое. Да бюджет весьма ограничен. Не получается иметь двух людей на тоже важной задаче, потому они все (задачи) важные. В проект вложены большие деньги за долгое время, так уж получилось.
Ну долю в фирме дать всяко дешевле(возможно не в деньгах) чем киллера нанять.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, Anatolix, Вы писали:
A>Мммм.... а ты точно хорошо понял идею книги? Туда MSFT и прочие не вошли ровно потому, что существуют слишком мало.
прекрасно все помню, в т.ч. и почему там нет MSFT — разве я где-то сказал что-то про них?
просто отметил, что их нет в списке — с целью заинтересовать потенциальных читателей
A>А долгоживущие компании рассматривались только потому, что хотели смотреть только на те компании, где гарантировано сменились люди просто с течением времени, но при этом компания осталась великой. Т.е. в велчии виновата именно корпкультура, а не конкретные люди. У этого же автора есть книга "построенные навечно" которая этот вопрос обсуждает более углубленно.
идей и пищи для размышлений в книге достаточно. есть что пообсуждать. корпкультуру же создают вполне конкретные люди и там это неплохо показано на примере компаний, где были во главе незаменимые, но не озаботившиеся грамотной подготовкой (в духе созданной в компании философии и корпкультуры если угодно) преемников кадры.
... << RSDN@Home 1.2.0 alpha 4 rev. 1138>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
...
V>Up. Предложение убрать программиста ещё в силе?
Кризис? Уволили?
Сообщение заговорено потомственным колдуном, целителем и магом в девятом поколении!
Модерирование или минусование сообщения ведет к половому бессилию, венерическим заболеваниям, венцу безбрачия и диарее!
Здравствуйте, Vladek, Вы писали:
V>Здравствуйте, novako, Вы писали:
N>>В компании B из города N, программист решил уволится, приходит к директору и говорит — Я увольняюсь сегодня же... N>>В продукт над котором работает программист вложено много денег и директор поразмыслив говорит — Дешевле будет киллера нанять, чем переделывать то что ты сделал... N>>Не будем обсуждать организацию работы и передачу знаний, системы CMMI и т.п. В жизни по разному бывает. N>>Реально такие слова слышал пока что в полушутку, но и в полусерьез.
V>Up. Предложение убрать программиста ещё в силе?
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, pashzhel, Вы писали:
AVK>>>Непонятно только, почему у одних выходит качественный продукт, а у других УГ. Учебники не те читают? P>>То о чем вы говорите , это профессионализм, мастерство, опыт, но это не изобретательность
AVK>Это все очень расплывчатые термины. По факту нужно как минимум инженерное чутье, а это не учебники совсем.
P>>, гением тут быть не нужно AVK>То есть все, что чуть больше "просто знать то что уже описано в учебниках, документации и применять на практике" это уже гениальность?
нет
P>>, просто нужно хорошо научиться выполнять операции. Это в любой инженерной профессии так AVK>Это в любой инженерной профессии не так. Куда не примени твой подход, на выходе получается все то же УГ.
Примеры ? То есть по вашему чтобы было не УГ нужно изобретать что-то новое или плохо выполнять свои операции ?
Скорее это минус для проекта когда программист вместо того чтобы взять готовый алгоритм или паттерн начинает сам что-то "изобретать", как правило это незнание алгоритма или паттерна приводит только к лишней трате времени и худшему качеству, в результате чего УГ и получается.
P>>Если я правильно понял вы говорите о расхождении теории в учебниках от практики.
AVK>Нет, не правильно. Фокус в том, что нет в учебниках единственного правильного ответа. Везде есть trade off между кучей параметров и противоречивых требований. И найти золотую середину — в этом и состоит задача настоящего инженера, а не попки-репитера.
Ну сантехник когда выбирает позицию для унитаза тоже ищет золотую середину, но можно ли его назвать гением или Ломонсовым если унитаз встал успешно ?
P>> Только тут вы учтите что в учебниках как правило достаточно грубая модель представляется и достаточно грубые приближения
AVK>Никакое огрубление не способно привести в ошибке на порядок. Дело не в точности модели.
Ну надеюсь вы не хотите сказать что принтеры не подчиняются законам механики ? Все там работает и расчитано по известным законам и принципам, то что у вас получилась шестеренка монстр говорит о том что либо модель была грубая, либо начальные условия заданы не совсем корректно.
Здравствуйте, pashzhel, Вы писали:
P>Скорее это минус для проекта когда программист вместо того чтобы взять готовый алгоритм или паттерн начинает сам что-то "изобретать" [...]
Что такое "взять готовый паттерн"?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, pashzhel, Вы писали:
AVK>>Непонятно только, почему у одних выходит качественный продукт, а у других УГ. Учебники не те читают? P>То о чем вы говорите , это профессионализм, мастерство, опыт, но это не изобретательность, гением тут быть не нужно, просто нужно хорошо научиться выполнять операции.
Какие именно операции нужно научиться хорошо выполнять, чтобы получался качестенный софт?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, pashzhel, Вы писали:
AVK>>>Непонятно только, почему у одних выходит качественный продукт, а у других УГ. Учебники не те читают? P>>То о чем вы говорите , это профессионализм, мастерство, опыт, но это не изобретательность, гением тут быть не нужно, просто нужно хорошо научиться выполнять операции.
ГВ>Какие именно операции нужно научиться хорошо выполнять, чтобы получался качестенный софт?
Например если мы говорим о роли программиста , то в данном случае можно представить разработку некой фичи следюущими операциями :
1. Анализ задачи
1.1 Проверка на реализуемость/непротиворечивость ( иметь представление о реализованном функционале, проверка совместимости фичи с существующим функционалом )
1.2 Выбор паттерна/алгоритма для решения ( знать паттерны, алгоритмы )
1.3 Оценка трудоемкости ( иметь опыт написания подобных решений для предварительной оценки )
2. Кодирование
2.1 Написание кода ( нужно знать язык программирования , корпоративные стандарты к оформлению кода )
2.2 Отладка ( нужно знать технологии отладки и применять их в соотвествии с ситуацией )
3. Документирование
3.1 Написание комментариев к коду
3.2 Дополнение руководства пользователя
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, pashzhel, Вы писали:
P>>Скорее это минус для проекта когда программист вместо того чтобы взять готовый алгоритм или паттерн начинает сам что-то "изобретать" [...]
ГВ>Что такое "взять готовый паттерн"?
паттерн = шаблон решения.
Например в документации к API или Examples приведен пример асинхронной работы с сокетом, программист от незнания , начинает сам экспериментировать с функциями API пытаясь добиться ожидаемого результата — пример плохой работы и производства УГ.
Есть паттерны проектирования и т.п. в любом собственно деле всегда есть шаблоны или примеры успешной реализации чего либо. Даже у сапожника.
Здравствуйте, pashzhel, Вы писали:
P>>>Скорее это минус для проекта когда программист вместо того чтобы взять готовый алгоритм или паттерн начинает сам что-то "изобретать" [...]
ГВ>>Что такое "взять готовый паттерн"?
P>паттерн = шаблон решения.
P>Например в документации к API или Examples приведен пример асинхронной работы с сокетом, программист от незнания , начинает сам экспериментировать с функциями API пытаясь добиться ожидаемого результата — пример плохой работы и производства УГ.
От незнания — это как? От нечтения документации?
P>Есть паттерны проектирования и т.п. в любом собственно деле всегда есть шаблоны или примеры успешной реализации чего либо. Даже у сапожника.
Вот про паттерны проектирования как раз и хотелось бы поговорить. Как их можно применять? Пример с документаций в данном случае не совсем подходящий — API подразумевает достаточно жёстко закреплённый порядок использования, на то он и API.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, pashzhel, Вы писали:
ГВ>>Какие именно операции нужно научиться хорошо выполнять, чтобы получался качестенный софт? P>Например если мы говорим о роли программиста , то в данном случае можно представить разработку некой фичи следюущими операциями : [...]
P>Как пример, не претендует на полноту.
Подходит. Но раз я спрашивал про хорошее выполнение операций, давай разберёмся с тем, что такое хорошо, и что такое плохо. Расскажи, пожалуйста, об этом применительно к п.п. 1.2, 2.1 и 3.1 (можно один любой по твоему выбору). Только давай так: не нужно рассказывать про то, как бывает "плохо", расскажи только о том, что "хорошо". И не забывай, что на выходе должен получиться качественный софт.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, pashzhel, Вы писали:
ГВ>>>Какие именно операции нужно научиться хорошо выполнять, чтобы получался качестенный софт? P>>Например если мы говорим о роли программиста , то в данном случае можно представить разработку некой фичи следюущими операциями : [...]
P>>Как пример, не претендует на полноту.
ГВ>Подходит. Но раз я спрашивал про хорошее выполнение операций, давай разберёмся с тем, что такое хорошо, и что такое плохо. Расскажи, пожалуйста, об этом применительно к п.п. 1.2, 2.1 и 3.1 (можно один любой по твоему выбору). Только давай так: не нужно рассказывать про то, как бывает "плохо", расскажи только о том, что "хорошо". И не забывай, что на выходе должен получиться качественный софт.
По некоторым пунктам могу осветить из своего опыта:
1.2 Выбор паттерна/алгоритма для решения ( знать паттерны, алгоритмы )
Для решения любой задачи есть оптимальное решение. Например, та же сортировка. Есть пузырьковая сортировка, а есть более быстрые способы. Если идет работа с большим набором данных, то эффективный с точки зрения производительности выбор метода реализации задачи сортировки оказывает весьма ощутимый эффект.
Как это влияет на качество продукта. В зависимости от поставленных задач, тут могут быть 2 направления: решение легче реализуемо и/или решение является более эффективным с точки зрения работоспособности системы.
В первом случае, человек, выбравший более оптимальное решение сэкономит время, которое можно потратить на кучу разных вещей, как отладка, оформление и документирование решения. Во втором случае, на выходе получается компонент, который работает быстрее, работает стабильнее в условиях разрабатываемой системы, более пригоден для использования в других аналогичных участках разрабатываемого приложения.
В результате, экономится время при дальнейшей разработке, экономится время для поддержки данного решения, так как изменения уже можно внести только в одно место.
2.1 Написание кода ( нужно знать язык программирования , корпоративные стандарты к оформлению кода )
Тут всё детально указано. Есть общепринятые стандарты написания программного кода. Для многих языков есть озвученные стандарты. Более того, есть средства, которые проверяют автоматически на соответствие кода стандартам (например, JLint, pylint ). Так вот, чем меньше подобные штуки ругаются, тем ближе состояние "хорошо". Другой момент, зачастую в коде много warnings, которые могут и ничего не портить, но как минимум засоряют эфир. "Хорошо" — это когда количество подобных warnings стремится к 0, а то и равно.
И в контексте разработки качественного продукта это в первую очередь оказывает влияние на удобство чтения ( а когда работает несколько человек, то так или иначе чужой код приходится читать и вносить правки ).
3.1 Написание комментариев к коду
Есть куча готовых решений для генерации документации из исходников ( javadoc, perldoc, phpdoc, jsdoc ). В результате получается т.н. API-документация, которую могут читать другие. Более того, в том же Eclipse при наведении на метод высвечивается текст, который был внесен в коментарии к данному методу и человек может понять, для чего этот метод используется. Такое же наблюдалось и в Visual Studio. В результате сам факт наличия такой возможности уже упрощает работу и экономит время. Что же здесь может быть "хорошо". Опять же, описание комментариев частично озвучивается в стандартах. В частности как раз уделяется внимание к комментариям-заголовкам функций, классов, методов. В частности указываются реквизиты, которые делают комментарии информативными. В частности, очень хорошо, если для нетривиальных методов помимо описания есть еще и примеры использования. Это упрощает в том плане, что уже изначально можно увидеть, как этот метод/класс используется и получить базовый рабочий пример. То есть, меньше времени тратится на копание в коде, а также снижает возможность некорректного использования разработанного компонента.
Эти пункты можно выразить через метрики, если так не слишком ясно. Но очень многое упирается на экономию времени без снижения качества (а то и с повышением), хотя время — это не единственный показатель.
Оказывается существуют настояшие суперзвезды и поярче
ибо довелось посмотреть на последствия несвоевременного избавления от незаменимых не раз и не два... результат всегда один. Киллеру скорее всего можно давать отбой 
