4802 читателя, 382 поста
Администрация
Модераторы
Хотелось бы, чтобы в этом блоге появились статьи и заметки о том, как работать быстро и правильно, затрачивая минимум усилий. И при этом обойтись без цитирования GTD, разумеется.
Учись Работать whois
- индекс
- 233,03
3 простых правила, которые сделают из вас Суперзвезданутого Программиста
Я верен, что вы уже читали пост Джоэля о том, что 1% разработчиков в 10 раз продуктивней всех остальных; про разработчиков-суперзвезд; тех, только которых и стоит нанимать. Вы знаете, что вы умеете программировать, что вы умный и талантливый, но – этого недостаточно. Вы хотите быть в 10 раз продуктивней, чем все остальные в вашей компании? Вы хотите быть гуру, к которому приходят все, когда у них возникает проблема; гуру, которому достаточно лишь мельком взглянуть на проблему и лишь взмахнуть пальцем, чтобы решить ее?
И вы можете! Следуйте следующим 3-м простым правилам, и в течение 12 месяцев все это и многое другое будет вашим.
Правило 1: Пишите много кода. Вам нужно исправить небольшую ошибку на участке кода, написанного кем-то другим? Не теряйте времени, пытаясь понять код или мотивацию человека, создавшего его. Просто перепишите большую его часть, и сделайте, чтобы код работал так, как это удобно вам. Назовите это рефакторингом, если, вдруг, кто-то спросит.
Правило 2: Пишите код быстро. Затроньте наибольшее количество файлов, и не забудьте включить каждый из них в ChangeLog. Не беспокойтесь о случайном создании трудно находимых ошибок; они помогут вам в будущем, потому что их, на самом деле, трудно найти. Избегайте создания тривиальных ошибок.
Правило 3: Не тратьте время для документирование кода, или добавления небольших комментариев, объясняющих потенциальные ловушки, связанные с изменением нечетких участков кода. Вам это не нужно – вы пишете код.
Усердно следуйте этим трем правилам – и вы станете суперзвездой вашей команды в течение 12 месяцев. Выпишете их и приклейте на видном месте. Только не в офисе! А где-нибудь в скрытом от посторонних глаз месте. И повторяйте их каждый день, перед началом работы. Они могут показаться вам спорными, но поверьте мне, все это имеет очень глубокий смысл.
Вы задаете вопрос: откуда я знаю, что это работает? – Потому что я сделал это сам, и потому, что я видел, как это делают другие. Конечно, я не понимал, что придерживался Трех правил – в то время, я был молодым и наивным и думал, что я просто пытаюсь сделать все возможное для проекта. И только теперь, спустя много лет, опираться на мудрость и опыт, я могу вот так просто поделиться ими с вами.
Система 3-х Великих Правил Программирования основана на Двух Фундаментальных Принципах: техническом и социальном.
Технический принцип: Вы работаете в 10 раз продуктивней над вашим кодом, по сравнению с тем кодом, который писали не вы.
Каждый понимает свой собственный код лучше. Это часть вашей памяти, часть ваших соглашений — весть этот код соответствует вашим убеждениям. Вы знаете, как работает функция, которая называется X и знаете все тонкости ее работы. Вы смотрите в класс Y, чтобы найти вашу функциональность и, конечно же, она там есть. Даже если вы находитесь в нижней части файла, вы прекрасно знаете какой код находиться сверху. Все эти мелкие детали понятны вам. Теперь вам не нужно так беспокоиться о случайных побочных эффектах, когда вы что-то изменили, потому что вы помните о тех местах, которые были немного рискованными и интуитивно знаете, где вы можете писать код небрежно, а где – нет.
Короче говоря: если вы написали код, у вас есть почти идеальная модель кода в вашей голове, потому что это то, что вы использовали, чтобы написать его.
Социальный принцип: то, насколько хороши вы в программировании, судят по тому, сколько строчек кода вы написали, насколько быстро вы можете завершить необходимые фичи и пофиксить критические баги, и насколько ваше понимание сути дела необходимо для решения проблем.
Эти два принципа определяют пространство задачи – или, как мы называем это – Игру. Вы победите, если улучшите свою репутацию суперзвезды до уровня гуру. Чтобы улучшить свою репутацию, вам нужно увеличить скорость, с которой вы пишете код, исправляете ошибки и помогаете другим. Технический принцип говорит нам о том, как достичь этого — работайте в своем собственном коде как можно больше. Именно так, захватывайте как можно большую часть проекта своим собственным кодом.
Система 3-х правил – это безупречная стратегия для достижения этой цели.
Следуя правилу 1, вы быстро ознакомитесь с большим количеством кода. Самое главное, вы не будете тратить время, пытаясь понять чужой код, ведь это является сложным и трудоемким процессом.
Соблюдая правилам 2 и 3, вы увеличиваете вашу долю захвата, избегая наиболее трудоемких частей написания хорошего кода. Это жизненно важно, чтобы вы контролировали больше кода, чем остальные участники команды вместе взятые.
Кроме того, есть и социальные выгоды работы подобным образом:
Выгода 1: все увидят, как быстро вы пишите огромные куски кода и начнут уважать вас – особенно ваш босс, который не имеет другого критерия, чем оценивать вас по частоте и объему вносимых изменений.
Выгода 2: Хоть вы и вносите множество новых ошибок, все равно пройдут еще несколько месяцев, перед тем как они вылезут, а к тому времени вы уже приобретете репутацию программиста-эксперта. И даже сейчас Вы можете получить выгоду от всех этих багов во второй раз, ведь вы же можете исправить эти проблемы быстрее, чем кто-либо другой. Ваши коллеги будут затрачивать в 10 раз больше времени, по сравнению с вами, для отслеживания каждой из этих проблем. Все чаще они будут приходить к вам за советом или помощью, потому что именно вы написали этот кусок кода. Будьте дружелюбным, скромным, помогайте с удовольствием. Вы определите место ошибки очень быстро. Ваша репутация великого Гуру будет расти день ото дня.
Относитесь к этому процессу, как будто это игра в стратегию реального времени. Карта мира – это код вашего проекта. Участки кода, которыми владеете вы – это ваши ресурсы, а чужой код – производит ресурсы другим. Но, главный ваш ресурс – это ваша десятикратная эффективность, так как вы в 10 раз продуктивней при работе, как с вашим собственным кодом, так и с чужим. Ваша десятикратная продуктивность улучшает вашу репутацию, которая является валютой в Игре.
Очевидно, что если вы владеете очень небольшим участком кода, вам не удастся поднять большое количество репутации, поскольку большую часть времени вы будете работать с чужим кодом такими же темпами, как и любой другой. Пришло время изменить эту ситуацию.
Правило 1 – это основа вашей экономики. Вы станете суперзвездой, если захватите наибольший участок кода, больший, чем у кого-либо еще. Создавая новый код, или преобразуя чужой код в ваш собственный – вы инвестируете в экономику, ведь каждый участок вашего кода генерирует вам производительность и репутацию.
Правило 2 — это агрессивность. Захватывайте владения других людей и изменяйте их код так, чтобы он был понятен вам. Пусть люди видят, что вы затрагиваете много кода — это хорошо для вашей репутации. Однако вы должны быть осторожными при переходе в атаку. Переписывание кода влечет за собой возможное урезание репутации, но об этом позже.
Правило 3 — это защита. Затрудняйте другим людям работать с вашим кодом или исправить в нем ошибки. За каждый час, который они тратят на исправление ошибок вы инвестируете час на создание свежего кода или переписывания существующего чужого, тем самым расширяя границы вашего влияния.
Никогда не забывайте, что это все это делается ради получения репутации. Тут самое главное – не переусердствовать, иначе, вашей команде и менеджеру может показаться, что вы вредите проекту. Не менее важно сохранять хорошие отношения с вашими противниками – коллегами. Старайтесь всегда казаться вежливым, полезным и скромным. Ваша репутация определяет какое количество и какие части кода вы можете переписать под себя, не вызывая негативной реакции.
Для этого вы должны начать с малого, в самой ненавистной, уродливой области кода в проекте. Просто зайдите туда и перепишите там все, чтобы все стало понятным вам. Не беспокойтесь о всех тех ошибках, которые вы внесете. Люди будут благодарны за то, что вы такой смелый и достаточно дерзкий, чтобы бросить вызов старому коду проекта. Они согласятся с тем, что это необходимо сделать, и что исправление ошибок нового кода будет проще, чем поддержка старого.
Когда вы закончите – то обнаружите, что ваша репутация возросла. И вот теперь вы сможете переписать чуть менее отвратительные участки кода, без занудных вопросов о том, действительно ли это необходимо было сделать. В конечном итоге ваша репутация вырастит и станет настолько огромной, что вы сможете переписать любую часть основной функциональности приложений по своему усмотрению. К тому времени, вы будете знать гораздо больше об остальных частях системы, чем кто-либо другой, и будете допускать на удивление мало ошибок. Это обеспечит ваш статус Гуру.
Теперь вы – суперзвезда команды. Это завершение вашей игры.
Вы выиграли!
Постскриптум для наивных: Этот пост – легкая сатира на программирование в составе команды. Эти три правила – зло, хотя, несомненно, очень эффективны. Они принесут вред общему прогрессу проекта ради вашей собственной выгоды. Они не сделают вас лучшим программистом по сути, только по сравнению с остальной частью вашей команды. Вы, как я и многие другие, могли невинно делать нечто подобно этому в вашем прошлом, когда вы не знали, как делать это лучше. Теперь вы знаете.
Постскриптум для руководителей проектов: Если ваша обстановка соответствует Двум Фундаментальным Принципам, то ваши программисты будут играть в Игру, и ваш проект будет страдать. Меняйте правила. Убедитесь в том, что программисты признают и хорошо играют кодом друг с друга, для успешной работы небольших групп, которые решают большие проблемы. Переписывание кода, из-за появления ошибок приводят к появлению новых ошибок, из-за которых код будет опять переписан. И я не знаю хорошего способа избавиться от этого. И если вы знаете, то, пожалуйста, ради всех проектов во всем мире, оставьте комментарий!
И вы можете! Следуйте следующим 3-м простым правилам, и в течение 12 месяцев все это и многое другое будет вашим.
Правило 1: Пишите много кода. Вам нужно исправить небольшую ошибку на участке кода, написанного кем-то другим? Не теряйте времени, пытаясь понять код или мотивацию человека, создавшего его. Просто перепишите большую его часть, и сделайте, чтобы код работал так, как это удобно вам. Назовите это рефакторингом, если, вдруг, кто-то спросит.
Правило 2: Пишите код быстро. Затроньте наибольшее количество файлов, и не забудьте включить каждый из них в ChangeLog. Не беспокойтесь о случайном создании трудно находимых ошибок; они помогут вам в будущем, потому что их, на самом деле, трудно найти. Избегайте создания тривиальных ошибок.
Правило 3: Не тратьте время для документирование кода, или добавления небольших комментариев, объясняющих потенциальные ловушки, связанные с изменением нечетких участков кода. Вам это не нужно – вы пишете код.
Усердно следуйте этим трем правилам – и вы станете суперзвездой вашей команды в течение 12 месяцев. Выпишете их и приклейте на видном месте. Только не в офисе! А где-нибудь в скрытом от посторонних глаз месте. И повторяйте их каждый день, перед началом работы. Они могут показаться вам спорными, но поверьте мне, все это имеет очень глубокий смысл.
Вы задаете вопрос: откуда я знаю, что это работает? – Потому что я сделал это сам, и потому, что я видел, как это делают другие. Конечно, я не понимал, что придерживался Трех правил – в то время, я был молодым и наивным и думал, что я просто пытаюсь сделать все возможное для проекта. И только теперь, спустя много лет, опираться на мудрость и опыт, я могу вот так просто поделиться ими с вами.
Система 3-х Великих Правил Программирования основана на Двух Фундаментальных Принципах: техническом и социальном.
Технический принцип: Вы работаете в 10 раз продуктивней над вашим кодом, по сравнению с тем кодом, который писали не вы.
Каждый понимает свой собственный код лучше. Это часть вашей памяти, часть ваших соглашений — весть этот код соответствует вашим убеждениям. Вы знаете, как работает функция, которая называется X и знаете все тонкости ее работы. Вы смотрите в класс Y, чтобы найти вашу функциональность и, конечно же, она там есть. Даже если вы находитесь в нижней части файла, вы прекрасно знаете какой код находиться сверху. Все эти мелкие детали понятны вам. Теперь вам не нужно так беспокоиться о случайных побочных эффектах, когда вы что-то изменили, потому что вы помните о тех местах, которые были немного рискованными и интуитивно знаете, где вы можете писать код небрежно, а где – нет.
Короче говоря: если вы написали код, у вас есть почти идеальная модель кода в вашей голове, потому что это то, что вы использовали, чтобы написать его.
Социальный принцип: то, насколько хороши вы в программировании, судят по тому, сколько строчек кода вы написали, насколько быстро вы можете завершить необходимые фичи и пофиксить критические баги, и насколько ваше понимание сути дела необходимо для решения проблем.
Эти два принципа определяют пространство задачи – или, как мы называем это – Игру. Вы победите, если улучшите свою репутацию суперзвезды до уровня гуру. Чтобы улучшить свою репутацию, вам нужно увеличить скорость, с которой вы пишете код, исправляете ошибки и помогаете другим. Технический принцип говорит нам о том, как достичь этого — работайте в своем собственном коде как можно больше. Именно так, захватывайте как можно большую часть проекта своим собственным кодом.
Система 3-х правил – это безупречная стратегия для достижения этой цели.
Следуя правилу 1, вы быстро ознакомитесь с большим количеством кода. Самое главное, вы не будете тратить время, пытаясь понять чужой код, ведь это является сложным и трудоемким процессом.
Соблюдая правилам 2 и 3, вы увеличиваете вашу долю захвата, избегая наиболее трудоемких частей написания хорошего кода. Это жизненно важно, чтобы вы контролировали больше кода, чем остальные участники команды вместе взятые.
Кроме того, есть и социальные выгоды работы подобным образом:
Выгода 1: все увидят, как быстро вы пишите огромные куски кода и начнут уважать вас – особенно ваш босс, который не имеет другого критерия, чем оценивать вас по частоте и объему вносимых изменений.
Выгода 2: Хоть вы и вносите множество новых ошибок, все равно пройдут еще несколько месяцев, перед тем как они вылезут, а к тому времени вы уже приобретете репутацию программиста-эксперта. И даже сейчас Вы можете получить выгоду от всех этих багов во второй раз, ведь вы же можете исправить эти проблемы быстрее, чем кто-либо другой. Ваши коллеги будут затрачивать в 10 раз больше времени, по сравнению с вами, для отслеживания каждой из этих проблем. Все чаще они будут приходить к вам за советом или помощью, потому что именно вы написали этот кусок кода. Будьте дружелюбным, скромным, помогайте с удовольствием. Вы определите место ошибки очень быстро. Ваша репутация великого Гуру будет расти день ото дня.
Относитесь к этому процессу, как будто это игра в стратегию реального времени. Карта мира – это код вашего проекта. Участки кода, которыми владеете вы – это ваши ресурсы, а чужой код – производит ресурсы другим. Но, главный ваш ресурс – это ваша десятикратная эффективность, так как вы в 10 раз продуктивней при работе, как с вашим собственным кодом, так и с чужим. Ваша десятикратная продуктивность улучшает вашу репутацию, которая является валютой в Игре.
Очевидно, что если вы владеете очень небольшим участком кода, вам не удастся поднять большое количество репутации, поскольку большую часть времени вы будете работать с чужим кодом такими же темпами, как и любой другой. Пришло время изменить эту ситуацию.
Правило 1 – это основа вашей экономики. Вы станете суперзвездой, если захватите наибольший участок кода, больший, чем у кого-либо еще. Создавая новый код, или преобразуя чужой код в ваш собственный – вы инвестируете в экономику, ведь каждый участок вашего кода генерирует вам производительность и репутацию.
Правило 2 — это агрессивность. Захватывайте владения других людей и изменяйте их код так, чтобы он был понятен вам. Пусть люди видят, что вы затрагиваете много кода — это хорошо для вашей репутации. Однако вы должны быть осторожными при переходе в атаку. Переписывание кода влечет за собой возможное урезание репутации, но об этом позже.
Правило 3 — это защита. Затрудняйте другим людям работать с вашим кодом или исправить в нем ошибки. За каждый час, который они тратят на исправление ошибок вы инвестируете час на создание свежего кода или переписывания существующего чужого, тем самым расширяя границы вашего влияния.
Никогда не забывайте, что это все это делается ради получения репутации. Тут самое главное – не переусердствовать, иначе, вашей команде и менеджеру может показаться, что вы вредите проекту. Не менее важно сохранять хорошие отношения с вашими противниками – коллегами. Старайтесь всегда казаться вежливым, полезным и скромным. Ваша репутация определяет какое количество и какие части кода вы можете переписать под себя, не вызывая негативной реакции.
Для этого вы должны начать с малого, в самой ненавистной, уродливой области кода в проекте. Просто зайдите туда и перепишите там все, чтобы все стало понятным вам. Не беспокойтесь о всех тех ошибках, которые вы внесете. Люди будут благодарны за то, что вы такой смелый и достаточно дерзкий, чтобы бросить вызов старому коду проекта. Они согласятся с тем, что это необходимо сделать, и что исправление ошибок нового кода будет проще, чем поддержка старого.
Когда вы закончите – то обнаружите, что ваша репутация возросла. И вот теперь вы сможете переписать чуть менее отвратительные участки кода, без занудных вопросов о том, действительно ли это необходимо было сделать. В конечном итоге ваша репутация вырастит и станет настолько огромной, что вы сможете переписать любую часть основной функциональности приложений по своему усмотрению. К тому времени, вы будете знать гораздо больше об остальных частях системы, чем кто-либо другой, и будете допускать на удивление мало ошибок. Это обеспечит ваш статус Гуру.
Теперь вы – суперзвезда команды. Это завершение вашей игры.
Вы выиграли!
Постскриптум для наивных: Этот пост – легкая сатира на программирование в составе команды. Эти три правила – зло, хотя, несомненно, очень эффективны. Они принесут вред общему прогрессу проекта ради вашей собственной выгоды. Они не сделают вас лучшим программистом по сути, только по сравнению с остальной частью вашей команды. Вы, как я и многие другие, могли невинно делать нечто подобно этому в вашем прошлом, когда вы не знали, как делать это лучше. Теперь вы знаете.
Постскриптум для руководителей проектов: Если ваша обстановка соответствует Двум Фундаментальным Принципам, то ваши программисты будут играть в Игру, и ваш проект будет страдать. Меняйте правила. Убедитесь в том, что программисты признают и хорошо играют кодом друг с друга, для успешной работы небольших групп, которые решают большие проблемы. Переписывание кода, из-за появления ошибок приводят к появлению новых ошибок, из-за которых код будет опять переписан. И я не знаю хорошего способа избавиться от этого. И если вы знаете, то, пожалуйста, ради всех проектов во всем мире, оставьте комментарий!
комментарии (128)
одному мне эта статья показалось правилом писания быдло-кода, не?
1) мотивирует людей писать понятный код
2) можно выявить бока на ранней стадии (еще даже до тестирования)
3) происходит дополнительный обмен видением продукта/реализации
хабр жесток к тому, что не понимает. пэтому лучше ссылаться на МакКоннелла и адептов магии, которые подсчитали, что ревью кода помогает выявлять едвали ли не больше ошибок, чем тестирование. да ещё плюс то, что все будут понимать, как работает код.
к сожалению, три правила из топика, многие поддерживают и исполняют даже не осознанно.
писать нужно в едином стиле.
понятия не имею что есть review и какое это имеет отношение к данной статье!
В конце правильно что расписали суть, а иначе было б совсем грустно.
в основном всё понятно из длинных, говорящих за себя названий переменных, методов и форматирования.
мне нравится, когда код — сам себе комментарий.
Тем не менее это не исключает необходимость документирования функций (JavaDoc, ASDoc).
По мне так лучше написать:
public User getUserByLogin(String login)
чем
public User a(String s) //этот метод принимает параметром логин пользователя и возвращает найденного пользователя с таким логим
Гораздо короче и понятнее:
/**
* jdoc
*/
public User getUser(String login) {… }
Когда пишешь оптимизированный код или хитрожопый алгоритм,
отсутствие комментов в блоке кода недопустимо
Также входные выходные параметры тем более
нужно комментить, особенно если поведение
функции меняется от значения аргументов.
Я пишу полотна кода на SIMD интринсиках.
Потому что он работает в 10-20 раз быстрее
чем это сделает компилятор.
Выглядит как марсианская язык, конечно
но задача — обеспечить требуемое (максимальное) быстродействие.
С другой стороны никто туда не лезет.
2) Какой смысл в более мощном оборудовании,
если не используешь возможности существующего
хотя бы процентов на 20.
3) Это не мучение, а недетский такой фан, и
я им готов и бесплатно заниматься.
И только тут понял, что нужно было дочитать до конца :)
Если человек пишет для себя — думаю, он будет делать всё качественно.
Исходя из этого надо или хорошо платить программистам (при этом увольняя «вечных лентяев») либо (а лучше не «либо», а «вместе с этим») мотивировать сотрудников их важностью в проекте, их долей в проекте и так далее. В идеале — раздать всем ключевым сотрудникам небольшой процент акций компании, тогда они будут чувствовать себя не нанятыми сотрудниками (которых можно всегда уволить в 1 день), а совладельцами (пусть и с очень небольшой долей, но всё же).
А вообще я к середине статьи тоже был в шоке, но все же добрался до P.S.
Линус Торвальдс
а эти три правила для рабочих лошадок,
посему они и не сделают из вас гения кода
копипаст бывает тупой, а бывает вдумчивый.
без копипаста все бы ездили на персонально хэндмэйдовских велосипедах,
долго, зато своё
Ведь именно HP придумали то самое начало, которое породило компании Apple и Microsoft))
Предлагаю вынести это в самое начало статьи, чтобы не сбивать с мысли программистов-новичков)
Читал с умилением) Спасибо, автор!
А вот если большой разницы в уровне нет — то лучше отпинать того, кто сделал ошибку, пусть сам ищет — это будет в 10 раз эффективнее :)
А вот представьте себе, что все программеры софтварных компаний сегодня прочитают эту заметку и последуют ей одновременно =)
Будет огромное количество изменений, нового кода. Будут убраны старые баги и добавлены новые. Менеджеры проектов которые не прочтут эти правила, глядя на всё это, будут поначалу в шоке, а затем поймут, что стабильный код никто из программеров не заинтересован поддерживать, так как это не приносит славы, денег, власти (выбрать одно из трёх).
Ко мне приходят. Знаете, как надоедает порой? Поработать спокойно не дают! Осторожней с желаниями — они могут исполниться =)
на самом деле из-за таких людей, очень тяжело работать в команде. хорошо что таких всего 1%
> новых ошибок, из-за которых код будет опять переписан.
> И я не знаю хорошего способа избавиться от этого.
А тестирование уже отменили?
Кардинально переписывать некоторые куски кода иногда оправданно. Важно понять, какое ты после этого получишь преимущество. К примеру, если у вас корявый менеджер плагинов, а переписывание его снизит трудозатраты на создание нового плагина в среднем на два человеко-дня, и вы планируете создать несколько десятков плагинов, то, возможно, стоит переписать его и перевести на новый интерфейс все существующие плагины. Главное не переписывать ради переписывания, должно быть экономическое обоснование. И переписываемый код должен быть хорошо покрыт тестами.
по теме. согласен насчет того, что большие коммиты хочется рассмотреть подробнее. Более мелкие и детально расписанные вещи воспринимаются легче, да и для того, кто коммитит проще описать мелкие изменения, чем когда объем кода большой. К тому же возрастает вероятность того, что где-то какие-то изменения забыл описать, а потом начинаются проблемы.
плюсануть не могу (карма закончилась :)), потому хотя бы на словах примите признание :)
Респект!
Дальше не читал.
а) Что за х*йло это писало?..
или, когда код документирован, форматирован, понятные названия единиц
б) Ай да я! Ай да маладец!
Большинство людей неосознанно проходят через этот этап «быть лучшим на фоне кого-то», и если вы уже осознали, что прошли его, осознали что «быть на фоне» — это вредно, то вы растете в личностном и профессиональном плане.
Многие люди пройдут этот этап и без прочтения топика. Лучшие – пойдут дальше.
P.S. Хорошо еще увидеть статью о балансе сил зла и добра, с последующими экономическими (с точки зрения работы в коллективе) выкладками.
P.P.S Сколько накипевшего-кипятка (сорри за тавтологию) вылилось в статью и перевод. )))))))))
Если 1% людей звёзды, то это не значит, что 100% ими могут стать.
Стандартный развод «Как Стать Миллионером За 5 Шагов». Обычно миллионерами становятся афтары таких изысков.
По сути:
1. Пишите много кода. Звёзды как раз гениальны и знают, как писать не много кода. Много пишут как раз менее умные люди, т.к. не знают, как писать мало.
2. Пишите код быстро. Думать людей учат затем, чтобы косяков меньше было. И скорость из классического треугольника обычно чуть менее чем полностью убивает качество. А это не звёздный подход.
3. Не тратьте время для документирование кода. Это подход людей недальновидных. Даже если код потом будет сопровождать автор, через год всё уже забывается и надо понимать. Опять же читайте Чехова (т.е. МакКонела), который писал, что код чаще читается, чем пишется.
Кароче все три правила — УГ.
Я зашёл и ни намёка не увидел, что это несерьёзно.
А т.к. хабр — саморегулируемое сообщество, то здесь всякое бывает.
Поэтому такое лучше как-то явно сходу обозначать.
Завидую :) Я, видимо, стала настолько недоверчива, что с первых строк почувствовала иронию.
Ну какой программист после нескольких лет работы в команде поверит в то, что не комментировать код полезно? ;)
второе правило — читать до конца.
третье правило — читать комментарии.
1. Едите его.
2. До конца его съедаете.
3. И ещё мнения других посетителей слушаете.
Concise, SCANNABLE, and Objective: How to Write for the Web
Автор — доктор американских наук по юзабилити.
Если статья написана неумелым сатириком, то это не означает, что читатель должен дочитывать.
Когда пишут непонятно с первых строк — это говорит о неумении мысли грамотно выражать и доносить до товарищей.
Так что если я вижу УГ, то я говорю, что это УГ, а не трачу своё время на полное его поглощение и не спрашиваю трусливо три раза у соседей: «А правда это УГ?»
Пипец, из-за УГ рамс…
если ничего не посоветовали, полностью знакомлюсь с меню, обычно дважды, первый — ознакомительный, чтобы знать что есть, второй раз уже выбирая.
наверное из-за внимательности мне говно ни разу и не накладывали.
да ладно, вам, вы немножко обложались не дочитав. нехорошо получилось, что пока я ждал стандартных пять минут, вам напомнили об этом до меня.
С этого ржал в голос.
Статья, действительно, — зло! Но, по сути, все ведь так и есть.
1. Пишите много постов. Не обязательно IT тематики, главное чтобы было многа букаф и картинок.
2. Комментируйте всё, что видите.
3. Следите за своим рейтингом. Принимайте всегда сторону большинства.
P.S. Простите, вырвалось :)
Когда чужой код ужасен по мнению всей команды, то нужно всем коллективом (а не в одно лицо) сесть и переписать с корнями (если начальство конечно санкционирует и будет свободное/лишнее время на рефакторинг).
А дальше по ходу текста становилось понятно, что это замечательное саркастическое чтиво ;)
Прочтение «постскриптума», вызвало облегчение и улыбку.
Если у программиста, чтение данного материала вызывало лишь негодование, сомнение или даже шок, а не мысли о замечательном и тонком чувстве юмора у автора, то ему следует задуматься :D (имхо, конечно)
Теперь хоть увольняйся, я вскрыт.
А вообще хоть и с юмором, но о правде, себя в тексте увидел, да….
комменты тоже будут мои, да и вообще хабр — это для 99% обычных, так что я сделаю свой хабр с блэкджеком и шлюхами =)
?
В каждой шутке есть доля правды.
пишите говнокод господа, а потом когда вас признают увольтесь нафиг ;)
Уж слишком красочно всё разрисованно. Я считаю, что у каждого человека должен быть свой подход к делу. И пользоватся вещами «Следуй трём Великим правилам и будешь крутым» для достижения успеха совсем недостаточно.
И мне интересна одна ситуация) вот предствате два таких великих 10x Coding Speed программиста работают в одной команде и каждый из них «звезда», и у каждого свой стиль программирования и соглашения, и оба они сидят и фигачат дофига кода в своём стиле, а потом берут и переписывают код друг друга сначала кусками(рефакторят), что из этого получится?)