Комментарии 37
Ну а так так многие люди сочли бы разумной стратегией работы с «крайне неуравновешенным и жестоким человеком, который знает код от домофона и умеет открывать замки» отказ от такой работы, то это правило преобразуется до еще более простого — не пишите код.
Пишите код так, будто бы его будет читать крайне неуравновешенный и жестокий человек, который знает где вы живёте, знает код от домофона и умеет открывать замки
Если вдуматься, то ничего хорошего в этом совете нет.
Всегда бесил этот «перл» своей бессмысленностью. Псевдоостроумная версия фразы «Пишите код хорошо», которая не дает ровным счетом никакого совета, как именно надо писать.
Стивен стал «более хорошим программистом», а его подруга Света — более лучше одеваться.
Если на то пошло, то «хороший» — это не сравнительная форма, поэтому «более хороший» — вполне легальная конструкция. «Лучше» — это сравнительная форма от «Хорошо» и это, вообще-то, наречие, так что здесь двойной промах.
Да-да, я еще подумал об этой фразе и понял, что не прав. Но все это предложение с более хорошим как-то режет слух. Похоже, что только мне.
В оригинале там It has already helped me be a better programmer. Он уже помог Стивену стать лучше в программировании, как вариант.
В оригинале там It has already helped me be a better programmer. Он уже помог Стивену стать лучше в программировании, как вариант.
не, не вариант, совсем колхозно смотрится
Я не понимаю… ЗАЧЕМ пытаться сохранить конструкцию максимально близко к оригиналу? Можно же перефразировать:
Благодаря этому списку Стивен достиг новых высот в программировании.
или
С помощью этого списка Стивен улучшил свой навык программирования.
Благодаря этому списку Стивен достиг новых высот в программировании.
или
С помощью этого списка Стивен улучшил свой навык программирования.
1. Ненужная «художественность» 2. Опять кривое калькирование
Единственный нормальный вариант «Стивен стал лучше программировать/писать код». «Лучше в программировании» — кривость по типу «сумки от Армани»
Единственный нормальный вариант «Стивен стал лучше программировать/писать код». «Лучше в программировании» — кривость по типу «сумки от Армани»
К.О. говорит, что это дословная цитата из одного видео.
![[спасибо, Капитан Очевидность]](https://habrastorage.org/getpro/habr/comment_images/a24/d62/a70/a24d62a700d1c9476c531ff46c0d9d6d.png)
О, вот ещё одному человеку нечего делать, как было мне.
После прочтения комментария на который я отвечал, мне показалось, что его автор протестует против использования «более лучше одеваться». Спустя некоторое время я конечно понял, что протест был против сравнения «стал более хорошим программистом» с «более лучше одеваться», но комментарий менять было уже поздно. На вашей картинке КО можно заменить на Слоупока.
Наш препод на 1м курсе любил говорить примерно так: «когда пишете код, пишите его так, чтобы ваш сосед мог не только сдуть его у вас, но понять и объяснить каждую строчку, каждую функцию и процедуру...».
При этом, в универе я делал (из эгоистичности) делал ровно обратное…
При этом, в универе я делал (из эгоистичности) делал ровно обратное…
… а еще позже я понял что чтение кода это такой же навык как и написание, поэтому учитесь не только писать код но и читать любой даже самый самый плохой…
Часто чтение чужого кода, да и перечитывание своего занимает достаточно много времени. Поэтому понятно написанный код и умение читать код могут значительно увеличить производительность труда. (Капитан Очевидность гордился бы мной )
Черт, это же неизведанная область!
Сейчас столько всего написано о том, как правильно писать хороший код, и практически ничего о том, как читать плохой. Срочно организовать курсы по чтению плохого кода и срубить денег.
Сейчас столько всего написано о том, как правильно писать хороший код, и практически ничего о том, как читать плохой. Срочно организовать курсы по чтению плохого кода и срубить денег.
Периодически встречаю подобные вещи и удивляюсь — зачем об этом говорить, если оно и так понятно?
Ан нет, всё время забываю, что люди не такие, как я, что все разные и думают по разному.
Согласен с правилами, спасибо за статью.
Ан нет, всё время забываю, что люди не такие, как я, что все разные и думают по разному.
Согласен с правилами, спасибо за статью.
Аналогично. Я думал, что заповеди будут гораздо более жесткими. А так, если кто-то нарушает даже это — то ему следует задуматься, подходит ли его характер к выбранной профессии вообще.
Тем не менее сама идея верная. Думаю, что заповеди надо ужесточать и добавить к ним следующее:
1) Если вам нужна библиотека, и вы решаете, что лучше: взять готовую или написать свою — берите готовую. Даже если она хуже, чем та своя, которую вы бы написали. Вы на этом сэкономите драгоценное время, которое может стать решающим в конкурентной борьбе вашего бизнеса или бизнеса вашего работодателя;
2) Действие п.1 сохраняется даже в случае, если готовая библиотека стоит серьезных денег. Решение должно приниматься ответственным руководителем предприятия. Если вы простой разработчик — оставьте решение директору. Если вы одиночка и сам себе директор — считайте выгоду по деньгам и рискам, умножая в 2-3 раза оцениваемые временные затраты, а не исходя из тщеславия.
3) Соблюдайте стандарты. Не изобретайте велосипед в виде форматов файлов, интерфейсов компонентов, протоколов обмена и т.п., если есть стандартные решения.
Тем не менее сама идея верная. Думаю, что заповеди надо ужесточать и добавить к ним следующее:
1) Если вам нужна библиотека, и вы решаете, что лучше: взять готовую или написать свою — берите готовую. Даже если она хуже, чем та своя, которую вы бы написали. Вы на этом сэкономите драгоценное время, которое может стать решающим в конкурентной борьбе вашего бизнеса или бизнеса вашего работодателя;
2) Действие п.1 сохраняется даже в случае, если готовая библиотека стоит серьезных денег. Решение должно приниматься ответственным руководителем предприятия. Если вы простой разработчик — оставьте решение директору. Если вы одиночка и сам себе директор — считайте выгоду по деньгам и рискам, умножая в 2-3 раза оцениваемые временные затраты, а не исходя из тщеславия.
3) Соблюдайте стандарты. Не изобретайте велосипед в виде форматов файлов, интерфейсов компонентов, протоколов обмена и т.п., если есть стандартные решения.
Программирование — не всегда бизнес. Ваши «заповеди» касаются чисто бизнеса и мало имеют отношения к программированию как таковому.
Профессиональные программисты, по определению, зарабатывают этой деятельностью себе на жизнь. Они прямо или косвенно продают результаты своего труда другим людям, а не только пользуются ими сами. А где есть продажа — там есть рынок. И там есть бизнес. Игнорировать его законы — это путь к неприятностям либо для себя, либо для работодателя.
Даже если вы пишете программу исключительно для собственного использования — то приведенные в статье и добавленные мной принципы тоже верны. Они позволят вам быстрее получить результат с минимальными затратами и получить ценный опыт, применимый в будущем.
Ну, а если вы занимаетесь любительским программированием ради самого процесса — то там, конечно, никаких ограничений нет. Ваяйте в свое удовольствие что угодно и как угодно. Но я бы не сказал, что любительское программирование в настоящее время преобладает над профессиональным. Все-таки больше программ (и количественно, и качественно) разрабатывается профессионалами. Поэтому ваша фраза: «мало имеют отношения к программированию как таковому» не верна.
Даже если вы пишете программу исключительно для собственного использования — то приведенные в статье и добавленные мной принципы тоже верны. Они позволят вам быстрее получить результат с минимальными затратами и получить ценный опыт, применимый в будущем.
Ну, а если вы занимаетесь любительским программированием ради самого процесса — то там, конечно, никаких ограничений нет. Ваяйте в свое удовольствие что угодно и как угодно. Но я бы не сказал, что любительское программирование в настоящее время преобладает над профессиональным. Все-таки больше программ (и количественно, и качественно) разрабатывается профессионалами. Поэтому ваша фраза: «мало имеют отношения к программированию как таковому» не верна.
Создавать продукт и продавать его — две разные профессии. Обычно программист продает не результат труда, а труд.
Труд, который не приносит результатов, никому не нужен. Поэтому продается только тот труд, который их приносит — это раз. Во-вторых, некоторые программисты продают именно результаты труда (готовые продукты). В-третьих, если фирма, нанимающая программиста, получает прибыль за счет продажи его разработок — то речь идет о косвенной продаже результатов, о которой я в комментарии упомянул. Это справедливо и для случаев, когда программист разрабатывает продукты сугубо для внутреннего использования работодателя, если эти продукты как-то влияют на получение работодателем прибыли или грантов.
Цель чего-либо — конечный продукт, а программирование просто инструмент.
И если слишком долго думать над эстетикой того, как молотком стукнуть по гвоздю, а может молоток стоит предварительно покрасить в желтый а гвоздь в красный, чтобы лучше видеть, или сперва просверлить тонкую дырочку, чтобы забить с одного удара, то конечная цель уже не видна за процессом. Из-за чего мы видим множество отличных, но но незавершенных или не взлетевших проектов, которых обошли менее щепетильные в выборе инструмента конкуренты.
В конечном счете, вся цель хорошего кода в в 90% заключается в том, чтобы сделать его дешевле в долгой перспективе.
И если слишком долго думать над эстетикой того, как молотком стукнуть по гвоздю, а может молоток стоит предварительно покрасить в желтый а гвоздь в красный, чтобы лучше видеть, или сперва просверлить тонкую дырочку, чтобы забить с одного удара, то конечная цель уже не видна за процессом. Из-за чего мы видим множество отличных, но но незавершенных или не взлетевших проектов, которых обошли менее щепетильные в выборе инструмента конкуренты.
В конечном счете, вся цель хорошего кода в в 90% заключается в том, чтобы сделать его дешевле в долгой перспективе.
П1. весьма спорный (если код не opensource или не крупной фирмы типа Oracle). На эти грабли неужели не наступали? Нужно сделать мелкое изменение или найден критичный баг, а производителя уже нет или он вас игнорирует или запрашивает безумные деньги за изменение/исправление бага… и т.д. и т.п.
А соотношение кода, например, 1/10 (1- стронняя библиотека, 10 — ваш код.)
Во многих случая, для критичный сервисов, которые будут развиваться, лучше сделать свою реализацию и изобрести свой велосипед.
А для не критичных или законченных продуктов… ну зачастую дешевле и проще взять готовое.
Так что не стоит из этого делать догму.
А соотношение кода, например, 1/10 (1- стронняя библиотека, 10 — ваш код.)
Во многих случая, для критичный сервисов, которые будут развиваться, лучше сделать свою реализацию и изобрести свой велосипед.
А для не критичных или законченных продуктов… ну зачастую дешевле и проще взять готовое.
Так что не стоит из этого делать догму.
Если в проекте используется десятка два сторонних библиотек, то в 2-3 из них обязательно найдутся баги. Обычно просто неприятные, реже — критичные. Но про остальные библиотеки вы даже не вспомните — все время существования проекта они будут просто работать. Но в памяти останутся только библиотеки с багами.
Стороннюю библиотеку нужно брать всего лишь в двух случаях:
1. Если вы можете сами написать ее — значит у вас займет меньше времени исправить готовую библиотеку, чем написать полностью свою.
2. Если вы не можете сами написать ее — значит в написанной с нуля библиотеке будет больше ошибок, чем в уже готовой.
1. Если вы можете сами написать ее — значит у вас займет меньше времени исправить готовую библиотеку, чем написать полностью свою.
2. Если вы не можете сами написать ее — значит в написанной с нуля библиотеке будет больше ошибок, чем в уже готовой.
«Критикуйте код, а не людей. Будьте добры к людям, но не к коду»
Когда человек в стопятьсотый раз пишет спагетти становится очень трудно сохранять доброту
Когда человек в стопятьсотый раз пишет спагетти становится очень трудно сохранять доброту
0. Удаляйте! Лучший код — несуществующий код.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
10 заповедей программирования без эго