Советы для джуниоров: формируем хорошие привычки

[berezuev]

1. Делайте обзор технологий как можно чаще

С одной стороны совет полезный, с другой… Джуны на то они и джуны, что начитаются про новый awesome super fast фреймворк, который перестанут поддерживать сразу после 1-й версии, и потом бегают, в проект это пытаются пропихнуть.

4. Никогда не забывайте писать комментарии к коду

А если в проекте по-умолчанию код не комментируется?

5. Исцели себя сам: рефакторинг

Если джун может сам провести рефакторинг, по своей инициативе, точно ли он джун?

Во всем остальном, повторение одного и того же в 101-й раз.
Всю мораль можно сжать в 3 строки:
1. Постоянно учись (книги, статьи, конференции, чужие исходники)
2. Пиши код
3. Работой с теми, кто сильнее тебя в профессиональном плане

[Aquahawk]

/*
* Set the name of the instancied planet
* var STRING $new_name Contain only a string to name the planet
*/
function set_name(string $new_name) {
$this->name = $new_name;
}

Объясните мне зачем? Просто, какой в этом смысл?

[peresada]

Само комментирование функции не имеет особого смысла (в данном случае), но добавление `@param`, `@return` и т.д. (а особенно `@throw`) довольно сильно помогают в разработке, так как IDE все это дело читает и толково подсказывает. С другой стороны, в php 7+ добавляется элементарная типизация аргументов и возврата функции, что тоже читается IDE и нивелирует элементарные param и return в которых не нужно подробно расписывать, что это за аргумент. Короче говоря, элементарный PHPDock полезен, чтобы проще было ориентироваться, однако его полезность уменьшается за счет развития IDE в рамках PHP7+

Кроме того, в том же PHPStorm есть всякие приколы типа «С зажатым CTRL и кликом по методу открывается код этого метода», так вот они работать не будут, если объект вызван неявно, но если перед этим задать `/* var SomeClass $classObject */` то IDE так же его увидит и фича, описанная выше будет работать.

[berezuev]

Не надо путать комментарии и аннотации phpdoc…

Хм, интересно, как часто хабраюзерам var, param и return на почту сыпятся уведомления об упоминании в комментариях?)

[return]

Очень часто, даже из блоков с кодом, хабор не хочет чинить даже это

[return]

Всех обманул, похоже что блоки с кодом починили, я просто давно не ходил сюда :}
Но в любом случае, не все оформляют код в специальный блок (гореть им в аду, независимо от нотификаций)

[sfi0zy]

разобрал множество сайтов на составляющие и таким образом изучил, как талантливые разработчики их выстроили… Awwwards, FWA, CodePen

Только тут есть одна маленькая-маленькая деталь: зачастую в исходниках сайтов, которые попадают в разные модные каталоги, творится такая дичь, что смотреть страшно. Сплошные костыли, странный выбор инструментов, какие-то идеи, которые «вроде работают», но никто уже не помнит почему они работают, интуитивно подобранные коэффициенты и математические функции, какая-то мешанина из копипасты и полное отсутствие архитектуры. Это следствие того, что такие вещи обычно не предполагают дальнейшую поддержку, многое придумывается в процессе экспериментов и полученные решения никто нормально не оформляет ибо это не выгодно.

Поэтому посоветовал бы начинающим не только смотреть, как другие что-то сделали, но и думать иногда своей головой. Не стоит бездумно тащить всю эту дичь в свои проекты и считать все это «единственно правильным» или «к чему нужно стремиться». Известные или талантливые разработчики тоже могут говнокодить.

[immaculate]

Иногда начинает казаться, что совет писать комментарии — из разряда вредных. Умный человек сам поймёт когда, как, и где писать комментарии. А джуниоры начинают писать мусор наподобие:

# Импортировать библиотеку
import requests

# Отправить уведомление
def send_notification()

# Увеличить значение переменной
i += 1

[peresada]

## Комментируем действие
# Увеличить значение переменной
i += 1
# Теперь значение переменной i на 1 больше
# @todo Написать тест на корректность увеличения переменной на единицу

[Madeas]

Странно, что в статье не упомянули behance и dribbble, а ведь это отличные мотиваторы и вдохновляторы, в которых, помимо вдохновения чужими, можно разместить и свое портфолио с работами. На счет второго конечно посложнее, в плане полноценного участия, но есть простое решение.

[Romario21]

1) Делайте самостоятельно, как можно больше законченных программ, которые имеют практическую ценность
2) Думайте своей головой и фильтруйте советы.
3) Не надо усложнять
4) Не существует исключительных(крутых) технологий
5) Не фетишируй на свой код, ибо через год ты будешь смотреть на него по другому
6) Не зазнавайся, крутых программистов не существует)
7) Хорошая программа — это только та программа, которая зарабатывает деньги!!!

[boblenin]

Все кроме рефакторинга — сомнительной пользы советы. Но и он без TDD или хотя бы серьезного юнит тестирования — сомнителен.

[DistortNeo]

4. Если ваш код требует комментариев, значит, это плохой код. Перепишите его.

[KonstantinSpb]

Относительно стеков технологий, регулярно смотрю
1. stackshare.io
2. www.cncf.io/projects
3. landscape.cncf.io/format=landscape