Здравствуйте, AleksandrN, Вы писали:
AN>Ты ничего не понял из нашего диалога. AN>Вопрос "Что ты имеешь в виду" относился только к фразе "декомпозировать желаемый путь в таски", а не ко всему предложению.
Я не ответил разве на этот вопрос?
AN>1. Объясняем очень мало. Потребуется очень большая детализация задачи и много времени на решение задачи. Новичок часто будет отвлекать других разработчиков, что бы уточнить какие либо вопросы. AN>2. Долго учим, детализация потребуется меньше, времени на разработку меньше, отвлекать других разработчиков требуется меньше.
Долгое обучение неэффективно. Пока учите падавана — он забудет как код писать. А к концу обучения уже забудет про что говорили в начале. И при этом надо отвлекать от работы понимающих в проекте сотрудников на заметное время каждый день.
Выдавание же детализированных тасков будет отвлекать прочих сотрудников сильно меньше, позволит сразу получать выхлоп от падавана и вообще станет понятно быстро — обучаем ли падаван и будет ли впоследствии полезен.
Лучшее обучение чему либо — погружение в эту область. Причём не с тетрадкой и учителем, а с инструментами в руках.
AN>Оба подходы имеют плюсы и минусы. Я в своей практике сталкивался с обеими. По моему опыту, при 2-м подходе хорошее понимание проекта в целом, наступает быстрее и меньше ошибок на первоначальном этапе.
Хорошее понимание проекта будет в любом случае.
AN>Ещё заметил, что там, где предпочитали сначала научить, код был лучше структурирован и весь проект был лучше документирован.
Не вижу связи.
Здравствуйте, alex_public, Вы писали:
_>Возвращаясь к разговору, с которого началась данная дискуссия — о разных подходах к установки ПО. Так вот Линус неоднократно критически высказывался о столько любимом Шериданом подходе.
А еще Линус противник C++ и потому ядро до сих пор на C с макросами. Да и вообще, когда вижу в ядре коммиты которые добавляют по тысяче строк кода в разных файлах ради экономии 10кб размера бинарника, понимаю убыточность апелляций к авторитетам(по-крайней мере, после окончания младших классов школы).
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, Sheridan, Вы писали:
MA>>>> Не так то, что некоторые задачи неразрешимы без prior-knowledge. При чём это справедливо, даже для хорошо документированных проектов, коих, как я полагаю меньшинство. Т.е. без этих знаний ты просто работаешь как компилятор, сидишь и выполняешь семантический анализ, а логика ускользает. S>>>Некоторые. Практика же показывает, что большинство разрешимо при правильной декомпозиции. Бывает смотришь в проект и не знаешь с чего начать. Потом вгрызаешься, отбрасывая разборки с кусками проекта, явно не относящимися к задаче, через какое то время смотришь — а уже и понятно куда надо что дописать. MA>> Если всё делать идеально и правильно, то всё будет работать как часики, а новые фички добавляться без всяких трудностей. Более того, будет сразу понятно, что и куда надо дописать сразу же, только открыв папочку с проектом. В принципе это было бы возможно, если бы люди были не такими, как они есть. MA>> А пока что — иногда нужно и мат часть подучить, что бы разобраться, что бы ответить на вопрос: что и зачем или какую роль играет тот или иной код. S>Некоторые, иногда... S>Да, иногда некоторые проекты надо изучать от и до несколько месяцев. S>Такого же разряда мысль, как и у тебя, только с противоположным знаком.
Правильно. Если ты эксперт в данной предметной области — то многие или даже большинство задач становятся, или тривиальными или хотя бы прогнозируемыми.
Это работает и наоборот: Если ты не эксперт в данной области — то многие или даже большинство задач становится, или нетривиальными или вообще не прогнозируемыми.
В практическом смысле — знакомство с существующем кодом, есть частью данной предметной области. В нормальной ситуации — это вторично, особенно (но не обязательно) если ты занимаешься проектом долгое время — ты желая или не желая того его освоишь. В не очень нормальной ситуации — код сам по себе может являться проблемой, просто потому, что невозможно удовлетворить новые требования за адекватное время, выбрана дебильная архитектура, либо ещё что. Второе я вот встречал на практике, и нужно отдать должное руководству: у них хватило духа отказаться от этого говна (переведя в "легаси"), и начать поэтапно мигрировать.
Мне не понятно с чем тут можно спорить.
MA>>СтОящая имелось ввиду, что у задачи нет наперёд известного решения. MA>> Проще всего представить трудноуловимый баг (и тогда задача как минимум сводится к его ловле), хотя и новый функционал так же может быть таким. S>Баги бывали, да. Бывало несколько дней ловил. Все нервничали, но сроки увеличивали на это время
Баги — это был пример того, что проще всего представить, хотя, честно говоря, по твоей реакции — я уже начал сомневаться правильно ли ты в данном случае воспринял слово "трудноуловимый". Наверное баги — сама по себе плохая аллегория, хотя полагаю, что всем понятная. Непонятно, прежде всего потому, как он может быть связан со сроками, т.к. трудноуловимые баги — встречаются как правило в боевом примении, либо при наличии довольно дорогой (во временном эквиваленте) тестовой инфраструктуры, которой, как я предполагаю, в твоём случае быть не может. Только, не подумай, что наши баги благороднее твоих.
Но, в целом, если ты знаком с подобными проблемами, тогда мне ещё более не понятно, почему ты так отчаянно отказываешься экстраполировать свой же накопленный опыт.
MA>> И наконец: если ты соглашаешься делать задачу за неделю, очевидно, ты или заранее лукавишь (и берешься на авось), или заранее делается оценка временных затрат, но, что бы их хотя бы приблизительно сделать — нужно наперёд знать решение задачи. S>Ну я сразу говорил
— 1-3 дня на оценку
Да, и я в основном согласен с твоими оппонентами.
Прежде всего, потому, что, на своей практике — я практически всегда ошибаюсь в прогнозах. И ещё потому, что знаю, что из задачек на 1-3 дня, потом, немного позже, выплывает совсем иной масштаб. Даже во время починки тривиальных багов, нередко находятся ещё ряд связанных или несвязанных проблем, и как правило с ними тоже нужно что-то делать (хоть и немного погодя).
Здравствуйте, Mystic Artifact, Вы писали:
MA> Правильно. Если ты эксперт в данной предметной области — то многие или даже большинство задач становятся, или тривиальными или хотя бы прогнозируемыми. MA> Это работает и наоборот: Если ты не эксперт в данной области — то многие или даже большинство задач становится, или нетривиальными или вообще не прогнозируемыми.
Кэп?
MA> В практическом смысле — знакомство с существующем кодом, есть частью данной предметной области. В нормальной ситуации — это вторично, особенно (но не обязательно) если ты занимаешься проектом долгое время — ты желая или не желая того его освоишь. В не очень нормальной ситуации — код сам по себе может являться проблемой, просто потому, что невозможно удовлетворить новые требования за адекватное время, выбрана дебильная архитектура, либо ещё что. Второе я вот встречал на практике, и нужно отдать должное руководству: у них хватило духа отказаться от этого говна (переведя в "легаси"), и начать поэтапно мигрировать.
Хз. Когда мне приходит таск — я думаю и ищу пути как его решить. А не изучаю приложение в поисках косяков в архитектуре.
MA> Но, в целом, если ты знаком с подобными проблемами, тогда мне ещё более не понятно, почему ты так отчаянно отказываешься экстраполировать свой же накопленный опыт.
Да с экстраполяцией проблем нет. Проблема с тем, что я несогласен что писать таск нужно с изучения проекта в целом.
MA> Прежде всего, потому, что, на своей практике — я практически всегда ошибаюсь в прогнозах. И ещё потому, что знаю, что из задачек на 1-3 дня, потом, немного позже, выплывает совсем иной масштаб. Даже во время починки тривиальных багов, нередко находятся ещё ряд связанных или несвязанных проблем, и как правило с ними тоже нужно что-то делать (хоть и немного погодя).
Бывает иногда. Да и вообще случиться может всякое. Всё это закладывать в время таска? Давай тогда уже заложим в таск и время на выздоровление программиста если вдруг загриппует.
Здравствуйте, Sheridan, Вы писали:
AN>>2. Долго учим, детализация потребуется меньше, времени на разработку меньше, отвлекать других разработчиков требуется меньше. S>Долгое обучение неэффективно. Пока учите падавана — он забудет как код писать. А к концу обучения уже забудет про что говорили в начале. И при этом надо отвлекать от работы понимающих в проекте сотрудников на заметное время каждый день. S>Выдавание же детализированных тасков будет отвлекать прочих сотрудников сильно меньше, позволит сразу получать выхлоп от падавана и вообще станет понятно быстро — обучаем ли падаван и будет ли впоследствии полезен.
С чего ты это взял, что обучение неэффективно?
Для того, что бы выдать детализированную задачу — эту детализацию кто-то должен сделать. При чём в письменной форме. А это, может быть немалым временем.
S>Лучшее обучение чему либо — погружение в эту область. Причём не с тетрадкой и учителем, а с инструментами в руках.
Не понимаю, чем пассатижи в руках лучше акваланга? Обучение — и есть начальный этап погружения.
Условно говоря, если тебе по ошибке пришлют задачу из соседнего отдела — ты должен эту ситуацию распознать, а не реализовать у себя в проекте.
AN>>Оба подходы имеют плюсы и минусы. Я в своей практике сталкивался с обеими. По моему опыту, при 2-м подходе хорошее понимание проекта в целом, наступает быстрее и меньше ошибок на первоначальном этапе. S>Хорошее понимание проекта будет в любом случае.
Не будет даже приблизительного понимания. Будет представление о избранных кусочках и полная каша обо всём остальном.
Я по моему уже рассказывал, но может и нет. Меня как-то попросили помочь парню с одного из проектов, где я раньше был занят. Парень бился к тому моменту уже неделю, и всё никак не мог реализовать. Он поговорил со мной меньше часа и в тот же вечер у него всё получилось. А знаешь в чём секрет? В том, что, в конкретно в этом месте, я знаю не только как это работает, но и как оно должно работать, и как оно может работать и даже репортил косяки "референсной" реализации (проекта прошлого поколения). А постановщик задачи — немного наоборот, не совсем понимает то, как оно точно не должно работать. После короткого разъяснения этого печального факта, всё стало на свои места, были сформированы правильные уточняющие вопросы и дано решение. Всё. Т.е. проблема вообще-то лежала в поле знания предметной области, а правильное её решение — было изменение условий исходной задачи, а потом — её кодированию.
Здравствуйте, Sheridan, Вы писали:
I>>Ты сам говорил, что не работал с проектами большого масштаба, типа ms office. S>Чо так мелко? Сразу бери оракл или нопример гуглопоиск. Ну, чтобы наверняка.
А с чего ты взял, что гуглопоиск больше по масштабу проект, чем ms office?
Здравствуйте, Mystic Artifact, Вы писали:
S>>Выдавание же детализированных тасков будет отвлекать прочих сотрудников сильно меньше, позволит сразу получать выхлоп от падавана и вообще станет понятно быстро — обучаем ли падаван и будет ли впоследствии полезен. MA> С чего ты это взял, что обучение неэффективно? MA> Для того, что бы выдать детализированную задачу — эту детализацию кто-то должен сделать. При чём в письменной форме. А это, может быть немалым временем.
Да. И это время будет меньше, чем отвлечение этого сотрудника на обучение падавана.
S>>Лучшее обучение чему либо — погружение в эту область. Причём не с тетрадкой и учителем, а с инструментами в руках. MA>Обучение — и есть начальный этап погружения.
Нет. Обучение это не погружение. Это замещение погружения.
MA> Условно говоря, если тебе по ошибке пришлют задачу из соседнего отдела — ты должен эту ситуацию распознать, а не реализовать у себя в проекте.
Даже если я могу это реализовать?
AN>>>Оба подходы имеют плюсы и минусы. Я в своей практике сталкивался с обеими. По моему опыту, при 2-м подходе хорошее понимание проекта в целом, наступает быстрее и меньше ошибок на первоначальном этапе. S>>Хорошее понимание проекта будет в любом случае. MA> Не будет даже приблизительного понимания. Будет представление о избранных кусочках и полная каша обо всём остальном.
Внимание вопрос: нахрена забивать голову этим самым "всем остальным"?
MA> Я по моему уже рассказывал, но может и нет. Меня как-то попросили помочь парню с одного из проектов, где я раньше был занят. Парень бился к тому моменту уже неделю, и всё никак не мог реализовать. Он поговорил со мной меньше часа и в тот же вечер у него всё получилось. А знаешь в чём секрет? В том, что, в конкретно в этом месте, я знаю не только как это работает, но и как оно должно работать, и как оно может работать и даже репортил косяки "референсной" реализации (проекта прошлого поколения). А постановщик задачи — немного наоборот, не совсем понимает то, как оно точно не должно работать. После короткого разъяснения этого печального факта, всё стало на свои места, были сформированы правильные уточняющие вопросы и дано решение. Всё. Т.е. проблема вообще-то лежала в поле знания предметной области, а правильное её решение — было изменение условий исходной задачи, а потом — её кодированию.
Всё верно, таск ставить надо правильно. Неправильно поставленный таск — часто причина задержек. У меня тоже были ситуации когда я реализовываю всё что в таске написано а потом приходит заказчик (который и писал ТЗ) и говорит что вот это вот всё совершенно не то что он хочет.
Здравствуйте, _ABC_, Вы писали:
_AB>Здравствуйте, Sheridan, Вы писали:
I>>>Ты сам говорил, что не работал с проектами большого масштаба, типа ms office. S>>Чо так мелко? Сразу бери оракл или нопример гуглопоиск. Ну, чтобы наверняка. _AB>А с чего ты взял, что гуглопоиск больше по масштабу проект, чем ms office?
А с чего ты взял что нет? Или что да?
Ты читаешь буквы или смысл? Потрудись читать смысл, пожалуйста, ибо похоже что ты читаешь буквы.
Здравствуйте, Sheridan, Вы писали:
S>Ты читаешь буквы или смысл? Потрудись читать смысл, пожалуйста, ибо похоже что ты читаешь буквы.
Ты извини, конечно, но мы читаем только то, что ты пишешь. Если ты пишешь одно, а подразумеваешь другое, то у меня для тебя плохие новости — телепаты в отпуске. Потрудись писать то, что ты подразумеваешь.
Здравствуйте, Sheridan, Вы писали:
MA>> Правильно. Если ты эксперт в данной предметной области — то многие или даже большинство задач становятся, или тривиальными или хотя бы прогнозируемыми. MA>> Это работает и наоборот: Если ты не эксперт в данной области — то многие или даже большинство задач становится, или нетривиальными или вообще не прогнозируемыми. S>Кэп?
Кэп. Но ты сам начал спорить с очевидными вещами.
MA>> В практическом смысле — знакомство с существующем кодом, есть частью данной предметной области. В нормальной ситуации — это вторично, особенно (но не обязательно) если ты занимаешься проектом долгое время — ты желая или не желая того его освоишь. В не очень нормальной ситуации — код сам по себе может являться проблемой, просто потому, что невозможно удовлетворить новые требования за адекватное время, выбрана дебильная архитектура, либо ещё что. Второе я вот встречал на практике, и нужно отдать должное руководству: у них хватило духа отказаться от этого говна (переведя в "легаси"), и начать поэтапно мигрировать. S>Хз. Когда мне приходит таск — я думаю и ищу пути как его решить. А не изучаю приложение в поисках косяков в архитектуре.
Я сделал оговорку, только потому, что не могу сказать, что код вообще не важен, т.к. был в ситуациях в которых приходилось "прибираться" и не раз, но в примере выше — это как бы не моё решение. А насчет архитектуры — так специально и я ничего не выискиваю. Оно само находит.
MA>> Но, в целом, если ты знаком с подобными проблемами, тогда мне ещё более не понятно, почему ты так отчаянно отказываешься экстраполировать свой же накопленный опыт. S>Да с экстраполяцией проблем нет. Проблема с тем, что я несогласен что писать таск нужно с изучения проекта в целом.
Это возможно только в случае, когда, фактически, решение известно наперёд и оно хорошо локализовано. Решения более сложные или просто менее локализованные — требуют больших знаний о проекте.
Вот как пример у меня была задача: добавить пару фич в система разграничения доступа. При том обо всех сущностях я и понятия не имел, хотя уже и успел немного поработать с системой. Довольно быстро у меня появились вопросы, неоднозначности, я понял, что дело так не пойдет, т.к. никто конкретно не может сказать как это должно работать. В итоге, 1. пришлось создать неформальную спецификацию, 2. согласовать (с правками) и 3. воплотить. При всей казалось бы простоте задачи (которую технически было понятно как и где реализовывать), пришлось немало времени потратить именно на изучение проекта, при том, больше не на общее понимание, а на выковыривание логических связей. Да, это довольно редкий случай, и тем не менее.
Я в целом-то могу долго и нудно рассказывать, что, мол, когда начинают вот так с наскока лезть куда не надо, при чём это может быть даже очевидно, то ничего особо хорошего не происходит. Более того, чаще всего, потом приходится это переделывать. Хотя, в моём конкретном случае (из-за выделенного) — я думаю, это скорее распиздяйство.
MA>> Прежде всего, потому, что, на своей практике — я практически всегда ошибаюсь в прогнозах. И ещё потому, что знаю, что из задачек на 1-3 дня, потом, немного позже, выплывает совсем иной масштаб. Даже во время починки тривиальных багов, нередко находятся ещё ряд связанных или несвязанных проблем, и как правило с ними тоже нужно что-то делать (хоть и немного погодя). S>Бывает иногда. Да и вообще случиться может всякое. Всё это закладывать в время таска? Давай тогда уже заложим в таск и время на выздоровление программиста если вдруг загриппует. Риски должны закладыватся всегда. Кто это делает и как — это уже другой несвязанный вопрос.
Здравствуйте, Sheridan, Вы писали:
MA>> Условно говоря, если тебе по ошибке пришлют задачу из соседнего отдела — ты должен эту ситуацию распознать, а не реализовать у себя в проекте. S>Даже если я могу это реализовать? Зачем? Я предполагал что "отделы" заняты разными проектами.
AN>>>>Оба подходы имеют плюсы и минусы. Я в своей практике сталкивался с обеими. По моему опыту, при 2-м подходе хорошее понимание проекта в целом, наступает быстрее и меньше ошибок на первоначальном этапе. S>>>Хорошее понимание проекта будет в любом случае. MA>> Не будет даже приблизительного понимания. Будет представление о избранных кусочках и полная каша обо всём остальном. S>Внимание вопрос: нахрена забивать голову этим самым "всем остальным"?
Затем, что "всё остальное" — часть продукта, и эти части, ещё как-то взаимосвязаны между собой. Для хорошего понимания не нужно знать весь код наизусть и в точности знать название всех файлов в проекте. Но, надо хотя бы в общем понимать, что там есть, чего нет и что это вообще всё за штуки такие.
S>Всё верно, таск ставить надо правильно. Неправильно поставленный таск — часто причина задержек. У меня тоже были ситуации когда я реализовываю всё что в таске написано а потом приходит заказчик (который и писал ТЗ) и говорит что вот это вот всё совершенно не то что он хочет.
Конечно надо сразу всё делать правильно... В моём примере отсутствие своих знаний у разработчика серьезно затормозило процесс. А если бы он был немного поболее знаком с этой областью — скорее всего без проблем бы справился без моего вмешательства.
Здравствуйте, Sheridan, Вы писали:
S>И конечно же ты приведёшь ссылку на сферический проект, который я упомянул когда меня попросили рассказать что я имею в виду под путём и целью?
Здравствуйте, Sheridan, Вы писали:
S>С этого вообще начался этот топик. Перечитай стартовое ещё раз.
Читал. Ты там говоришь, что можешь работать вообще в любой ОС с любыми проектами в любых предметных областях. Народ, имеющий некоторый опыт в разработке, засомневался. Вполне резонно. Правда, ты там выдаешь вот такое:
А у вас же "венда, фотошоп, лайтрум и студия!". А дальше мир кончается.
Типа ты Д'Артаньян, а все остальные — фанатики.
S>Поделился. И понеслось "такого быть не может" и "да ты хернёй какойто занимаешься, не то что мы, небожители".
Я пропустил, где ты озвучиваешь методику быстрого вхождения в незнакомый проект без посторонней помощи?
S>Нет. Я просто недоумеваю. Вроде программисты, а очень на детский сад похоже и мерянье лопаточками в песочнице. У кого лопаточка длинее, тот и круче.
Ты админ. Вполне возможно, и даже скорее всего, ты знаешь работу программиста в общих чертах. Но при этом учишь разработчиков, как правильно разрабатывать. "Умные указатели — зло!" "Сетевые протоколы — под каждую задачу свой!" Про энергосберегающий код я просто молчу. А когда народ начинает задавать наводящие вопросы, оказывается, что просто либо свято веришь, либо подразумевал что-то сильно отличающееся от написанного тобой в сообщении.
S>Я делаю так: изучаю проект настолько, чтобы мне хватило знаний реализовать таск. Но не больше. Следующий таск — следующий кусок проекта.
И тебе на это хватает 2-3 дня? Или это уже после того, как ты проведешь аудит?
В процессе реализации таска такие нежданчики вылезают, что не знаешь, куда бежать.
Был у меня случай. В одном из проектов мне надо было переписать выборку данных. Тогда от древних файлов с самодельными индексами систему переводили на БД, и мне поручили делать выборку, потому что успел узнать, что должно получиться в результате и знал, как связаны данные в файлах. Заметь, я был не новичком.
Дак вот. Когда я начал, выяснилось, что некоторые из этих файлов в БД не перевели. И данные надо брать из них. Как ты считаешь, возник ли у меня какой-нибудь вопрос к руководству? Что, по-твоему, я должен был делать?
Проект начинался в 80-е. Файлы — часть "тяжелого наследия".
S>Никаких "дайте мне месяц на изучение вашего кода" — на такое мало кто идёт.
Ну, эту тему обсудили минимум дважды.
S>Если ты ещё раз перечитаешь мой пост, то, возможно, поймешь что ты ошибся.
Перечитал. Может, исходя из моего ответа, покажешь, где я ошибся?
S>Александр: [ща я тебя завалю примерами из реальных проектов, заставлю тебя выдумывать сферические решения а потом поймаю на каком нибудь слове и объявлю идиотом] сразу возникают вопросы [потому что я выдумал эти вопросы, основываясь на предполагаемых ответах]
S>Поправил. Не благодари.
Сколько раз тебя Привалов спросил «как ты умудряешься читать то, что мы тебе не пишем»? Только в этом обсуждении раз двадцать уже наверное. Вся ветка идет о реальном опыте и реальных проектах. Ты утверждаешь, что мы тупые и у нас один день уходит на git clone. Мы тебе раз за разом показываем, что это не так:
P>>Дак ведь все коллеги писали о реальных проектах, в которых участвовали. Даже я. S>А я значит не участвовал, да, о небожители?
Самый длинный проект в одиночку 4 месяца. Остальное — мелочевка на одну-две недели
В Кларне вторую версию чекаута делало 40 человек на протяжение 8 месяцев, после чего ее по сути выкинули нафиг. После этого от 20 до 40 человек на протяжение полутора лет делали версию 3. И эта версия до сих пор разрабатывается и дорабатывается, а некоторые внутренние куски переделываются мини-проектами типа «10 человек, 6-12 месяцев».
И да, Шеридан. Это именно потому, что все тупые, делают git clone одного репозитория один день, и у них нет Шеридана, который придет, за три дня во всем разберется, а за неделю все сделает.
S>Я делаю так: изучаю проект настолько, чтобы мне хватило знаний реализовать таск. Но не больше. Следующий таск — следующий кусок проекта.
Это — уровень джуниор девелопера. И через год-два такой работы, если подходы не меняются, такиех разработчиков выпинывают за дверь. По понятным всем тут, кроме тебя, причинам.
S>Никаких "дайте мне месяц на изучение вашего кода" — на такое мало кто идёт.
На такое идет любая крупная компания. Потому что иначе твое «я понял достаточно, чтобы сделать таск» легко обернется в многомиллионные убытки потому что ты понял, например, далеко не все. Или понял, но неправильно (потому что бизнес логику никто не отменял и различные бизнес-решения никто не отменял). И т.п.
Здравствуйте, Privalov, Вы писали:
S>>С этого вообще начался этот топик. Перечитай стартовое ещё раз. P>Читал. Ты там говоришь, что можешь работать вообще в любой ОС с любыми проектами в любых предметных областях. Народ, имеющий некоторый опыт в разработке, засомневался. Вполне резонно. Правда, ты там выдаешь вот такое: P>
P>А у вас же "венда, фотошоп, лайтрум и студия!". А дальше мир кончается.
P>Типа ты Д'Артаньян, а все остальные — фанатики.
Какое отношение к разраьботке имеет лайтрум? А фотошоп?
А именно этот софт начинают мне в лицо совать, когда я заговариваю про линусп на десктопах.
S>>Поделился. И понеслось "такого быть не может" и "да ты хернёй какойто занимаешься, не то что мы, небожители". P>Я пропустил, где ты озвучиваешь методику быстрого вхождения в незнакомый проект без посторонней помощи?
Почему у меня получается такое, а у вас — снет?
S>>Нет. Я просто недоумеваю. Вроде программисты, а очень на детский сад похоже и мерянье лопаточками в песочнице. У кого лопаточка длинее, тот и круче. P>Ты админ. Вполне возможно, и даже скорее всего, ты знаешь работу программиста в общих чертах. Но при этом учишь разработчиков, как правильно разрабатывать. "Умные указатели — зло!" "Сетевые протоколы — под каждую задачу свой!" Про энергосберегающий код я просто молчу. А когда народ начинает задавать наводящие вопросы, оказывается, что просто либо свято веришь, либо подразумевал что-то сильно отличающееся от написанного тобой в сообщении.
Всё что я говорю — основано на моём личном опыте.
S>>Я делаю так: изучаю проект настолько, чтобы мне хватило знаний реализовать таск. Но не больше. Следующий таск — следующий кусок проекта. P>И тебе на это хватает 2-3 дня? Или это уже после того, как ты проведешь аудит?
2-3 дня — аудит. Учу читать, дорого.
P>В процессе реализации таска такие нежданчики вылезают, что не знаешь, куда бежать.
P>Был у меня случай. В одном из проектов мне надо было переписать выборку данных. Тогда от древних файлов с самодельными индексами систему переводили на БД, и мне поручили делать выборку, потому что успел узнать, что должно получиться в результате и знал, как связаны данные в файлах. Заметь, я был не новичком. P>Дак вот. Когда я начал, выяснилось, что некоторые из этих файлов в БД не перевели. И данные надо брать из них. Как ты считаешь, возник ли у меня какой-нибудь вопрос к руководству? Что, по-твоему, я должен был делать?
Переводить файлы в БД, озвучив заказчику увеличение сроков если это необходимо.
S>>Никаких "дайте мне месяц на изучение вашего кода" — на такое мало кто идёт. P>Ну, эту тему обсудили минимум дважды.
Ваши слова не стыкуются с моим опытом. А я успел повыполнять заказы приблизительно полутора десятков кзаказчиков, у некоторых по нескольку раз.
S>>Если ты ещё раз перечитаешь мой пост, то, возможно, поймешь что ты ошибся. P>Перечитал. Может, исходя из моего ответа, покажешь, где я ошибся?
Ты решил что я написал про "их тут тысячи", тогда как я писал про "при поддержке "
Здравствуйте, Mamut, Вы писали:
M>Сколько раз тебя Привалов спросил «как ты умудряешься читать то, что мы тебе не пишем»? Только в этом обсуждении раз двадцать уже наверное. Вся ветка идет о реальном опыте и реальных проектах. Ты утверждаешь, что мы тупые и у нас один день уходит на git clone. Мы тебе раз за разом показываем, что это не так:
Ваше "не так" не стыкуется с моим опытом.
Здравствуйте, Mamut, Вы писали:
M>В Кларне вторую версию чекаута делало 40 человек на протяжение 8 месяцев, после чего ее по сути выкинули нафиг. После этого от 20 до 40 человек на протяжение полутора лет делали версию 3. И эта версия до сих пор разрабатывается и дорабатывается, а некоторые внутренние куски переделываются мини-проектами типа «10 человек, 6-12 месяцев».
M>И да, Шеридан. Это именно потому, что все тупые, делают git clone одного репозитория один день, и у них нет Шеридана, который придет, за три дня во всем разберется, а за неделю все сделает.
Странные у вас заказчики. Готовы платить годами программистам без выхлопа.
Никогда я таких сроков не видел.
Здравствуйте, Sheridan, Вы писали:
S>Какое отношение к разраьботке имеет лайтрум? А фотошоп?
В этом обсуждении ты их сюда притащил, так что вопрос — к тебе.
S>А именно этот софт начинают мне в лицо совать, когда я заговариваю про линусп на десктопах.
И про разработку?
S>Почему у меня получается такое, а у вас — снет?
Дак что у тебя получается-то? То, что я читаю в твоих сообщениях, как уже много раз повторяли, относится к мелочевке. Или уровню джуниора. Или вообще ВНЕЗАПНО™ выясняется, что речь идет о сферическом проекте.
S>Всё что я говорю — основано на моём личном опыте.
Который говорит мое, что ты никогда не работал в командах, делающих проекты чуть больше тех, что писали в 90-е на FoxPro или Clarion-е.
P>>И тебе на это хватает 2-3 дня? Или это уже после того, как ты проведешь аудит? S>2-3 дня — аудит. Учу читать, дорого.
Глянь еще раз на выделенное. А потом подумай, кого тебе нужно учить читать. Я могу подсказать. Но это будет и правда дорого.
S>Переводить файлы в БД, озвучив заказчику увеличение сроков если это необходимо.
А тут ВНЕЗАПНО™ оказывается, что есть несколько сервисов, которые все еще работают с этими файлами и которые не планируется переводить в БД. Потому что эти сервисы спустя какое-то время закроют, и эти данные станут не нужны. Но когда их закроют — зависело от многих обстоятельств. Я об этом не знал. Знал руководитель проекта, которому я задал вопрос, что бы это значило. Он мне коротко и внятно все объяснил.
S>Ваши слова не стыкуются с моим опытом. А я успел повыполнять заказы приблизительно полутора десятков кзаказчиков, у некоторых по нескольку раз.
Конкретики от тебя пока никакой. Ты попробуй, как я. К примеру: принесли мне проект А. Предметная область — Б. Требуется допилить фрагменты В, Г. Д. Объясни, как справлялся.
S>Ты решил что я написал про "их тут тысячи", тогда как я писал про "при поддержке "
Посмотри, какое заглавие ты поставил своему посту... Возможно, ты подразумевал "при поддержке". Но телепат — это положение в шахматной игре по телефону. Так что я не прочитал написанного за строкой названия.
Риски должны закладыватся всегда. Кто это делает и как — это уже другой несвязанный вопрос.
